By Brian Dalton, and Saleem Rahman.
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. Please use @daltobar and @intera11y to discuss the article on the Twittertron.
I’m a QA Accessibility Lead tester for both Aer Lingus and InterAccess, doing accessibility testing of websites and UI components to ensure they meet the WCAG 2.0 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.
I became involved in user testing for organisations such as: the National Council for the Blind of Ireland Centre for Inclusive Technology, (NCBI CFIT) and the Visually Impaired Computer Society (Vics). Recently I have become part of the Beta Testing team for VFO, the company who develop the JAWS screen reader.
What is Accessible QA testing?
Accessibility QA 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 affectively. The main screen readers I use are JAWS, NVDA and VoiceOver, with IE, 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.
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/Enter key.
- 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.