In this day and age, information and services previously only served by bricks and mortar are increasingly becoming digitised and accessible by websites and applications. Throughout 2020 and into 2021, this was made even more common with the onset of the global coronavirus pandemic. As such, a digital-first world can, if accessibility is not considered properly, become a severe barrier to entry to those with disabilities.
Website and mobile app accessibility has all too often been an afterthought in the development process, but with the importance of it ever increasing, it is vital to ensure accessibility features are considered early in the software development lifecycle (SDLC) – ideally at the requirement or design stage – to ensure this is an intrinsic feature of any development from the outset.
What’s more, advancing your Web Accessibility can enhance your brand, drive innovation, and extend your market reach.
When should accessibility testing be performed?
Being accessible should be enshrined into the fabric of any organisation that develops an app or website that the public will use. Both the design and subsequent development undertaken should conform to the WCAG standards, rather than tested after the fact and corrected retrospectively.
This can range from visual choices made (colour palettes, font sizes and so on) to the capability of the website/app itself and its underlying code supporting things such as screen readers.
With that being said, Accessibility Testing should be undertaken as early in the SDLC process as possible, to ensure any development completed (or being undertaken) is conform.
In terms of why it’s important to design with this in mind from the outset and test early on, it’s 6.5x more expensive to resolve something whilst it’s being developed, 15x during testing and up to 100x once it’s gone live. Therefore, with accessibility being considered from the outset (i.e. design), not only is what’s being designed and subsequently built that’s more accessible, but it’s also much cheaper in the long run, versus doing this retrospectively once it’s gone into production.
How to perform accessibility testing
Accessibility Testing can be performed in 2 ways: manually and semi-automated.
Using these methods, organisations can identify areas of their systems – be that private (internal) or public (website/apps) – that require mitigative work or redesign to become conform to the WCAG standards.
Manual accessibility testing
Keyboard-only navigation
Being able to navigate and operate all a website’s functions without the use of a mouse is essential for many users with disabilities, especially those who use certain assistive tools. Manual accessibility testing can help you determine if your site is optimized for keyboard-only functionality such as:
- Moving between sections of a web page
- Accessing all menus
- Top-of-page links that allow users to skip directly to each page’s vital content
- Links and form fields that can be highlighted using keyboard commands
Screen reader compatibility
Screen readers are among the most commonly used assistive tools for users with low vision or visual impairment. Manual testing is imperative to determine how readable the content is for various assistive technologies, or whether navigating menus operates as expected, or determining where links lead or understanding the context of alternative text. Other significant scenarios could include:
Colour adjustments
While automated scans and browser plugins can be helpful in catching problematic colour-contrast issues that make comprehension difficult for some users, most of these scans can’t detect contrast ratio images related to background images. Manually testing each area of your website against established standards can help make sure your content is understandable to a broader range of users.
Page titles
The proper use of page titles can be a tricky prospect. While an automated scan can usually identify pages that are missing titles, it can’t determine their context or usefulness. Manual testing can help ensure that titles provide the meaning of the page in a clear, concise way that’s compatible with both assistive technology and search engine crawlers.
Proper coding
Some elements of accessibility are not evident on the consumer side. Ensuring that HTML5 and WAI-ARIA elements are properly employed for maximal accessibility will often require a manual check by someone familiar with coding best practices. This ensures that assistive technologies have as much valid information to operate with as possible, thereby improving the experience for the end user.
You might also be interested in…
Colour accessibility and the importance of accessibility testing
Focusing on colour accessibility in the digital world, in this ebook we break down how colour affects your conversion rates, examples of how to cater your website to be more accessible and the revenue boom you can experience after implementing our top tips.
Semi-automated testing
First off, fully automated accessibility testing simply isn’t possible – an application cannot reasonably discern if the alternative-text associated with an image, or a secondary audio track to a video, is contextually correct.
Using browser extensions to determine whether a range of different aspects conform to best-practices:
-
- Text spacing – you can simulate wider spacing to confirm whether any content becomes obscured or hidden altogether.
- HTML (CSS) disablers – by disabling the styling of a page (by disabling the CSS) does any content become unreadable, hidden, or obscured?
- Validity checkers – using these tools to check whether the markup of the HTML doesn’t present any errors that may inhibit assistive technologies.
- WAVE – this tool can be used to identify a range of issues ranging from missing alternative text, missing form labels, broken or missing ARIA references, empty links, missing skip links, as well as contrast related issues.
- Lighthouse – this tool can be used to validate a range of attributes related to specific elements, but more significantly it can generate an audit report covering a wide array of attributes that cover a good proportion of the WCAG standards.
The above is just a small subset of tools that can be used, but there are also several other frameworks/applications that can be used – these include AxeTools and Microsoft Accessibility Insights.
What method and tools you choose to use should be whatever is most effective for your automation testing strategy but ultimately, both manual and semi-automated solutions will need to be used to form a robust and effective automation testing strategy.
What if you can’t launch with a fully accessible website?
It is not uncommon for a website to launch with inaccessible elements in it. Whilst not ideal, you can demonstrate that you as an organisation care about accessibility and your users, irrespective of whether they have a disability or not, and that you are committed to improving how accessible your website and content is, by providing an accessibility statement.
An accessibility statement, in simple terms, will confirm how accessible a website is, and details any aspects that aren’t. It should provide the end-user with easily readable simplistic language that can be understood and provide contact details to make an accessibility-focused complaint.
W3C stipulate the following 3 aspects that must be covered:
- A commitment to accessibility for people with disabilities
- The accessibility standard applied, such as WCAG 2.1
- Contact information in case users encounter problems
They also advise you should include the following information:
- Any known limitations, to avoid frustration of your users
- Measures taken by your organization to ensure accessibility
- Technical prerequisites, such as supported web browsers
- Environments in which the content has been tested to work
- References to applicable national or local laws and policies
The statement must be published as a basic HTML page on a website and easily locatable on every page. Because of these requirements, most companies choose to include their statement in the footer of every page.
In the long run, your website and app’s accessibility should be an ongoing commitment and duty to your users – be that those without disability, or those with. Therefore, Accessibility should be within the fabric of an organisation and be a key consideration (and practice) by all parties involved in bringing a product to market.
Simply put, your product should not discriminate against those with disabilities – of which there are over 7 million people in the UK (in other words, over 10% of the population).
A statement should not be used as a ‘cut-and-run’ measure – it should convey in an open, honest and clear manner about what your website can and cannot do. It should define where your shortcomings are, but also reaffirm your commitment to improving your level of accessibility.
How does WCAG compare to ADA or EAA and EU WAD?
Strictly speaking, the ADA (Americans with Disabilities Act) doesn’t state websites or applications anywhere in its wording. However, the Department for Justice (DoJ) has previously interpreted that Title III of this act does apply to websites (and mobile apps) as they consider them ‘places of public accommodation’.
The Department first articulated its interpretation that the ADA applies to public accommodations’ websites over twenty years ago. This interpretation is consistent with the ADA’s title III requirement that the goods, services, privileges, or activities provided by places of public accommodation be equally accessible to people with disabilities.
September 25, 2018 letter from Assistant Attorney General, US Department of Justice
Whilst this isn’t underpinned by legal wording within the ADA, it is widely considered that conformance to WCAG 2.1 is sufficient to be on a good grounding when it comes to ADA conformance.
Next, lets look at the EAA (European Accessibility Act). The act doesn’t specifically provide legal wording on the exact requirements, however, it does state a minimum standard for accessibility equivalent to WCAG 2.1 Level AA. From an EU perspective, this is covered within the European Standard EN 301 549.
Finally, in the context of private businesses (i.e. non-public sector entities), the EU WAD (EU Web Accessibility Directive) does not apply (as it only applies to public sector bodies).
Effective and robust accessibility strategy
An effective and robust accessibility strategy is one that is established from the very outset of a project – ideally at the design stage. This way, best practice and design that is suitable for all is baked into the very foundations of what is being built. Furthermore, any development teams working on said projects should be versed in the best practices and solid coding markup to support assistive technologies such as screen readers.
An effective accessibility testing strategy will comprise of both manual and semi-automated approaches and tool-sets. The latter can be incorporated into a CI/CD pipeline, or initiated on an ad-hoc basis when required.
In any case, the need for a product to be accessible will always be there, and as such, the maintenance of a product and its content will always require testing to ensure conformance to the WCAG standards is maintained. The silver lining being the more accessible you are, the more customers can make use of your services, which could lead to improved conversion rates and in turn greater revenue.
