Accessibility testing of web applications

Most people nowadays can hardly imagine their life without the internet.
Web is providing unprecedented access to information, interaction, goods and services.
You don`t need to be smart or educated to browse the web and find any possible information you need.
Despite of the fact that internet is so easily accessible for most of the people, most Web sites and Web software have accessibility barriers that make it difficult or impossible for many people with disabilities to use.
The goal of this article is to help you understand why making web accessible is a must nowadays, the common problems people face and how to eliminate these problems.
Some statistics
The current world population is 7.5 billion as of April 2017 according to the most recent United Nations estimates.
285 million people are estimated to be visually impaired worldwide.
Over 5% of the world’s population — 360 million people has disabling hearing loss.
Over a billion people, about 15% of the world’s population, have some form of disability.
As you can see these are Impressive and terrifying numbers.
At the same time around 40% of the world population has an internet connection today.
So you can imagine that good part of internet users are people with different forms of disabilities.
How Web and technologies are changing the lives
Before even web was invented, people with disabilities weren`t able even to read a newspaper without someone’s help.
Audiotapes or Braille printouts were expensive and not available world wide.
They were dependent of family members and other people who could read the newspaper out loud for them.
Nowadays internet gives a lot of opportunities for people with disabilities.
Most newspapers now publish their content online and it can be read by screen readers used by the blind.
Similarly, people with other disabilities for example who cannot pick up a newspaper or turn its pages can access online newspapers through their computer, using certain assistive technologies, for example voice control or eye-tracking software that allows to use a computer with eye movements.
What is Web Accessibility and why it`s so important
Despite of the fact that web is making significant improvements in lives of people with disabilities, it potential is still largely unrealized.
Some sites still can only be navigated using a mouse, and only a very small percentage of video or multimedia content has been captioned for the deaf.
At this point we should start thinking about web accessibility.
Accessibility can be viewed as the “ability to access”.
So the people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.
As more accessible Web sites and software become available, people with disabilities are able to use and contribute to the Web more effectively.
It is essential that the Web be accessible in order to provide equal access and equal opportunity to people with disabilities.
A11y represents the word “accessibility”. There are 11 characters between the first and last letter of accessibility so it’s common in the accessibility community to shorten it to a11y.
Understanding web accessibility principles
Much of the focus on Web accessibility has been on the responsibilities of Web developers.
But everyone should understand it basic principles and concepts.
In order to assure that websites and web applications are accessible and usable by everyone, designers and developers must follow web accessibility guidelines.
Below guidelines by Web Content Accessibility Guidelines 2.0 are the basis of most web accessibility law in the world:
- Perceivable — Available through sight, hearing, or touch.
- Operable — Compatible with keyboard or mouse.
- Understandable — User-friendly, easy to comprehend.
- Robust — Works across browsers, assistive technologies, mobile devices, old devices/browsers, etc.
Evaluating the Accessibility of a Web Site
Before starting any development and testing activities you should evaluate your product first.
Using Simple techniques test your product to ensure that particular features are usable/accessible to users with disabilities using various assistive technologies.
- HTML validation
It is mostly developers responsibility.
But even test engineers can perform this task simply by using any HTML validator to check the code and then provide generated report to engineers.
2. Test a product with a keyboard
Imagine that you don`t have a mouse and try to traverse through web pages using keyboard only.
You should be able to access all interactive features (e.g., menus, links, form fields, buttons, controls) and operate them by pressing Enter, space, arrow keys.
If you are unable to access some of your site’s features, then the site is likely to have accessibility problems.
3. Use an accessibility checker
There are several free online tools that will check your web pages for accessibility.
You can find some on them on Web Accessibility Initiative web site of just google them.
Getting started with testing
The process of testing for accessibility (a11y) is often tedious and confusing.
Test engineer should have some prior accessibility knowledge in order to make sense of the results.
So before get started try to familiarize yourself with various assistive technologies (screen readers, screen magnifiers/large font, high contrast mode).
Then you can go through manual tests which can be executed on different browsers and platforms to perform Accessibility testing.
All manual test can be divided into such groups:
- Navigation and control
- Alternatives for media features
- Error messages and Inputs
- Keyboard navigation
- Labels and Content
- Magnification
- Contrast and Colors
- Animation and visual characteristics
Possible test scenarios to each group can look like that:
Navigation and control
- Does the website include consistent navigation?
- Is the tab order and read order logical and intuitive?
- Are mechanisms in place that allow users to bypass blocks of content (e.g., a “skip to main content” link on a web page or bookmarks in a PDF)?
- Does the website include two or more ways of finding content, such as a navigation menu, search feature, or site map?
- Do features that scroll or update automatically (e.g., slideshows, carousels) have prominent accessible controls that enable users to pause or advance these features on their own?
Alternatives for media features
- Do images have alternative text?
- Does video have captions?
- Does audio have a transcript?
Error messages and Inputs
- Do web site provides helpful, accessible errors and verification messages?
- Are errors caused by improper input by the user identified and described to the user in text?
Keyboard Navigation
- Can all menus, links, buttons, and other controls be operated by keyboard.
Labels and Content
- Do form fields within web pages and documents have appropriate labels and prompts?
- Does the web page or document have a title that describes its topic or purpose?
- Is link text meaningful, independent of context?
- Has the language of the web page or document (or individual parts of a multilingual document) been defined?
- Do links, controls, or form fields that automatically trigger a change in context is avoided?
Contrast and Color
- Does the interface have sufficient contrast between text color and background color?
- Do content and controls are visible in high contrast mode?
Magnification
- Does the content scale well when text is enlarged up to 200 percent?
Animation and visual characteristics
- Does content that flashes or flickers is avoided?
- Does using of visual characteristics to communicate information (e.g., “click the circle on the right” or “required fields are in red”) is avoided?
Recommendations for performing testing
When performing accessibility testing using screen readers, test engineers might find issues on the screen reader side too which cannot be fixed on the product teams.
That`s why it is important to understand the difference between product issue and tool issue.
Following the strategy below will help you to identify issues on a product side.
- Choose one screen reader and one browser.
Usually it`s a ChromeVox in Chrome browser, because it is easiest and fastest to learn and it`s free.
2. Test the product using test scenarios described above and list out the issues found.
3. Choose a second screen reader and same browser if possible.
Usually people select VoiceOver because it works quite similar to ChromeVox.
4. Reproduce the previously found issues with the second screen reader.
5. File all reproducible issues.
6. Continue only if there were issues which were not reproducible.
7. Reproduce the remaining issues with third screen reader (JAWS or NVDA).
8. If the result with JAWS/NVDA is similar to that of ChromeVox then file the bug for the product.
Accessibility testing may be challenging for testers because they are unfamiliar with disabilities.
It is better to work with disabled people who have specific needs to understand their challenges and needs.
Now you have some background and ideas about web accessibility so you`re good to go and start trying new funny things.
Enjoy )
