If I was working with you today
I would be helping testers adopt these practices into their work:
- Requiring accessibility acceptance criteria for testing
- Test in the correct order: keyboard then screenreader
- Using appropriate screenreader/browser pairings
Testing is a team effort
When teams have the right resources, tools and success criteria, testing becomes a default part of team culture.
At the beginning of the product cycle, product owners/managers must establish accessibility acceptance criteria. These criteria follow the product throughout the entire process.
Build phase testing
When developers require accessibility acceptance criteria for defintion of ready, this allows them to manually test with the keyboard and screenreader during development, meaning that there will be fewer defects for testers to report.
By utlizing automated code scanning tools, programmatic accessibility defects and invalid markup can also be identified, leading to cleaner code with less technical debt.
Automated tools can include:
- Code quality checks in developer IDEs
- Code quality reports from the CI managers
- Browser extensions like Google Lighthouse or WAVE
QA Testing
Having clear test case instructions is the foundation of proper QA processes, and with a little help testers can quickly become proficient at testing for accessibility.
I can coach your testers through the process through lunch and learns or hands on real world testing sessions.
Common tester needs
Even with documented accessibility acceptance criteria available on a story basis, uninitiated testers will always need some guidance to become familiar with using their keyboard and screenreader instead of a mouse.
Misunderstanding of keyboard interactions
Ex: Testers commonly believe the tab key is used to browse every piece of content
A11yEngineer.com solves this problem by giving step by step keyboard instructions
Missing tests with the keyboard only (no screenreader)
Screenreaders can add their own “band-aids” to a broken experiences.
Keyboard testing is crucial because it is pre-requisite to screenreader requirements.
Expecting identical screenreader experiences across platforms
The precise user experience will vary by browser, operating system and screenreader combination
The fundamental requirementes defined in A11yEngineer.com (Name, Role, State and Group) are very consistent.
Release considerations
Release managers should confirm that acceptance criteria have been met and be empowered to hold a deployment if criteria haven’t been met.
Typically, being the reason a deployment is held up is enough reason for a team to understand that accessibility best practices must be followed.
On occasion, an exception may needsto be made for business reasons. Accessibility exceptions and escalations should be approved by leadership with an understanding of the legal risk of non-compliance.
Deployment follow up
After deployment, regression testing should proceed that includes manual testing of the product and automated testing triggered by the deployment.
When inaccessible experiences are discovered, a root cause analysis should be conducted to understand where the process isn’t working for the organization. Tools should provide a documentation trail that allows for examination of process.
How to get started
I can attend a grooming session to help product managers assign acceptance criteria or be available for testing guidance when criteria are present.
Contact me to get started.