Introduction to web accessibility

SeriesAccessible Web clock8 min read

What does it mean for a website to be accessible and how should web designer and web developer approach it?

At WWDC 2016, there was an excellent workshop led by Apple accessibility engineer Conor Hughes. Besides an update on upcoming accessibility enhancements in the Apple software, this session included an amazing example of an iOS app accessibility audit with clearly, precisely drawn set of steps to take. This inspired me to present a similar approach, but focusing on the web instead of a mobile platform.

Four steps

I'm going to lay down a concise set of four guidelines, so that every web pragmatist can get a grasp of what to go after when it comes to web accessibility in minutes. 

1. All items exposed

Every element on the website that adds to its message, must be reachable ("visible") for all users, even if they're not using conventional means (a healthy vision) to browse and consume the content. It can be a catchy heading line, menu with a bunch of links, an image crucial to the blog post or an interactive video or social embed. Here's how each of those may suffer in case of incorrect implementation:

  • Instead of plain text, heading line could be coded as an image (in order to place some extra typography effects) or a content attribute of CSS :before/:after selector. This, depending on implementation, may become highly unscalable for a person with low sight or completely unreadable for a blind person.
  • Menu could be hidden behind a trigger button (which seems to be a dominant design pattern among websites on Awwwards). This may make the whole menu harder to find and use for just about everyone. Regular visitors are forced to learn a fancy custom menu mechanics and wait for those damn animations to end every time. Visitors with motor and visual impairments must hold their fingers crossed so that their assistive software will get through all the HTML and CSS trickery that makes such menus possible.
  • Image could be implemented as div with CSS background instead of an <img> element (eg. to make it cover all its space). Without appropriate markup, CSS backgrounds are completely invisible for the assistive software. That's perfectly OK if the image is indeed more of a layout decorator than a content of its own, but there are certainly more and more places on the web where images are key content these days (like social networks).
  • Embeds may include lots of HTML structure redundant from a content perspective, like an iframe with a heavy DOM structure, that may trap an assistive software such a voice reader in a lengthy session in which it struggles to read all that bonus content to the visitor. It may be hard to find that single subject of matter such as a play button in between.
  • Social plugins with fixed positioning are a nightmare both for browsers and their users. Browsers go crazy with them every time a pinch gesture is used for zooming in/out the page. They may either become unreachable or, even worse, overshadow everything else.  Then again, many pages "fix" this by killing this gesture with a <meta name="viewport"> tag, therefore rejecting people with low sight from their target audience.

How to see if everything is exposed? If you have an iOS device, you can go with what's built into it by activating VoiceOver, as shown in the aforementioned audit. Just browse a website in mobile Safari with VoiceOver on, just as if it was a native app. For everyone else, I can't recommend enough a powerful combo of Google Chrome with ChromeVox and Accessibility Developer Tools. There's a great official guide to using those, too.

2. All exposed items labeled

Even if all parts of the webpage are reachable, it won't help much if they aren't labeled properly. In case of WWDC session, a button was shown that allowed adding each list item to favorites. It was made of a star icon and, lacking additional accessibility enhancements, it was read as "empty star", as inferred from image file name. OK, that's better than nothing but it doesn't describe the action that it really offers. It may be a huge barrier for people with sight or learning disabilities who can have hard time guessing or inferring what action may stand behind that star.

It's all the same on the web. In case of links or buttons with just an image or webfont icon and no text, it's crucial to include titles for links. Form controls must have proper labels. And of course, all images must have alternative text, even if their filename seems to describe them properly.

So again, grab ChromeVox or VoiceOver, but this time you should not only try reaching elements but also understanding what they are without looking at them. If there's any room for ambiguity, there's probably a more fitting HTML markup or ARIA attribute that could fix it.

3. All interactions supported

Web is not just about reading but also taking actions. Every single website contains hyperlinks which are a basis of navigation. Most websites also feature forms and/or various controls and buttons. On top of it, we have dozens of DOM events, each of which may be hooked into a JavaScript function with varying outcome. So there's a lot going on, especially in apps that make heavy use of Ember, Angular, React or other frameworks that embrace this dynamic world.

But it all comes down to a single question: can each action on the website be effectively made by every visitor, regardless if their tool is mouse, touch screen, keyboard, VoiceOver, Switch Control or any other assistive technology? Here's what you may stumble upon:

  • Custom form control that doesn't rely on native <input> may not be reachable by [Tab]. You may need to add tabindex="0" or rethink your element's structure to make it fit the native HTML universe better, perhaps by using <a> or <button> as interaction trigger.
  • Element that was made interactive just by adding JS handler to event such as  mousedown or drag may not be usable for a visitor that doesn't have a mouse. Depending on a case, you can add equivalent handlers for keyboard or offer an alternative flow for such visitor.
  • Everything that relies on JavaScript, certain browser feature, plugin and/or media type support should be able to resort to a reasonable fallback or at least a message that clearly describes the issue. Libraries such as Modernizr may come helpful here.

Here's a good news: this time you can do a basic test without even relying on VoiceOver or ChromeVox. Just start pressing [Tab] to jump between interactive elements and then [Return], [Space] and arrow keys to play with them. See if it can take you through all interactions, may it be navigating the website, filling all the form fields or acting on that fancy JS thing. 

4. Good interface flow

And finally, something that I consider the greatest and the most motivating challenge, bringing together efforts of designers, UXers and programmers. It's making your website's outlook, interactions, flow and experience universal. Now, forget for a moment about disability considerations and ask yourself the following questions about your website:

  1. Is the title of each page descriptive of its content?
  2. Is the navigation easy to access, logical and understandable?
  3. Is the key content of each page instantly visible and uncrowded?
  4. Are the key actions  of each page easily reachable and obvious?
  5. Does the order of containers and headers help conveying the message?
  6. Are all those handled consistently across the whole website?
  7. Do those still hold true when using keyboard, touch or assistive? 

You'll see similar questions as above asked and answered in books about SEO, web marketing, UX or typography. That's because web is about bringing everyone to the party and that's exactly what accessibility is all about. And that's why it matters to large players like Apple or Google.

But here's the issue for web programmer: how to support such a diversity of users, crawlers, devices and browsers? How to combine that with all those crazy design ideas? Your best bet is to stay close to W3C standards that determine a proper DOM structure, hierarchy and properties. There are many ways to embrace them, like:

  • proper use of HTML5 elements such as header, nav or article
  • use of heading elements (h1, h2...) to create properly nested tree of sections
  • choosing HTML elements because of their meaning, not their outlook (use CSS for that)  
  • not using tables for layout (that's a little old but still relevant)
  • preferring HTML5 semantics for embeds over iframe
  • using img or svg for icons instead of a webfont hack
  • in general, using native elements instead of custom ones wherever possible
  • when native elements fail, using roles and aria-* tags to describe custom ones

There are many tools that aid in tracking DOM issues, including good old W3C validator and the Accessibility Developer Tools extension for Chrome. And if your designer or UX guy still insists on that custom selector or fixed-positioned embed, you don't have to tell touching stories about impaired people in order to persuade them - just show them how those work on the iPhone or otherwise kill website's usability, discoverability, performance and business.


Accessibility is a more and more important concern in web development these days. And for a reason: Internet has never before been so full of such differing kinds of users, with such differing devices and needs. At the same time, web standards and browsers are improving to offer improved tools for being universal.

There's a ton of challenges on the way to proper accessibility which I'll do my best to describe in subsequent articles. But I hope to have presented here a concise foundation for a more generic way of thinking about the web. Remember, the more the merrier.