Frequently-Asked Questions

We don’t know — for any site.

One reason we don’t know is because it’s difficult to detect assistive technology with a web server – and it’s arguably unethical to determine who’s disabled based on whether they use assistive technology.

Another reason we don’t know is because the definition of “disabled” depends on who you’re asking and in what situation. There are a large number of models of disability defining who is disabled, and to what extent. If we start to define who in our audience is disabled, we find ourselves in muddy water quite quickly.

The third reason is because when our website has inaccessible code, we’re actively blocking potential disabled users from visiting the site. That forms a vicious cycle: we don’t have disabled users because we don’t code for disabled users because we don’t have disabled users. Nicholas Steenhout illustrates this cycle in his article Why accessibility is good for business (according to my mechanic).

Ultimately, it doesn’t matter. If we’ve got a public presence on the web, providing access to as many customers as possible is not only ethical, it makes good business sense. If we’re providing services business-to-business, an accessible website ensures our customers don’t have to worry about whether their disabled staff members can do their jobs with our products. Section 508 requires accessibility to sell in the US federal vertical, and similar legislation at the local, state, and federal levels in many countries requires compliance.

In short, if even one disabled user is unable to use our site, we risk legal, social, and civil rights repercussions. Doing the right thing by making our sites accessible carries none of these risks.

First, because HTML markup is part of the content layer, and separating the presentation layer from the content layer aligns with the software design principle of separation of concerns.

Second, because semantic markup provides both humans and computers the ability to look at naked HTML and identify the purpose of the content – whether a content chunk is part of an article, or navigation, or the footer, for example. This makes it easier to understand the content. It makes the content’s purpose explicit instead of implicit.

Because the content’s purpose is explicitly stated, assistive technology can make better decisions on what to communicate to people with disabilities. For example, a screen reader can tell a user they’re entering a form, or what the headings on the page are.

Similarly, search engines are better equipped to prioritize content based on its role. This may seem like it wouldn’t matter for some sites or applications, but these days every site ends up with a federated search eventually. When semantic HTML is used, a search engine will provide much better results if the HTML makes sense to the crawlers.

Finally, semantically-written code is easier to maintain because it’s clear and standardized, and that helps everyone.

For more information, read Semantic HTML for Meaningful Webpages by Brevity and Sexy New HTML5 Semantics by Bruce Lawson at Smashing Magazine.

The following 2017 video also provides a great explanation.

First, here’s what the WCAG success criteria don’t mean:

• They’re not a measure of accessibility. One person I spoke to hypothesized that for a given problem X, A was the lowest level of accessibility to solve X, AA was the middle of the road level, and AAA was the most accessible. That person wanted to know why I didn’t just adopt the A solution for everything so that we could move on.
• They’re also not a measure of audience, although often they correlate with audience size. Pretty much everyone needs you to implement the A-level solitions, and many of the AAA-level solutions are most meaningful to small audiences such as “people who are D/deaf and need ASL translations”.

Here’s what the success criteria do mean:

For the entire set of guidelines, A-level guidelines are the absolute minimum an organization should do ¹ (presumably because they are both achievable and meaningful for a very large audience). AA-level guidelines are the middle, achievable and meaningful, but with not as much effort as AAA guidelines, which are meaningful for a smaller audience but more challenging to achieve ¹.

I tell people to think of level A as table stakes. If you’re not getting the A guidelines correct, your website, document, or app probably isn’t usable by anyone, much less by people with disabilities.

Level AA is not only the legal standard in most places (meaning you have to complete both A and AA) it’s the most achievable for a reasonable expense.

Level AAA is for the times when you know you have a niche audience that you need to ensure has access, but it’s also for standing out from the crowd. Some AAA guidelines are actually easy to achieve, especially if there’s a matching AA guideline that has exceptions that don’t apply to you.

When choosing what level to test, I recommend WCAG 2.1 AA, with the understanding that anytime you can pick up a AAA without significant effort, you should do it.

Conformance is the floor, not the ceiling.