In this new series of articles, Brian Dalton will share his experiences and advice working as an Accessibility QA tester and consultant. He will be discussing his methodologies and tools, as well as giving advice for those with diverse ability who either already work or may wish to work in this exciting area. In this first article, Brian introduces Accessibility QA testing, outlining his tools and approach.
About Brian
I’m a QA Accessibility Lead tester for InterAccess, doing accessibility testing of websites and UI components to ensure they meet the WCAG guidelines. I’m also blind and a screen reader user, and I want to share some of my experiences in this and future articles, as well as tips that others who have diverse abilities will find useful if they want to work in this space.What is QA accessibility testing?
QA accessibility testing is an important link in the chain in terms of the final delivery of any product. When a product is released to the general public, it should be fit for purpose and work as expected for everyone. The QA tester is an integral part of making this happen. We raise and track bugs and work with the Development team to verify those bugs have been resolved by re-testing them. The QA Tester is also required to work with the Project Manager and Business Analyst to ensure that all areas/requirements are covered in terms of testing its functionality.The Accessibility QA Tester will need to communicate with the development team the importance of accessibility to the final product. We raise awareness of requirements around accessibility for screen reader users and beyond, and ensure that accessibility is a part of the ‘definition of done’ in any project we work on.
Browsers and Screen Readers used
An Accessibility QA Tester must use a combination of screen readers and browsers to test effectively. The main screen readers I use are JAWS, NVDA and VoiceOver, with Chrome, Mozilla Firefox and Safari.At the time of writing, Google Chrome has undergone a great deal of development in terms of its accessibility, and is fast becoming the browser of choice for many screen readers. It is only a matter of time, before this browser will be in scope for user testing.
Microsoft’s browser for Windows 10, Edge, in conjunction with JAWS (the latest version), is not fully supported to allow a screen reader work across all functions of web browsing. This product has undergone serious development in recent times, and Microsoft and VFO are working together to improve this for future releases of JAWS. In time, I have no doubt that Edge too will be in scope in terms of user testing.
Approaches to Accessibility QA testing
The main way in which an Accessibility QA tester looks at a product or component in terms of its use and level of accessibility is through the keyboard. Keyboard accessibility is one of the most important principles of web accessibility. There are four main areas that a QA Accessibility Tester needs to write and execute test cases for, to validate the functionality and the level of accessibility of a component on a Website. They are:Area 1: Navigation
Ensure that a screen reader user can bypass any irrelevant content, to find, navigate to and focus on the content that is of interest to them. They should be able to reach their chosen area by locating and activating its Headings, Links, Buttons, etc using the screen reader shortcut keys.Area 2: Interaction
Validate that a screen reader user can interact with elements and controls on a web page in order to perform all necessary tasks. These include:- Activating Links and Buttons, with the Space and Enter key.
- Ensuring a screen reader user can interact with all Form Fields, and that they appear in the correct tab order.
- Ensuring that the state of all controls are announced. Boxes are checked/checked, and menus are expanded/collapsed with the
Space/Enterkey. - Ensuring that radio buttons can be navigated to with the Tab key and selected with the up and down arrow keys.
Area 3: Time Limit
Test cases need to be documented and executed to ensure that a screen reader user has sufficient time to carry out all tasks, where a time limit is necessary. A person’s response time can vary a great deal, depending on how accessible the content is, and whether they are a beginner or a power user. In cases such as this, it is important that a screen reader is informed that the session will time out, and given the option to extend this if necessary.Area 4: Error Recovery
Error recovery is also an important feature to validate and test for. Nobody likes to enter an invalid password and become blocked from moving through the flow on a page by not entering the correct details in the correct place, which will prevent the chain of events moving forward. While this is frustrating in trying to complete a task, error recovery can hold greater significance. If errors are not identified correctly to a screen reader user, it could mean that they pay for the wrong product entirely, by making a mistake that cannot be corrected. No one would wish this to happen, so a person using a screen reader needs to be informed of all error alerts that are displayed during tasks that require the input of data or boxes to be checked to accept terms and conditions. Error alerts should be built into the design by the developer. A QA tester needs to write and execute test cases around these scenarios, to ensure that error recovery works efficiently.In short, all content and functionality should be navigable and operable by a screen reader user, through the keyboard. The Tab/Space/Enter keys are fundamental in carrying out functions, while the Virtual Cursor (the up/down arrow keys) is used to read static content by a screen reader user. Along with the above, informative messages need to be called out, and need to be included in test case preparation.
In our next article we will look at writing test cases. What they are and how to do it.