Accessibility of digital content is increasingly in the spotlight, and so, for web (and indeed, mobile) developers and testers, it is an important subject. In some cases, achieving a certain level of accessibility is mandatory or even a legal requirement, such as public sector websites visited by citizens. However, even when those necessities do not exist, it is crucial to avoid discriminating inadvertently and ensure that digital content includes all potential audiences. Plus, from a business point of view, it makes commercial sense to make content usable by as many consumers as possible.

Also, accessibility does not just apply to people with permanent disabilities. For example, small screens, slow Internet connections, and bright sunlight can make it harder to understand digital content. Likewise, anyone who wears and has mislaid their reading glasses will identify with the frustration of trying to read on-screen text. Everyone deserves the best possible user experience.

Resources

Accessibility has traditionally been an afterthought for many developers, but these days, it must baked into the development lifecycle and mindset from day one. At first, it can seem daunting, but fortunately, a wealth of knowledge and guidance is available, including the Web Content Accessibility Guidelines (WCAG) and A11Y. Between these two, they encompass a wide range of best practices. For instance, the WCAG is part of the Web Accessibility Initiative (WAI) from the World Wide Web Consortium (W3C), and it covers four main areas:

• Perceivable – users must be able to perceive the information (it cannot be invisible to all their senses).
• Operable – users must be able to operate the interface (in other words, not requiring actions that they are unable to perform)
• Understandable – users must be able to understand the information and how to operate the user interface
• Robust – content must be able to be interpreted reliably across different devices and technologies.

In addition to WCAG, A11Y is a community-driven project to make digital accessibility easier. A11Y is a numeronym, with 11 referring to the number of letters that the word 'accessibility' contains between 'a' and 'y', and it covers many assistive technology requirements. These include reading comprehension level and how easy content is to view (across sight impairments, dyslexia, migraine triggers, and colour blindness).

Examples of accessible design

A wealth of information available from the A11Y, WCAG and other knowledge sources gives detailed guidance, but here are a few examples to consider when designing for accessibility.

Alternative text (alt text) is already well-known and assists those with visual impairment, allowing viewers to get the gist of an image using words. When writing alt text, the message is added to the image, and if the image itself has text, that is included too. An example might be: ALT = white trainers, blue stripe, or ALT = woman, red dress, laughing. ALT text descriptions should be concise and use plain language rather than promotion.

Headings are another issue to consider. Screen readers — which people with visual impairments use to convert text, buttons, images and other screen elements into speech or braille – navigate content using heading structures. So, ensuring those structures are easily translatable and well-organised is essential for accessibility. For instance, if using h1, h2 and h3 as the structure, h1 is for page titles and should not be used elsewhere. And it is essential not to skip a number (such as jumping from h1 to h3). Otherwise, the screen reader assumes there is no text.

Graphics and colour

Graphics and contrast play important roles in accessibility. Strongly contrasting graphics always make content stand out more. In addition, people with colour blindness can find it difficult to differentiate between hues, so it helps if they contrast strongly. Various contrast analyser tools are available to check a visual design’s accessibility. Furthermore, removing the reliance on colour alone is even better: colour should not be the only clue for presenting the information.

Not everyone uses tracking pads or a mouse on a laptop, so a website should be navigable using a keyboard by pressing the tab key and then navigating each element logically.
Regardless of how users engage with the website or app, they must be given clear feedback about their interactions, such as payment processing or filling in forms. Easily understood explanations and instructions should accompany any error messages.

Testing for accessibility

Testing is the only way to know if a team has developed a website or app that meets accessibility guidelines. A starting point to establish a baseline could be an accessibility audit, which can involve external consultants or carried out in-house.

Knowing the devices most popular among users is also helpful. Perfecto’s regularly updated Mobile and Web Test Coverage Guide is a free resource that provides insight into the most widely used mobile devices and web browsers in each world region. This can help developers and testers decide which platforms and operating systems to prioritise for accessibility.

Testing accessibility

Mainstream testing techniques have an important role to play in ensuring that what is being developed meets accessibility requirements. Areas to test include:

• Labels - used by assistive technologies, like VoiceOver or TalkBack.
• Text contrast – the ratio between text or images and background colour.
• Hit area size – the area designated for user interaction.
• View hierarchy of UI – to determine how easy the website or app is to navigate.
• Dynamic font size – the option for users to increase the font size to fit their needs.

Valuable resources include generic accessibility testing libraries, which are available for different platforms (Question: are these just mobile? If so, we should remove this reference because the article needs to be more web-centric (though we can mention mobile)). These provide sets of acceptance tests for accessibility and, anecdotally, have been found to discover up to 50% of relevant issues. Similarly, interactive intelligent guided testing is embedded in browser extensions, enabling developers to test for buttons and links. So, from the very start, the accessible names associated with those buttons and links are correct.

Frameworks and automation

In addition, consider test frameworks explicitly designed for behaviour-driven development (BDD), such as the widely used Deque AXE solution. Accessibility also needs to be part of regression testing, and most functional testing frameworks for web content, such as Cypress and Selenium, integrate with the Deque AXE solution. For mobile apps, there are native iOS and Android A11Y scanners.

Traditionally, most accessibility tests are performed manually, not included, or outsourced to third parties. However, like other forms of testing, accessibility benefits from being part of development from the get-go, in tune with the trend towards ‘shifting left’. In other words, defects — in this case, accessibility issues — are identified and dealt with sooner when it is easier and less expensive to fix. Of course, some tests will still need to be manually performed, but automation of as much as possible helps to mitigate the additional workload on the team.

Automation, the right tools, making the most of all the available resources, and techniques such as early testing will all help make accessibility less arduous and more achievable. Accessibility can — and should — be front of mind when creating digital content for the modern, more inclusive world.