In case anyone finds this useful, here’s what I’ve written for the Accessibility part of a QA Strategy document for a new project (underneath the ‘Non-Functional Requirements’ section). Feel free to reuse, adapt etc. for your own purposes!
The [project name] project should aim to achieve and maintain WCAG 2.1 AA compliance across the board. All project team members should consider the needs of disabled users and the common impairments that might prevent any user from accessing the [project] site or its services. All team members should embrace the principles of universal design and usability for all, and aim to put these into practice through their work.
When designing/implementing/reviewing a new feature or change, project team members should:
- Maximise the use of Semantic HTML to help assistive technology interpret page content/functionality and present it in a logical and consistent way to disabled users.
- Optimise pages and components for keyboard navigation and screen reader users, ensuring that all elements are programmatically accessible and presented in a logical ‘reading’ order.
- Provide text alternatives for all non-text content such as images, charts/graphs, video and audio.
- Ensure that there is an adequate colour contrast between foreground and background elements.
- Where necessary, use advanced techniques like ARIA, tabindex and visually-hidden to enhance the user experience for disabled users and/or assistive technology users.
- Ensure that all users have adequate time and appropriate help text to complete their intended actions.
- Provide multiple methods for navigating to (e.g. navigation menus, landing pages, search) and interacting with content.
- Consult subject matter experts for help when needed.
In summary, project team members should do all they can to ensure that users of all abilities have equal and fair access to the [project] site and its services .
In addition, any user testing that is conducted should aim to gather the perspectives of users with a range of abilities, including disabled users.
Hopefully some of my fellow travellers will find this useful. This is very much an aspirational document, nor is it intended to cover all accessibility bases, but I think it’s a great starting point that (hopefully) all my project team members will agree with.