Guest Post: Common Accessibility Fails
This post from Kim Chatterjee is the first in a series of Invited Guest Posts from our CoE members. We encourage everyone to get involved in the Community, so if you want to participate by writing a Guest Post and sharing your advice or views on accessibility, please let us know.
Accessibility in the online space is not just about whether a blind user with a screen reader can understand your website. It is about providing universal access and an effective user experience. This caters for the needs of people with hearing impairments, cognitive and motor impairments, but also caters for a much broader audience. It includes the guy who forgot to pack the mouse in his laptop bag and is keyboard-dependent, the lady who broke her glasses and squints an inch from the screen, the tourist who checks his online booking on his mobile, the potential international student trying to understand your instructions, and the kid who lives in rural Australia still waiting for your page to finish loading. Good accessibility = good usability.
When it comes to designing online content, the Web Content Accessibility Guidelines 2 (WCAG 2) are the standards to follow. Version 2 emerged in 2008, and today we’re relieved to see a lot more acceptance (and recognition) on people’s faces when we mention accessibility. However we’re still seeing a lot of the same issues, so we’ve compiled five of our top issues that we constantly encounter when we run an accessibility check across a site or piece of software. We want to show you WHY it’s important to fix.
When designing forms, it is important to add the necessary code to connect the label to its field – – not just position the label next to it. “Edit” is all a screen reader might announce if you haven’t correctly assigned a label to a field even if the text is right there for all the sighted world to see.
If you can click it, you should also be able to get to it by only using the keyboard. This is an area where visual design can sometime fail. All your navigation elements, your clickable images, your embedded widget controls, and importantly, the stop button on that annoying video that keeps automatically playing – should be controllable by using the keyboard on its own. Note that different browsers use different keyboard commands.
Not all web elements are equal, and some cannot (and were never meant to) capture keyboard focus – such as text or images. If you’re making an element selectable, use the correct element.
As painful as this sounds, yes, your PDF documents should be checked to see if they hold the correct reading order and are tagged properly. Read about how screen reader users read PDF documents (PDF, 367KB). Is the PDF the only source of information? Not good. Do they contain complex graphics that are essential to the message? Better tag these. Are they interactive? Check that they are keyboard friendly and follow a logical order. A lot of applications now have embedded features of saving a file as PDF, but this isn’t enough. The Adobe Acrobat site holds some tips on how to make various documents accessible.
5 Keep the language simple
Keep it simple; get to the point. Know your audience, and write for the web. Users are short on patience, but they can also have actual trouble processing the language. English as a second language, dyslexia, Attention Deficit Disorder, and other learning and cognitive disabilities should not be ignored when you are writing for your audience.
Tackling these issues can be simple if considered early in the design and development process. The list does go on, but it comes to this: if you keep the user’s experience in mind and reflect this care in your design, then following the WCAG guidelines checklist will come naturally, and your users will love you forever.
Kim Chatterjee works for Stamford Interactive. The views expressed in this post are not necessarily those of the Australian Government.