Strategies for building accessible websites
By: Shan Plourde
Tags: Accessibility, Usabiilty, WCAG, Process

For years I was a full stack developer and loved what I did. Around 2014 I decided that I wanted to focus more of my development time on the front-end. My first real experience of developing accessible websites started in 2016. I worked on a project where our goal was to achieve WCAG 2.0 AA compliance. The experience was fun, and it gave me a greater appreciation of the challenges that users with visual and motor skills impairments face when using websites.

In this article you’ll find some process and development strategies that should help to provide you with a better understanding of what you need to do to develop an accessible compliant, screen reader user friendly website.

Developing accessibility is easy, but…

It’s easy to get started with accessible development. Use semantic HTML, ARIA attributes, etc. I recommend that you do those things right from the beginning of your project. And if that’s all the budget that you have for accessibility, then that’s still better than doing nothing at all!

However if you need to create an application that is fully compliant to an accessibility standard such as WCAG, and you are planning to go above and beyond compliance by ensuring usability, then there is much more to consider.

Usability issues of compliant websites

Your application could meet a compliance checklist, but still be difficult for screenreader users to use. We often found this to be the case with our more complex components.

The October 2017 WebAIM Screen Reader User Survey distilled the most common usability issues faced by screen reader users into the following list:

CAPTCHA — images presenting text used to verify that you are a human user Screens or parts of screens that change unexpectedly Links or buttons that do not make sense The presence of inaccessible Flash content Lack of keyboard accessibility Complex or difficult forms Images with missing or improper descriptions (alt text) Missing or improper headings Too many links or navigation items Complex data tables Inaccessible or missing search functionality Lack of “skip to main content” or “skip navigation” links

Of this list, automated tests can discover some of the issues, such as those under points 3, 4, 5, 7, and 8. My point is that many of the top reported issues are usability related, are not things that an automated tool can uncover, and require manual testing to uncover and improve upon.

Recommendations

Identify a subject matter expert 🤓

Identify someone in your company or on your team who will be the accessibility subject matter expert. I like to call this person the “accessibility architect” 😃. This person can help to maintain and evolve your company or project’s accessibility guidelines, train team members, support accessibility related design questions, etc.

The accessibility user experience should be looked at from a holistic perspective, so that the end user experience is consistent and predictable. Everyone else working on accessibility needs to become familiarized with it as it relates to them, but the subject matter expert should have that mile high view of the bigger picture so that they can provide insights into difficult design problems.

Include screen reader users in your testing processes if possible

The company that I worked at had a screen reader user who supported our team from time to time. Where possible, they were able to provide useful insights based on their own user experience.

These are the users that are actually using accessibility tools on a day-to-day basis. They will use the tools differently from how your QA team and developers use the tools.

Standardize on testing tools

Your team should standardize on the test tools that will be used. This includes screen readers, as well as QA and developer test automation tools.

Standardizing on tools is important because each tool may present different findings. Screen readers behave differently from one another, and unfortunately the budget to make them all usable is likely going to be greater than the budget you can get.

On my last accessibility project, we used the Voiceover, ChromeVox, and NVDA screen readers, since they were all free 😃. Sometimes one screen reader provided a good user experience, while another would provide a confusing user experience. In these scenarios, you might need to trial and error development approaches until a usable solution is found for all screen readers.

Objectively measure your accessibility compliance

Use a defined accessibility standard for your project to track to, such as WCAG 2.1 AA. If your team wishes to define their own standard, have the team explicitly define their compliance criteria.

Without having objective measurements, the components that your team completes will subjectively be accessible. If you have a testing team it will be difficult for them to define their accessibility test cases and validate that the components pass accessibility. There is a good chance that your application won’t be fully accessible.

If your team decides to create its own list of accessibility requirements, have the team create a well-defined checklist of requirements. Ensure that each checklist item links to a well defined definition of that item, such as a corresponding WCAG definition for the item. This will help your team to understand the scope and best practices of the item.

In the WCAG standard, some things are not objectively defined such as font sizes (the ability to zoom text by up to 200% is defined though). Regardless, design should ensure that they avoid tiny, difficult to read fonts as the baseline font and size at 100% zoom. Ensure that these items are included in your compliance checklist, otherwise it will become costly to change font sizes and colours once you’re farther into development as page layouts will be impacted.

Include accessibility in your definition of done

Factor accessibility into your project’s definition of done, since accessibility is something that impacts design, development, and QA. This will help to ensure that there is commitment, review processes, and workflows at each step of the development process.

QA, design, developer feedback loops

Ensure that the team communicates often and reviews one another’s work during development to avoid wasted cycles. Lots of open communication and feedback is super valuable for many other reasons as well!

Testing tools

There are numerous continually evolving accessibility test tools, suitable for manual and automated testing. Even though there is a plethora of tools, we found that none of them were able to fully test our web pages for WCAG 2.0 AA compliance. However, these tools have a ton of value during design, development, and QA.

Manual testing tools include screen readers, standalone applications, and browser extensions.

Automated tools can and should be integrated into your build processes.

Summary

Building an accessible, screen reader friendly application or website requires the commitment of everyone on your team. The effort is significantly less if you build it in from the start. Otherwise just like unit testing, it can easily become technical debt that never gets addressed.

Let me know if you’re interested in any follow up accessibility articles, and feel free to contact me if you have any questions about my experience or if you need some advice for your project!

Resources