What is Accessibility Testing and Why is it Important?
What is Accessibility and Accessibility Testing?
Quite simply, the web should be universally available to everybody, regardless of any kind of impairment or disability that a person may have. In today's world, this means that all web applications or websites and all mobile applications should work without functional barriers to, or the exclusion of, anyone that may have auditory, cognitive, physical, neurological, visual or speech disabilities.
When web and mobile applications are poorly designed, built and tested from an accessibility point of view, the core principle of universal web accessibility is not met.
The WAI (Web Accessibility Initiative) was established by the W3C (World Wide Web Consortium) and works very closely with accessibility experts from within industry, disability organisations, government and accessibility research organisations.
The WAI's primary objective is to promote extremely high levels of web useability for people with a wide range of disabilities.
In joint partnership, the WAI and its web accessibility subject matter experts are chiefly responsible for enforcing support for accessibility within W3G standards, developing web accessibility content guidelines and building and sharing resources for evaluating web accessibility.
Web accessibility testing refers to the testing of web and mobile app software to measure compliance with a number of international Accessibility Standards.
Testing in line with these Standards will expose where components, sections and pages of your application as a whole, violate accessibility requirements and best practice.
Testers look to ensure that assistive technology so relied upon by people with disabilities, such as screen readers, speech recognition products, keyboards and magnification software will be able to parse and present a website's content in an accessible manner for all users.
Accessibility testing helps to ensure that the web is truly accessible to all people. Let's explore the 3 main Accessibility Standards below.
What are the standards for Web Accessibility?
Testing of your applications for web accessibility will need to consider the requirements of 3 main standards depending on the nature of your business and your location.
The WCAG or Web Content Accessibility Guidelines is an international standard as developed and promoted by the W3C and its Web Accessibility Initiative (WAI). WCAG v1.0 dates from the late nineties but today's focus is on published versions 2.0 and 2.1 of the WCAG standard. v2.2 is scheduled for release at the close of 2022 and a draft of version 3.0 to be published in the next 2-3 years is already in progress.
Within the WCAG standard, there are also compliance adherence levels of A ('single A'), AA ('double A') and AAA ('triple A'). AAA level compliance as you would expect requires more accessible feature adoption than A level compliance and can be challenging for any organisation to fully implement.
As well as the WCAG, web accessibility compliance in the United States is measured against 2 legislated acts. These are the Rehabilitation Act and the Americans with Disabilities Act.
The Rehabilitation Act (1973) was amended in 1998 to incorporate a new Section 508. This section "requires Federal [Government/public sector] agencies to make their electronic and information technology accessible to people with disabilities." All federal agencies as well as vendors, contractors and any partners, both in and outside of the United States are required to comply with the Act.
The ADA or Americans with Disabilities Act actually predates the American public's introduction to the web, however, it was always designed to evolve and change with the rise of new technologies. As such, businesses in the US falling under either Titles 1 or 3, are required to have a website "that gives ‘reasonable accessibility’ to people with disabilities."
Neither Section 508 nor the ADA provide a clear guide as to what actually constitutes a suitably accessible website, and as such, it is widely accepted that compliance with the very specific WCAG 2.1 A and AA (single and double A) standards will meet the Section 508 and ADA requirements for accessibility.
Why is Accessibility testing so important?
With people around the world spending ever increasing amounts of their time using the internet for social and business reasons, both on desktop and mobile, it is of course the right thing to do to ensure that as much web content as possible is made as accessible as possible for everybody.
For example, in the now common scenario whereby different types of business are either eradicating bricks and mortar premises or shifting focus from paper based documentation to digital, consumers often have little to no choice but to embrace the business' website or mobile app.
Airlines for example are promoting significant use of mobile app technology for all aspects of air travel and some financial institutions are now severely limiting paper based communications in favour of websites and mobile apps.
Some banks are now even removing functionality from their websites for it to only be available via their mobile app. Clearly in these kinds of examples where people absolutely depend upon this new digital workflow, it must be accessible to all customers.
In the retail sector, we have long witnessed the shift from highstreet shopping to e-commerce for convenience and greater choice and customers require accessible websites in this sector as well.
Aside from obviously being the right thing to do in every scenario, businesses should be aware that failing to deliver accessible web content on their websites or mobile apps will often expose them to potential lawsuits with subsequent fines and significant damage to brand reputation. Nike, Amazon, Domino's Pizza, Netflix, Burger King and the Fox News Network have all been hit with lawsuits regarding aspects of in-accessibility of their business websites under the ADA.
Finally, whilst in recent times, there has tended to be more litigation stemming from US based business and dissatisfied customers, Europe and the UK are fast catching up.
Read more - Accessibility In Edtech
Can you automate your Accessibility testing?
Absolutely, yes, you can. In the past, most organisations have tended to test manually and even outsource any of their accessibility testing, but we need to change our thinking if we now shift focus to agile software delivery. Agile testing needs to be thorough with extensive functional and non-functional coverage, yet cannot be a bottleneck to frequent delivery.
Testing needs to be consistently undertaken, potentially many times a day across multiple environments to ensure that rapid deployments of code are not introducing breaking changes or functional regression. We refer to this as continuous regression testing.
We should be of exactly the same mindset with regards to our accessibility testing. Accessibility testing is not a one-time exercise, never to be repeated. Continuous automated accessibility testing with an intent to ensure that violations against WCAG, ADA and Section 508 standards are consistently reduced over time, should be the aspiration of any application delivery team looking to build a quality product for its customers.
The WCAG standard advocates 4 key principles:
Perceivable - ensuring that users can perceive web content with more than one sense. i.e. if visual perception is not possible, auditory perception takes precedence.
Operable - Users can make use of all website functionality without the need to use a mouse - i.e. Keyboard only.
Understandable - Text is readable and understandable with language identification and further terminology breakdown and definition where necessary.
Robust - All website content is accessible on a variety of browsers, user agents and with a wide range of assistive technologies.
Within each of these principles, there are a raft of conditions to be met, criteria for testing success, suggested means of implementation and correction, and always a clear explanation of just why a particular website or mobile app accessibility aspect is so important to a user.
It is widely accepted that you cannot automate all of your accessibility testing though. A reasonable expectation, depending on test tooling of choice, is that you can automate around 40-60% of all of your accessibility testing with the remainder needing to be assessed manually.
What types of Accessibility tests are run?
It is beyond the scope of this article to detail every type of automated accessibility check that can typically be executed but some simplified critical examples are documented below.
ensuring use of alternate text for all visual content
ensuring aria attributes are used comprehensively throughout the site
ensuring audio captioning for audio elements
ensuring keyboard navigability
ensuring sufficient colour contrast application
ensuring blinking content is not used are able to be controlled by users
ensuring sites offer bypass jumps immediately to the key content
ensuring uniqueness of element naming
ensuring language identifiers are used
ensuring links have clear text and implied purpose
ensuring video and audio elements offer user control mechanisms
Tools for Accessibility testing
There are a wide range of available accessibility testing tools. They broadly fall into 2 categories - those that you would employ within a manual testing approach and those that can form part of an automated accessibility testing strategy.
Additionally, some tools will focus specifically on certain aspects of web accessibility - for example, ensuring compliance with Screen Reader technologies. Some popular tools are shown below.
WAVE - a browser extension for Edge, Firefox and Chrome, enabling manual accessibility testing by entering a site url for assessment and report generation.
JAWS - screen reading software for Windows machines.
Axe - Automated accessibility testing solution for web app and mobile app developers and automation test engineers.
Google Lighthouse - A command line interface and Chrome browser extension returning page by page scores in 5 categories: Accessibility, SEO, Performance, Code Best Practices and Progressive Web App readiness. you can check Test Evolve’s Automated Light house testing tool.
Test Evolve Spark - A complete test automation solution with cloud dashboards and localised reporting. Enables the integration of automated Axe accessibility and Google Lighthouse checks within existing browser based end to end automated tests. Enables the auditing of multiple pages in a single test. Simple to deploy within your CI/CD pipeline. Supports use of JavaScript or Ruby.
Tenon - An API led automated accessibility testing engine where users call a REST service with a specific page URL to be scanned. Can be integrated within all popular CI/CD pipelines.
Accessibility testing myths and challenges
Let's consider some incorrect assumptions about good web accessibility and testing.
I can automate all of my accessibility testing - No. Even with a suite of tools, you can hope to automate around 60% of your necessary accessibility testing. The rest will need to be undertaken manually.
I only need to test once - No. As long as your developers continue to deploy new code for your application, you need to continue your accessibility testing. Breaking changes can easily be introduced and you want to reduce violations over time, not let them creep up again.
Accessibility is just about colour contrast and alt tags - No. As you can see from the vastly simplified list of critical checks above that accessibility audits will need to cover, there is a considerable amount of technical improvement to be made to the average web application to start your compliance journey with A, AA and AAA level WCAG.
Accessibility is only significant in the USA - No. Whilst it's certainly true that legal ramifications of in-accessibility have tended to be more prevalent in the US, quite rightly, there is a big shift in focus and importance with regards to accessibility compliance in Europe and the UK. There are specific Irish, French, German and European standards and quite simply, it is the right thing to do on a global basis.
Accessibility compliance means I have to sacrifice aspects of brand and design implementation - No. If your Product, Design and Delivery Teams place accessibility up front and centre, there is no shortage of contemporary, attractive and compliant UI layouts that can be implemented.
I didn't consider accessibility at the start of delivery, it's too late now OR I can leave it until next year...I've got time and it's not my top priority - No. Accessibility compliance is most definitely a marathon and not a sprint. There are always many low hanging fruits for companies to quickly and easily address so why not start immediately with those and then consider a more comprehensive strategy for implementation. In addition, don't shoot for Triple A ('AAA') on day 1. Climb the accessibility ladder one step at a time and worry about Single A first.
Accessibility doesn't impact that many users - No. The WHO tells us that 19% or 57 million people in the US alone have a registered disability. On a global scale, 15% of people have a registered disability. For the greater good of the internet and the future prosperity of your business, embrace accessibility compliance today.
Conclusion
Web and Mobile application compliance to one or multiple International Accessibility Standards is only going to become more commonly required regardless of the country from which your business operates. Presumably, you are aiming for an international customer base?
If you are at the beginning of delivery, up your accessibility focus now. You will have the best chance of succeeding quickly and painlessly when you don’t delay.
Make continuous automated accessibility regression testing part of your Agile delivery strategy and treat accessibility regression as you would functional regression. 57 million people in the US alone would thank you for taking it seriously.
Undertake an analysis of the tooling that’s available to your organisation and your testing team. A comprehensive automation results dashboard solution like Test Evolve will allow your developers and testers to leverage end-to-end UI automation tests that are already running to add further value still with accessibility tests, Lighthouse audits and Visual regression testing.
When deciding how best to incorporate accessibility testing for Test Evolve users, we evaluated the market and chose to integrate the leading and best equipped Axe-core engine from Deque Systems. It will help you plan corrective accessibility code change to start your compliance journey.
With the understanding that although a powerful addition to your CI pipeline, automated testing cannot resolve all WCAG, Section 508 or ADA issues, we recommend booking an Accessibility Awareness Lab with Deque Systems for an in depth immersive experience into the daily challenges and frustrations of disabled internet users.
Test Evolve is available for a free 30 day trial. Let us show you how you can make significant strides in your accessibility testing in a very short space of time.
