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.