Developing accessible web applications case study and why it matters

Recently I had an opportunity to work as a QA practice lead as part of the Triad team on the Department for Transport (DfT) project developing the new Manage Motor Fuel Greenhouse Gas Emissions service for GOV.UK.

Every online platform should be aware of and striving for high levels of accessibility, not least because we know that accessibility is closely connected with usability.

What’s great about working on public sector projects is that they have invested the time and expertise to define and optimise accessibility guidelines (Web Content Accessibility Guidelines - WCAG 2.1), which are rigorously tested through the Government Digital Service (GDS) assessment process. As this Manage Motor Fuel Greenhouse Gas Emissions service is hosted in GOV.UK, it needed to pass level AA accessibility.

To test this service before the GDS assessment, we created an Accessibility Empathy lab at Triad that helped the new service pass all three assessments first time without any issues. It’s those techniques and strategies we followed to design, develop and test this service for accessibility that I will cover in this article.

What is web accessibility?

Web accessibility means that websites, tools and technologies are designed and developed so that people with disabilities can use them. Web accessibility encompasses all disabilities that affect access to the web including vision, hearing, cognitive, learning, neurological, physical/motor and speech. 

Benefits of accessibility

The web has become an essential part of society. However, 1 in 5 people has some kind of disability. As such, web accessibility ensures that disabled people have the best chance of using websites and online resources to live a normal life.

Accessibility also benefits people without disabilities. This might be people using different devices, people with changing abilities due to ageing, or situational limitations such as bright sunlight or a slow internet connection / limited bandwidth.

Web content Accessibility Guidelines (WCAG) 2.1 design principles

The WCAG 2.1 are an internationally recognised set of recommendations for improving web accessibility. They explain how to make digital services, websites and apps accessible to everyone, including users with impairments.

WCAG 2.1 is based on four design principles.

1.    Perceivable – the information and user interface components must be presented to the user in a way that they can recognise and use the service with the senses that are available to them.

2.    Operable – the users can find and use the content, regardless of how they choose to access it (e.g., using keyboard or voice commands).

3.    Understandable – the users can understand the content and how the service works.

4.     Robust – the content can be interpreted reliably by a wide variety of user agents (e.g. assistive technologies, different browsers etc.)

Design and testing techniques for different types of disabilities

WCAG 2.1 design principles are key when developing an accessible web application.

Here are some of the techniques we followed to design, develop and test the service to make it accessible to people with different disabilities.

Vision impairment

There are many degrees of visual impairments ranging from difficulty in reading small characters through to complete blindness and colour blindness.

Design for users with vision impairment

• Use good colour contrasts and a readable font size.

• Use a combination of colour, shapes and text to convey meaning.

• Follow a linear, logical layout when magnified 200%.
• Put buttons and notifications in context.

• Put error messages inline and focus on the first error field.

• Use colour and underline for the links.

Design for users of screen readers

• Describe images and provide transcripts for video.

<alt>

• Follow a linear and logical layout.

• Structure content using HTML5.

<h1>
   <nav>
<label>

• Build for keyboard use only.

• Create descriptive links and headings.

Testing techniques for vision impairments

Here are the testing tools and techniques you can use to test a web application for vision impairment.

• Test making text larger.
• Magnifying the screen (zoom) should have a linear layout.
• The text has sufficient colour contrast with the background (greater than 4.5:1 for WCAG 2.1 level AA). Use tools such as WCAG Colour contrast checker or similar.
• Test using screen readers like JAWS, NVDA, ChromeVox, VoiceOver
• Test with keyboard only navigation
• Using the tab, enter, and space bar to navigate the page and ensure each input and interaction can be triggered appropriately.
• The keyboard focus does not get trapped in a loop.
• Tab order is logical and follows the visual order of elements on the page.
• Check that the focus is always visible when moving through the page with the tab key.
• Model dialogue boxes needed to trap the keyboard. When a modal dialogue box is triggered, the keyboard focus needs to immediately move to the first actionable element in the modal.
• Check that the focus never goes to elements that won’t be available to somebody using a mouse.
• Check that all form inputs have explicit labels and descriptions. Screen readers also use these attributes.
• Check that all relevant images use an ‘img’ tag.
• Check that all images have ‘alt’ attributes.
• Test using screen readers like JAWS, NVDA, ChromeVox, VoiceOver of mac.
• Speech recognition tools such as Dragon Naturally Speaking.
• Colour blindness simulator such as Color blinding chrome extension.

 Hearing impairment

