Designing for all abilities isn’t just the right thing to do, it makes good business sense. The benefits of becoming compliant far outweigh the effort, and it’s not hard to do. Besides dodging a PR and legal nightmare like that Beyoncé or Dominos have recently been battling, you’ll increase your customer base, improve SEO and create a positive brand. It’s a win-win proposition!
The first step is to become familiar with the WCAG 2.1 guidelines by the international World Wide Web Consortium (W3C) and get your entire web team engaged. Review our ADA Compliance Checklist for more detail of specific areas to test.
We’ll recommend certain tools to help with manual testing. Steer clear of relying on automated tools to provide you a defect list or to prove compliance without manual verification. These tools only catch about 40% of errors and commonly give false positives. For example, it may mark success because an image has alternative text. It can’t tell you if that text is correct or makes sense in context. And, it’s possible you’ll have images such as icons that don’t need alternative text.
Knowing the purpose of your site and the key user interactions is important in evaluating the overall equivalent user experience. Do people need to provide email in order to download content, login and view account info, or to make a purchase? Lastly, it’s important for visitors to know how to get customer service or technical support if needed.
Getting Started
For this purpose, we’ll assume you’re a private sector company with a website in the public domain looking to achieve WCAG 2.1 Level AA compliance.
We won’t specifically look at mobile, Braille outputs, speech to text or other alternative input devices. If your site meets WCAG 2.1 success criteria and best practices on desktop, chances are mobile and other devices should be in good shape as well. Specialty devices are best tested by expert users of that device with a particular disability.
Set up Environment and Tools
Let’s talk tools! Use your standard PC or Mac, keyboard and favorite browser. We recommend Chrome because of the availability of helpful plugins such as Google Accessibility, SiteImprove, aXe, Alt Text Checker, WCAG Contrast Checker and Google High Contrast.
JAWS and NVDA are screen readers for Microsoft Windows PCs while VoiceOver is Mac’s built-in screen reader. JAWS requires a paid license after the trial period whereas NVDA suggests a donation. Once you’ve selected your screen reader, dig into the tutorials to learn how to use all the functions and features. It will take some practice to become proficient and make your testing a lot easier. Screen reader usage is the most time-consuming part of manual testing. Screen readers process web pages and play it back in a synthesized voice. For that reason, I would also recommend headphones.
Tool Set Up Checklist:
- Mac or PC
- Chrome Browser
- Chrome Plug-ins
- Screen Reader
- Headphones
Sounds obvious, but you’ll also need full site access so you can do everything that normal users do, including features behind a login.
Lastly, decide how to catalog your findings and what you’re doing with the results. You could be approaching this as a high-level audit to raise support of management. Or maybe you want to give the development team specific items to fix and start a ground up effort. Regardless of your audience, issues should be prioritized as severe, medium and low. Severe issues are show-stoppers that interrupt the normal flow and prevent further access. Medium issues are still serious, but there may be a work around or alternative path. Lower priority issues may add value and quality to the experience but do not interrupt the purpose.
Approach
Look at your site and determine what the purpose is and the end goal of visitor traffic. If you’re not 100% sure, it’s always helpful to check out analytics and site traffic reports. Analytics reveal top paths through your site and heavily used pages. Start with the top key use cases and heavily accessed pages and you’ll uncover most, if not all of your issues. Typically, the same mistakes are made throughout a site.
This approach will help you gain an understanding of how issues are being introduced and how to implement fixes across the site.
You will be going through the site in several passes, looking at different criteria listed below, to uncover dynamic content or discover “edge” cases. People commonly test the “happy path” but forget other common interactions such as lost password, session timeout and entering wrong data.
- Color Contrast
Use a Chrome extension like WCAG contrast checker to determine if text and background meets minimum 4.5:1 contrast ratio. At minimum, designers may need to revise the color palette, font or iconography. Worst case scenario is you’ll be challenging corporate brand standards.
Just for information, use the Chrome High Contrast plugin to see how colors can be inverted with different contrast colors to make text easier to read.
- Alternative Text
Getting through screen reader testing will be the final word in the performance of your alternative text that is embedded behind the scenes. That’s when you’ll uncover the end-to-end audio qualitative experience. You’ll want to uncover and fix as much of this underlying text. Use a plug-in like Alt Text Checker or similar to display the alternative text that is in the code.
Ensuring all images have alternative text isn’t enough. Check to see that it makes sense in context. There will also be cases where an image won’t need alternative text. For example, a menu may have a cute icon next to a menu link. You don’t need the screen reader to hear the description for the icon, alternative text for the link and link itself.
- Keyboard Navigation
Starting at the top address bar, check to see that you can navigate to everything you need to on the page and your key user paths using only tab, up and down arrows. You should be able to get to your regions, headings and links in a logical order. Can you tell where your focus is on the page? Are you able to get to essential information? If you find that you’re stuck in a section and can’t move unless using your mouse, you’re in a keyboard trap. That’s often a showstopper for people with assistive devices.
Now take another pass and check to see that you’re not keying to content you don’t need to. For example, if you have an icon next to a text link, it’s okay for the keyboard to skip over the icon and just get to the link. Similarly, a date input field that has a calendar widget is okay to skip the calendar widget and use the keyboard date entry.
Sometimes there are hidden elements or just plain garbage in the code that the keyboard finds that should be cleaned up.
Take as many passes through so that you render dynamic content and different scenarios. Keep track of the use cases, data entered, and actions triggered as you go along so you can repeat during screen reader testing.
Ensuring the site is fully navigable by keyboard is a pre-requisite to screen reader evaluation. It will make screen reader testing that much easier.
- Screen Reader
Screen reader testing will be the most time-consuming part of the assessment. You’ll need to make the auditory experience primary and to have more than a working knowledge of screen reader software.
You’ve made the experience as smooth as possible by addressing alternative text and keyboard navigation. The multiple passes through will be checking to see the screen reader registers dynamic content updating on the page, timed content, or error messages. You’ll understand how to optimize your site for a linear experience versus a visually rich experience.
Summary
It takes practice to become proficient in manual testing and to interpret the best path forward towards accessibility. Also, getting efficient in methodology also takes practice so you can optimize the number of passes in testing. You find that the help of a professional to provide direction or to do an assessment would be more efficient.
Adally is offering a free homepage ADA scan. Take advantage of our no obligation scan today. CLICK HERE.