Web User Interface Accessability
When website content is properly structured, it is easily consumed by all devices, whether it be a desktop browser, mobile device, screen reader for the visually impaired (e.g. JAWS, NVDA, Window Eyes), or a crawler bot. Designing with the degradation of experience to support the least common denominator of a search crawler bot, your content is often already structured properly to handle all the other devices, and most of the way toward compliance with government regulation Section 508. .
When you start in to consider these challenges, you’re beginning to think about user interface architecture. Or put another way, how can you ensure that your interface is structured in a way that is flexible and supportive of all those who access the content. And the mechanisms by which to facilitate your audience are pretty straight forward.
To build a well architected user interface that maximizes accessibility, consider these few steps:
Document-Native – First and foremost, it is important to move away from interface structure being embedded in binary Flash, Flex, Java, or Silverlight components. This is unavoidable with certain media such as video or audio, but when it comes to your navigation and content, you absolutely cannot have this embedded in a binary file, or you will have erected the single biggest barrier you can, to allowing machine facilitators such as search engines and screen readers to even access the content, much less make sense of it. Meanwhile, the iOS devices don’t even support it. So if you’re looking to build dynamic interactive content, you should absolutely use JavaScript and HTML to accomplish those goals, not Flash, etc.
Semantic HTML – HTML5 introduces semantic tagging for navigation, headers, footers, asides and articles. Proper use of these tags can considerably improve a machine’s ability to parse and interpret the content. Augmenting the HTML5 with Semantic Web tags such as RDFa or Microformats (aka Schema.org), further significantly improves machine accessibility, which again, is great for search engines and screen readers. It also opens the door to many other great semantic web applications of the future. So beginning to think semantically is a great habit to begin today.
Unobtrusive JavaScript – The term “unobtrusive” means writing your JavaScript in such a way that if a machine or browser doesn’t understand the script, it doesn’t cause an error. Ideally you’ll provide a graceful fallback scenario for any critical path functionality, in this case. To do this properly, you’re looking at writing your JavaScript a bit differently. Rather than using embedded onclick and on submit commands directly on the DOM elements, you’ll write “listener” objects that sit in an external file and listen for events on the DOM that match the specified DOM selector. The beauty of this approach is that if the event listeners are not executed because the machine doesn’t understand the script, then nothing happens when the DOM even occurs. In which case you could execute your fallback scenario such as a screen refresh to the page content, rather than it coming up in the pretty AJAX lightbox you preferred. This way, the user (and computer) can still access the content.
Unobtrusive CSS – Similar to the JavaScript being held external, you’ll want to do the same with CSS. That means forgetting the style attribute exists and focusing instead on class and ID attributes. The reason for doing this is similar to the reason you don’t want to use nested tables. If you contain style information in your HTML document, then you’ve mandated certain styles to be rendered regardless of the device. That’s not going to present the content well on a mobile device however. What if instead, you have a single HTML output from your server which has no style, and then dynamically switch which external CSS file is served, based upon the user agent requesting the document. You could render the same HTML to appear optimally on a desktop browser, an iPad, a Blackberry, etc. It further reduces code bloat and confusion potential for screen readers and search engines.
AJAX Live Regions – AJAX is the use of JavaScript to dynamically call a web service and get back new content. Users will typically recognize AJAX because the page content updates or a lightbox appears with further navigation steps, without having to wait for a page to update. AJAX is a huge step forward for critical path workflow, but presents challenges for machine accessibility, since the subsequent content is not present on the original HTML. To overcome this, consider using ARIA (WAI-Aria specifically) to tag live regions of content and further instruct screen readers and search engines, so they are aware of, and know how to parse the dynamic AJAX content.
And that’s it! Hopefully that provides a decent overview of why it is sometimes necessary to think of the user interface beyond simply what we see on our main computer screen, and beyond the latest technical bells an whistles. By being aware of how the content is being consumed and the challenges faced by certain users and machines attempting to access your content, you can quickly see the need to think a little deeper about how the interface is structured. And by following a few new guidelines as provided above, you can significantly improve accessibility for your web application. This will make your content more accessible for mobile devices, screen-readers, and search engines alike.