In my article on Integrating Accessibility In The Web Development Process, I talked about the importance of integrating accessibility from the beginning, already in the planning phase.
What does this mean for the QA (quality assurance) tester?
The QA team's job is to write tests based on the requirements established in the planning phase. When accessibility requirements are clearly defined, this also leads to well-defined tests.
The goal is to find all major accessibility bugs before they even occur (often highlighted as critical and serious accessibility issues when using axe DevTools).
Ways To Write User Stories For Accessibility Issues
User stories can be reused from one project to the next in the long run, as accessibility requirements stay constant even if implementation details vary from one design to the next.
User stories can also already be included in the design or development requirements and do not need to be treated as separate issues. This would ensure that accessibility is considered in the whole development process from the beginning, rather than being added as a final step.
In this process, it would be easier to work with an accessibility specialist, if available in the team, if the QA tester is not so deeply immersed in the accessibility topic to consider different types of disabilities when writing user stories and not forget anything.
Example: Form
A form is the perfect example to show how user stories could be written, as it shows many different aspects related to accessibility.
The user story could include a description and acceptance criteria for keyboard users for example, or blind users.
User Stories
| Example 1: Keyboard User |
|---|
| As a keyboard user, I would like to be able to navigate the form using only the Tab key, jump back and forth as needed, and enter and exit the form without experiencing keyboard trap. |
| Example 2: Visual Impairment (Blindness) |
|---|
| As a screen reader user who has a visual impairment (e.g. blindness), I want the screen reader to read aloud the label of each input field on the form so I know what the input field is for. |
| Example 3: Visual Impairment (Low Vision) |
|---|
| As a user with a visual impairment (e.g., low vision), I want to be able to clearly distinguish the input field from the background so that I know where to click to activate the input field. |
Acceptance Criteria
Designers and developers, especially those who are not as experienced with accessibility, need clear guidance to know when they have reached acceptance criteria.
They would also benefit from links to more information about the specific topic or examples of accessible input fields.
Example: Acceptance criteria
Correct labels to each input field by applying one of these methods (regarding w3c)
- Explicit label
<label for="name">Name:</label> <input id="name" type="text"> - Implicit label
<label>Name: <input type="text"></label> - Usage of
ariaonly where first and second option won't work
High enough color contrast regarded WCAG AA 2.1. (or the version which is relevant in the company/country)
- Check with WebAIM Color Contrast checker
Conclusion & Best practices
The more specific the user story and, in the later stages, the QA team's bug report, the more successful the designers and developers will be in integrating the feature or fixing the bug.
Make sure the bug report explains the accessibility issue in a simple way so that others who are not as familiar with accessibility can understand it, and provide examples and links for further introductions.
Include users with disabilities in testing, or better yet, employ QA testers who have specific disabilities. Ultimately, people with disabilities need to have a good user experience (UX) with the product when it comes to accessibility, so they provide the best opinion on whether the product provides a good UX.
Top comments (0)