Sample accessibility strategy for a new project

šŸ—„ļø Archive
1

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!

Accessibility
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.

5 Likes
2

Interesting you labelled it as a QA strategy though, from reading it Iā€™m guessing you didnā€™t intend it as a test strategy (nor would a test strategy be in a requirements document). So youā€™ve actually used QA in itā€™s proper sense, which is cool!

1 Like
3

Yeah, absolutely. This is the intro section of the document:

Quality Assurance (also known as QA) is a continuous process that involves all project stakeholders and takes place throughout the project lifecycle. On the [project name] project, the QA Process will be overseen and developed by the Test Lead and other members of the Testing team, but all team members should be involved in:

  • defining what quality means within the context of the project
  • deciding how quality should be measured and assessed
  • ensuring that their own work meets the agreed levels of quality
  • identifying potential problems/bugs and improvements in any part of the system, and sharing their concerns with the relevant stakeholders

QA should not be thought of as merely a step in the development process after Tech Review and before UAT, nor should QA Analysts/Testers be the only people who are involved in QA. Instead, QA processes should be implemented at each step of the project lifecycle and form part of the Definition of Done.

My general outlook on QA is that, while I donā€™t particularly like the term, if itā€™s going to be used then I should do what I can to make sure itā€™s used properly!

3 Likes
4

Thatā€™s pretty amazing!

1 Like