Addressing Accessibility for the Web
brandt
Mon, 10/17/2016 - 09:20
Michellanne Li
Oct 17, 2016
Making sure your website is accessible requires more than just fulfilling a checklist of best practices.
In this post we will cover...
How you should be thinking about accessibility
How to bake accessibility into your process
Some tips and tricks for creating accessible websites
We want to make your project a success.
Let's Chat.
The Americans with Disabilities Act was a landmark civil rights legislation that tore down barriers preventing individuals with disabilities from fully participating in society. This bill covered important aspects of life in the 1990s, such as public transportation and employment. A decade and a half later these things are still important, but technologies have emerged that raise new questions about how they can be made accessible for all users.
This year, I had the privilege of attending the 2016 Accessibility Summit, where presenters from organizations such as the W3 Consortium, Adobe, and WebAIM talked about ways in which we can make the web more accessible to users with disabilities such as low vision, blindness, deafness, and limited dexterity.
One of my biggest takeaways was that I had been thinking about accessibility all wrong. Initially, I saw accessibility guidelines as a checklist. Although lists are published by thought leaders such as Google (https://material.google.com/usability/accessibility.html#), it’s entirely possible for a website to adhere to accessibility criteria without effectively meeting the needs of disabled users.
While checklists are useful, they lack a human element. It helps to view accessibility as a holistic approach to design, development, and content that, at its core, relies on empathy and understanding of a wide range of user experiences.
Accessibility issues are ultimately user experience issues.
How do you bake accessibility into your process? Below are some ideas of how accessibility may become an inherent part of creating a website:
Create personas for disabled users to address accessibility. Some examples might be:
A person with low vision or blindness
A person who has recently suffered a stroke
A person who is positioned in the glare of the sun
The World Wide Web Consortium has created a diverse set of personas representing disabled users, which are available on their website (https://www.w3.org/WAI/intro/people-use-web/stories). There are also solutions provided for common problems these users might face on the web.
Create tickets based on disabled user personas. These tickets should have specific quantifiable success criteria, such as: “a person with vision impairment can fill out this form.” This is a great platform to demonstrate to clients how accessibility is being achieved.
From the onset, design with accessibility in mind. Designers should familiarize themselves with accessibility guidelines and incorporate them into their work starting with the earliest concepts.
For instance, whenever I’m working with text, I run potential colors for both the text and the background through a contrast checker (such as this one: http://webaim.org/resources/contrastchecker/). Contrast checkers confirm whether the combined text color and background color will be readable. Such measures preempt the need to rethink the design later in the process, thus saving time and avoiding the pitfalls of presenting a client with ideas that cannot be realized.
When designing the UI, aim for fewer steps to task completion. By decreasing the number of keystrokes, steps, and time required to complete tasks, we can make websites more accessible for everyone.
A task that is mildly annoying to complete for an abled user can be prohibitively time-consuming and frustrating for a disabled user. All users can benefit from the simplification of tasks, but disabled users will be especially impacted.
During development, take advantage of the wide range of auditing tools available to check whether your site adheres to accessibility guidelines. Some popular tools include:
a11y command line auditor: https://addyosmani.com/a11y/
Pa11y command line auditor: http://pa11y.org/
aXe Chrome developer tools extension: https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US
Tenon.io online testing tool: https://tenon.io/index.php
WAVE online accessibility evaluation tool: http://wave.webaim.org/
WAVE Chrome developer tools extension: https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh?hl=en-US
Navigate and complete tasks on your website with the tools available to disabled users. This doesn’t replace user testing, but it can provide some useful insights. Here are some ideas:
Try using a screen reader, such as Chrome Vox. This helps you confirm whether your interactive elements are labeled clearly.
Change your iPhone’s accessibility settings and practice using your website with voiceover. Go into “Settings > General > Accessibility.”
Try using your keyboard only.
You can implement these techniques when demoing websites to clients to help them understand how different users access websites.
Recruit individuals with disabilities to participate in usability testing. This is the best way to confirm whether a website truly is accessible. Remember that accessibility guidelines are just the starting point. A site that checks off all the boxes may still have roadblocks for disabled users.
Disability rights lawyer, Lainey Feingold, provides on her website a list of nonprofits that offer usability testing by disabled individuals (http://www.lflegal.com/resources/#test).
Additionally, here are some tips and tricks for creating accessible websites.
Use flyingfocus.js (https://github.com/NV/flying-focus) to add a sense of movement to the :focus state of interactive elements. This enhances the user experience of tabbing through a web page. Check out some examples here: https://github.com/NV/flying-focus/wiki/In-the-Wild
Sighted users who tab through a website also benefit from the addition of skip links. (However, non-sighted keyboard users do not use skip links because screen readers have ways of getting around repetitive content.) What’s a skip link? It is a link at the top of the page that the user can select to “jump” to the main content. This saves time that would otherwise be spent tabbing through the site header on every page. A skip link can be styled so that it is hidden until a user tabs over it. Adding a css transition so the hidden link is visible for a fraction of a second longer will ensure that the user doesn’t miss it.
Aria roles are useful, but employ them sparingly. Overuse of aria roles can actually diminish the accessibility of a website.
It’s dangerous to make assumptions about how users are interacting with and viewing your website. For instance, desktop users who zoom in on websites will wind up activating the mobile view. And some mobile users navigate with a keyboard.
Rather than “Read More” links, be specific: “Read more about ---.” This is important for users with screen readers who are unable to see the association between the “read more” link and the content it references. You can visually hide “---” so that only screen readers will detect it.
Blocks of text should be no more than 80 characters or glyphs wide (40 if CJK). 45-75 characters is considered ideal.
Avoid using screen reader detection. Visually impaired individuals do not want to feel like they are being treated differently or tracked.
Avoid using tabindex with positive values. Instead, structure your markup for logical and intuitive navigation.
Use tabindex(-1) to set focus on things that aren’t natively focusable.
Stay connected with the latest news on web strategy, design, and development.
Sign up for our newsletter.
Design