Strategies for building accessible 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.

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.

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.

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.

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.

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.

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.

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.

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.

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!

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.

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!

Related posts:

The twin imperatives of teaching for employment and teaching for education demands the attention of public policy scholars as it does of those in most fields political science and, indeed, the higher…

I know that nowadays everybody is talking about dieting, yoga, career, sleep and balance and how you should have them all in 24 hours. So I will not start with giving advices or tell you what you…

Laying on the sofa at mom’s this morning, listening to the sounds of the ever-increasing traffic from the street, I’m feeling stuck. I’ll have been in the Los Angeles area for two weeks Monday and…