Blog

In my last post, I talked about how we use accessibility clinics to help ensure we’re building software that works for everybody. Today, to mark Global Accessibility Awareness Day, we’re sharing the top accessibility issues that we uncover in the clinics.

In each clinic we test a feature or a service using several types of assistive technology. Here’s what we use, and the most common issues we uncover with each tool.

axe

axe is a browser extension for Chrome and Firefox that checks your pages for potential WCAG violations, as well as other issues such as invalid values for ARIA attributes. We run axe on each page and discuss each issue it flags up. Often the person running the clinic will be able to provide the team with a solution on the spot, but occasionally we realise it’ll take a bit more discussion, so we make a note of it and discuss it after the session.

Common issues that axe spots include:

• Colour contrast issues. The WCAG guidelines include strict contrast requirements to ensure that the combination of text colour and background colour is readable. For example, black text on a dark blue background fails the contrast requirements and is hard to read:
• Invalid ARIA roles: ARIA roles let you provide extra information to users on how they can interact with the page. For example a button with role="tab" lets the user know that the button acts as a tab rather than a normal button. However, some elements are only allowed to use a limited set of ARIA roles - so, for example, a button with role="article" isn’t valid.
• Lack of alt attributes for images. Any img tag must have an alt attribute that describes the image for people using a screen reader. If the image is purely decorative and alt text wouldn’t be helpful for the user, the alt attribute should be empty, but it still needs to be there.

Keyboard-only navigation

Being able to use pages with just a keyboard is essential for users who have motor issues that make it painful, difficult or impossible to use a mouse. Screen reader users also often use the keyboard exclusively if they can’t see the mouse pointer. We test each page to ensure:

• using the tab key to move between links and form elements follows a logical order.
• interactive elements can be operated using the keyboard (for example drop-down menus). We’re especially on the lookout for elements that aren’t usually interactive (divs, or spans, or basically anything that’s not a link, a button or a form widget) and have been made interactive with JavaScript (for example mouse or click events), as these aren’t focusable by default, so tabbing through the page will just skip over them. CSS :hover states, for example for dropdown menus, are also ones to watch out for.
• focussed elements are highlighted visually.
• changing a form value (for example ticking a checkbox or selecting an option from a dropdown) doesn’t submit the form or refresh the page. This can be disorientating because when the page reloads the keyboard focus moves back to the start of the page.

Screen reader

NVDA is an excellent free screen reader; however, it’s also useful to test with JAWS as there can be differences between them and JAWS is often used by our government users. Common issues we’ve come across include:

• Not enough context in button or link text. For example, if you have several sections on a page and each one has an ‘Edit’ link, it’s harder for a screen reader user to work out what each link will actually do than if the screen reader read out ‘Edit personal details’, ‘Edit address history’ etc. They may be navigating the links by tabbing through the page, or by using the link list feature:
  
  
  We usually fix this by adding extra text for screen readers; for example, a sighted user may see “Edit” but a screen reader user would hear “Edit patient John Smith”. This can be done either by using the aria-label attribute or using a visually hidden span.
• Skipped heading levels, for example an h3 after an h1 with no h2 in between them. Skipping levels can make the page harder to navigate; for example, JAWS lets users view a hierarchy of the page based on the heading levels.
• Unlabelled form elements - for example, a select element for sorting results without an associated label. A user might be able to infer the purpose of the dropdown from the options but it does make it much harder, and it’ll be marked as ‘unlabelled’ by the screen reader.
• Unannounced changes - This is especially a problem for JavaScript-based pages, where interacting with something (for example, a button) changes something else but doesn’t reload the page. These changes should be announced, for example by using an ARIA live region.

Windows high contrast mode

Windows’ high contrast mode is often used by people with visual impairments to make text easier to read. We test each page in high contrast mode to check that everything’s still usable with the colours changed.

The main issue we find in high contrast mode is when we’ve relied on background colours to separate areas of the page. High contrast mode removes all background colours and images from every element, to ensure text has enough contrast with the background. This can cause issues if a page is relying on background colour to distinguish an element from its surroundings, like a banner:

(This example is taken from the GOV.UK Design System, which gets this right - I’ve broken it here for illustrative purposes)

To mitigate this, we add a transparent border to the element. It’s invisible normally, but high contrast mode makes all borders visible:

High contrast mode also removes all CSS background images, so we make sure none of the images that have been removed are important for the user to see. For example, a patterned background being removed is good because it makes the text more readable, but an image on a product listing page being removed is bad because the user might still want to see what the product looks like. Any images that should be visible in high contrast mode must use an img tag or an SVG rather than being a CSS background image.

We also check that pages aren’t relying on colour alone to convey information. This is also essential for making sure that users with colour blindness are able to use the page, even if they’re not using high contrast mode.

Accessibility is a big field, and this is just a small sample of the most common issues we come across. Every project is unique, and that’s what makes accessibility clinics and accessibility testing in general so valuable. Even if you’re following established patterns or using a well-tested framework such as the GOV.UK Design System, you’re not immune from issues, either in the framework itself or in how you’re using it. Accessibility clinics are a key part of how we educate people on the issues and make sure everyone knows the critical role they play in building services that are accessible to everybody.

1 in 7 people globally are challenged by inaccessibility. As an organisation that delivers digital services to the public sector, we know how important it is to ensure services are accessible. Accessible services help public servants deliver often critical support to those that need it - quickly and smoothly.

Join us. We’re always on the lookout for like-minded people to join us on our quest to make accessible software that really matters. If you think this is you, then get in touch with us, we’d love to hear from you.