Hearing disabilities include mild to moderate hearing impairment in one or both ears. Include hard of hearing or deafness.

Design for users with hearing impairments techniques;

• Use plain English.
• Use subtitles or provide transcripts for videos.
• Use a linear, logical layout.

• Break up content with sub-headings, images and videos.
• Let users ask for an interpreter when booking appointments.

Testing techniques for hearing impairments

• Provide subtitles/captions for all video content.
• Provide text transcripts of audio content.
• Check the accuracy of captions.
• Check that the captions are synchronised with the audio.
• Provide summaries of audio and video content.
• Check that the audio doesn’t play automatically.
• Ensure all content is in simple English.

Cognitive, learning and neurological disabilities

Functional cognitive disabilities can range from memory, problem solving and attention challenges through to, reading, linguistic and verbal, math and visual comprehension ones.

Design techniques for users with cognitive disabilities;

• Use simple colours.
• Use plain English.
• Use simple sentence and bullets.

• Make buttons descriptive.

• Build simple and consistent layouts.
• Use images and diagrams to support the text.
• Align text to the left and keep a consistent layout.

• Consider producing materials in other formats (e.g. audio or video).
• Do not force users to remember things from previous pages – give reminders and prompts.
• Keep content short, clear and simple.
• Let users change the contrast between background and text.

 Testing techniques for cognitive disabilities

• Provide clear instructions to navigate through the website.
• Colour contrast for foreground and background (greater than 4.5:1 for WCAG 2.1 level AA).
• Make user journeys simple and easy to understand.
• Provide progress indicators.
• Error messages should be explanatory and in line with the fields.
• Highlighted elements appropriately.
• Provide clear headings and ensure that:
• Visual ‘heading’ elements are identified.
• All visual ‘heading’ elements use an ‘<h>’ tag.
• All sub-heading elements have a higher number.

Physical or motor disabilities

Physical or motor disabilities are weakness and limitations of muscular control. Here are the design techniques we used to ensure accessibility.

Design techniques for users with physical or motor disabilities

• Design for keyboard or speech only use.

• Design with mobile and touchscreen in mind.
• Make large clickable actions.

• Give adequate spacing between the form fields.
• Provide shortcuts.

Testing for physical or motor disabilities

• Use of speech recognition software like Dragon Naturally Speaking.
• All content on the page should be keyboard accessible:
• All content must be keyboard accessible.
• Tab order must be logical.
• No keyboard traps.
• Headings create a logical outline of the page supporting quick navigation to page sections.
• Test with alternative keyboards.
• Provide shortcuts for filling up the forms (e.g. postcode lookup).

Speech impairments

Design for users with speech impairments

Speech disabilities include the inability to produce speech that is recognisable by other people or software. The design techniques for this disability are mostly similar to those suggested for vision and hearing disabilities.

?Automation testing

Axe-core is the accessibility engine for automated testing of HTML based User Interface (UI) of a website for accessibility violations. There are different implementations available for Axe such as Axe chrome extension, Axe firefox extension, Axe-webdriverjs, React-axe, Axe-selenium-java, Axe-selenium-csharp and the Protractor-accessibility plugin.

For the Manage Motor Fuel Greenhouse Gas Emissions project, our QA team built a test automation framework using Axe-Selenium-csharp that ran as part of our daily build, in our CI/CD pipeline.

By following these principles, which included automating and integrating accessibility testing into developing a new service for the DfT, we passed all three GDS assessments first time. That’s practically unheard of.

However, if I’ve missed any disability accessibility angles, do let me know and if you’d like support accessibility testing a project that’s underway or planned, please get in touch.

 Venu Botla, Triad Group Plc

Venu is a passionate QA and Test Automation consultant with extensive experience developing test automation frameworks to support releases with CI/CD pipelines, implementing QA best practices and leading QA teams within the public, private and third sectors. He has helped organisations implement the QA process in Agile teams, integrating testing at each stage of the software development life cycle and preparing automation test strategies to support CI/CD pipelines. He also has a special interest in making web application more accessible and passionate about learning new testing tools and technologies.

Triad has over 30 years working with private, public and third sector organisations drawing on experience in the toughest of environments to identify the right solutions for digital transformation. We can provide extra support developing a Quality Assurance strategy or an automated testing strategy or with resources to oversee and manage your QA and Testing function.

So, whether it’s advice and guidance, project and product delivery, or additional capacity and expertise, we can find the right people to deliver your technology requirements.