Development teams often overlook accessibility requirements or place them very low on their priority list when building websites and web applications. A recent study by Deque Systems shows that as much as 70% of websites are inaccessible to people with disabilities. Many assume that the default user of our software will be users who can read, listen, write or see. It’s not always true. Many software users are people with disabilities.
Developers, therefore, should adapt software to make it more accessible. Creating applications that are inaccessible to users with disabilities is effectively limiting the audience. By law, some applications must be accessible. Some companies have faced legal challenges because their products did not meet accessibility expectations.
Consequences of inaccessible apps
One recent web accessibility case involved Maryann Murad and the tech giant Amazon. Murad, who is blind, and the National Federation of the Blind filed a lawsuit against Amazon in 2017 for employment discrimination. The lawsuit alleged that when Murad was applying for a virtual customer service position, she was unable to complete the online evaluation on Amazon’s site. The platform was not compatible with Voiceover — the Apple text-to-speech software Murad uses to operate her computer.
When Murad brought this to the attention of Amazon, the company’s representative replied that the site was inaccessible and the woman should look for another position. The case settled outside of court for an undisclosed amount in July 2020 and Amazon has agreed to make its sites more accessible. As accessibility awareness is growing. Companies that develop and test software accessibility come to help.
What does accessibility mean?
Accessibility means that the software is available to everyone. That’s all. But what does accessibility testing mean? Accessibility testing is one type of software usability testing. Accessibility testing aims to ensure that an application meets accessibility requirements and is accessible to people with various disabilities.
During the development phase of the concept of software accessibility, guidelines for software development and testing were created by the World Wide Web Consortium (WCAG) and the US Access Board (Section 508). These guidelines are rules that development teams should follow to make websites and web applications available to users with disabilities. The most popular guidelines today are: Section 508 and WCAG.
Common guidelines
Section 508 — these are Federal U.S. guidelines to make government sites accessible to people with disabilities. Section 508 provides guidelines regarding among others:
- tables (“row and column headers shall be identified for data tables”)
- colors (“Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup”)
- documents organization (“Documents shall be organized so they are readable without requiring an associated style sheet”).
WCAG — guidelines proposed by the World Wide Web Consortium (W3C) to establish a new international standard for web accessibility testing. Most national web accessibility standards are based on WCAG, including Section 508. WCAG has been accepted as the International Standards Organization (ISO) standard. Many countries treat WCAG as the legal standard for web accessibility. WCAG describes three levels of availability A, AA and AAA where AAA stands for the highest degree of availability. Currently, the most up-to-date version is WCAG 2.1, which was released in 2018 due to the large increase in the number of users using mobile devices.
Due to the fact that WCAG is the basis of international accessibility standards, I will base this article on these guidelines.WCAG guidelines use the acronym POUR — perceivable, operable, understandable and robust.
Perceivable — clear interface and clear content. More specifically perceivable means that the developer should remove the barriers to accessing the website/web applications. The developer should provide the software with alternative texts for content that is non-textual, that is, transcripts or multimedia subtitles and captions. Perceivable is also about providing clear contrast, support for sound controls and support for zooming.
Operable — that is, ensuring that users can control the software and interactive elements with a keyboard, mouse, or dictation software. Operable also means the software is suitable for screen readers. Another important thing about “operable” is the lack of content that may be dangerous for some users, such as flashing lights, which can cause epilepsy attacks.
Understandable — this means that messages should be readable and understandable for every user. It also means that no operation of the software should surprise you. This includes consistent navigation, appropriate shortcuts, useful instructions, IT support, error handling, or contextual help.
Robust — that is, content should conform to various forms of assistive technologies. The software should work properly on different platforms, technologies and devices. In the context of testing, this means that the website content should always be available to the user regardless of technological progress, such as browser updates.
Manual or automated?
We can use two approaches in accessibility testing. Manual testing and automated testing. Which will be better, faster, or more effective? Well, the answer is to use both approaches simultaneously. Manual testing allows us to avoid errors that software may overlook. We also do not always have the budget for an automated tool. Manual testing is particularly important and useful because it often does not require specialist knowledge and we can involve people with disabilities in tests who may point out things a tester didn’t know to look for.
Basic manual accessibility testing does not have to be difficult. Checklists are the best way to test your product manually. The most popular and comprehensive checklist is WCAG, which is prepared for A, AA and AAA levels.
Below, I also suggest some other checklists that are also helpful for accessibility testers.
You can also create your own comprehensive checklist depending on your needs and test it just manually. For example:
- Text — this will show whether, if necessary, users can freely change the size, thickness or underlining of the text. The test can also reveal whether the font is easy to read.
- Color and contrast — do the background and foreground colors have sufficient contrast? It is helpful to users with low vision or other visual disabilities. High contrast mode present in Windows change or invert web page background and text colors. For color contrast tests you can use WebAim Contrast Color Checker and WebAim Link Color Contrast Checker.
- Audio and video — in this test, you should pay attention to whether the video on your website has subtitles, whether you provide transcription, whether you offer audio description, whether you have turned off auto-play or whether the video has flashing content.
- Images — when testing images, you should pay attention to whether all of them are important and necessary, whether the page is not loading too slowly due to the presence of too many images, whether the images have flashing content.
- Content scaling — when you zoom in you will see if the content is still readable.
- Language — check that the text is clear, concise and that you are not using too advanced terms.
- Forms — check that form fields are sufficiently marked and that form fields can be filled in using only the keyboard by jumping between them.
- Keyboard only — for some of your website/web application users, using the keyboard is the only option. Not everyone will use the mouse as well. When creating a page, you should enable navigation through the page using the keys on your keyboard. By default, most operations should be possible with the tab, enter, space keys.
If you want your application to be fully available, you should also consider testing it using assistive technology such as: screen readers, screen magnification software or alternative input devices like, head pointers motion, eye tracking devices or speech input software — but these tests are not just manual tests. These are just a few of the suggestions, there are more detailed checklists in the links above.
Automated testing tools
Automated testing is limited (due to the fact that the automated tool does not think like a human), but it gives a general idea of the application accessibility status. It also allows detects obvious problems at an early stage, such as for example form fields without labels, invalid HTML code, content without heading, or images without alt text. Testing with automated tools will allow you to make sure that nothing has been overlooked in manual testing or simply make the tests faster.
There are many tools on the market that allow you to test the availability of the application. Some of them are free and some we have to pay for. Some tools are easier to use and some are more advanced.
- WAVE (Web Accessibility Evaluation Tool) — one of the most popular tools for testing website accessibility. WAVE is a free tool that allows you to enter a URL. WAVE then displays and analyzes the page through its interface to finally display the non-compliance report. When checking the website via WAVE, you do not need to enter the URL of individual subpages because the tool provides navigation through the elements of the interface page. The reports generated by WAVE are safe and private. WAVE provides extensions for Chrome and Firefox.
- Dynomapper — Paid site-map generator offering checking websites and web applications for accessibility. Dynomapper checks in accordance with the guidelines of WCAG 2.1, WCAG 2.0, WCAG 1.0 and Section 508. The application works by checking groups of pages or sites included and then generates a general report. The report results are displayed as a visual sitemap. Supported formats are CSS, HTML and XHTML.
- TAW — free tool available in the form of online/desktop application and add-on for Firefox. TAW checks websites against the WCAG 1.0, WCAG 2.0 guidelines, and according to its own set of guidelines for mobile applications. TAW breaks down accessibility problems into priorities 1, 2, and 3. After analyzing your site, the tool provides recommendations for resolving the problems.
- AXE — this free available tool can be used as a plug-in for Chrome, Firefox and Android. AXE offers website testing in the browser. After clicking the button responsible for the analysis of the website, AXE signals problems with accessibility, which additionally describes in detail also suggestions regarding the recommended solution. AXE is a bit more advanced tool, so it can also be helpful for developers. In addition to indicating general accessibility problems, the tool points to more detailed and advanced problems.
Conclusion
Even though in most cases the general accessibility of the website/web application is not an obligation, it is worth considering testing and introducing corrections in this regard. Development teams should remember that users with disabilities are also a very important group of users and all users should be able to access your website or application. After the tests for accessibility, you can be sure that your website meets the law requirements for accessibility, but that your brand will also get a more favorable image.
