Accessibility Testing: An Essential Guide
By Sourojit Das, Community Contributor - October 27, 2022
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” – Tim Berners-Lee, the inventor of the World Wide Web.
Introduction to Web Accessibility
It is challenging enough to deliver flawless web and/or mobile applications, but what makes the task doubly complex is to ensure that the product is accessible to one and all. And that is where Accessibility Testing comes in.
In a recent interview, Paul Smyth, the Head of Digital Accessibility at Barclays, promoted the business case for web accessibility under three major headings:
- The Legal requirements,
- The Commercial Opportunity, and
- The Moral Obligation to provide accessibility.
The World Wide Web Consortium (W3C) defines web accessibility to indicate that websites, web tools, and web-based technology, in general, are designed and developed in a manner that “specially abled” people can use them in a frictionless manner.
Not only is this a moral obligation, keeping in line with the philosophy of why the internet was created, but it allows a large section of the population to navigate and interact with the web and contribute in a meaningful manner to the web community as a whole.
The web was created with a vision of removing any obstacles to communication that people face in a physical scenario, and badly designed web tools and technologies exclude a significant portion of the populace from reaping the benefits freely available to their fellow man.
The WHO in a 2020 study, stated that 15% of the entire global population has some form of disability. The Pew Research Centre states that 75% of all US citizens with disabilities use the web on a daily basis.
This market has tremendous fiscal potential as well, with the Return on Disability Group publishing a 2020 report that this segment of the population represents almost USD 13 trillion in annual disposable income when coupled with their friends and families.
Recognizing this fact, governments across the world have put legislation in place to ensure digital content is as accessible as possible. Some landmark acts in this field include:
- Americans with Disabilities Act – 1990
- Disability Discrimination Act – 1995 (UK)
- Disability Discrimination Act – 1992 (Australia)
- Disability Act of 2005 (Ireland)
It is easy for organizations to fall afoul of these acts when it comes to web accessibility and the number of lawsuits under Americans with Disabilities Act (ADA) Title III website accessibility increased to more than 2500 due to companies not providing accessible web services.
Any organization seeking to be inclusive, tap into a relatively under-serviced market, and avoid legal penalties should focus on designing websites that do not pose an interaction barrier to people with disabilities, and this is where accessibility testing comes into the picture.
Accessibility Testing: What it is and How it works
Accessibility Testing is a type of testing that tests the features of a web application in a way that ensures all users, irrespective of most disabilities, will be able to interact with the software to its full potential. This includes allowing differently-abled users to perform all key actions without external assistance and making the application intrinsically inclusive for ALL users.
Accessibility testing can be performed both manually, as well as using test automation tools. It usually depends on checking specific application features against a set of guidelines to ensure that the relevant accessibility criteria have been met.
- Testing that the text and labels are universally accessible – This is done by validating the application to see if users will be able to see the text in case it’s increased or decreased in size.
- Testing the contrast ratio for images and text – This validates if the users still are able to interact with the application in the case of the contrast being changed to a greater extent than currently set.
- Testing the Navigation flow of the application – This verifies if a differently-abled user, say someone with a visual impairment, will be able to navigate the full scope of the application.
- Testing the Style Sheets for the application – This helps check if the CSS of the application has a degree of tolerance to ensure that the users will still be able to access the web content if the CSS malfunctions.
- Testing hit areas of the application – This verifies that the major interaction interfaces, i.e., the “hit areas” of the application, meet the accessibility criteria for differently abled users in order for them to perform actions smoothly.
Read More: For a more detailed guide on the aspects to be covered under accessibility testing, check out Quick Website Accessibility Testing Checklist
Accessibility Testing using Screen Readers
Screen Readers help in converting digital text into an audio format. This helps users to interact with the web application in a non-visual manner and is especially useful for people with sight impairments.
By loudly enunciating the web text visible on the screen, screen readers assist users in navigating digital content without the need to actually see it.
This is especially useful for those individuals who suffer from partial or complete blindness and/or have cognitive issues like dyslexia.
Screen Readers can work solely with the keyboard present and do not need a mouse to be used.
On enablement, the screen reader reads out the text on the screen, and different custom commands like jump, skip, select, etc., can be used to navigate the site using the screen reader.
WCAG guidelines under the Quick Reference Guide mandate the inclusion of textual alternatives for those visually impaired, and thus it is vital to validate the scope of auditory navigation on websites using screen readers.
Pro Tip: BrowserStack’s Screen Reader feature for desktop allows testers to validate non-visual navigation & usability of websites.
Below is a simple tutorial to test websites with Screen Reader on the Browserstack Live cloud:
Step 2: Once the website has loaded using the selected browser and device combination, the “switch the browser” option on the left needs to be navigated.
Step 3: Out of the list of options available, the “Screen Reader” option needs to be selected from the menu. Once the box has been checked, a green banner will appear on the top of the screen mentioning that “Screen Reader” has been enabled.
This step indicates the completion of the preliminary steps, and the following instructions deal with the actual tests with the screen reader.
However, some useful commands that require familiarisation for using a screen reader are enlisted below for reference:
- TAB – To move to the next element.
- SPACEBAR – for opening dialog boxes.
- SHIFT + TAB – for navigating the next elements
- ESC – To close menus
Step 4: The next step is to use the TAB command to navigate to the Product Link option and verify if the Screen Reader gives voice to the content on the screen, and aid the tester with further command hints.
In this case, SPACEBAR is pressed to expand the Product option to display the menu as shown below.
Must Read: For best practices for accessibility testing with Screen Readers, refer to How to Test Websites with Screen Readers
Automated Accessibility Testing
Screen Readers are a great way to execute accessibility tests manually. However, these tests may need to be executed in bulk and in a very short span of time, especially when it comes to regression test scenarios.
BrowserStack allows the leveraging of the Axe library – an automated testing tool that validates the entire web document against standard accessibility testing tools and generates automated reports.
BrowserStack Automate allows testers to leverage a variety of scripting languages to achieve this, as shown below:
Step 1: Download the axe.min.js library file.
Step 2: Write a script to test the webpage required in a number of languages, including Java, Python, Node.js, PHP, C#, etc.
The following example uses Selenium and Java.
Step 3: An automated report is generated with the results in a format as shown below.
In this nested JSON report:
- Violations indicate the elements that have failed to meet the accessibility rules.
- Passes indicate the elements that have successfully met the accessibility rules.
- Incomplete lists the elements that could not be tested to completion due to technical limitations or system errors. It is these elements that are prime targets for testing using Screen Readers.
Inapplicable enlists the elements that do not correspond to the WCAG rules and can be ruled out from the scope of accessibility tests.
In a rapidly developing web community trying to be inclusive to all users regardless of their disabilities, it is imperative that accessibility testing is included in QA operations from the get-go.
Verifying sites as having met the Accessibility Guidelines allows organizations to promote it to people with special needs and also avoid heavy penalties if they fall afoul of the government legislations in place for ensuring an inclusive World Wide Web.
Accessibility tests should take into account the exact real-time user conditions to identify any potential bottlenecks and loopholes and ensure that the user experience has been optimized even for people with special needs.
Thus, using emulators and simulators for accessibility tests is often insufficient, and real device testing has to be performed for optimal results.
Since obtaining physical devices to test such features is both expensive and maintenance-heavy, BrowserStack allows the use of a real-device cloud with more than 3000+ browser device combinations with compatibility to Screen Readers and solutions like BrowserStack Automate to ensure frictionless accessibility tests across the board.