How Accessible Is Your Web Site?

Often times we are asked to determine to what percentage is our web site accessible. While this measurement helps us fill in a questionaire, in itself it does not allow us to learn much about the extent of accessibility. This article will explain why we should not measure accessibility in percentage and what other ways we can use to provide a more accurate estimate.

Examples

First let's look at two extreme, but often occurring problems to demonstrate how measuring the percentage of accessibility can be misleading.

Let's assume that a web application consists of 50 pages. With one exception, all pages are accessible, except the login page, which requires the user to type in a word from a picture (captcha), though even the rest of the page is accessible. In theory, this web application is more than 99 percent accessible. However, when people are not able to see the screen and have to rely on a screen reader they will not be able to use the application at all. For these people, the application is not accessible at all. One can say that we can just remove the captcha and it is ready to go, but what happens if some sort of a security measure has to be implemented. In order to solve the accessibility problem here while keeping the required functionality, much more effort will be required.

Another extreme example is when a web application mostly consists of data tables. It has no other functionalities, other than displaying and sorting immense data sets. The table headers, however, are not indicated. Therefore, all pages have a major accessibility problem, and one hundred percent of the pages have to be fixed. We might claim that this application is not accessible at all. The data sets, however, are generated by scripts, and the same script is used to generate all tables. Consequently, if we change the generation of the table headers, all of a sudden the entire web application will be accessible, and most likely it will not take more than a couple of keystrokes.

How to measure accessibility?

While the above examples demonstrate extreme situations, these scenarios are completely valid and do occur in many applications. In these cases, instead of providing the percentage of accessibility, it is much more valuable to assign other values to the measurement. For example, we can provide an estimate of how long it will take to fix the accessibility problems, then we can also assign cost estimates to it. Based on the first example, the fix is relatively complex. We need to find an accessible captcha solution, or we need to figure out a security measure to fulfill the functional requirements. Then, we need to implement the solution. In case of the second example, most likely we will have to change a couple of TD tags to TH tags and to rebuild the code, which could only be a matter of minutes. Providing such additional measures will be more helpful for a buyer, who is looking into hiring developers to make a product completely accessible, or when the buyer wants to purchase an accessible product to see when the product can be made accessible.

Another way of measuring accessibility is to apply the WCAG measurements. While in some countries this is not an official requirement, if such a requirement exists, it is surely closely related to the WCAG. Therefore, if we can establish a priority 1, 2 or 3 requirement based on WCAG 1.0, or a level A, AA or AAA conformance based on the WCAG 2.0, it will be much more informative for those who are in charge of purchasing accessible products.

In a few instances, pure metrics can also be informative, but only with an added description of accessibility. Let's assume that a web site is a picture gallery, containing one hundred pages. Each page contains ten pictures. All pictures are missing textual descriptions. In its current stage, the picture gallery is not considered to be accessible. However, each page will require the same amount of work, and by fixing one page, we get one percent closer to making the site accessible.

When describing the state of accessibility of a web site, there is another informative method, we can provide the buyers with a Voluntary Product Accessibility Template (VPAT). While this is not based on metrics, it will contain a thorough description of the web site from an accessibility point of view.

Solution

It is recommended to use all of the above methods to describe the accessibility of a product. The purpose is not to totally dismiss pure metrics, rather, to provide the buyers with extra explanation in order to make an informed decision. Once all this information is distributed, metrics will carry actual additional information.