• Introduction
• Choice of code framework
• Versions matter
• Designing for native apps is different
• Applying accessibility best practice
• Checking apps for accessibility
• The need for closer team collaboration
• Wrap-up
• Further reading

Introduction

Mobile app accessibility has some similarities with web development, but it is also important to be aware of the differences so we can account for them during development.

This article assumes some knowledge of how websites manage accessibility and is mainly aimed at web developers and designers who have made the jump to app development.

Choice of code framework

The official frameworks are SwiftUI on iOS and Compose on Android. These will give you access to the best accessibility features to use when coding your interfaces as they use the native languages for each platform. Frameworks which allow you to code once and then deploy both iOS and Android apps from the same codebase (such as React Native) can end up sacrificing accessibility in order to do this.

The choice of framework may only be found to be an issue when an accessibility issue is raised and you find that the one you are using cannot support the code you need to write.

Using native languages is perhaps the ultimate “shift left” for accessibility. Yes it is extra work writing to those two codebases but it means you can ensure you are likely to be able to support most accessibility improvements. But it is not without tradeoffs in speed of delivery and consistency.

Versions matter

Just as different browser versions support different features of CSS, different versions of iOS and Android support different accessibility features. This may require conditional logic within the app to determine if these features can be used.

Designing for native apps is different

If you are used to designing responsive web-based products, there are differences in how native mobile apps should be approached. A native app needs to be considered in a different way to a mobile view in a browser.

Websites have a lot of accessibility features they can use to help users understand content. HTML is heavily semantic at its core and ARIA allows designers and developers to be really explicit about how accessibility is translated to the user.

On native mobile this is not as clear or as well developed. We need to keep native mobile interfaces simple and avoid complex components. For this reason just porting a responsive website's mobile view to a native mobile app is potentially going to introduce accessibility pitfalls, especially for screen-reader users.

Tools for designers

• Include Figma plugin from eBay
• iOS Annotations Figma plugin from CVS

Applying accessibility best practice

The first thing to appreciate when designing or building native mobile apps is that WCAG still applies. Whilst WCAG was not directly written for native apps (it was originally written before they existed), most of the criteria can be applied to them as WCAG is platform agnostic.

The W3C created a guide to help teams understand how WCAG principles apply to mobile. Whilst this concentrates on mobile versions of websites it does contain some useful reminders for how small screens and predominantly touch-based devices can affect a design.

Let's have a look at some specifics of things which should be considered when designing or building a native app.

Checking apps for accessibility

We will be discussing some visual adaptations and assistive software but in particular what we need to think about when looking at native apps.

Roles

Just as on the web, native apps can communicate some semantic information in how the components are coded. On the web this is done using particular HTML tags or explicit role attributes. On native these are done by using accessibility traits.

These can be checked using tools (see below) or a screen-reader.

Accessible names

Images should in most cases have good alternate text descriptions as you would normally do. Form inputs should be correctly labelled, and links and buttons should have accessible names. On native apps these are referred to as accessibleLabels but are just as important.

These can be checked using tools (see below) or a screen-reader.

Headings

iOS supports different heading levels, but Android does not, so whilst iOS users can determine hierarchy from the different levels of headings this is not something Android users can benefit from.

Frameworks which compile down to both iOS and Android such as React Native look to have devolved to the Android state. This means even when iOS supports an accessibility feature this can be prevented from being used by the framework.

Colour contrast

Checking colours on-device can be tricky but if you can mirror the device to your development computer screen it makes it easier. Otherwise you may need to screenshot the app and export it to somewhere you can use a contrast checker with a colour picker, such as the TPGi Colour Contrast Analyser.

Dynamic content

On the web where we have dynamic content we can use ARIA live regions to keep screen-reader users up-to-date with changes to page content.

We need to do the same with our native apps, whether this is error messages or other notifications.

Touch target size

With the small size of mobile screens we can find we have scaled down controls too much in an effort to squeeze them all in.

Touch targets need to be a minimum of 44 by 44pt on iOS, and 48 by 48dp on Android.

Larger font sizes

Many users will adjust the font-size on their devices to make it easier for them to read content. Native apps should support this by using responsive fonts (on iOS this is known as Dynamic Type and as Scalable Pixels on Android).

Whilst using responsive fonts is the first step, you also need to ensure the text is allowed to expand as it grows. Otherwise text can be cut off or truncated and become unreadable.

We are firstly wanting to check that the font actually increases in size in response to the user's preferences.

Once we are happy that is happening then we also want to check that all the text is still readable and none of the previously readable content has been cut off or otherwise truncated.

On iOS there is a “Larger Accessibility Sizes” toggle which gives access to 5 larger font sizes than those in the standard display settings. These should be tested too. Apps may have areas where these larger fonts cannot be displayed (such as in the tab bar). Where this is the case the app should make use of the iOS “Large Content Viewer”. This allows the user to long press on the item to see a zoomed version of it on-screen.

Note the Large Content Viewer should only be used where sizing text is not possible - such as the tab bar where sizing the tabs up would obscure the main content. It should not be used for body copy or where layout changes could allow larger font sizes.

Larger display size

Android also has a setting called Display Size. This increases the size of UI elements (such as icons) which just increasing font sizes does not.

Larger display sizes should also be tested in conjunction with larger font sizes as it likely these will both be used together.

Orientation

This is something often overlooked on native apps. Take a look at some of the apps on your phone. How many of them rotate their view when you turn your phone to landscape?

Orientation is a user preference and so should be respected and supported just as we do on the web. Some users may not be able to use their devices in any other way other than landscape.

The app should be viewable in both portrait and landscape. Crucially here we also want to check that not only has the orientation switch worked but also that nothing in the layout has broken as a result, and content can still be read.

For example Audible on Android does not switch orientation until you have selected and are listening to a title when it does present a landscape mode.

Larger viewports

We can forget to review designs for how they present on larger viewports. For mobile apps in particular we need to think about tablets and how that extra real-estate can affect accessibility.

For example a button attached to the right side of the screen on mobile may not cause any issues, but on a tablet not adjusting the design can lead to that same button being very isolated. This could cause issues for some users such as those using screen-magnification.

Also be aware that other components may change between these device types. For example on iOS main navigation will be shown in a tab bar at the bottom of the screen, but on iPadOS it will move to the top of the screen or even as a sidebar. These different versions will need to be checked for contrast and keyboard accessibility in both versions.

Voice Entry

When users are being asked to enter data into fields not all users will want to type an answer. Virtual keyboards allow voice entry now by using the microphone option. We need to ensure input fields which we present to users do not prevent this type of entry, but also that we are forgiving of simple issues this may create.

Switch control

We can set up an external keyboard (see below) to act as our switch input, just as we might on a laptop.

Switch control can work slightly differently on native apps than it does on websites. By segmenting our screens we can present groups of controls which a switch control user can navigate in sets to reduce time in making a selection.

Another thing to consider is avoiding reliance on gestures to control the interface. Whereever gesture controls are added it is best to have a non-gesture option.

External keyboard

Just as with websites, keyboard access is often overlooked, but this happens a lot more with native apps as the assumption is users will be using the touch-screen.

The easiest way to test is by using an external bluetooth keyboard.

On iOS in order to move through an app using a keyboard you will need to turn on “full keyboard access” under Accessibility in Settings.

On iOS you also have the option of using “keyboard gestures” by using the Tab + G command. This then allows you to make swipe gestures. However bear in mind that not all users will be aware of this and Android phone users do not have this option. It is always best to provide keyboard users with buttons to accomplish what other users may do with gestures.

Navigating within the app will be a mix of tab and arrow keys, but arrow keys will be the primary way. This differentiates native app testing from website testing and can take a little getting used to.

Other than how you navigate, we are looking for largely the same issues we might with websites - can we reach and activate everything and can we see where our focus is easily?

Screen-readers

Screen-readers work largely as they would on websites. In fact it is easier to test on mobile apps because there is one less complexity - the absence of the browser. We are also only going to need to test with the native options - TalkBack on Android and VoiceOver on iOS and iPadOS.

One thing to note is that native apps may not announce roles (or traits) in the same way as websites do. For example a button may just announce the label and “Double tap to activate.”

On/off labels

This is an iOS-specific user setting. It adds an "on" or "off" text label to switches within the app to help users who may have difficulty determining the state of the switch. We should verify that any toggle switches are correctly updated when this option is set.

Other tests

These tests will work very much as they would with websites:

• text-to-speech - Select-to-speak (Android) and Spoken Content (iOS)
• speech-recognition - Voice Access (Android) and Voice Control (iOS)
• colour filters - Simulate Colour Space (Android) and Colour Filters (iOS)

Testing tools

On native apps we don't have access to code in the same way as you do with websites and browser developer tools. However there are a couple of tools which can help with some basic checks.

Android accessibility scanner

This is an app which you install on the same device as the app you are testing. It then appears as a floating button which you activate when you are on the app you want to test. You can choose to snapshot test the screen you are currently viewing, or set it to record and it will check as you move through the app.

With either method it will generate an interactive overlay where you can zoom in on particular issues. You can then export this set of results via email.

Issues this scanner may find include:

• using height or width restricted containers for dynamic text sizes
• colour contrast issues
• touch target size
• missing labels on elements
• duplicate labels or descriptions
• unexposed text (visible text which has been hidden from assistive technology)

XCode Accessibility Inspector

By connecting the device running the app to a Mac with XCode this will allow you to inspect the various elements on the screen with the Mac's “Accessibility Inspector”.

The inspector has 3 modes: “Inspection”, “Audit” and “Settings”.

Inspection

This is useful for spot-checks on specific elements or helping with debugging an issue you spotted with something like VoiceOver or Voice Control. It allows you to pick an element and see a bunch of information such as traits.

It also has a VoiceOver emulator which allows you to hear the elements read out (through the Mac) as a VoiceOver user might hear it. This can be handy for some quick checks but should not replace testing with VoiceOver on the actual device.

Audit

This allows you to run a scan on the current screen and get a list of potential issues. You can also bring up a screenshot of the screen with the item being talked about in the issue highlighted.

Settings

This allows you to control certain OS-level preferences such as font-size, reduce motion and more. This feeds off the device settings so it will display any existing state of these settings here. Updating one of these will also show immediately on the attached device, so it is a good way to check some settings quickly.

Note that the upper half of the font-size slider here equates to the “Larger Accessibility Sizes” toggle on the device. So the maximum setting of the slider in the Inspector settings is equivalent to having the Larger Accessibility Sizes setting toggled and the font-size slider on device all the way to the right.

The need for closer team collaboration

HTML is a fairly easy to understand language. Even if a designer is not comfortable with writing it they can follow along as it is a succinct set of tags which are largely readable. When it comes to native app development it is much more akin to using javascript to create DOM nodes from scratch and assign attributes. This abstraction coupled with the need for more specialist software to build apps and the associated learning curve means it is more difficult for designers to engage directly with the code.

As such it is vitally important that designers and coders of native apps work closely together to develop accessible solutions.

Wrap-up

Just as with websites, native mobile apps need to consider accessibility and implement a range of checks to ensure we don't leave users behind when we move from the web to native.

Further reading

General guidance

• Intro to mobile app accessibility
• Appt guide for making apps accessible
• Evinced mobile app accessibility guidelines
• Mark Steadman on BlueSky
• Dani Devesa on BlueSky

iOS references

• iOS Human Interface Guidelines - accessibility section
• iOS developer guidelines - accessibility section
• SwiftUI Accessibility Fundamentals
• CVS Health iOS SwiftUI

Android references

• Android accessibility principles
• CVS Health Android Compose
• Building accessible Android apps with Jetpack Compose

Contents

• Auto-playing full-screen video
• Not respecting user preferences for reduced motion
• Alt text
• Not updating ARIA
• Menu dialog issues
• Headings
• Inaccessible links
• Use of title attribute
• Poor contrast
• Missing programmatic information
• Other issues
• Verdict

Auto-playing full-screen video

The Whitehouse website has a full-window video auto-play when you first visit the site (edit 18 Feb 2025 - it looks like this may now have been removed).

Having a large video auto-play on page load is an issue for some users - we can’t assume users will know how to set a preference so we should always avoid this kind of addition.

It is also not great for first impressions as on slower connections it can stumble. At 8.4MB it is also a heavy load for users on data limits. Disabled users in general have lower disposable incomes due to employment issues and additional expenses, so this is an accessibility issue.

On the plus side at least the sound is muted and the user can dismiss the video immediately (although even doing that allows 4.2MB of video download). On 3G I ran out of patience before the video even loaded.

Thankfully you only see it on first visit as a local storage flag is set.

Not respecting user preferences for reduced motion

Related to the first point, the website does not respect where a user has asked for reduced motion in their settings.

The auto-playing video, the heavy use of zoom effects in hover states and animation of the carousel on smaller viewports can all trigger issues for users.

There are simple mechanisms for websites to check for this setting and adjust the interactions based on it.

Alt text

Missing alt text

There are a couple of places where alt text has been left blank. For example the 47th president logo and adjacent signature. These could have been given explanatory descriptions as they do mean something.

Repetition caused by alt text

Elsewhere alt text has been used and created repetition where a better pattern would have prevented it, such as the 3 links to "White House", "Camp David" and "Air Force One" towards the bottom of the page:

Here the images are the links and the text above is unlinked. The images each have alt text which repeats the text above. So a screen-reader will get repeated content as they move through - it will be announced something like this:

“Camp David, Camp David link”

A better solution would be to use a card pattern which would use the text as the link and add a click-handler to include the image. This would allow users to click the text (as well as the image) and also allow us to add proper descriptive alt text to the images. For example:

<div class="wh-card"> /* js click handler added to this container */
  <a href="...">The White House</a>  
  <img src="wh.webp" alt="Exterior of the White House on a summer's day" />
</div>

Overly basic alt text

Finally on images, the two large images of Trump have very basic alt text of “Donald J Trump“ which whilst true does not put across any of the emotion I am sure the designers are intending to convey with those images.

Not updating ARIA

The search button in the top right has an ARIA attribute applied to indicate that it triggers something which is currently closed:

​<button aria-expanded="false" title="Open search">Search</button>

But when the button is pressed the ARIA is not updated which then conflicts with the information the user is now getting from the accessible name (which has been updated):

​​<button aria-expanded="false" title="Close search">Close</button>

Oddly the team managed to do this correctly with the menu dialog.

Menu dialog issues

Keyboard

When the user opens the menu dialog keyboard users are not restricted to the modal. A keyboard user can tab to the page behind the dialog which can mean their focus becomes obscured.

Screen-readers

Screen-reader users don't fair much better as once the modal has opened the close button is unreachable as it sits outside the dialog bounds despite being visible.

We can see the issue when we look at the elements list for NVDA and see the buttons are there when the dialog is closed:

But the same elements are missing when the dialog is open, despite being visible:

Fortunately the dialog has been hooked up to be closed via the Esc key so both users can close it if they are aware of the shortcut.

These issues are most likely a result of using role=”dialog” instead of the dialog element and not thinking through the impact of doing this. The dialog element brings with it some functionality, such as making the rest of the page inert and trapping focus. Using role=”dialog” is the equivalent of using role=”button on a div - you need to bring the functionality yourself.

Missing accessible name

Using a role=”modal” also requires that you give your modal an accessible name, for example using aria-label. This is not present here so adds another issue.

Headings

It is important that headings are correctly applied as they are one of the main navigation methods for screen-reader users on longer pages. They also give an indication of grouping of content and provide an important introduction to the content the user may find next.

Missing semantics

On the homepage "The Administration" text which introduces the photos of the president and others is just marked up as plain text:

​<div class="wp-block-whitehouse-front-administration__headline">
  The Administration
</div>

So if we take a look at the HeadingsMap browser extension (which lists all headings on a page and constructs a tree diagram) we can see that the first heading we will encounter after the h1 is actually below this group:

Non-unique headings

Another issues is that we can also see from this list that despite the h2 further down the page visually saying "About the White House":

This is not what is communicated as the "About" is actually sitting outside the h2:

​<p>About</p>
<h2>The White house</h2>

This then means we have two headings adjacent to each other with the same content, but with different levels and with different meanings. The word “about” needs to be included in that h2 - something which should happen even if it didn’t cause the non-unique error.

Inaccessible links

While we are looking at the Administration section, the links for the 4 items are unreachable for both keyboard users and screen-reader users. This is also the case for the "Executive Actions" and "News" links above. This constitutes the majority of the content on the website.

Looking at the code it looks like there has been a decision made to not wrap the link element around any content, but instead use CSS to position it above the content:

​<a href=".../jd-vance/" aria-hidden="true" tabindex="-1"></a>
<img src=".../jdvance.jpg" alt="" />
<p>J D Vance</p>

The lack of accessible name on the link is obviously one concern, but the link also has an aria-hidden attribute (which hides it from screen-readers) and a tabindex="-1" attribute which removes the link from the focus order. Both are very conscious decisions and suggest they are attempting to implement a card pattern.

The card pattern would normally have included making the main call-to-action (in this case the name) a link and letting keyboard and screen-reader users discover that and then have some positioned area as a mouse/touch option covering the whole card.

Looking at a fix

So the first step in fixing this would be to link up the main text for each item:

​<a href=".../jd-vance/">J D Vance</a>

This works, however we still have our odd, heavily attributed and nameless link. Adding aria-hidden to a control such as a link is never a good idea as it causes a slew of odd behaviours.

For example if we just left it like this, then screen-readers suddenly start picking up both links (the initial one is now showing as the document name from the href):

For this to work as we want we need the card link to be removed and instead replaced by a click handler on the container. This is ok as without js we still have the new link to fall back on.

<div class="container"> /* add click handler to this using the link href as target */
  <img src=".../jdvance.jpg" alt="" />
  ​<a href=".../jd-vance/">J D Vance</a>
</div>

We can improve this further by swapping the position of the image and link and adding alt text to the image. We could even include the secondary text as part of the link.

But at least now the content will be usable!

In short, never use aria-hidden on interactive things.

Use of title attribute

The title attribute has been used a lot on images and controls across the site. The title is problematic because it has a dual nature. It is really an accessible name source of last resort - so if there is no 'standard' accessible name provided (via content, alt text, labels or aria) then this would be used. However where an accessible name is provided the title is demoted to an accessible description, which means it will be read out after the given accessible name.

For example, the White House logo at the top of the screen:

​<a href="..." title="The White House">
  <img src="..." alt="" />
  <span>The White House</span>
  <span>President Donald J Trump</span>
</a>

Will be read out by a screen-reader as

"The White House President Donald J Trump The White House"

Whilst not a major issue this repetition can become confusing and is unnecessary.

Poor contrast

It wouldn't be a list of accessibility issues without at least one for poor contrast. While the text overlaid on the images on the homepage could potentially cause issues, I am going to look at one of the subpages for a more clear-cut example:

Here we can see the sub navigation has poor contrast with the exception of the currently active page. The contrast here is 4:1 which is below that required for AA conformance.

When the contrast is so close to passing it is not going to require a full re-think of colour choices. Here the non-selected links are set using a 0.42 opacity of the white colour. If we tweak it to 0.62 opacity instead:

We now get a 7.4:1 contrast which is a pass. However we are left with another issue.

The original 0.42 opacity gave us exactly a 4.5:1 contrast with the selected option and increasing the opacity has made this worse. I think here we should be looking at adding an extra visual indicator for the current page, such as the underline used on other pages:

Missing programmatic information

Another issue with this navigation is that whilst it is showing the current page visually through the colour change, this is not being reflected programmatically.

This is simply done through the use of aria-current=”page” on the currently active link:

 <a 
  class="is-current" 
  href="https://www.whitehouse.gov/presidential-actions/" 
  aria-current="page">
    Presidential Actions
  </a>

We could even use this as a hook for CSS to help us improve our accessibility right at the start and get rid of the is-current CSS class entirely:

[aria-current]{
  ...
}

You could try to argue that the h1 does this job (and I suspect this is what the thought process was with this as the aria-current attribute is used elsewhere), but we cannot assume screen-reader users navigate sequentially or understand the relationship between these two components.

Other issues

These are just the main issues which jumped out at me after a quick look and only picking up a screen-reader. But there are other issues, such as poor error messages on the email form (along with a lack of error announcement for screen-reader users) and missing autocomplete on the same (although this is likely not to be an issue as most broswers will do a decent job of figuring this out in this instance). This administration has also removed the Spanish language version of the site, which in one move has made accessing information more difficult for a huge group of users.

This does show however that just a few simple checks can expose some quite major accessibility issues.

Verdict

I think it is good to say what a team have done well, so here are a few accessibility areas where they did ok too:

The dialogs are dismissable with the Esc key - without this the other issues would be more serious.

Landmarks are being used which will help screen-reader users. They have used several nav elements and whilst the footer ones do not have accessible names, where they have been using in-page such as for pagination controls, these have been given meaningful names.

Skip to content link is present and most importantly actually works, taking keyboard users beyond the main navigation.

In the main the team have used semantic elements. This goes a long way to improving accessibility, although they have shot themselves in the foot a couple of times.

ARIA has been used but not massively overused. Yes they have made some mistakes but you can see the thought process and adding some testing will help with these.

This goes to show that regardless of how your stakeholders view accessibility, there are accessibility wins which you can bring to a project just as part of doing your job.

• Introduction
• Accessible by default
• Time and budget
• Think about the entire journey
• Using 3rd-party services
• WCAG AA is the baseline, not the aim
• Team responsibility
• Embedding accessibility in team processes
• Dealing with accessibility debt
• Wrap-up

Introduction

Accessibility is a complex thing and it involves all aspects of a product's lifecycle from the initial idea, to design, development, testing and maintenance. It also needs support to be implemented cohesively and robustly.

Without a process to work to we become too reliant on the goodwill of individuals and when these individuals leave accessibility knowledge and practice leaves with them. Processes mean the entire team is brought along and accessibility becomes part of everyone's job.

Accessible by default

We should not see accessibility as an add-on or a nice-to-have, it should be just part of how we work, whether that is during kick-off discussions, during a discovery phase or during a build. We should never see accessibility as something we can deprioritise or leave until later.

Time and budget

Accessibility in a project will add some additional time (and budget), but it will result in a much better product.

Make sure you allow time for your team to get up to speed and learn as they go. Think about avenues for help for the team - is there an in-house an accessibility team they can run things past for example? Think about setting up some process right at the start of the project (see Definiions of Ready and Done below).

The most important thing is don’t wait - it is never too early to start thinking aout accessibility and including users in your discovery phase.

Finally, make sure you schedule time both to prepare and undertake accessibility audits (especially if your team is in the Public Sector).

Think about the entire journey

Accessibility doesn’t start and end with the code we put on a screen. The user has to get to the product in the first place - how do they do that? Is it through a social channel, an email, a print campaign or something else? Are we looking at the whole journey and making sure it is as accessible as possible?

It’s no good if the online product is accessible if the social media posts are not.

Also think about the off-ramps from the product. Are contact mechanisms capable of supporting all the users - is there a range of contact options to allow users to choose the one which might suit them best? How about 3rd party integrations such as help-desks? If a user needs to raise a support ticket can they use the platform provided to follow it up?

An example of poor ancillary communication methods is a case against DWP where it was found they had discriminated against a blind user by not providing communication in an accessible format.

Then think about any support staff, are the systems they work with accessible? How about how the user logs into the product? Are those authentication methods accessible?

Using 3rd party services

If you are embedding or paying for 3rd party services then the responsibility for their accessibility comes down to your product. Do some investigation before signing up to any 3rd party services and where possible ensure accessibility is covered in any contracts.

Claims of WCAG compliance is one metric but it is often cited with no real data to back it up so treat such claims with caution if there is no evidence or demonstration of processes. Look for the ability to request fixes to bring in compliance where it is lacking. This expectation of the level of support should be covered in any contract.

WCAG AA is the baseline, not the aim

There is often a confusion that WCAG AA compliance should be the aim of a product. Unfortunately this would leave a lot of users behind as the WCAG criteria are not all-encompassing. There are lots of ways a product can be WCAG compliant but place barriers in front of their users.

Because of this we should view WCAG AA compliance as only the baseline for accessibility. We should always aim beyond this, leaning on testing with actual users, assistive technology and devices to bring a holistic approach to accessibility. If a user is having problems with a product, pointing to your WCAG compliance statement is not going to help them.

Just working to passing WCAG rather than true accessibility means we are just doing the bare minimum to make something just accessible. That's not enough.

Read more about WCAG, guidelines and legalities.

Team responsibility

Everyone, regardless of their team role, can contribute to making a product more accessible. We should never leave it to one person on the team to always be pushing for accessibility. Having one person with sole responsibility means others aren’t contributing their own valuable experience and makes it too easy for pushback. It also means the team never upskills. Reliance on a single person will mean they will quickly get overwhelmed and burn out as they try to fix issues caused by the rest of the team.

The only way forward is for everyone to take responsibility for their area. Look at drawing up a RACI matrix to show who is responsible for what at each stage of the project.

Example RACI matrix

This example shows that each role is responsible for their own section and shows how responsibility for accessibility moves through the team along with the work. Notice also that previously responsible team members still need to be consulted so that solutions are correctly implemented.

• A = Accountable (the person ultimately accountable for the task)
• R = Responsible (the person doing the task)
• C = Consulted (people who should be involved in decisions)
• I = Informed (people to keep in the loop)

Embedding accessibility in team processes

“Accessibility lives in people, processes and tools”

Derek Featherstone

Our aim should be to have accessibility embedded in the team processes so everyone knows their role and no one person is taking on all the accessibility work and responsibility.

Treat accessibility issues as bugs

This means we treat accessibility issues as what they are - bugs, not features. Any other situation where users are having barriers placed in front of them by the code or design would be jumped on, but for some reason if it is an accessiblity concern it tends to get put way down on the backlog.

Having the accessibility-issues-as-bugs mindset will push us more to fixing any accessibility issues in the current ticket within that ticket’s timeframe rather than spinning off another ticket to fix it later.

Real-world testing

Where possible we should be including people with assistive needs in all stages of our product design and development. This goes hand-in-hand with real device testing to ensure what we are producing both satisfies the needs of the user and the abilities of the technology they use.

How users have their assistive technology or adaptations configured can impact on how they interact with the product, so getting this insight early on is key to developing a truly accessible product. Try to work in regular user testing throughout the project.

Consider accessibility in every ticket

Sometimes accessibility will obviously not apply, but if we get into the habit of at least thinking of how accessibility might play into a ticket then we go a long way to catching issues before we write any code, and that is where the savings really come. See Definition of Ready below for more on this.

Implement robust testing

Good accessibility testing means multiple stages and types of tests.

Testing should begin at the design phase and follow through all the way to go-live and beyond. The person responsible for delivering the content, design or code is ultimately responsible for ensuring this testing is done and what is delivered is accessible.

Designs in particular need to consider how different groups of users will perform the required tasks and how the design will adapt to different user preferences such as font size. Questioning designs before they are passed onto the development team is an important aspect of this. All this information needs to be communicated to the development team .

• manually triggered automated testing on design documents, during code development, code reviews and QA testing
• automated testing as a pipeline tool for continual baseline assurance
• manual testing to catch issues automated tooling cannot, again at all stages of development. This can range from simple keyboard tests to more complex assistive technology testing.

Testing is something which team members need to be aware of and then know how to conduct so there is a bit of a learning curve. Like many skills this will become easier with continual application.

Some tests such as screen-reader checks will require more effort but a few simple commands can cover most of the requirements.

Read more about testing strategies

Add automation but don’t rely on it

Automated tests in accessibility are useful but should not be relied on to take care of your accessibility concerns for you. Automated tests can only check against specific criteria and a lot of accessibility depends on context and wider aspects of relationships and information conveyed by the page as well as different states.

Because automated tests do not have the contextual awareness needed to check effectively they are often cited as only being able to find around 30-40% of issues.

However this does not mean that automated tests are not useful. They should be seen as a baseline - a zero failure in automated tests is an easy benchmark but should be seen as the minimum start-point.

Automated testing in a pipeline can be very useful in flagging any issues creeping in, it will allow you to see when things are getting worse, but also when things are getting better. If the team has access to this data it can be just the mental boost they need.

Manual testing will be required to take us beyond that and into true accessible products.

Definition of Ready

When looking at work which needs to be brought in to a sprint, take some time to look at how accessibility requirements might be addressed.

Be really specific when asking questions - for example “How will someone using speech recognition access the information on this page and navigate successfully?”

Annotating designs in Figma or Mural can help convey important information about desired page markup (such as relationships between content, heading hierarchy, non-visual copy, or use of ARIA) to developers and will help inform questions before the work is started.

Some questions to ask:

• how will this work on smaller viewports?
• does the content have the appropriate reading level, are we using language which can cause issues such as metaphors?
• what is the heading hierarchy - does it follow the visual hierarchy?
• will someone who cannot see the screen still get the information and the relationships between the content?
• do all the interactive elements have focus indicators?
• do non-decorative images have meaningful alt text copy written?
• are all the different error messages considered and are they helping the user fix the issue they are facing?
• do visually-identical links have hidden contextual copy to make them unique for screen-reader users?
• are interactive elements without visual labels given meaningful accessible names so they can be addressed by speech-recognition users and understood by screen-reader users?
• does this journey require users to remember details from previous pages?
• is there a need for the user to do work which we could do for them?
• are we making any assumptions? For example are we assuming how a screen-reader would work with this component or have we actually tested it?
• be prepared to take a ticket back to the design phase if accessibility issues are raised. It is better to have an accessible design to work from rather than build an inaccessible one and have to retro-fit accessibility later.

Think about each user group, for example:

• screen-magnification users
• screen-reader users
• switch users
• keyboard-only users
• speech-recognition users
• users with reduced dexterity
• English as a second language
• users with memory impairments
• user who find dealing with numbers difficult
• users with cognitive difference such as ADHD, ADD, dyslexia
• colour-blind users
• users with vision impairments

Depending on the specific work a set of accessibility requirements can be drawn up. For example:

As a sighted keyboard-only user

In order for me to successfully navigate the page

I need interactive elements to show a clear focus indicator

Definition of Done / PR ready

Issues found after the code has been merged will normally become the responsibility of another ticket in the backlog, rather than be fixed at point of causation. It is only by finding and fixing issues as they are created that accessibility will be seen as an integral part of development practices.

The desired outcome here is to effectively add a release gate so we are not introducing accessibility issues to the codebase which will need to be picked up later at a greater cost.

Any accessibility failures should be found and fixed before a PR is raised, but the code review should also look at potential accessibility issues which have been missed.

When looking at the outcomes of a piece of work, specifically when it is a code ticket there are some tests we can do to ensure the work is accessible, beyond what has been raised as part of the Definition of Ready. These checks should be done both by the ticket-holder but also by the code-reviewer.

1. View the page being worked on in the browser. It is often eye-opening how often this simple check can be overlooked. Whenever work is done on a page which is rendered to the user the page should be viewed to verify the output.
   • If the changes are complex also verify how the page renders in different browsers and devices.
2. HTML validation - while this may not always expose an accessibility issue it is an easy check
3. Check no issues are raised by automated tools (such as Axe or Wave plugins).
4. If using a pattern library, verify the page follows the guidance - these often have a lot of advice around how to code up specific examples and are not just for designers.
5. Check all hidden copy (including those added using aria and alt attributes) are correctly rendering (no-one likes exposed message keys) and translated where applicable.
6. Finally, manually test the page. This is the most important aspect when it comes to accessibility as so much in the published specs is not supported in assistive technology or cannot be checked with automated tooling.

Dealing with accessibility debt

It is often the case that accessibility only gets raised as an issue part-way through a build, or even at the end after launch. Whilst it will now cost more in time and budget to fix any issues found it is still important to tackle any potential accessibility debt.

First you should put in place some processes to avoid technical debt from increasing any more:

• set up automated checks in the pipeline if possible to help give some baseline metrics and show if the debt is getting larger (and help with a morale boost when you start to reduce it).
• use the steps outlined elsewhere in this article to embed accessibility in the team processes and limit the number of new accessibility issues being introduced

Then you need to know how big of an issue you may be looking at:

• find out what you don’t know - use a full accessibilty review of the product to find out what issues you have
• make sure issues from this review are recorded on the backlog with an epic so progress can be tracked

Work through the issues which you find:

• triage the issues and prioritise them
• set some realistic timescales for fixes
• add firebreaks into feature build timelines to allow the team to fix accessibility issues
• document the current state and keep track of progress to keep the team and stakeholders informed and motivated

Wrap-up

It may not be perfect immediately. Accessibility is tough and some aspects may seem simple but have hidden complexities. You will likely make mistakes.

Take it one step at a time, it’s easy to get overwhelmed. Processes help keep everyone on the same page and provide structures of support.

Just make it better today than it was yesterday.

• Contents
• Introduction
• Custom styles
• Page zoom
• Screen-magnifiers
• Font-size increase
• Hardware assistance
• Switch controllers
• Eye-tracking
• Text-to-speech
• Screen-readers
• Speech-recognition
• Windows High Contrast
• User preferences
• Wrap up

Introduction

It can be very easy to fall into the trap of only considering the type of browsing and input methods which we ourselves use every day. For many in digital teams this is heavily mouse-oriented, but not thinking about how others may interact with our products can lead to unintentionally excluding users.

Whilst we will be exploring screen-readers and speech-recognition, there are a lot of different adaptations users might use and which we need to consider when building accessible interfaces.

The economics of assistive technology

Before we look at specific assistive technology we should take a moment to look at how disabilities can affect the performance of some technology.

Users with disabilities are more likely to have a lower disposable income than those without. This can have a knock-on effect in the age of hardware or software being used due to the costs involved in keeping them up-to-date. On top of this is the concern that any software update - either to the operating system, the standard software or the assistive software - will render the computer unworkable or mean time having to trouble-shoot or relearn interfaces.

For this reason it may be that the user of some of the following may not be using the latest version of the technology stack. This along with the additional processing overheads of running assistive technology can mean poor performance metrics for websites can have a greater impact on these end-users.

Do not assume conditions based on tools

When looking at supporting particular assistive technology it can be helpful to concentrate on the tool first. These tools are used by a myriad of users for many different conditions so do not assume that a particular tool is only used by one group or that one group only uses one tool. Users are just as likely to jump between tools based on their current needs.

For example a user with low vision may use a screen-magnifier but switch to a screen-reader when they become tired. Users may also have multiple conditions and use a selection of tools in concert.

Design for no tools

Something else to bear in mind is that not all users who would benefit from assistive technology may be using it. They may not be aware of the existence of the different options, or they may not be confident enough to install and use it, or they may just not consider themselves as needing it. We should build our interfaces to as much as possible be accessible without users having to rely on tools to make it so.

Custom styles

When we design a page we are making a lot of assumptions about our user, but it is also not possible to produce a design which accomodates all users to the extent that might be optimal for them.

Whilst this should not stop us designing as accessible a page as possible from the start, we need to be aware that some users may need to go beyond what we provide and we should not prevent them from adapting our design themselves.

The most common way a user may adapt our page styles is through use of a custom style plugin for their browser. This will allow them to change various elements of the page.

Something to be aware of here is that the more specific our styles are (for example styles set on the element itself, rather than using the css cascade), the more styles the user then has to override with their own and the harder it will be for them to adapt your site.

Page zoom

This is something which all desktop browsers have available to them. These allow the entire page to be zoomed up to around 500% in increments.

Something to note here is that this will typically trigger a mobile viewport style, so even if you are not expecting mobile users you still need to develop and robustly test a mobile-friendly style. These users will be using keyboard on that view rather than their fingers as they would on an actual mobile, so we need to test that mobile view with keyboards too.

As some users may require a higher level of zoom than this allows, they may prefer an alternate method or combine this with another.

Screen-magnifiers

This is a piece of software which might be either built into the operating system or installed and which acts as a magnifying glass on the screen. These can take various forms:

• full-screen - the entire screen is zoomed
• split-screen - half the screen is retained at standard zoom and half shows the zoomed view. This can help users with orientation on a page.
• picture-in-picture - essentially a digital magnifying glass shows a small section zoomed

They can be set to different levels of magnification suited to the user and the user can adjust the magnification to suit different situations.

The main thing to be aware of with this type of magnification is that the user has a much reduced view of the wider page - it could be as small as a few words across. This can then impact on the understanding of how elements visually relate to each other but also on cause-and-effect interactions.

For example when a user clicks on a button and something happens at the top of the page, someone using a screen-magnifier might not see this - to avoid this we should look to closely locate triggers and the things they trigger so the effect is easier to understand.

Font-size increase

Browsers also have the option to just increase the size of the text. This tends to be hidden in the browser settings menus (except for Safari on iOS) but generally allows text to be increased up to 200%.

This is useful because it preserves the layout of the page (it doesn't switch to a different viewport layout like page zoom does) and be a better user experience because of this. However because it is not something which is tested during development we tend to see broken layouts when this is employed.

Container heights set in absolute (rather than font-size-relative) units mean they don't scale along with the font. This means text either gets cut-off or overlays other content.

Hardware assistance

Outside of software assistance, some users may also use hardware to assist them. An example of this is a keyboard overlay to help a user with mobility issues to only trigger the key they want and not inadvertantly trigger neighbouring keys.

These type of adaptations may not directly impact how the user interacts, but is worth keeping in mind as it can illustrate the difficulty some users may have in just typing. This is why we should try and help users reduce the amount of typing they need to do, either in the design of the page or in being forgiving of data submitted in form fields.

As some users may also require their mobile to be held in a cradle it might be that they are unable to change orientation. So we should also make sure we are not forcing any particular orientation to view our sites.

Switch controllers

This is a group of hardware and software tools which allow users who have limited mobility to interact with a screen using just a single click at a time with no mouse. They consist of one or two physical switches mapped to specialist software. Mac OS has switch support built in.

The switch software moves through the options available and the user activates the switch when the desired one is highlighted.

For data input the user will use a virtual keyboard, first selecting the line of keys the desired character sits in, then the second switch trigger will select the key on that row.

For on-screen navigation the user will trigger first a vertical line moving across the screen, stopping it when it is over the target. Then a horizontal line moves across the screen and again the user will action the switch to create a cross-hairs where the two intersect.

As you can see, using a switch will greatly slow down a user compared to a mouse user, and entering text can be time-consuming. We should also look to ensure there is adequate space between controls to avoid mis-clicks.

Head pointer

This was addd to Mac OS and makes it easier for those who might otherwise use a Switch device. It allows head movement to be mapped using a webcam and to control a mouse pointer's movements. Using alternative pointer options also allows commands such as clicks, key-presses and shortcuts to be added using facial expressions.

Eye-tracking

Eye-tracking software translates the user's gaze (tracked using a camera and LED targeted at the user's eye) to mouse clicks or gestures. Like switch devices it allows users who find it tiring, difficult or impossible to use a mouse to interact with sites.

As with switch users, although eye-tracking software may also include zoom options to increase accuracy, we should look to provide margin for error in making sure our controls are both large enough and well spaced. Eye-tracking also uses on-screen keyboards to allow users to enter data.

Eye-tracking also has similarities with other assistive technology such as screen-readers and speech-recognition in that they are code-aware - such as being able to identify links on a page. For this reason it is important to use the correct elements when marking up the page.

One other consideration is that the user is having to use their eye movement for all mouse movement and keyboard entry, so their time looking at the screen is increased, so fatigue can become an issue. Help these users by avoiding overly bright content and distracting animations which pull their gaze away from their task.

Text-to-speech

This is software which reads out the content on the page. There are lots of different versions as well as some which are part of the operating system or browsers.

These are helpful for some low vision users, but can also help with cognitive conditions, such as dyslexia and other reading difficulties, and those who find reading tiring.

Most will provide reading aides as well - for example MS Edge browser's Read Aloud will highlight the line and each word as it is read out.

Unlike screen-readers, they do not expose accessibility information or hidden copy, purely reading the visible content. They do not announce if the copy is a link for example and will not read out image alt text.

Well structured content where sentence length is not allowed to become too long can help users take in spoken information easier. A similarity with full screen-reader software is that ensuring the language of the page is set correctly will allow the software to load the correct voice engine to provide accurate pronunciation.

Screen-readers

Screen-readers are software which produces an audible, or braille, version of what is on-screen. They are available on all operating systems, including mobile, both as part of the OS and as installable software.

Screen-reader is a little of a misnomer as they do so much more than just read the screen and so are more complex to use and have a lot more options than a text-to-speech reader. Along with the content, a screen-reader will announce a set of meta data for that content which helps the user to figure out the page structure and how the interface works.

It is also assumed that all screen-reader users are blind but partially-sighted and those with some cognitive conditions find them helpful too.

The information which gets passed in addition to the content includes data about the type of content (input, heading, link and so on) along with any status information (such as a radio input being selected or not).

For example with a simple heading such as this:

<h2>Extremely small margins</h2>

a screen-reader may hear:

"Extremely small margins, heading, level two"

So the user can tell this content is a heading but also that it is a level two heading, information a visual user may get from the visual styling.

Find out more about accessible names and how screen-readers work.

Screen-readers also allow users to move around the page in a non-linear manner to prevent them from having to read each page from top to bottom. For example a user could move from heading to heading in order to understand the page structure and find the section they want.

This data is built from the code we write. This means we can have significant impact on what gets passed to the screen-reader and what gets ignored, as well as being able to manipulate the information sent. This is why screen-readers are often highlighted as having particular issues when it comes to accessibility as we can actually make things worse for the end-user if we aren't certain about the effects the code we write has.

Speech-recognition

This allows the user to navigate and enter data using just their voice. This software is built into both Windows and Mac, but there are also commercial options.

The user typically interacts by stating the name of the thing they want to click. Because of this they rely heavily on the visual text associated with the control (for example the link text) or well-established conventions (such as “close” for a cross icon on a popup).

Sometimes using the visible text, or trying to guess when there is no text, does not work. Some speech-recognition software allows the user to request the names of elements be displayed.

Different speech-recognition software has different tolerances for how much of the accessible name is needed to trigger a response. If they are unable to trigger the control in this way they can ask the software to number elements and then choose one of those numbers.

As a last resort and as a way the user can also perform more complex interactions, such as drag and drop, the user can overlay a grid (called a ”mouse grid”). Each square is numbered and choosing a square reveals another grid inside similarly numbered. By repeated choices the user can direct a click or other action.

When it comes to entering data (such as in a form), doing this by dictation can be difficult if the software doesn't pick up the word correctly. Where possible we want to again avoid having the user type unnecessarily, so offering options which don't involve typing (such as picking from a list) can be helpful.

Windows High Contrast

Windows has a High Contrast set of themes which the user can choose from and even edit to an extent. Note this is different from high contrast user preference settings.

These are primarily used by people with low vision (around 30% of low vision users use high contrast modes), where the increased constrast helps them pick out elements on screen. They are also used by people who find the standard display too bright as it allows them to enforce a theme which suits them better.

When the user chooses to use one of these themes it is to enable them to read the page so the visual design must take second place to practical readability.

Windows High Contrast mode has several preset options but also allows the user to edit the default colours. This allows the user to adjust the colours to best suit their own requirements.

As we have seen already, using semantic HTML is important to accessibility and it is here too. By using standard HTML elements for buttons and links we can ensure a consistent experience for Windows High Contrast users. For example Windows High Contrast does not recognise aria attributes when assigning styles.

Whilst css can be used to tweak our designs in Windows High Contrast mode this should be done very sparingly and in a very specific way. This is because we can't be sure what colours the user might use so we need to be careful not to end up with something unreadable by forcing specific colours.

User preferences

When we talk about user prefernces we are looking at the various options the user can set via their operating system's settings panel. Whilst these might not do anything with a website on their own, they give us the ability to respect these preferences when we are coding our interfaces.

Colours

As we have seen already users may want to adjust the colours on-screen for a variety of reasons, from reducing fatigue to making it easier to percieve elements or make reading easier. There are a few options which allow this.

Dark and light mode

We can check for the active operating system dark or light theme and align our site's dark or light mode with it using the prefers-color-scheme media query. However we should always provide an on-site switch to let the user change the theme independently of the OS.

High contrast

High contrast is where the operating system performs a system-wide colour switch. Although both Windows and Mac also provide options to heighten the standard contrast used across the OS this doesn't affect web pages automatically. We can implement changes however using the prefers-contrast css media query.

Inverted colours

Whilst Macs provide the option to invert colours it is not customisable by the user, but we can help designs work with it via css inverted-colors media queries. Just as with Windows High Contrast care should be taken not to override the reason the user enabled it in the first place.

Motion

Some users may have conditions which are triggered by animation - especially large animations or repeating ones. Anything from carousels to parallax scrolling to advertising can cause unwanted distraction or even a physical reaction, such as intense headaches or nausea.

The user can request reduced motion at the operating system level and we can hook into this with the prefers-reduced-motion css media query to disable or tone down animations and movement.

This can be demonstrated using a carousel (on BBC's iPlayer site) which has been coded to respect this user preference.

Something as seemingly small as this can make the difference between a user being able to access content or not.

Wrap up

When we consider these different methods of interaction when designing and building our interfaces we are more likely to deliver an accessible product at the end.

• Introduction
• What can it be used for?
• The rules of ARIA
• What is ARIA not?
• Support vs the specification
• Roles to avoid
• Things to consider when using ARIA
• Wrap-up
• Further reading

Introduction

ARIA stands for Accessible Rich Internet Applications. It is a set of attributes which are applied to HTML elements to provide additional information to users of assistive technology. There is an entire specification for it (W3C).

What can it be used for?

ARIA has a lot of different uses but the main theme is to improve a user's understanding of the page.

Let's have a look at some examples of some of the more common use-cases of ARIA which you might come across.

Providing accessible names

An element's accessible name can be modified by using one of a couple of ARIA attributes, aria-label or aria-labelledby.

For example, it can help provide an accessible name to a button which may just have an icon:

A button like this might be coded like this, where the image is applied using CSS:

<button class="icon-arrow-r"></button>

This is an issue because whilst there is a visual affordance to what the button does and what we might expect if we click on it, a screen-reader user may not be able to benefit from this. To a screen-reader user this would just be announced as:

"Button"

Not very useful. This is because the button has no current accessible name - it has no contents and no attributes which would provide one.

By using the ARIA attribute aria-label we can make sure it has a meaningful accessible name:

<button aria-label="Next" class="icon-arrow-r"></button>

To a screen-reader user this would now be announced as:

"Next, button"

Much better.

As well as providing an accessible name where one is missing, we can also override the current accessible name. In the example below we are overriding the one provided by the content ("Change"):

<a href="..." aria-label="Change name">Change</a>

Now instead of "Change" the link has an accessible name of "Change name" and will be announced to screen-readers as:

"Change name, link"

The aria-label attribute takes content directly - you place the content in the attribute itself. The aria-labelledby attribute is different in that it takes one or more ID references. This means we can re-use existing content as the accessible name.

The accessible names of the elements with the referenced IDs will be used as the accessible name. You need to add the IDs to the attribute in the order in which you want them to be announced by the screen-reader.

You can self-reference the element the aria is on to include its own natural accessible name in the computed one. For example, the link below has an accessible name of "Continue reading Travelling to Newcastle" because it is referencing the preceding h2 as well as itself to construct a compound name:

<h2 id="article-title-1">Travelling to Newcastle</h2>
...
<a href="..." id="article-link-1" aria-labelledby="article-link-1 article-title-1">Continue reading</a>

Potential mishaps

Getting reference IDs out of order

As mentioned, the order of IDs in aria-labelledby matters and getting it wrong can have bad consequences, from changing the meaning of an accessible name to making a control difficult to target for speech-recognition users.

Misunderstanding of the impact

Using either of these attributes will override any natural accessible name of the element. So the text content of a button will be overriden by these attributes, as will the association with a label for a form input.

Not understanding the impact of this and how accessible names are calculated (W3C) can lead to the wrong accessible name being delivered to the user.

Limits of aria-labelledby

Using aria-labelledby will only "hop" once. So you can reference another element and its accessible name (even if created using an aria-label) will be used. However if the element you target uses aria-labelledby then that attribute will be ignored and other accessible name sources will be used. This is to stop circular references.

Fragile ID references

Because aria-labelledby uses IDs it is possible to inadvertently end up with an incorrect accessible name.

For example if you mistakenly have more than one ID with the same reference (they should be unique) the browser will pick the first matching one it finds. This may not be the one you expected and you can end up with a different accessible name to the one you wanted.

Similarly if the target ID is removed or changed this will affect the accessible name of the element with the attribute, potentially removing its accessible name entirely.

For this reason I recommend developer teams only ever use IDs for ARIA so their purpose is clear. If you use IDs as testing hooks I recommend you use data- attributes instead - for example data-test="card1". This separates concerns and reduces the potential for mistaken altering or deletion of IDs.

Hidden names

It can be too easy to add aria-label to an icon button (as above) without thinking if the name is obvious to all users.

Speech-recognition users will not know what name you used so have to try to interpret the image - does the arrow mean "right" or "next" or something else?. They need to use the accessible name in order to target that button using speech Whilst there are fallback strategies they can use we should always strive for the simplest option. For this reason I'd recommend using visible text alongside the icon instead of ARIA.

Not having the visual copy at the start

You should also be careful to always have the visible content as the start of the accessible name. This makes it easier for speech-recognition users to interact with it as some software will only match the connection when the accessible name starts with what the user says.

For example doing the following will cause an issue as the speech-recognition user will not be aware of how you have manipulated the accessible name and will say "Click change address" to access the link:

<a href="..." aria-label="Change Bob's address">Change address</a>

Instead do this which places the entire visible text at the start of the computed accessible name:

<a href="..." aria-label="Change address for Bob">Change address</a>

What we don't want to do is make it better for one group (screen-reader users) whilst making it more difficult for another group (speech-recognition). This is one of the balancing acts we need to make with accessibility.

Maintenance slip-ups

Finally, because aria attributes are less visible it can be possible for the visible copy to get updated and the ARIA attributes to be forgotten about. This can lead to a mismatch between the two.

Take this example which works for screen-reader and speech-recognition users:

<a href="..." aria-label="Change address">Change</a>

Then some updates are made to the copy and the link text is updated to "Edit", but the aria-label copy is missed (as it is not readily visible):

<a href="..." aria-label="Change address">Edit</a>

Now a speech-recognition user will not be able to action the link by saying "click Edit" (the visible text) because that is no longer a match for the accessible name.

Providing additional information

The aria-describedby attribute operates in the same way as aria-labelledby in that it takes one or more ID references, though in this case the result affects the element's accessible description. The accessible description is announced after the accessible name and a short pause and is there to provide some supporting information.

Potential mishaps

Just as with aria-labelledby, aria-describedby can suffer from the same issues with having to reference another element.

Semantics are stripped

Another thing to note is that the content referenced will be stripped of any semantics, so if it includes something such as a link or a heading only the text will be carried over.

Take this example:

<label for="ref">Order reference</label>
<div id="order-hint">
    Your order reference is 10 digits, 
    <a href="...">find my order</a>
</div>
<input id="ref" type="text" aria-describedby="order-hint">

The accessible description will be announced as:

"Your order reference is 10 digits, find my order"

Note no mention is made that there is a link present.

For this reason avoid referencing anything other than simple text with these attributes.

Complex markup can be truncated

More complex markup can also result in the screen-reader stopping after the first part, despite the entire block being referenced. For example:

<div id="app-hint">
    <p>Tell us if one of the following is true:</p>
    <ul>
        <li>You have moved house in the past 3 months</li>
        ...
    </ul>
</div>
...
<fieldset aria-describedby="app-hint">
...

Whilst other screen-readers may read out all the referenced content this will be annouced by MacOS Voiceover as:

"Tell us if one of the following is true"

This is a good example of why we test with multiple screen-readers.

There is a delay in announcing a description

Finally, as already mentioned there is a short delay between announcing an accessible name and the accessible description. For this reason you need to be careful of using aria-decribedby on a submit button to reference things like terms and conditions such as in the example below:

<p id="t&c">By clicking submit I agree ...</p>
<button aria-describedby="t&c">Submit</button>

Because of the delay between announcements, a user is likely to hear “Submit, button” and activate it before they hear the description.

It may not be heard at all

An accessible description is categorised as a "hint" to screen-readers. Some screen-readers allow users to turn off hints (which cover a wide variety of announcements) to reduce noise. Unfortunately this can mean that some users may never hear the accessible description.

For this reason avoid putting important information in an accessible description. Where possible ensure accessible descriptions can be accessed as part of the normal document flow so users can find them when hints are turned off.

Providing update notifications

Sometimes we might update content on a page without refreshing the page. Think of "success" or "error" notifications, or when just part of a page is updated such as search results.

This can be difficult for screen-reader users as they may not be aware that the content has been updated. We don't necessarily want to place their focus on the new content as this can be very disorientating and unexpected.

So how do we tell the screen-reader user that something has changed without moving their focus? This is where ARIA live regions come in.

A live region is a part of the page which we mark with ARIA to tell the screen-reader that this will be getting updated and it should monitor it. Any new content will then be announced to the user.

For example in the screenshot below we see an ecommerce site with a grid of search results and a set of filters.

Each time the user changes a filter the grid updates, but a screen-reader user will not know this (or know how many results were returned). This means a screen-reader user will need to figure out that the page is doing this and then will need to explore the page to see how many results were returned.

By using an aria-live region on the result count (highlighted in the screenshot) we can ensure a screen-reader user is told how their filter selection is affecting the number of results. They get this information as a discrete announcement without them having to navigate to the results themselves.

An aria live region is marked up using the aria-live attribute. The value we pass to that attribute is very important as it indicates whether we should interrupt whatever the user is listening to (assertive), or wait until they have finished (polite). By default you should always use polite unless it is something the user really needs to know right now (for example if they don't push a button in the next 30 seconds they will lose some data).

For the ecommerce example above we could wrap the result count in a live region like this:

<div aria-live="polite">
    14 items
</div>

The default is for an aria-live region to look for text being added to it. By using the aria-atomic attribute we can instruct whether it should just read out the change or re-announce the whole live region.

Whilst we can theoretically ask it to also look for content being removed by also using the aria-relevant attribute, support for this can be hit and miss so this information should be communicated directly. The best way to do this will depend on the situation, but an example might be another live region only visible to screen-reader users.

Some ARIA roles have an implicit aria-live and will act as live regions but with added semantic meaning. These include role="alert" (defaults to "assertive" announcements), role="progressbar" and role="status" (both default to "polite" announcements). They should only be used where their semantics make them appropriate.

Potential mishaps

Not triggering the announcement

Because live regions only get reliably triggered with new content, you should always add a live region to the page first and then add the new content (a split second is normally enough). Otherwise you may find the screen-reader is seemingly ignoring the live region entirely.

This behaviour can vary between screen-readers and is why we need to test in more than one.

Providing too much information

A common mistake is to include an entire component or section as the live region. This will be overwhelming to hear as all the content will be read out every time. This will also make it difficult to identify what has changed, negating the purpose of the live region.

A live region announcement is normally not there to tell the user all the changes, just to make them aware that something has changed - in our example we tell the user the number of products returned, not which products.

Make sure the live region only contains a short piece of text to tell the user what changed. If the page has been laid out well the user will know where to go to explore the actual changes.

Not considering other users

Whilst live regions help screen-reader users they do not assist screen-magnification users. If the notification or updated content is remote from their position on the screen these users can still miss the updates. Best practice is to try to place updates as close to where the user is as possible to make them obvious to visual users. This will often be the place where the update was triggered from.

Skipping testing

You should always test a live region with multiple screen-readers to make sure it is doing what you expect it to, especially when using roles with implicit live regions.

If you use an assertive live region you can inadvertently make a page or component unusable by a screen-reader as the user will not be able to hear feedback from other actions as they are constantly getting bombarded by live region updates.

When using assertive be careful that is it only going to be providing occasional updates.

Providing a sense of place

Often we may use a visual indicator to tell our users that a page in a menu is the one they are looking at:

But screen-reader users who are relying just on the code will not get this purely visual information. The blog link will be announced as any other link:

"Blog, link"

This is where the aria-current attribute helps.

<li><a href="/">Home</a></li>
<li><a href="/blog/" aria-current="page">Blog</a></li>
<li><a href="/about/">About</a></li>

By applying this attribute a screen-reader will now announce the link as:

"current page, Blog, link"

In this way ARIA has conveyed the information which was previously just visual. This attribute has a few different options for values besides "page" and can be used to indicate the current item in a range of things, from the current day in a calendar view to the current step in a journey.

Read more about aria-curent

Potential mishaps

aria-current is quite low risk and the only issue can really come from poor implementation. This could lead to it not announcing at all or not being updated as the interface updates and the user being told they are somewhere they are not.

Providing state information

ARIA can help us provide additional information to a user about a component's state which might be difficult to convey in normal HTML.

aria-pressed

As the button below acts like a toggle, either on or off, we need to indicate when the button is pressed (on).

We can use an aria-pressed attribute to communicate the state of the element which will also mean this information is passed onto screen-readers:

// Off state
<button aria-pressed="false" aria-label="Mute"></button>

"Mute, toggle button, not pressed"

// On state
<button aria-pressed="true" aria-label="Mute"></button>

"Mute, toggle button, pressed"

You can also see that by adding this state information the button role announcement has also changed to a toggle which helps a screen-reader user identify how they might expect it to behave before they use it.

aria-expanded

Just like the aria-pressed example, aria-expanded allows us to provide more information to a user which would otherwise only be available visually.

The most common use-case for this is with menus where clicking a button opens additional options, like in the example below.

Without ARIA a screen-reader user would not know if the button had done anything or not.

However with ARIA added the screen-reader user is told:

<button aria-expanded="false">Channels</button>

Channels, button, collapsed

when they land on it, which immediately tells them that clicking this will open something. When they click it, javascript is used to update the attribute and the announcement changes to:

<button aria-expanded="true">Channels</button>

Channels, button, expanded

so now they know there is new content for them to access.

Potential mishaps

Discoverablility

As you may have guessed it is all very well adding in more content, but how will the screen-reader user know where it is?

This is the reason why new content should always be added immediately after the thing which triggered it in the source code. This ensures the next move the user makes will put them in contact with that new content.

Keeping on top of state

As with all ARIA state attributes (such as aria-pressed) the key is keeping on top of the current state so the announcement is correct. So when the menu in our example is closed, ensure the attribute is updated to indicate that. This will require javascript to be written to do this.

Overriding a role

HTML elements all have their own impicit role. This tells the accessibility tree what kind of thing it is, what the user might be able to do with it but also what attributes can be applied to it and some other rules which apply.

You can view the roles provided for each element as part of the detail in the accessibilty inspector in Chrome.

Most of the time a role is derived from the element type and its semantic meaning and while it appears in the accessibilty tree it is not normally defined on the element itself in the HTML. So a button element has a role of button, whilst a ul has a role of list. As you might expect listitem roles (such as the li element) need to be placed as children of a list.

Some elements like div and span do not have any semantic meaning, so these have what is called a generic role.

Where it gets interesting is that roles can also be explicit. We can set it by using the role attribute. As doing this is essentially changing the element's semantics we need to be very careful when we do this.

For example we can change an a element's role from link to be a tab using the role attribute. As there is no native HTML element for a tab control this is a common use-case:

Here is the code for the first tab (note the use of some of the other attributes we have already discussed)

<a 
    href="#past-day" 
    role="tab"
    aria-controls="past-day"
    aria-selected="true">
    Past day
</a>

Bear in mind that tab roles require other roles to also be present (tablist and tabpanel) as well as some javascript to handle functionality.

Potential mishaps

As mentioned, we need to be super-careful when doing this, not only because we can make interfaces confusing for assistive technology users (and potentially future maintainers!), but also as we need to keep track of the requirements for the role we applied, both to the element we changed but also its children.

Changing an element's role is normally only a last-resort - in reality you are often better off changing the element itself if possible.

The rules of ARIA

ARIA is really powerful and can be crucial to the accessibility of an interface when correctly used. However the flip-side of this is that you can absolutely make a page less accessible, or even totally unaccessible, if you just throw ARIA at elements without knowing exactly what effect they will have.

With ARIA more than anything else you need to test with multiple screen-readers to make sure what you think it does will actually happen.

The power of ARIA has led to a set of rules you must follow when considering adding ARIA to a page:

Rule 1 - don't use ARIA if you can use HTML instead

This is sometimes mis-quoted as The first rule of ARIA is do not use ARIA. Whilst a little off the actual meaning of the first rule's wording it is still a good mantra to use as a guide and the Fight Club (IMDB) reference makes it stick in people's minds.

The issue with ARIA is that it is sometimes the first thing developers reach for when trying to make a page accessible. In reality it should be used very sparingly and only when there is not an existing HTML way of achieving the same result.

ARIA is often used without fully understanding the impact it will have, often it seems also without testing the output with screen-readers or other assistive technology.

When WebAim performed their survey of the top 1 million homepages they found those with ARIA present had 34.2% more detected errors than those without. Whilst this undoubtably has some relationship to the complexity of those homepages, there is certainly some evidence to suggest that ARIA is not always used wisely.

If you can use a native HTML element instead of building a component using ARIA, do so. ARIA is great for sprinkling on helpful touches or even for creating interctive components which don't exist in native HTML, but all too often ARIA is used to do work which can be done better with plain HTML.

Native HTML elements include a lot of functionality which you might not even be aware of. If you are trying to replicate an HTML element without using the actual HTML element you will likely miss something. You will also save having to write a lot of javascript.

So to avoid using ARIA where we can, instead of writing:

<div role="button">Save</div>

and then having to add a stack of javascript to handle the different kinds of input the user might use (touch, mouse, keyboard etc) and more javascript to cope with all the native options you didn't know existed, you can write:

<button>Save</button>

You just saved yourself a lot of effort and potential for things to break.

Rule 2 - don't change semantics

Unless you really need to you should avoid changing the sematics of an element.

This example shows a developer trying to assign a region to a list.

<ul role="region" aria-label="my list">
    <li> ...

However by assigning the region to the ul it has overridden the native ARIA role, meaning it will no longer be seen as a list and the list items (li) inside will be orphaned.

Because there are rules around how roles interact, such as listitem roles being direct decendants of a list role, this will generate errors on those li elements, but more importantly the list will no longer be announced as a list to screen-readers.

Instead you could wrap the ul with the region:

<div role="region" aria-label="my list">
    <ul>
        <li> ...

Rule 3 - interactive elements must be keyboard friendly

This goes for any interactive element, no matter how it has been built, but care should especially be taken when building components with ARIA.

Remember that adding ARIA attributes just adds semantics and information to the element, not any functionality (including being able to interact with it with a keyboard), so we need to add that ourselves.

Rule 4 - don't hide focussable elements from screen-readers

Sometimes we might see something like this:

<button aria-hidden="true">
    Am I hidden?
</button>

The aria-hidden="true" attribute tells the browser to exclude this item from the accessibility information sent to assistive technology. Essentially this hides the item for screen-reader users and those using speech-recognition - but does not hide it visually.

This means speech-recognition users and some screen-reader users will be able to visually see the button. Removing it from the accessibility information will prevent them from using the button they can see which will be confusing.

Screen-reader users will also still be able to focus on the button using the tab key (as this does not hide it from keyboard users) but when they navigate using the screen-reader key commands the button will not be exposed. More confusion. A quick test is that if a keyboard user can still focus on something, then so can a screen-reader user.

Rule 5 - interactive elements must have an accessible name

If a user can do something with an element, then that element needs an accessible name. Without an accessible name it is like having a link with no text, the user will not know what it is or what interacting with it might do.

Ideally all interactive components will have an accessible name which is also visually presented so speech-recognition users can see what they need to say to trigger it.

See more about accessible names

Rules about what you can use where

As well as rules around when you should use ARIA, there are also a lot of rules around which ARIA attributes you can use where (W3C).

• you can only use some aria attributes on certain roles
• some roles require other roles to be nested as children (think of lists and list items - a list item without a containing list does not make sense)

For example, you cannot add an aria-label to an element with a role="generic" - which includes elements such as span and div - as this is one of the "Roles which must not be named (W3C)". So this is not valid:

<div aria-label="About you"> ... </div>

When we talk about not being valid with ARIA, this means it can have either no effect, some odd kind-of-works effect, or a plain-just-unwanted effect. So it is best to stick to valid usage, but then test with actual screen-readers for real-world support.

Invalid use of ARIA is normally caught by the various automated browser plugins (such as AXE or Wave) as it is syntax based and easy to check for automatically.

What is ARIA not?

What it does not do is provide any functionality beyond the announcement of the attribute.

For example the HTML button below has ARIA added to tell the user that clicking it will expand additional content such as a navigation menu:

<button aria-expanded="false">Menu</button>

However as it stands it won't tell the user that the menu state has changed after the button has been clicked. To do that we will need to add javascript to toggle the ARIA attribute (to aria-expanded="true"). There are a few ARIA attributes which deal with state so for these javascript is necessary to help us improve accessibility.

If we created that button entirely with ARIA (which is possible but not recommended):

<div role="button" aria-expanded="false">Menu</div>

then we would also need to add things like some way of that button getting keyboard focus (as div elements don't get focus), and provide event handlers for both keyboard and pointer (mouse and touch) users.

ARIA is also purely for users of assistive technology which uses the accessibility tree. That includes screen-readers and speech-recognition. But not all assistive technology makes use of the accessibility tree and these will gain no benefit from ARIA. For example Windows High Contrast will not highlight links and buttons created using ARIA in the same way as it will native HTML links and buttons.

Support vs the specification

ARIA support can be somewhat patchy. This is a combination of the complexities of implementation and communication between the various involved parties and conflicting demands on screen-reader development teams.

To correctly support a feature the correct information needs to be passed from the browser into the accessibility tree, which needs to be communicated via an accessibility API to the assistive technology.

All the following can have an impact on whether a feature is available:

• different browser support and interpretation of spec
• different accessibility APIs used
• different assistive technology vendors
• regression issues or bugs in any of the above
• different support depending on browsing modes (for example tocuh vs keyboard, browse mode vs forms mode)
• assistive technology vendor heuristics (where deviations from spec are deliberately introduced to improve user experience)

This means that just reading and following the spec may not guarantee that the user will get the result you expect. Developers just following the spec and either not fully understanding it or assuming it is fully supported (not an unreasonable thought) are the main reasons why ARIA implementations can cause issues.

Even if you test with a screen-reader and browser and get the result you want, a different screen-reader and browser might mean you get a very different result.

There is an ARIA-AT project (W3C) which is trying to standardise how assistive technology announces or reacts to ARIA, but this is in the early stages.

For now, use the specification to guide what might be possible and within the rules of ARIA, but then test robustly in multiple screen-readers and speech-recognition software. If what is in the specification does not work then you will need to look for an alternative solution.

As an example, I was consulting on a webchat project, but the per-specification role="log" which should have been a perfect fit, worked poorly and inconsistently with different screen-readers and browsers. Instead I used a solution which generated dynamic aria-live regions to achieve the effect we wanted in a robust and consistent way.

The APG - a warning

The W3C produces something called the "ARIA Authoring Practices Guide" or APG. This on the face of it is a useful guide to different patterns and practices for using ARIA.

However, this guide is written to the specification. The patterns it showcases are idealised solutions which are intended as guidelines for browser and assistive technology vendors to aim at for support (a bit like the old Acid tests for CSS). They do not claim to be real-world usable nor to support mobile or touch interfaces.

Whilst these can be used by teams building sites as a starting point, they should not be just dropped into production without extensive testing with different assistive technology.

Things to consider when using ARIA

There is another phrase which is often used:

“No ARIA is better than bad ARIA”

What this means is that in many cases an interface is still usable without ARIA, but if ARIA is added in a poor way it can make it truly inaccessible. So it is worth double-checking any time you are looking at adding ARIA that what you are doing is necessary, is done in the correct way and has been robustly tested.

Here is a short checklist to use when looking at adding ARIA into your codebase.

• What is the problem I am trying to fix?​ Is ARIA the right tool?
• Can I do this without ARIA?​
• Would a small redesign solve this instead?​
• Am I adding content only for screen-reader users? Will other users benefit?​
• Can a speech-recognition user understand what they need to say?​
• Will this make the interface audibly noisy?​
• Have I followed the rules of ARIA?
• Is this supported in the real world?​
• Do I have a robust testing structure in place?

Wrap-up

Whilst ARIA is a very powerful tool in making our sites more accessible to users, it is one which needs careful handling. You need to know exactly the reason why you are adding ARIA and what effect you want it to have and then confirm it.

ARIA is simple to add but tougher to test, but not testing can really mess up your site's accessibility if not done.

If you add ARIA to your page or component, you must then test it with multiple screen-readers.

Further reading

• ARIA is spackle, not rebar (CSS Tricks)
• ARIA 101 (YouTube)

• Introduction
• The causes of accessibility issues
  • Lack of awareness
  • Deferring responsibility
  • Assumed cost of implementation
  • Assumed impact on deadlines
  • Accessibility as a checkbox item
  • Reliance on out-of-the-box automation
  • Lack of support from processes
  • Find out the reason for any pushback
• A roadmap for accessibility
  • Just complaining rarely works
  • Fixing a lack of awareness
  • Skill gap
  • Present a plan
  • Build accessibility into team processes
  • Measuring success
  • Legislation
• Wrap-up

Introduction

Tackling accessibility is a multi-stage approach. Often the most difficult part is not the remediation of issues but instilling a culture where those issues are caught before they reach any backlog.

The causes of accessibility issues

When we talk about accessibility we are generally talking about the barriers which are placed in front of people wanting to complete a task.

For the most part, on the web at least, these barriers can be fixed in some way or other. So we have to examine if this is the case, then why are so many websites still inaccessible when accessibility has been on the professional radar for so long?

The likely cause is unfortunately related to the processes which are involved in the building of those products.

This can take several forms:

• lack of awareness
• deferring responsibility
• assumed cost of implementation
• assumed impact on deadlines
• accessibility as a checkbox item
• reliance on out-of-the-box automation
• lack of support from processes

This needs to be managed by the delivery leads on a project to ensure that both the stakeholders and wider team are aware of the need to prioritise accessibility.

Lack of awareness

This can take a couple of forms, a lack of knowledge or a misunderstanding of the principles.

It might be that no-one has ever broached the subject of accessibility before. This is the easiest blocker to fix as it probably means there are no preconceived ideas, so some upskilling may be all that is needed.

Sometimes it might be that there is a misunderstanding of what disability means or who it affects. Let's examine a couple of the common misunderstandings:

“None of our users are disabled”

Well 1 in 5 people in the UK are disabled, so that is unlikely.

Often this thinking is a result of an assumption that people with disabilities don't use the internet - certainly not blind users who surely cannot see the screen? It is also likely due to a narrow view of what conditions are within the scope of accessibility, and thinking it won't include users with cognitive or degenerative conditions, users with low vision or colour blindness or older users.

The hidden nature of many conditions

What people may mean by “none of our users are disabled” is that they’ve never heard of a user who explicity stated they were disabled use their product. Why would they? Many people keep their disabilities or conditions hidden, or don’t even see their condition as a disability.

People have adaptations or coping mechanisms which they use to work around their condition which reduce the outward presentation but do not lessen the impact.

Things like screen-readers or page zoom or high contrast mode don’t show up in analytics (nor should they), so they would never know if someone was using assistive technology.

Negativity of poor accessibility

What stakeholders might see is negative reviews about a product because of their lack of accessibility, or alternatively see praise heaped upon a competitor because they took accessibility seriously.

A product with poor accessibility is essentially shouting that they do not care about you as a customer. Why would you give such a company your business, especially when there is an alternative?

As users who need to make adaptations to use digital products are so used to poor accessiblity, when a product is accessible it means that this becomes a straight recommendation. It could even win customers over from a theoretically more capable or cheaper competitor.

If they really don’t have disabled users it is likely be because their product is inaccessible and they are leaving revenue on the table.

The uncertainty of tomorrow

Let's for a moment say that they can be absolutely sure none of their users are disabled. They cannot be sure those same users won’t be disabled tomorrow. Disability is a group which anyone can join at almost a moments notice.

No product can dismiss accessibility because they feel they know their users that well. The truth is they don’t and that knowledge is transitory at best.

“This is an internal product”

I've heard this a lot as a reason for not thinking about accessibilty on internal products. The assumption is that they “know” there are no disabled users on the team which will be using it, so why go to all the effort to make it accessible?

As hinted at above, it is not the responsibility of our users to declare medical conditions when using a site. Accessiblity is not just for publicly-available products. If someone needs to use something as part of their work then they have the same rights as those accessing public sites. Read more about the legalities of accessibility.

All the same arguments apply here as the previous example - you do not know everything about your users and certainly cannot know your future users. This is even more true now as working from home has increased and conditions and adaptations (such as using a screen-magnifier) are less visible.

You also have a duty of care for your staff. For example, you have a small team using an internal product. One of that team develops a condition. Because the product is inaccessible that person can no longer do their job which could lead to a variety of legal and other outcomes.

Deferring responsibility

It is tempting to say that your team does not have the expertise to make a product accessible (we will get to this shortly) and pass all responsibility to the other teams, whether that is the team producing library code or a specialist accessibility team.

Just as with security the specialist teams can help with specific issues or provide the building blocks for good practice, but it is the responsibility of the product team to undertake accessibility as part of the job.

With accessibility there are both long and short term aims, but if no-one is taking responsibility for keeping up momentum then it is possible for the team to fall back into old habits. So it is essential that the delivery leads are keeping an eye on this at least until it becomes embedded in the team.

It is necessary for the whole team to be on board for an effective accessibility strategy and accessibility needs to be incorporated into all the team processes to avoid it being forgotten about.

Read more about team processes and responsibility

Deferring to a code library

It might be that you are using a design system or code library. This can lead to assumptions that if the team uses that, then accessibility will be “inherited” from this. This can be true to an extent.

A design system should be robustly tested for accessibility, but in practice this is usually only done when the components are initially developed. Time, browsers and assistive technology support moves on and unless the design system has a regular testing regime in place, things can slip through.

These components will likely come with some accessibility features, but the team implementing them needs to understand how they help the user. Misunderstanding how a component presents information to a user of assistive technology can lead to those features being misused. For example, a component allows an aria-label to be added, but it is clearly up to the development team to use this correctly and ensure the attribute is actually needed and that content provided is appropriate.

Component libraries also by design need to allow for a degree of flexibiity in how the components are utilised. This flexibility can allow accessibility issues to creep in when implemented in the real world.

Design systems often only have a dozen or so components. Often teams may find they need to build something custom for their project. At this point the team needs to understand how to build that in an accessible way.

A well-built design system component can give you an amount of assurance that what the team is building is accessible. However the structural component is only part of the story. The content used in those components, how multiple components are composed together, the wider page and even wider user journey are all part of the accessibility story and also need to be considered from an accessibility viewpoint by the team implementing it.

Deferring to an accessibility audit

Some companies (and especially government departments) undertake accessibility audits or reviews prior to launching a product. It can be tempting to see this as an opportunity for someone else to do the hard work of finding the project's accessibility issues so the team can fix them, without it getting in the way of day-to-day delivery.

This approach will always lead to either missed deadlines or products launching with multiple accessibility barriers, which will most likely then languish in the backlog. It also misses a valuable learning opportunity for teams to pick up skills (without the looming deadline) during the product development.

A pre-launch review can only be used as part of a wider accessibility testing strategy. By itself it is unlikely to achieve the desired outcome as it sits too close to the launch date and is rarely able to prevent a launch if it finds issues.

Read more about accessibility testing strategies

Assumed cost of implementation

It's interesting that accessibility is one of the few practices which we seem to have to barter for time and budget on. There are so many sites which have had no accessibility process prior to launch and which are now having to face costly remediation.

If accessibility is included in all stages of a project then the actual cost is much lower than what will be seen on a remediation project. It won’t be zero as there is additional time, testing and research required, but the figure is much lower than only tackling it at the end.

It has been estimated that having to fix issues after release can increase cost by 30 times against finding that issue during the design phase. By including accessibility during all stages this rework can be avoided and costs minimised.

What really costs when it comes to accessibility remediation is where the fundamental page design or user journey is found to be flawed. This requires major rework and is not something you want to be doing as a product flies towards a deadline.

Something to bear in mind is that considering accessibility during design and development generally results in a better product. Clearer signposting, more understandable content and other benefits often come out of such accessibility work.

The question then is really can you afford not to consider accessibility?

Assumed impact on deadlines

Just as with the monetary cost, there of course is some additional cost to making a better, more robust, more usable product. Because that is what we are talking about - making the product usable by more people.

Yes the team may take a little extra time to learn new skills, but we need to allow teams to upskill in accessibility just as we might for security, testing or performance. Accessibility is a part of every role's responsibility, not an addition which can be opted out of.

This may sound harsh but it is true - accessibility is not a nice-to-have for those affected by it, it is essential to being able to use your product.

However, just as with the monetary cost there is a benefit in less rework later on. If accessibility is not tackled as part of the initial development process it becomes harder to prioritise later on as feature releases take precedence.

The more usable product which comes out of accessible design will mean less support tickets from users having trouble with the product. Often the product which results is less complex and so easier to maintain.

The Minimum Viable Product (MVP) paradox

Accessibility is often the first thing sacrificed to deadlines. Too often I've heard “this is an MVP, we'll add accessibility in later”.

Minimum Viable Product. That means a product which has the smallest amount of functionality to perform its required role. It doesn’t mean that you can cut out a whole group of potential users from using that functionality.

What if we left off any cross-browser testing from our MVP? Lets exclude any users of non-Chrome browsers. We wouldn’t do that because cross-browser testing is one of the core tenants of web development (although it seems not always). In the same way accessibility should be part of the core delivery.

Not including accessibilty in an MVP shows that something is lacking in the design and development process. As outlined above accessibility needs to be part of every step. It isn’t something you de-prioritise.

By dropping accessibility to your backlog you are just creating a design and technical debt mountain which in my experience never gets tackled.

If an MVP doesn’t include accessibility then I'm afraid you don’t have an MVP.

With good planning the additional time required for an accessible product delivery should not mean a deadline needs to shift to accommodate the extra work. It will however likely lead to less work later down the line. Remember accessibility work in a project starts before development beings.

Accessibility as a checkbox item

There is a lot of noise around compliance, especially in the public sector. Read more about the legalities of accessibility. This can lead to accessibility and compliance being seen as the same thing. This can further lead accessibility to be seen as a checkbox item - “once compliance has been confirmed we can forget about accessibility”.

This is both incorrect and damaging to ongoing efforts to improve accessibility.

Compliance only measures a site against a predefined set of criteria at a specific point in time. Whilst these criteria are well-meaning they are not comprehensive, nor do they guarantee that a site built to them will be accessible, merely that you have done the least you can do to prevent the worst issues from appearing on your site.

Even a compliant site can have significant barriers for some users and it is only through rigourous testing, including with users, that we can remove most of them.

The checkbox mentality also suggests that once accessibility has been “done” that it can be forgotten about. But accessibilty requires an ongoing approach to ensure future work, for example new features or maintenance updates, do not introduce issues, but also so changes in the support landscape (such as browsers and assistive technology) are catered for.

Read more about testing strategies and accessibility

Reliance on out-of-the-box automation

When it comes to testing for accessibility we too often rely on one-click solutions to tell us if something is accessible or not. Browser plugins such as axe or Wave certainly have their place in our accessibility toolbox, both they should not be the only items in it.

I have often seen teams run one of these plugins and declare the page or component accessible. Whilst it is true these tools are valuable in finding some issues, they cannot find a whole range of accessibility failures (current thinking is they may find around 40% of issues). It is similar to running a code linter and then not doing any unit, integration or end-to-end testing because the linter said it was ok.

We need to utilise a range of different testing methodologies to help us discover accessibility issues.

Read more about improving automated testing

Overlays

There is another aspect of automation and accessibility - the accessibility overlay. This takes the form of a javascript widget which is installed on an already launched site and promises to fix all of its accessibility failings by automatically fixing issues or offering the disabled user different options.

“We’ll use one of those accessibility overlays, they’ll fix everything for us“

Seems a smart choice - bypass all the expense and time by taking out a subscription to an accessibility overlay which will take care of all that accessibility stuff.

Except they don’t work. In fact often they will make things worse for the user.

The European Commission has even weighed in and said they can be harmful:

The European Disability Comission and the International Association of Accessibility Professionals (IAAP) also issued a joint statement against the use of such overlays.

And think about the use-case. If a user needs these adaptations, they are going to need them everywhere, not just on your site. So if they need text reading to them they will use reader software that works everywhere. The solution is not to present the user with a custom solution, but to make the product work with what the user already uses.

Often the overlay just cannot fix what is broken, whether that is poor font-sizing and colour choice or just poor copy design or page design.

Moreover, why should the user have to try to work out how to use the particular overlay you decide to put on your site (and then a different one on the next site)? All an overlay does is shout to the user (and the product’s competitors) that you don’t really care about accessibility.

They are also an expense which would be much better spent on actually fixing the issues with the product.

For more on this see the overlay factsheet.

Lack of support from processes

Even if the team is skilled in accessibility, without a process which supports this work it is all too easy for standards to start to slip. This is especially true as team members rotate out and this can result in just one or two people becoming the only ones maintaining accessibility best practice.

Read more about team processes.

Find out the reason for any pushback

If you come across pushback like the examples above, the first thing to do is to find out the reason for the pushback.

• are they just unaware of the impact of an inaccessible product?
• have they heard accessibility is difficult?
• are they worried as accessibility is something they haven’t dealt with before?
• does accessibility not feature in a key performance indicator (KPI), so drops down in the levels of importance?
• is there a skill gap on the team so no-on knows how to proceed?

Theses are just a few reasons why accessibility is getting de-prioritised on a project and all require slightly different approaches.

A roadmap for accessibility

Just complaining rarely works

Just complaining about lack of movement on accessibility rarely works, but empowering someone to deal with it who was previously had it down as a problem area can lead to them becoming an evangelist as others will then look to them for help in doing the same in their own area.

If your product has accessibility problems sometimes just finding the worst area, fixing it and then demonstrating it and the impact it has to the team and stakeholders can be the first step to getting buy-in. Sometimes a simple before and after showcase is all you need. Even better if you can show a user for whom it caused a barrier which has now been removed.

Fixing a lack of awareness

There are a lot of assumptions around the whole area of disabilities and accessibility. Sometimes you just need to break a few of these to get traction. There is also a general lack of understanding of the simple issues users might be having because people have difficulty in seeing how something might impact a user with a particular condition.

Proctor & Gamble designers were having difficulty getting accessibility taken seriously.

They finally sat stakeholders down with low-vision emulating glasses and asked them to pick which bottle was shampoo and which was conditioner.

When they couldn’t, accessible adaptations to the bottles were finally approved.

Even just taking a screen-recording of how a page sounds to a screen-reader user before and after a fix can be enough to show how important accessibility is. If you have access to UR recordings of users with accessible needs using the product and having difficulties then this is the best thing to show to help unblock accessibility work.

Skill gap

There is no way around it, accessibility is a complex thing. That is why we cannot expect one person on a team be be responsible for all of it. It has to be a team responsibility.

Be aware that implementing code solutions without proper knowledge of the impacts that code may have can actually make things worse. It is always best to give the team time to learn this properly. This also means it is important to ask for assistance where possible if there is a lack of skills on the team. If there is expertise elsewhere in the company, lean on that to help your team.

Look to work with an accessibility specialist, they can provide insight by working with:

• the design team to find accessible solutions
• delivery and product managers to review ticket requirements
• the test team on how best to enforce accessibility requirements
• developers to implement designs without excluding users

However the team cannot come to rely on an accessibility specialist being available. They need to develop their own skills to find solutions to day-to-day issues, perhaps occasionally utilising the specialist for specific and complex problems.

Encourage the team to take time to learn. Just as with any other skill such as security or performance it will take time and this needs to be accounted for in timescales. Use team meetings such as sprint reviews to highlight accessibility wins and discuss issues.

Of course the team might not be able to upskill in everything right away. Look at staging the training.

If the team lacks skills, also look to increase the amount of user testing you are doing with disabled users to help inform decisions.

Present a plan

Sometimes there is an understanding of an issue being present but no understanding of how to go about fixing it. There can be an awareness that there is a large accessibility backlog, but because no-one has taken ownership it is never acted upon. This is a silent backlog - there might not even be tickets created but everyone is aware there is something there which needs to be done.

In this case there is no actual person blocking the progress of accessibility, just a lack of process. There might even be a willingness to get it fixed, but no idea of where to start.

In this case it just needs a plan putting in place to tackle the issue and at least get it on the backlog and in the development cycle.

Build accessibility into team processes

It is important to provide a team with a structured way to help them move toward more accessible practices. Use existing team processes and add accessibility points to each one.

Places where accessibility can be highlighted and potential issues caught:

• design documents
• prototype development
• definition of ready
• code commits / pull request reviews
• testing procedures
• defintion of done

For more detail on how these can be improved see team processes and role-based accessibility.

Start with small wins

Some accessibility improvements require very little in terms of time allocation, for example making sure form fields have accessible names. But these simple fixes can start to drive momentum and provide the team with the morale boost which they might need when facing a new skillset.

Work through the backlog to size issues based on time and complexity as well as severity and pull through groups of the easy wins to keep momentum going.

Keep accessibility current

Always talk about accessibility - include it in demos to stakeholders, reports, meetings. Make it a staple of everyday life in the team so it just becomes part of the furniture. Encourage delivery leads and stakeholders to advocate for accessibility and showcase accessibility wins to ther teams.

Find out what other teams are doing around accessibility and bring that back to the team.

Measuring success

Especially when starting out on an accessibility journey it is important for a team to be able to see progress, especially if they are dealing with a large backlog of remediation issues.

With accessibility being such a diverse and complex subject, how might we go about measuring success? Sure, the number of WCAG issues flagged on a site is one way, but as we have already touched on, compliance is only one aspect.

Here are a list of things we can look at in our backlogs:

• WCAG A/AA issues outstanding - the most obvious thing to track but worthwhile nonetheless
• WCAG AAA issues - whilst not required for general compliance they can be a good indicator of the depth of accessibility and are too often overlooked
• best practice issues - these might be raised as non-WCAG issues on an audit or flagged as best practice on automated tool reports

But we can also dig a little deeper to help improve processes:

• time to fix - keep an eye on the time it takes to get around to fixing any outstanding accessibility issues, perhaps setting an upper limit so items do not fester on the backlog
• new issue generation - we should not be adding issues when we add new features so keep track of why any new accessibility issues are being created and if they could have been caught before shipping
• mapping accessibility issues across user journeys - this can be useful, both to identify problems in processes, but also to identify where a user may be confronted by a series of issues which even if low impact individually can wear the user down to the point they abandon the task

Then there are some more general things to keep an eye on:

• team skills - do all of the team engage in accessibility
  • by attending training sessions
  • attending user research observations
  • being able to showcase work they did to incorporate accessibility

And some user-centric metrics:

• user satisfaction reports (or Github issues) - how many times are accessibility issues raised by users, but bear in mind they might be framed as a usability issue, so some investigation may be needed as to the true cause
• task completion - whilst we cannot know who is completing or abandoning a task we can continue to perform usability testing with disabled users to catch any regressions

Legislation

Sometimes it can be necessary to resort to pointing at the legalities of a situation to get it resolved.

However this is never the preferred way as it invariably ends up in a word-wrangling exercise where exemptions to the requirements are claimed.

Wrap-up

One of the hardest parts of accessibility is getting buy-in from stakeholders and the team. However once they are on board there is still work to do to ensure the momentum is kept up and accessibility becomes a natural part of the process.

• Introduction
• Aria and accessible names
• Accessible name computation
• Manipulating accessible names
• Potential issues
• Guidelines
• Wrap up

Introduction

An accessible name is the name of an element in HTML and is what is exposed to assistive technology. Not to be confused with the name attribute on form fields.

In practical terms, it is what is read out to a screen‐reader when they navigate to the element. If the element is interactive, it is what a speech-recognition user would need to say to click on that element on the page.

An example is the accessible name of a link. This can be, at its simplest, the content enclosed by the link tags. For example, the accessible name of the link below is "Bob":

<a href="...">Bob</a>

You can see the accessible names of elements in most browser developer tools by inspecting the element and checking the accessibility panel.

Accessible names can also be supplied by some attributes. For example, an alt attribute can provide the accessible name to an image:

<img src="/assets/images/logo.jpg" alt="Adam Liptrot">

Derived accessible names

But that same image's alt text can also supply the accessible name to a link wrapping it, just as the text in our first example did. This is because the link's "contents" include elements inside it and their accessible names.

<a href="/">
  <img src="/assets/images/logo.jpg" alt="Adam Liptrot">
</a>

Accessible names from relationships

But an accessible name can also be created from other things, like the relationship generated by a for attribute. The following input's accessible name is generated by the label. The accessible name for the input is "Your name" and this is what will be announced to screen‐reader users when they land on it.

<label for="name">Your name</label>
<input id="name" type="text" />

Aria and accessible names

The ARIA specification also has a couple of attributes which can assign accessible names:

• aria-label
• aria-labelledby

aria-label

This attribute will override any default accessible name with the contents of the attribute.

For example, we can use an aria-label instead of content to supply the accessible name to a button:

<button aria-label="Search"></button>

aria-labelledby

The aria-labelledby attribute takes a list of IDs from elements on the page and those element's accessible names will be used to create the accessible name.

Here we are pointing the attribute to the heading, whose accessible name is "Search" (from its contents), and so the accessible name of the button becomes "Search".

<h2 id="search-copy">Search</h2>
<button aria-labelledby="search-copy"></button>

We will look at more complex uses of this attribute shortly.

Accessible name computation

So we know accessible names can be assigned using a few different methods. Because of this we need some way of deciding which one wins out, especially as we can use several of these on one element.

How an accessible name is computed is subject to a hierarchy of checks against the existence of various attributes, each one potentially overwriting the others. You can even see this order represented in the devTools display as in the examples above (the items appearing in each list vary depending on the element type, for example alt will only be shown for images).

The order is in descending order of priority (so ARIA attributes win over everything else). For example:

1. aria-labelledby
2. aria-label
3. contents (not form elements)
4. derived from the label relationship (only form elements)
5. placeholder (only form elements)
6. title

So if you take the link from our first example and add an aria-label attribute:

<a href="" aria-label="Tom">Bob</a>

that will overwrite the contents and the accessible name is now “Tom”. Note that the visible text will still be “Bob” as we are only changing the accessible name.

Similarly if you take that link and add an aria-labelledby attribute it will trump all of the others:

<a href="" aria-label="Tom" aria-labelledby="name">Bob</a>
<div id="name">Kim</div>

The link’s accesible name is now “Kim” despite the other changes still being present.

<button aria-labelledby="search1">Btn</button>
<button id="search1" aria-labelledby="search2">Btn1</button>
<button id="search2">Btn2</button>

<button aria-labelledby="search1">Btn</button> <!-- "Btn1" -->
<button id="search1" aria-labelledby="search2">Btn1</button> <!-- "Btn2" -->
<button id="search2">Btn2</button> <!-- "Btn2" -->

Manipulating accessible names

Occasionally it can be useful to have a different accessible name from the visible one.

If you have a number of links which have similar functionality, but where adding unique visible text to each item might make the interface cluttered or confusing for other users, you can use certain techniques to provide different values to different groups of users.

The issue with identical links is that a screen‐reader user would not be able to distinguish the purpose of the links when viewing the links in isolation (this is one way screen‐reader users navigate a page - for more on this take a look at my guide on the JAWS screen-reader).

For example, a page where you have lots of editing options, each with a “Change” link.

A screen-reader user navigating by links or using an element listing will see a list of "Change" options and will have to go into the content to find out which one they need to follow to get to the article they want:

Change
Change

But making the links more contextual by adding more text to them like “Change your address” would make the interface overloaded and repetitive, helping one group to the detriment of another.

We need a way to satisfy both and one way to do this is with an aria-label to override the content-derived accessible name, like so:

<a href="#" aria-label="Change your name">Change</a>

<a href="#" aria-label="Change your address">Change</a>

or we can add copy which is only available to assitive technology which combines with the visual copy to again adjust the accessible name:

<a href="...">
    Change
    <span class="visually-hidden"> your name</span>
</a>

<a href="...">
    Change
    <span class="visually-hidden"> your address</span>
</a>

Either option keeps the visual the same but makes the links make sense to screen‐reader users as they will see a list of links like this:

Change your name
Change your address

As we have kept the visible label at the start of the accessible name, the user can still say "click 'change'" and the software will place a number next to each link to allow them to pick the one they want.

Using multiple sources

You can reuse existing content to build an accessible name by using aria-labelledby. This takes a list of IDs of elements and constructs an accessible name based on the order of the IDs.

This allows you to re‐use content, which removes some of the hidden aspect of the accessible name. But care must be taken that the content used does not later change and inadvertently mess up the accessible name.

In the example below I'm creating the same accessible name as we have just done ("Change your name"), but using the dt and link content via aria-labelledby to concatenate them into one phrase.

<dt id="q1">Your name</dt>
    <dd>Bob Hoskins</dd>
    <dd>
      <a id="q1-change" 
        aria-labelledby="q1-change q1" href="#">
        Change
      </a>
    </dd>

Potential issues

Accessible names pose a number of opportunities for us to break things and introduce barriers for our users.

Trying to name an unnameable role

Some roles such as generic cannot have an accessible name assigned. Check out the other "roles which must not be named". The elements span and div are the two most common elements with this role

This means that even if you try to assign an accessible name to something like a plain div, that will not be communicated to assistive technology (or at least not in any sort of robust way).

Missing accessible names

Where none of the ways of assigning an accessible name are present, the browser cannot calculate an accessible name and nothing is returned.

This is most commonly found where form inputs are missing the connection with their label, or the one I see most often is on buttons.

The most common example is where a button doesn't have any content because a background image, an icon font, or an image with no alt text is being used to display a visual-only message. You might have seen this yourself in a mobile menu (“hamburger”) icon, or a carousel control like the one below:

<button><img src="rightArrow.png" /></button>

To a screen‐reader user this will just be announced as "Button" so they will have no idea what it does.

For a speech-recognition user they could try a few words based on the visual appearance but will likely give up and resort to other means.

If you happen to have used an embedded SVG for that image, you might have inadvertantly provided an accessible name (in the SVG title attribute for example), and it could even have the opposite effect to the one you might have wanted, like the example below:

On Autotrader’s homepage they had a carousel which uses an SVG icon inside the directional buttons.

<button type="button" ...>
  <svg xmlns="http://www.w3.org/2000/svg" ...>
    <title>chevronLeft</title>
    ...
  </svg>
</button>

Unfortunately on this page an accessible name was not provided for the button. However because the SVG had a title attribute, this is what is exposed as an accessible name (as it counts as Contents as far as accessibility is concerned). The “chevronLeft” title from the SVG whilst meaningful to the designer who exported it, is not of any use to the end-user, not least because it suggests the arrow points in the opposite direction when it has been rotated using CSS for the right-facing button.

For those wondering, yes the left button uses the same SVG and the image rotated for the opposite direction, so both left and right buttons on the carousel had “chevronLeft” as their accessible name.

What they should have done in this case was hide the SVG from assistive technology using aria-hidden and provided a suitable aria-label on the button itself.

<button aria-label="Next" type="button" ...>
  <svg aria-hidden="true" xmlns="http://www.w3.org/2000/svg" ...>
    <title>chevronLeft</title>
    ...
  </svg>
</button>

Update (July 2025) : Autotrader have since updated their carousel and now use an aria-label on the button.

So accessible names are very important for users to understand what the various controls on the page do and having the wrong ones can even cause the user to do something they didn't intend.

Overriding the visual label

This does mean that you can do things like override the visible contents of the element with a different accessible name, which can lead to issues.

The following example is the code for the button from the BBC screenshot above (since I took this screenshot it has been fixed, although it took a redesign for this to happen).

<button aria-label="Next">Continue</button>

The visible content is "Continue", but the accessible name is "Next" as the aria-label has overridden the content‐derived accessible name.

For a screen‐reader user who can see (many screen‐reader users are not fully blind), this can be a bit confusing as the visible and audible messaging is different.

For a speech‐recognition user it is frustrating as they will try to say "Click 'continue'" which will not work because the software has been told the accessible name for this button is "Next". In this situation the speech-recognition user will (probably after a few tries) resort to asking the software to number all the controls on the page to allow them to select the correct one and continue. This is not good as it is asking the user to do a step which is completely unnecessary and especially so on the first step of a registration process.

Undoing good work

This next example shows how a misunderstanding of how accessible names are computed or how ARIA works can lead to good work being undone.

Below we can see a product card with an image of the product and a button to add it to the basket. The button has had hidden content added to allow screen-reader users to understand which item they are adding to their cart. This was done using the visually-hidden technique outlined above. However an aria-label attribute has also been added to the button to replicate the visible label. This means the hidden copy (and the context it provided) is lost. The accessible name computation states that an aria-label will overwrite the content of the element. The button is no better off than if it had just been coded as a button with "Add to basket" as the contents.

<button aria-label="Add to basket">
  Add to basket
  <span class="visually-hidden">, Matthew Williamson Ombre Cone Ceramic Base Table Lamp</span>
</button>

This will be announced as:

"Add to basket, button"

So, despite all the good intention, the above code is equivalent to:

<button>Add to basket</button>

Visual not matching the name

The most dangerous issue is where the meaning of the visual label is completely different to the accessible name. For example using an aria-label of “cancel” on a button with the visual text of “continue”.

<button aria-label="Cancel">Continue</button>

This obviously could have a major impact on a screen-reader user as they could potentially submit data when they wanted to cancel an application.

This is an extreme example (but one I actually saw in production), but we should always ensure that any visible text is part of the accessible name (ideally at the start).

WCAG even has a criterion to cover this called “Label in name”.

Overloading an accessible name

Accessible names are meant to be short - a few words long at most. Remember a screen-reader user will listen to an accessible name to understand what the element's purpose is. A long accessible name can confuse matters and leave a user wondering what the element is.

This is especially something to be aware of when wrapping content with a link (or button). As we have seen, the content inside the link will be used as the link's accessible name.

We can often see this where a card component is used:

In the above image the whole card, from image to price, is wrapped in a link, as can be seen in the simplified markup below:

<a href="...">
  <img src="..." alt="GoodHome Mulanje Industrial Matt White Wood effect Floor light">
  <p>10 people bought this in 48 hours</p>

  <p>GoodHome Mulanje Industrial Matt White Wood effect Floor light</p>
  <p><span class="sr-only">5 stars</span>(3)</p>
  <p>£48.00</p>
</a>

But this has the effect of utilising the entire card as the accessible name for that link, as it constitutes the 'content' of the link.

So the accessible name of the card link becomes:

GoodHome Mulanje Industrial Matt White Wood effect Floor light 10 people bought this in 48 hours GoodHome Mulanje Industrial Matt White Wood effect Floor light 5 stars (3) £48.00

This is a lot to digest for a user! This method of card markup should be discouraged in favour of only using the primary name as the link (in this case that's the product, but it could be a blog post title). The card click action could then be added with javascript. See more information on this approach to cards on the Inclusive Components site.

There are other issues with the card in this example. For example the product is plain text when it could be useful to have it marked up as a heading. The image is also just the product name, which as well as adding repetition does not really describe what the product looks like to the user. See more on writing accessible content, including alt text.

Placement of extra copy

The critical thing with speech recognition users and editing an accessible name to add context is that only added to the end of the visible label. Speech recognition software varies in ability to search for content and most do not respond well to the visible content not being the first content in the accessible name.

For example if you have a link like this:

<a href="/">change name</a>

and you want to add some context, don't do this:

<a href="/" aria-label="Bob change name">change name</a>

or this

<a href="/" aria-label="change Bob's name">change name</a>

as most speech recognition software won't make the match when a user says “Click ‘change name’”. Remember speech-recognition users cannot see the aria-label content, but the software can (it needs to for a variety of reasons).

Instead add the new content to the end of the visible label:

<a href="/" aria-label="change name for Bob">change name</a>

Guidelines

Here are a few pointers to help reduce the amount of issues you may have with accessible names.

Prefer visual labels

Where possible keep accessible names visible, especially where the item is interactive, such as a link, button or form control. This will ensure people who do not use software which exposes hidden accessible names to them will still be able to determine the purpose.

For example if we provided an accessible name to a button with just an aria-label and image:

<button aria-label="Open menu"><svg>...</svg></button>

then it would be more difficult for anyone not using a screen-reader to determine the purpose of the button than if the button contained visible text:

<button><svg>...</svg> Open menu</button>

The second option makes it much clearer to all what the button does, and also lets speech-recognition users know what they have to say to activate it.

Follow the ARIA rules

As some of the techniques we have discussed use ARIA attributes, we should always look to follow the rules of ARIA.

There are two which particularly apply to accessible name ARIA attributes:

1. If you can achieve the same by using an HTML element rather than aria then do so. For example, do not add aria-label to an input when you can use a label element instead.
2. All interactive controls need to have an accessible name, whether this is achieved using ARIA or not.

How should this element be named?

As a general rule assume only landmarks and interactive controls such as links, buttons and form controls can have attributes like aria-label or aria-labelledby applied.

Elements such as span, p and div have what is called a generic role by default and fall into a group which cannot have these attributes applied.

For which aria roles can have accessible name and how they can be set, see the W3C naming guidance

Do not overuse aria

It can be tempting to add accessible names via aria-label attributes to lots of elements, such as sections in a bid to help the user. But this can just add noise for the user and make maintenance more problematic. Instead consider the above guidelines - use HTML elements where possible and visual labels - perhaps using visible headings instead. Only add it where you know it will help - and test it in a screen-reader.

Wrap up

Accessible names are how you communicate the meaning of the interface to your users and getting it right is really important.

If you have any doubt as to what the accessible name is for an item, most browser developer tools now have an accessibility panel which shows you the computed value. However testing with screen‐readers and speech recognition is still necessary to ensure the correct meaning is conveyed.

• Introduction
• Considering users
  • Interaction modes
  • Reduced typing
  • Memory conditions
  • Numbers
  • Avoid redundancy
  • Save progress
  • Time restrictions
  • Cognitive load
  • Inclusion
• Communication
  • Styling
  • Labels
  • Placeholders
  • Hints
  • Errors
  • Grouping inputs
• Assistance
  • Validation
  • Avoid select inputs
  • Avoid disabled buttons or inputs
  • Avoid read-only inputs
  • Showing the correct keyboard
  • Helping browsers autofill inputs
  • Focus indicators
  • Do not disable copy & paste
  • Avoid using maxlength
  • Size fields to expected data
  • Review before submission
• Wrap-up

Introduction

Forms are a key part of accessibility as they are often the reason a user will interact with a page - whether that is to buy a product, post something on social media, contact a company or communicate with their bank or government.

With so much of the daily interactions moving to digital, having accessible forms is essential for living today. Consequentially having a form which does not account for the needs of users can lead to those users being excluded from crucial services or aspects of daily life.

Whether it is a simple single field newsletter sign-up or a multi-page application form there are things we need to get right to ensure everyone can use it.

Considering users

Before we start to think about designing a form we need to consider our users.

Interaction modes

Different users may interact with our form in different ways so we need to be careful that our form design does not get in their way or make it difficult to understand what we are asking for.

For example:

• Some users cannot use a mouse so more complex input types will need to be checked to ensure they can be used with just a keyboard.
• A screen-reader user is going to rely more on programmatic relationships between form fields and content to understand what is being asked.
• Speech-recognition users will use visual labels to place their cursor in a field. Labels need to be both visually and programmatically associated with the field.
• For screen-magnification users we need to be sure that the form is easy to follow when perhaps only one field can be seen at a time.

Reduced typing

Some users find it difficult to enter data by typing. Perhaps a physical condition makes it difficult or painful to type; they find thinking about and constructing answers difficult or they are not confident in how their answer may be interpreted. These users may benefit from answering questions with a simple yes or no, instead of having to type an answer in a field.

Memory conditions

Users may have conditions which affect memory so designing for recognition rather than recall will help. Reduced typing solutions can help here too. For example picking an option from a list rather than asking for them to type in a field.

Similarly avoid asking the user to remember answers from previous pages. Instead provide the information the user needs on the same page where you are asking the question about it.

Numbers

Some users find it difficult to work with numbers. This can be due to low numeracy or conditions such as dycalculia. Where possible we should avoid asking users to make calculations, instead we should be doing this for them.

This can be a particular issue when digitising a paper form as these tend to ask the user to do calculations. If we are not careful we can just duplicate the paper form instead of looking at ways we can make the user's life easier.

Avoid redundancy

When we are building our form design we want the user to have to do as little work as possible. The easiest way we can do this is by not asking the user questions in the first place.

We should avoid asking the user any questions which we do not need in order for them to complete the given task. For example, don't ask questions which don't provide value for the user (such as demographic information for metrics) or ask questions which you can get the answer to via other means (such as querying your own databases or APIs).

Similarly do not ask the user to enter the same data more than once. If the task requires the user to enter their address for shipping and then they need to enter a billing address, allow them to pick the shipping address if they are the same.

Save progress

Conditions and disabilities can make interacting online very tiring, moreso if it involves having to think about answers or typing. It might be that users are unable to complete multi-page or lengthy forms in one sitting. To help users we want to save progress as they go and give them the option of exiting the form and coming back later.

In order for this to be effective the option should be clearly signposted so the user is not uncertain if their data has been saved. When they return they should be able to pick up where they left without having to revisit all the completed pages.

Time restrictions

Whether the form allows the user to save and come back or not we also want to avoid setting artifical time limits on the time they take. Again not all users work to the same pace and asking users to complete an application or move to the next section within 15 minutes may be ok for some but difficult to achieve for others.

The way we can manage this is to either not set any limits in the first place or offer a way for the user to extend their session. The most common way is to provide some type of alert or dialog which appears shortly before the session is about to expire offering the user the chance to extend their session.

Cognitive load

Whilst it may be possible to cram all the fields your task needs onto one page it can be better for the user to spread them over several pages.

Having a lot of fields on a single page may feel more efficient, however it has a few downsides.

• having a lot of questions on one page can be overwhelming
• less chance to save progress
• more time pressure
• more difficult to locate errors
• more chance for data loss
• branching questions become more technically complex and more difficult to understand

We can avoid these issues by placing small groups of related questions on their own pages. This allows the user to just think about that topic, keeping cognitive load as small as possible.

This is a pattern called “one thing per page”. The “one thing” does not mean one field, but one concept per page. For example “Your contact details” is one thing but may include fields for your name, email, phone and address.

This may not always be the best solution - for example users who reguarly fill out the same form may prefer to avoid the additional navigation, or users may prefer to see the entire form in one go to better manage expectations and required information. However this pattern is often a good starting point and fields can be grouped onto the same page in response to feedback during testing.

Inclusion

We should also consider if we might be excluding users by the questions we ask. This also crosses into inclusivity and includes examples such as:

• asking about gender or sex
• asking about equality information
• cultural biases such as asking for a first and last name rather than a freeform field
• only asking for a phone number when users may prefer or need to be contacted in other ways

Remember that if you need to gather data around a user's gender or pronouns you should also have a route for them to be able to edit them in the future.

Communication

Forms are all about communication. Content within a form is really important to get right. We need to avoid any confusion about what the user should enter and in what format. When things go wrong we also need to make sure they know why and how they can fix it.

All the following need to be carefully considered by content designers:

• content which directs the user to the form
• labels and legends
• hint copy
• error messages
• confirmation and “what happens next” content

But before we get into these, we also need to think about how our form is communicating with the user visually.

Styling

When users are entering data into a form their main concerns are going to be about getting the data entered and knowing they have filled in all the required fields. Whilst a set of fields which fit nicely with the site design are pleasant, this should not detract from the functionality of the form or get in the way of the user completing their task.

Also think about font-sizing. Users are able to adjust their font sizes so ensure that your styles are able to cope with this.

If you are going to be doing anything but very simple form styling you need to look to heavily test these components. This includes introducing components from a component library (such as calendar pickers). Even simple CSS can render a form inoperable to a keyboard or screen-reader user. This is even more of a risk when javascript is also introduced. This can mean they will not be able to complete their task - which may be the primary functionality of the site.

More about styling impacts in forms

Labels

Labels are a visual instruction for a field, but it is not enough to place text above an input. There are several things to consider when writing and coding a label.

Larger touch target

When correctly associated with the field labels provide a larger hit target as clicking the label will place focus within the field. This is especially important for checkboxes and radio buttons due to the smaller size of the input itself.

Positioning

Users need to visually associate the label with the field it relates to. This means the label needs to be adjacent to the field. Having a bunch of content between the label and the field makes it more difficult to make this cognitive leap but especially so for screen-magnification users and mobile users.

Take the below for example:

This is not great. If we take this line-by-line we are asking a question, then providing the user with a hefty set of copy around how they should answer and then asking them to tell us the answer (the input). By the time the user has read the guidance copy it is likely they will need to re-read the question. This becomes even more of an issue for screen-magnification users (and mobile users) as they cannot just glance up at the question, instead having to move back up the page to find it.

A better option would be to put that label right next to the input and precede the block of content with a heading:

It would be even better if the block of text could be reworked to make it easier to understand or even broken up a little.

Accessible name

Labels most importantly provide the accessible name for the field. This programmatic link means that when a screen-reader user lands on a field the label is read out.

It also allows a speech-recognition user to focus the field by using the label. Labels should be visible text next to the field and easily identifiable to the user as the label to help make the cognitive link but also assist speech-recognition users in understanding what they need to say to select the field.

Let's take a quick look at a poorly constructed field:

<div>
    What is your name?
</div>
<input type="text" ... />

If a screen-reader user jumped directly to the field above, they would hear:

“Edit text”

They woud not know what the field was expecting and would have to explore the page to find out and assume text above the field was the label. Having the user make cognitive leaps like this is poor accessibility.

Similarly a speech-recognition user would not be able to easily place their cursor in the field. A speech-recognition user would typically say the label text to focus the input (“Click What is your name”) - here doing that would not do anything because the input does not have the accessible name.

Even if we had used a label instead of the div this would make no difference as without the association with the field the label essentially becomes just plain text.

So how do we make this association?

The label is programmatically associated with the field by using the for attribute to point to an id attribute on the field. This relationship allows the accessible name of the field to be supplied by the label contents.

<label for="name">
    What is your name?
</label>
<input type="text" id="name" ... />

Now if a screen-reader user jumped directly to the field above, they would hear:

“What is your name name, edit text”

Let's have a look at that on a larger form.

<label>
    What is your name?
    <input type="text" id="name" ... />
</label>

<label for="name">
    What is your name?
    <input type="text" id="name" ... />
</label>

Placeholders

Placeholders are faint copy inside an input and are set using the placeholder attribute. The intent was for them to provide format information. We will see how even this is problematic but their use has been stretched beyond this to include providing labelling.

Placeholders as labels

If no other accessible name is provided they can offer an “accessible name of last resort”, but are far from an ideal way of providing one.

It can be tempting, especially when struggling for space or when wanting to “de-clutter” an interface to use a placeholder instead of a label. However using placeholders instead of a label has accessibility knock-on effects.

Increasing font size can lead to placeholder copy being cut off. This can also be an issue where the page is translated into different languages and the content becomes longer than the original.

Once the user starts typing, the placeholder (which remember is taking the functionality of the label), disappears. This can be especially an issue when the browser autofills fields incorrectly.

When you remove a visual label you are also removing the ability of the user to verify that they have added their data in the right place. You are essentially preventing the user from checking their answers before they submit the form.

Any format information has to be included in the placeholder, so we are unlikely to be able to provide a meaningful hint. Remember we need to be careful of increased font sizes and translations.

Placeholder contrast is normally low in order to prevent it being registered as actual data entry. However this also means that it often falls below the required contrast ratio so can be difficult to read.

“We'll just increase the contrast so people can read the placeholder then” you might say. When contrast is increased the placeholder copy can sometimes make it look like the input has already been filled in which can lead to more confusion.

Some of the examples above use what is known as the “floating label pattern”. This is where the label sits over the input (so it looks like a placeholder) and then is animated to sit above the input once the user places focus in the field. This is better than just using the placeholder as a label, but issues remain:

• the label has to take on many characteristics of the placeholder (for example low contrast) to avoid looking like the input has been pre-filled
• the label text ends up being overly small to avoid an odd layout shift when it is placed above the field as the inputs are typically closer together

If the labels are going to float, why not just have them in that position in the first place?

Placeholders for format information

Even using placeholders for format information (what we will call hint copy) is problematic. Many of the reasons outlined above also apply, such as contrast issues.

Just as with labels, by removing the format information as the user starts typing you are preventing the user from checking their answer is correct before submitting the form. It also means you will need to be more verbose with any error messaging to make up for that loss of reference.

Repetition

What often happens is placeholder information is added without considering the other options. With some thoughtful reworking we can remove the need for placeholders entirely.

Placeholder wrap-up

Any situation where you end up removing visual information just as the user starts interacting sounds like a terrible idea. But this is exactly what we are doing with placeholders, however they are used. And if the removal of that information does not impact the user then you need to consider if it was really earning its spot on the page in the first place.

This is a great write-up of some of the issues with placeholders.

In short, avoid placeholders entirely. Instead use well-sized labels and leave format information or examples to separate hint copy.

Hints

We don't want to overload a label with too much information. However we still want users to understand if there are particular format requirements or help them understand waht they are being asked to enter a little better. The aim of the hint is to reduce cognitive load and prevent errors.

Good examples of a hint might be:

“For example GB123456”

when asking for some sort of reference number, or

“You do not need to include any middle names”

when asking for someone's name.

Because we do not want to include the hint in the label tag (labels should be short), we need to programmatically tie it to the input somehow so it will be noticed by screen-readers. The way we do this is by using ARIA.

<label for="yourname">
    What is your name?
</label>
<div id="name--hint">
    You do not need to include any middle names.
</div>
<input 
    type="text" 
    id="yourname" 
    name="name" 
    aria-describedby="name--hint"
    autocomplete="name" />

One thing to be aware of is that content which is announced using aria-describedby is stripped of all semantics. So it is best to keep this content as plain text.

For example, avoid adding a link to a hint such as below:

When a screen-reader lands on the input the hint will be read out as:

“This is 6 digits. Find your account number in your profile”

We can see immediately that the link is not announced, so the user is likely to miss that there is a handy link there.

Similarly some screen-readers (MacOS VoiceOver) will stop announcing aria-describedby copy when it encounters markup such as lists, so it is best to keep hint copy simple.

One final thing to be wary of with hints is colour contrast. It is often desirable to make the hints visually distinct from the adjacent labels. It can be tempting to reduced the contrast a little to achieve this. But be aware that all copy needs to be of sufficient contrast for all users to see it (at least 4.5:1 but in practice above this).

Errors

If the data the user submits does generate an error we need to tell the user three things:

1. that there was an issue with their submission
2. which field had the problem
3. how they can fix the issue

Tell the user there was an issue

What a user is going to expect when they hit submit on a form is that they will get some sort of “success” message. So when they don't and instead find they are still where they were, we need to tell them why as soon as possible to prevent confusion.

This means we also need to think about managing the user's focus. If we don't manage focus, the user is going to be dropped back at the top of the page (assuming a page refresh happened) or stay on the submit button (with a javascript handled form). This can mean the user does not realise there was an error as the form and error message may be off-screen. Keyboard and screen-reader users would also need to navigate back down to the form.

If we are dealing with a multi-field form it can be best to present an error summary at the top of the page where it will be very visible when the page loads and we can also place focus on this. But if it is just a single field then placing focus on the field may be sufficient.

An error summary is a section above the form which lists all of the errors. This can be helpful as it makes it very obvious that something has gone wrong and we can even tell the user that in the error summary heading. The errors listed in the summary should be the same content and in the same order as those in the form it relates to. Ideally the errors in the summary should link to the field they relate to, enabling the user to quickly jump to the field to fix it.

It can also be helpful to add the word “Error” in front of the page title (in the tab bar) as this will mean a screen-reader user will hear that when accessing the page. This can be helpful if either the user switched tabs by mistake or moving focus failed.

Which field had the issue

We also want to make it clear which field or fields had the issue. We do this by displaying an error message next to the field (even if we are showing an error summary) and also adding some sort of visual treatment to make it easy to see the problem fields. The visual treatment should ideally be not just a colour change.

It is also important that the error message remains visible until the user submits the form again. This allows the user to refer to the error for help on fixing the issue.

The error message should be associated programmatically with the field just like we did with the hint, using aria-describedby. If we are also showing a hint for the field then the ids of the hint and error should be added to the aria-describedby in the order they appear on the screen so they are announced in the same order.

How they can fix the issue

Whilst just adding a message like “Invalid” next to a field may tell the user there is an error, it doesn't tell them how to fix it. Our error message should give the user specific information on how they can fix the issue they have.

We also want to make sure we are replaying the data they entered in the field when we show them the error. This means the user can see what in that field caused the error they are now seeing and helps them edit the answer to fix it.

If we don't do this it makes it more difficult to understand the error (as they may have just mis-typed something and be unaware they did) and it allows them to edit it to fix it.

Grouping inputs

For checkboxes and radio buttons which are in a set of options such as below, it is important to provide screen-readers with some way of understanding that they are part of a group beyond the shared name attribute.

We can do this by using a fieldset and legend. As checkboxes and radio buttons have labels which indicate the value of each option we typically want to have some sort of question or name for the group.

The fieldset provides this grouping mechanism (if you are curious this actually has an ARIA role of group). The legend needs to be the first element inside the fieldset and this provides the accessible name for the group. Without the accessible name the group will not be announced.

<fieldset>
    <legend>Where do you live?</legend>

    <input type="radio" value="eng" id="eng" name="country" />
    <label for="eng">England</label>

    <input type="radio" value="scot" id="scot" name="country" />
    <label for="scot">Scotland</label>
    
    <input type="radio" value="wales" id="wales" name="country" />
    <label for="wales">Wales</label>
    
    <input type="radio" value="nire" id="nire" name="country" />
    <label for="nire">Northern Ireland</label>
</fieldset>

The fieldset also means we have a nice grouping which allows us to assign an error message or hint to the contained fields as a set which is necessary as we will be validating these fields as a set.

We can assign a hint and / or error by using aria-describedby on the fieldset:

<fieldset aria-describedby="country--hint country--error">
    <legend>Where do you live?</legend>
    <div id="country--hint">This is your main residence.</div>
    <div id="country--error">Error: select where you live.</div>
    ...

Beyond checkboxes and radio buttons, fieldsets can also be useful if you are asking similar questions on the same page. Having the legend allows the fields to be named the same, but the legend and fieldset provide the differentiation - for example asking for shipping and billing addresses.

They can also be used to group other inputs which need to be seen by the user as related - for example a date group consisting of three text inputs for day, month and year.

What we don't want to do is apply fieldsets where we don't need them. This is because screen-readers will announce the fieldset as a “group” with the legend as the accessible name. We only want to be providing information like this where it will be useful, this keeps noise to a minimum.

Assistance

Validation

HTML5 Validation

We need to talk about HTML5 validation at this point. When you use certain attributes such as required, maxlength and pattern, or certain input type attributes like email, this triggers HTML5 validation (also known as native browser validation or constraint validation). This is not very good from a usability or accessibility point-of-view - for example the messsages do not persist, have issues with zoom and the user only gets one error message at a time.

Whilst it can be improved, it is a lot of work and just adds complexity. The recommendation is to disable HTML5 validation and handle error messages ourselves. Adding a novalidate attribute to our form tag will prevent this validation from ever appearing.

<form action="/" method="post" novalidate>

Dynamic error handling

Dynamic error handling, also referred to as client-side validation, is where fields are checked to see if the data is valid using javascript. This is best done when the user submits the form, rather than firing off errors whenever a user enters invalid data (what we will call inline validation).

The issue with inline validation is - when do you tell the user?

Often you will see websites trigger an error message as soon as you place your cursor in the field and it only clears when a valid entry is added. This is clearly problematic and not desirable.

How about validating after each character or word? Well consider how this might sound to a screen-reader user who is trying to check that they pressed the correct key. Each validation check would trigger an announcement which could prevent them from hearing information they need to fill in the field. Remember we

So how about validating when the user exits the field? The problem here is that the user has most likely moved to another field and will be on that field when the validation announcement is played. At best it is going to distract them from their current task of filling in the field, at worst depending on the error message they could think the error relates to the field they are on right now.

So validation is best left to when the user expects it - on form submission.

Be forgiving

We should also think about the validation we are carrying out. Our aim is to prevent the user from seeing any error messages. The best way we can do this is by using helpful labels and hints with examples of the data expected so the user is more confident about their submission. But where there is some format required it might be that by being just a little bit forgiving with our validation we can avoid the error in the first place.

Let's look at a couple of examples.

Here we have a tracking ID field which is asking for a 2-letter prefix followed by 8 digits. We have a hint with the format in to help the user. However this does not mean we have to be really strict with what we will validate. We can see the user has input lowercase letters (well we didn't say about it being case-sensitive) and the numbers have spaces every couple of digits.

There are a few reasons why a user may enter the reference in this way, for example:

• simply not understanding the format is strict with casing and spaces
• when using speech-recognition or by using the voice-entry option on a mobile virtual keyboard. As the user reads out the reference, each time they take a breath the software will add a space, especially if the user groups numbers. For example the user may enter this by saying “gee bee twelve thirty-four fifty-six seventy-eight”.
• users with low numeracy or dyscalculia may prefer to enter numbers with spaces to aid reading
• users with poor motor skills may have difficulty changing case
• screen-reader users will hear the hint but may not pick up on the casing
• by copying and pasting from elsewhere - this can also introduce leading or trailing spaces

Instead of failing this on validation we can be a bit smarter - and more helpful to the user. We can simply uppercase and strip out spaces from the user's entry and transform this into our desired format. We can see what they mean and are not changing any of the actual meaning of the data. But we will prevent the user from seeing an error.

In the next example (below) we have a field with a unit of measurement as part of it. The unit is displayed visually but it is hidden from assistive technology, instead the unit is mentioned in the label. However as screen-reader users cannot see the unit placed after the input, suggesting that the user does not need to add it, we should allow the unit as part of the entry and strip it out. Care should be taken to allow different versions of the unit which users may enter, such as different casing.

The only place you may not be able to be as forgiving is if the data is case-sensitive or where spaces have meaning. But where possible we should be avoiding this being a requirement in content like reference numbers. By thinking about accessibility from the start we can look to design out stumbling blocks like this before the user is affected. This both helps speed up form completion and means less errors are seen which then reduces the overall cognitive load of the form.

Optional or required

It can be helpful to indicate in the label if the field is optional or not, the actual implementation will depend on your use-case. One thing to bear in mind is that the required attribute is to trigger HTML5 validation and prevent submission of empty fields. As we want to avoid HTML5 validation this is something we also want to avoid.

There is an aria-required attribute which purely signals to assistive technology that the field is required, but does not do anything beyond that - so does not trigger validation but also does not tell any other user that the field is required. Also bear in mind that if all your fields are required, having this attribute announced on every field can become intrusive for screen-reader users.

A better option is sometimes to just indicate the optional (or required) field status within the label. This way everyone gets the information.

Avoid select inputs

Whilst select inputs can offer an easy way to display a lot of potential answers, it has been shown that using them presents challenges to some users. This can be problems in trying to recognise which answer should be chosen (especially if the list is long), or difficulty in scrolling or picking from the list.

A better solution might be using a set of radio options, using a type-ahead or even reworking the design to avoid the need for the select input.

Avoid disabled buttons or inputs

A not-uncommon pattern is to disable a submit button until all fields in a form are filled in or valid. Disabling controls (inputs and buttons) is an issue for users for several reasons:

• to distinguish from non-disabled controls they often have reduced contrast making them difficult to read
• users may not understand why a control is disabled and become frustrated
• disabled controls are not included in the native tab order for keyboards

Disabled buttons

The last point brings us onto another variation of this pattern which is hiding a button until certain prerequisites are fulfilled. Whether hiding or disabling the submit button, the user may not understand how they can proceed - they may not realise they have missed one of the requirements.

Instead keep it simple - present the button and allow the user to submit the page. Then explain why they cannot continue. If it is an issue with a field on the current page then display an error as normal. If it is more complex such as a section has not been completed then take the user to an explainer page where the issue can be detailed and the user directed where to go to fix it.

Here is an example of a button being disabled until inputs have been filled:

The issue here is the user may be trying to click the button but nothing happens - and no error message is shown. It is not clear that the button is in fact disabled. This means the page is asking the user to problem-solve why they cannot submit the form. The user may work it out or they may abandon the task.

A better solution would be to allow the user to submit the form and then provide error messaging for the missing field information. This requires more work and thought from the team, but will result in a better outcome for the user and likely less abandoned forms.

Disabled inputs

Similarly disabled inputs can be an issue. The contrast has to change to indicate the difference to normal inputs, but this is either so slight as to be hardly percievable (causing users to click on the input thinking it is an active input) or so different as to make the text in the input unreadable. They are also not included in the natural tab order.

Avoid read-only inputs

As with disabled controls, read-only inputs tend to cause confusion. Whereas a disabled control is removed from the tab order, a read-only one remains in place but cannot be edited. This duality can be confusing, especially as the read-only state is not visually communicated.

This is often done to save development time - it is easier to just switch out the readonly attribute than do the work needed to use static text instead and the potential styling and routing for edit option requirements. But by doing this work we can make a more understandable interface.

Instead make it clear what the user is looking at and how to proceed. If the data is not in an editable state then display it as text and have an “edit” button alongside if needed. This way the user can see what they can edit.

Showing the correct keyboard

Most of the time when entering data in a field on a touch-screen device you will be using the standard virtual keyboard which shows the QWERTY key layout.

But sometimes we might want to alter which keyboard is shown. For example if the user is entering a phone number then having to switch to the number keyboard will take time and effort and even then it may not be easy to use.

For this reason we are able to give the user's device hints as to which keyboard should be shown for a given input. For example for a field asking for an email address we can present a specific virtual keyboard which includes email-specific keys such as @. This saves the user having to switch keyboards part-way through their entry to find that symbol.

We can do this by using either specific type values (which have an implicit inputmode) or by using the inputmode attribute directly. Some of the more useful inputmode values:

• inputmode="tel" (or type="tel") will present a phone keypad making it much easier to add a phone number
• inputmode="email" (or type="email") will add specific email address characters like @ and .
• inputmode="numeric" will display numbers but should only be used for whole numbers as the keyboard may not include a decimal point

Things to avoid with inputmode and type attributes

The actual keyboards presented will depend on the operating system so it best to conduct testing if exploring other options.

There is an issue with some system's handling of inputmode="decimal". Whilst this should display a number keyboard (as numeric does) but with the addition of a decimal and/or comma, some systems omit to include the decimal. As such it is best to avoid this value or do comprehensive testing.

Be aware that the type="numeric" should be avoided. This has also had a troublesome past with some browsers allowing the user to enter non-numeric values but then stripping them out of the data actually sent to the server. It even caused issues with numbers entered with decimal points as they aren't whole numbers. Instead stick to the inputmode="numeric" attribute to provide assistance without the validation issues.

Helping browsers autofill inputs

It can be annoying to have to keep typing your name, contact information and payment information into forms all the time. Browsers can now store this data for you and when they see a form which is asking for it prompt you to autofill it from this stored data.

This can be very useful for people who have cognitive conditions which affect their memory for example or those who find typing difficult or tiring. Whilst browsers can try to work out which fields to suggest autofilling they can sometimes get it wrong. This can end up with the browser not prompting the user, leaving some fields blank or in some cases adding the data to the wrong field. As such it is always best to help the browser out by telling it what data (if it has it) it should add to which field.

This is done by using an autocomplete attribute with a set value. For example here is how we would mark up a field which is asking for someone's full name:

<label for="fullname">Full name</label>
<input type="text" id="fullname" name="fullname" autocomplete="name" />

This has some obvious benefits:

• reduced typing for the user
• allows the user to use recognition rather than recall
• avoids introduction of spelling mistakes
• speeds up form filling, especially for addresses

Note we should normally only add autocomplete attributes to fields where we are asking for data which we can anticipate they have the data for. This is normally their own personal data. So if the above field was asking for someone else's name we would not add the attribute.

For some data we can add more than one value to be specific, such as here where we are asking for the person's work phone number (as distinct from their home phone):

<label for="phone">What is your work phone number?</label>
<input type="tel" id="phone" name="phone" autocomplete="work tel" />

Focus indicators

Just as with other controls, form inputs and buttons should have very visible focus indicators. For text inputs, strictly speaking the cursor flashing is counted as enough of a focus indicator to pass WCAG compliance, but some users may modify their cursor not to flash and besides we want to go way beyond just compliance.

Ensure that at least some of your error styles are not obscured when the field is focussed.

Whilst browser default styling is enough to pass compliance for radio button and checkbox indicators, in reality they are very poor. So we would want to also provide good focus indicators to the non-text inputs too.

Providing custom focus indicators for form controls can really help users find their place in the heavily interactive landscape of a form. Be careful not to cause additional accessibility issues when adding styling.

Do not disable copy & paste

Sometimes there is a requirement to disable copy & paste in a form. Requirements like this should be scrutinised to see if a different approach could be used instead. Removing the user's ability to copy & paste is going to disadvantage users who may rely on this - for example speech-recognition users often work within a sandbox area to generate responses which they copy & paste into a field.

Look for alternatives. For example, you are asking for an email address twice to prevent errors and are disabling copy & paste to force the user to type it in twice. Instead add an autocomplete attribute to an email field potentially avoids the user typing at all, and then you could replay the entered email before submission, or send a confirmation email.

Avoid using maxlength

The maxlength attribute is often used when asking for data which we expect to be a certain length and no more. For example reference numbers or dates. The issue with this is that users are not told when the limit is reached, often browsers will just stop responding to data entry. Even if we tell the user in a hint how many characters the answer should be it can still cause issues.

We have already discussed not disabling copy & pasting. Users may need to paste in a larger answer before editing it down. Similarly for longer answers (such as in a textarea) it is best to allow the user to go beyond the allowed limit within the field to finish a train of thought and then they can reduce their answer by editing it down.

We have also seen how speech-recognition can add spaces to data entry and how we should be forgiving of this in our validation. If we physically restrict the data length we can end up with some very unsatisfactrory outcomes.

The best approach is to let the user know of the required format but allow them to exceed it in their submission and if necessary display an error message to allow them to edit their answer down to the correct length.

Something to bear in mind with this example is that the user was not notified of the restriction ahead of entering their information. It is always a good idea to make the user aware of format requirements so they can adjust their answer accordingly and avoid the error in the first place. In this case the limit is really too restrictive for the required data and we'd want to set a limit which the user would be very unlikely to hit (such as 50 characters) - if we did this we would not need to make the user aware as no-one should hit the limit.

For larger blocks of text where the user is being asked to submit several sentences of copy, we can look at using dynamic messaging. This can indicate how many characters they have left and even more usefully how many they are over the limit by. This can make use of an aria-live region to ensure screen-reader users are updated too.

Size fields to expected data

For visual users it can be a help to size text fields to give an indication of the amount of data required. For example the field for a post code should be shorter than that for an email address.

Having a field which is too large or too small can make the user wonder if they are entering the correct data. A field which is too small can also make it difficult to read the content and even more difficult to edit it confidently. Always ensure the field is large enough to accomodate the longest answer you might expect.

Review before submission

It is good practice to allow users to review the data they have entered before they finally submit it, particualry if there are more than a few questions. This should also provide an opportunity for them to change any of their answers. This is especially important when the thing the user is submitting is to do with official documents - such as a government application, legal or financial processes.

When a user goes to edit one of their responses we should where possible take them to the same page where they entered the data, with their data pre-populated. This should provide the same labels, hints and guidance material they had first time around as well as letting them re-read their answer and edit it if needed. By replaying their answer we allow them to simply correct a spelling issue without having to re-enter the whole thing.

Once the user has finished editing their answer we should return them directly back to the review screen - not require them to resubmit each subsequent page after the one they just edited. There may be some additional work involved if the form included branching questions to clean up redundant answers or present additional questions where necessary, but the user should be returned to the review screen as soon as possible.

Wrap-up

Forms are a complex thing and offer many places where we can inadvertently place barriers in the way of users accomplishing the task they are set on.

By considering how we can reduce the friction users have with forms we can make this potentially stressful part of digital interaction less daunting.

• Introduction
• Inclusive content
• Plain language
• Colours
• Directional content
• Headings
• Links and buttons
• Image alt text
• Charts and graphs
• Transcriptions, captions and audio description
• Adjusting content for screen-readers
• Form content
• Wrap up

Introduction

Content is the first building block of a website, so it is crucial to how accessible the final product will be. If a user is unable to access or understand the content the rest of the page will fail along with it.

When writing accessible content we should favour clear messaging and understanding over anything else.

Inclusive content

One of the important aspects of accessibility is making all our users feel considered and welcome in the end result. Writing inclusive content is a large part of this. Content should be free of bias and exclusionary or discriminatory language. This is especially important when it comes to asking users for personal information.

Think about how we talk about age, disabilities, ethnicity, religion, gender and sexuality. But this also means thinking about the way we ask questions to allow a wider accepted answer. For example rather than asking for “First name” and “Last name” simply asking for ”Full name” can make entering this information easier and less of a barrier.

A wide audience

Writing accessible content is not just writing alt text for images and copy for screen-readers. It is making content easy to understand for as many people as possible.

For example, short-term memory conditions (such as dementia) might mean the user loses their place when reading a page. In these cases reducing the cognitive load can help. A well written page broken up into sections reduces the cognitive load and helps the user find their place again. This guide to writing better for those with dementia (PDF) also includes some very good general accessibility content guidance.

More reading on inclusive content

• NHS Inclusive Content guidance
• Inclusive language: words to avoid when writing about disability - Gov.UK
• Inclusive Language guidance - Atlassian

Plain language

Content construction is at the core of writing accessible content.

As well as being easier to digest for all users, plain language can be essential for some groups such as

• those for whom English is not their first language (including some British Sign Language users)
• those with cognitive conditions such as dyslexia which make reading more difficult

Especially for online content, we should be looking at a reading age of around 9 years old. Lengthy sentences should be avoided where possible. Long sentences can slow down reading speed and make it more difficult to understand what is being said.

Other things to avoid are:

• acromyns - if needed then they should be written out in full with the acromyn alongside when first used on a page (for example "Pay As You Earn (PAYE)...")
• jargon - even when writing for a professional audience, using simple terms rather than jargon can make things easier to understand
• slang, metaphors and similies - these can be confusing for people with certain cognitive conditions and for those for whom English is not their first language

Tools such as Readable and Grammarly can be used to test our content for any potential issues and help aim for the right reading age level.

Plain numbers

If the content deals with numbers in any way we should look at how to support users who have may have difficulty with them. This includes conditions such as dyscalculia (which is a difficulty in dealing with or understanding numbers) and low numeracy skills in general.

Simplifying and explaining numbers and calculations can help. We should also avoid asking users to do calculations themselves (including things such as rounding up a figure).

More reading on writing with numbers

• Accessible Numbers
• Designing for people with dyscalculia and low numeracy - Gov.UK

Colours

We should not rely on colour alone to convey information. For example using green to signify success and red to indicate an error, or phrases like “pending applications are shown in blue”.

Users with visual conditions such as colour-blindness as well as screen-reader users will be unable to perceive the connection. We should ensure that the information is communicated in an alternate way such as a text label. Other visual differentiators such as a shape or pattern can be used, although we should ensure the same information can also be perceived by screen-reader users.

Tools like Color Oracle can be used to simulate how colour-blind users might see a page.

Directional content

Screen-readers consume content in source-code order which may be different from the visual layout. Bear this in mind when assuming a user has seen or read content from elsewhere on the page.

As screen-readers linearise the page for the user (as they read the source code), we should not use language which refers to a "left" or "right" direction when referencing other content. For example avoid saying "the image on the left shows ...". Using "above" or "below" is ok, but make sure to check that the visual position also matches the source code order and that the visual layout doesn't change depending if the page is viewed on mobile or desktop.

Headings

Breaking up content with section headings as already mentioned goes a long way to improving accessibility for many users.

Screen-reader users employ similar scanning techniques to how visual users do, just using elements instead. For example they may read all the headings first to determine if any of the sections might contain the information they need. Headings are one of the main ways screen-reader users navigate around busy pages.

The hierarchy of the content should be reflected in the headings used. Heading hierarchy moves down from h1 (level 1) to h6 (level 6). A page should only have one h1 which should be the principle headline or purpose for the page. Other headings normally follow the h1 and it is important that they are marked-up correctly as these are announced by screen-readers to help users understand how content is related.

Providing an annotated screenshot with each heading level indicated is one way to communicate the hierarchy to developers. This can be especially useful where areas of a page use different font sizes for the same heading level.

Links and buttons

It is useful for all users that links and buttons are descriptive of the thing they link to or the action they will perform.

Magnification users

When using high magnification a user might not have clear view of the surrounding context for a link or button. Making them descriptive can add confidence and avoid the user having to go back through the preceeding copy to confirm.

Screen-reader users

Screen-reader users can extract lists of elements from the page to examine in isolation from the rest of the page copy. This includes links. Because of this all link copy should be both unique and give some indication of the destination, ideally even when taken out of the context of the page. It might be that adding this kind of information might make the page overly cluttered. In this case we can add additional copy which won't be visible but which screen-readers will still pick up.

For example we can use a visually-hidden CSS class to hide the additional content but which still allows it to be picked up by a screen-reader. To a visual user both links below will read “Change”, but to a screen-reader user they will be announced as “Change your name” and “Change your address”. The same effect could also be achieved using aria-label - read more about ARIA.

<a href="...">
    Change
    <span class="visually-hidden"> your name</span>
</a>

<a href="...">
    Change
    <span class="visually-hidden"> your address</span>
</a>

Speech-recognition users

Speech-recognition users use their voice to click buttons, links and inputs and need to know what they need to say to perform that action. So if a button contains the text "Send", then they would expect to be able to say "Click send" to action it. This is why having a visible label for each is important.

Speech-recognition software is also affected by hidden copy like we used in the example above, just like screen-readers, but users of it can only see the visible copy.

<a href="#">Change<span class="visually-hidden"> your address</span></a>

In our example above, the user might say “Click Change”. In this case, even though this is not a full match, the software should do a partial match on that phrase to both links and the user will be able to choose from either.

It is important that any visually-hidden content such as on links this is added to the end of the visual copy. As speech-recognition software pattern-matches the spoken word to elements on the screen, adding copy before or between it can interfere with this.

However, if we add the hidden copy before or inbetween the visual copy (as below) it might make it much more difficult for them to trigger that link. This is because the user will say “Click Edit account”, but the software will not find a match to the spoken phrase.

<a href="...">
    Edit 
    <span class="visually-hidden">Bob's</span> 
    account
</a>

Speech-recognition software varies in their pattern-matching skills, so results can vary. The aim is always to make it as easy as possible for users to trigger the command they want.

Telling a user about context-change

Finally, if opening links in a new tab it is advisable to tell users this as part of the link copy. Studies have shown opening a link in a new tab without warning can disorientate users. We add the text to the link to be sure screen-reader users get this information too. For example:

<a href="..." target="_blank">
    View our guidance (opens in new tab)
</a>

Image alt text

Some users cannot see the images we use and so it is down to us to make sure they are not missing out. This means being thoughtful about what alt text we use on those images. Because alt text is literally out of sight it is often thrown in just as a filler without much thought to what the user might need.

Types of image

There are several types of images when it comes to alt text:

Utilitatian

For these the alt text may often not be a description of the image, but an indication of its function.

For example, icons which need to communicate functional meaning like a "menu".

Of course where these functional images are used we need to ensure that the words we use are going to be the words the users would use. After all a speech-recognition user is going to need to use these words to activate it. If in doubt it can be best to add visible text to the control and leave the alt text blank:

<a href=""><img src="/i/my-account.png" alt=""> My Account</a>

Note we don‘t start alt text with “image of” as screen-readers will already get this information from the element.

Informational

This is the typical image you might think of when adding alt text. They are images which add information to the wider content, perhaps to illustrate a point or give further clarity. The idea here is to describe the image to support the surrounding content. Care should be taken not to add information which is not available in the image as users who cannot see the alt text will not have access to it.

<img src=".." alt="A classic 2-door yellow sports car with a roof-rack. On the roof rack is a christmas tree tied down with bright green straps.">

Emotional

These are images which can sometimes be thought of as decorative. Occasionally an image may be added to a page to impart a certain feeling. Screen-reader users should also benefit from this as it may change how they read surrounding copy. Try to put across a sense of this emotion in the alt text as you describe the image.

Decorative images

There are cases where an image should not have any alt text (although they should always have an alt attribute). For example it could be that the image is purely decorative. In these cases it might be that not adding alt text is the right thing to do.

Consider context

The important thing to consider when adding alt text is the context. The image is often trying to put across a specific message to support the surrounding content rather than just being placed there in isolation. This could mean that the same image used in several places across a site may have different alt text in each use-case. It may also mean that you need to take the audience and their level of knowledge into account.

What is the important information?

A screen-reader can only do one of two things with alt text. Listen to the whole thing or stop listening part-way through. There is no way for them to skip through, so if you put important information at the end one of two things can happen - they will have to listen to the whole thing each time, or they might even miss it, moving on once they think they have got the gist.

For this reason look to front-load alt text where possible by giving the important information at the start.

Avoid repetition

There is a reason we might want to use an empty alt attribute on what would otherwise be thought of as an informational or utilitatian image. This is where adding alt text would cause immediate repetition for a screen-reader. This can also make a link more difficult for speech-recognition users.

Alt text vs image captions

Alt text is very different to a figure caption and the two are not mutually exclusive. Alt text as has been discussed is about describing the image for those who cannot see it and it does not add any more information than what is in the image. A caption can add more context to the image.

More reading for alt text

Alt text seems simple but is deceptively difficult to write well. Here is some more reading to help:

• Dungeons & Dragons taught me how to write alt text - Eric Bailey
• Your Image Is Probably Not Decorative - Eric Bailey
• Writing great alt text: Emotion matters - Jake Archibald
• Text descriptions and emotion rich images - Léonie Watson
• My Approach to Alt Text - Adrian Roselli

Charts and graphs

These can be tricky as some of the content may be available to screen-readers, but because graph and chart output can vary so much depending on the technology used it needs to be tested properly by the team. If we cannot make the output accessible to all, then we need to consider alternates which could convey the same information.

A written version of the data can help the all users understand the visual whether they can see it or not, especially if they find working with numbers difficult. We might add a curated summary of the content if the data is static or easily adapted. If the data is more dynamic and precludes a summary written in advance, one option is to look at using AI to provide one, using a well-crafted prompt, to highlight trends in the data.

If the data is more complicated and the user might want to look at all the data points then offering a tabular version means a screen-reader can access the data on-screen. An optional downloadable version (for example as a spreadsheet file) would mean any user could open the data in their accessible app of choice.

Transcriptions, captions and audio description

Just as with images, not all users can watch video content or listen to audio. The difference with audio and video is that the audience is even wider. They allow users who cannot consume the original to follow along but also help users who may have trouble understanding the original for whatever reason.

Transcriptions

Transcriptions are a written version of the audio which can optionally be synchronised to the original. As well as making the content available to those who would otherwise miss out, it makes that content more easily consumable and findable. They enable users to skim, search or review the transcript to see if it contains the information they are looking for without having to sit through the entire original. In addition to this it can make the content easier to follow for someone who has difficulty keeping up with captions. Transcriptions should be placed alongside the player so they are easy to find and can be followed as the video plays.

Captions

Captions are placed over the video and allow the user to follow along without the audio. They include any dialog but also noises and other audible information. In this regard they differ from subtitles which are intended to be consumed by those who can hear the audio and which contain purely the voice content - for example they are used where languages are being translated. Ideally videos should use a platform which allows captions to be adjusted to a size and colour which suits the user.

Audio description

Audio description is an additional audio track laid over a video describing what is happening on-screen for those who cannot see it. At its most complex this can be found on tv shows and movies. But even short videos for the web can benefit from an audio description if there is on-screen information which is not verbalised in the video.

Adjusting content for screen-readers

It can be tempting once we hear content read out by a screen-reader want to change how some of it sounds.

For example a reference number might be read out differently to how we might expect or desire:

"QQ123456C"

might be read out as

"Q Q one hundred and twenty-three thousand four hundred and fifty-six C"

Resist the urge to ask developers to change how this sounds by manipulating screen-reader copy or adding various attributes to it. Screen-reader users are listening to content all day and know how things sound. They can also adjust how their screen-reader reads out this kind of content and if they want can also read it out character-by-character.

Trying to adjust content purely for a screen-reader can also have knock-on effects for other users such as braille and speech-recognition users.

However, sometimes it might be that changing how our content is written can improve understanding.

This could be removing some repetition, such as we have already discussed around image alt text. But it could also be about making our content more understandable when removed from the visual context. By listening to the content in isolation we can sometimes find improvements because our brain is not visually filling in missing words or fixing spelling errors.

What screen-readers don't announce

Styling

Screen-readers do not generally announce formatting. For example, if some content is using a larger font size than other content, this is not conveyed to the user. Some screen-readers can provide some styling information to the user, but the user needs to request this specifically each time and would need a reason to.

This is why using the correct semantic HTML elements and using the correct heading hierarchy is important. If we just made the text look like a heading by making it larger this information does not make it to the user (and it's so Microsoft circa 2006).

<div class="heading-xl">Heading</div> /* do not do this */

<h2 class="heading-xl">Heading</h2> /* do this instead */

This obviously also means screen-readers do not pick up on colours, so where colour is used to convey information it needs to be supported by some sort of text labelling.

Some formatting elements

Formatting such as bold or italics is not announced by default by screen-readers. Whilst users can enable this in some screen-readers, as it is not on by default it is not something we can expect to be available. This means that we should be careful that content which uses this type of formatting should not be reliant on it to highlight content. That is not to say we should not use it as visual readers will find it beneficial.

Form content

An accessible form makes entering the correct data as easy as possible for the user. We want the user to understand exactly what they need to enter and avoid having to revisit the data due to errors.

Clear labels

Make it easy for the user to understand what they are supposed to be entering in a field, or which option they should choose if using checkboxes, radios or a select input. Use a label which is succinct but explains clearly what information is required.

Making the desired data clear it means the user can complete the task quicker, thanks to less cognitive load, and is less likely to result in an error. For some users this can mean the difference between finishing a task and not. When an error does occur we want to make sure the user understands what went wrong and what they need to do to fix it.

Placeholders

Placeholders are a light grey text which sits inside a form field. They were intended as a way of indicating to the user an example. However they have always been a poor solution.

Mobile viewports, the user zooming the interface or increasing the font-size will all mean the placeholder runs the risk of getting cut off.

This can also cause issues when content is auto-translated into a language which results in longer wording than the original.

As the placeholder disappears when the field receives focus, the information it provides also disappears. If this was formatting information then it means the user does not have it to reference as they type.

Placeholders are sometimes used as a replacement for a visual label element to save space, but this only makes the issues worse.

There are other issues with placeholders too. Some user interface libraries use the placeholder location for the label and then animate it to above the field. These so-called floating labels has also been shown to be an anti-pattern.

Hints

Hints can also be used to help remove any ambiguity about how the user should answer a question.

Where the form field is asking for a specific format it is worth telling the user upfront, usually in the form of some text between the label and input. This can include a general format such as “10 digits” or an actual example such as “12 34 56 78 90”.

Hints are, when coded correctly, programmatically associated with the input they relate (typically using ARIA). This means that they will be read out after the label. Avoid putting anything in a hint more complex than a plain sentence as semantics are removed when using aria-describedby. This means a link in a hint will only be heard as plain content - the fact that it is a link will not be announced.

Error messages

When it comes to writing accessible forms, having well-written error content can make all the difference. Error messages should be as specific as possible - one field can have multiple error messages written for it and the relevant one shown based on what caused the error. They should also be straight to the point and avoid blaming the user.

Just as with hints, error messages should be programmatically associated with the input they relate to. And as with hints any semantics will not be announced when read out, so avoid adding links and similar to error messages.

It can also be useful to present an error summary at the top of the page, especially where more than one field may have an error message.

Other content in forms

Avoid adding any non-form content between form inputs. Effectively, from the first form element to the last there should only be content which is directly associated with the fields - that is labels, hints and error messages. These three types of content, coded correctly, should all be exposed to a screen-reader when the user lands on the input.

Because screen-reader users are likely to jump directly from input to input, any other content is in danger of being missed. This behaviour can also be seen on mobile devices which have a "next field" button on the virtual keyboard, and with screen-magnification users who use the tab key to move from field to field. In both these cases the user may skip past additional content between the fields.

Wrap up

Writing accessible content is complex, but by considering the users at each step we can ensure the content can be understood by as many people as possible.

• Introduction
• Why we test
• When to test
• In-team testing responsibilities
• The aim of testing
• How to test
• Wrap up

Introduction

An important part of making sure a site or component is accessible is testing. Just like any other aspect of coding, mistakes can be made, regressions introduced and so on, but accessibility issues can often be overlooked. Whilst some accessibiilty issues can be obvious or caught by automated tools, many need manual testing and an understanding of the potential issues to surface them.

For these reasons it is important that accessibility features as part of an overall testing strategy to ensure it is not overlooked or insufficiently tested.

It is the responsibility for the whole team to test their own work. Whilst the test team has an important role, leaving accessibility to just one or two people on the team is a guaranteed way to end up with a flawed end product which will cost time and money to remediate.

Why we test

Just as with general functional testing we need to verify that our users can complete tasks with the product we are building. Accessibility testing can be seen as a super-intense version of what might be being undertaken right now.

Typically a test process may look like something similar to this:

• user interviews
• prototypes
• user testing
• build with unit and automated end-to-end testing
• browser and device testing
• manual or exploratory testing
• further user testing

But at each of those points, unless we make a concious effort, we will end up just testing the product with people in mind who, from an accessibility point of view, are just like the team which built the product.

We are not our user

There are a large group of users who do not interact with the online world in the same way as the people on our teams. Users who benefit from accessibiilty testing are not a minority, they may form a significant part of our user-base and so we need to take this aspect of testing seriously.

It is all too easy to forget the diverse range of our user base when designing and building resulting in a product which unintentionally leaves out these users by baking in these biases. Poor accessibility can mean a component or page is left difficult to use or understand at best and completely broken, or potentially even make the user ill at worst.

By creating testing processes and strategies which ensure we consider and include all types of users we can start to approach a product built for all, instead of for a narrow section of the population.

The added complexity of assistive technology

With accessistive technology in particular, there are a lot of variables at work. This means even coding to a published specification might introduce issues.

If we take screen-readers as an example, here are some of the factors which can influence the viability of a solution:

• different screen-readers (and versions within the same screen-reader) might support different aspects of the specification, or not support it at all
• different browsers might interact with the same screen-reader in different ways
• even with the same screen-reader on the same browser, there are different navigation methods a user may employ which can introduce variations in support
• regression issues from browsers or screen-readers themselves
• different screen-readers may add their own heuristics to make interactions more usable, but which adds in further variations in how code may be interpreted

Add into this complexity, the fact that accessibility is always a balancing act between the needs of different users. Enhancing the accessibility for one group may adversley impact the accessibility of another, so testing helps expose this too.

This might seem like a lot to consider, but by putting in place some robust testing policies we should be able to affirm the products we build are as accessible as possible.

When to test

Testing should be a continuous procedure and something which is handled by the team doing the design and build work. Accessibility testing needs to be considered as soon as an idea for a component or feature is raised.

Whenever possible testing should include real users with a variety of disabilities and conditions. However realistically most of the testing will be done by team members with occasional valuable insight from users.

Why not leave it to a pre-launch audit?

A “strategy” I have often seen is for a product team to only start looking at accessibility a few weeks before launch, normally because there is a requirement for some sort of sign-off of the product for accessibility legislation or company policy. This can mean the actual accessibility testing work ends up with the team doing the accessibility review rather than with the product team. This approach will always lead to either missed deadlines or products launching with multiple accessibility barriers, which will most likely then languish in the backlog.

This approach also means the product team will never upskill in accessibility as it will always be deferred to another team. The product team will likely make fixes in a rush to meet the launch deadline and so not truly understand what they are doing and why it matters. This is doing the team a disservice.

We should see accessibility issues in a similar way as technical debt in the way the issues increase in quantity the longer the project goes on. Even with the best intentions a team will generate accessibility issues in the code they produce. As time goes on these issues begin to overlap, perhaps becoming more complex, and are copied into new code deepening the accessibility debt. What might have been a simple fix if found at the time of writing may result in a product-wide bug hunt when left.

The increased time it takes to retrospectively fix accessibility issues means that it can cost up to 30 times as much compared to catching that issue at the point it was created.

But these issues may not be limited to only the code. By far the most difficult issues to fix are ones which are fundamental to either how the wider page or journey is designed. By the time we get close to product launch finding out you need to redesign whole pages or components or even whole journeys can be devastating to a deadline and team morale. Typically the product gets released with major accessibility flaws which then persist as new features take priority. This is often related to the MVP paradox.

A pre-launch review can only be used as part of a wider accessibility testing strategy. By itself it is unlikely to achieve the desired outcome as it sits too close to the launch date and is rarely able to prevent a launch if it finds issues.

Design system and coding libraries

Ideally a project will be using a pre-existing design system which has already has been robustly tested. A design system should indicate where accessibility has been understaken, how and which assistive technology was used (including version numbers of that technology and browsers). Without this information it is unwise to assume the testing has been done and is being kept up-to-date so we need to include additional testing in our build.

If evidence of testing is present, then it is a responsiblity of each team to both keep their project up-to-date with the latest releases and have a maintenance plan for this going forward. If any issues are surfaced with library components or pattern library components are surfaced during testing, this should be raised with the appropriate team to assist them in keeping the libraries as accessible as possible.

Discovery stage

Testing of assumptions and hypotheses is normally done with users in the discovery phase, but this too should involve a diverse range of users with disabilities and different conditions. This can be especially valuable if there is an existing system which is being replaced or similar services already exist which they are able to give insight to.

Design and prototype stage

A prototype, whether that is in something like Figma or actually working in HTML, is the best place to get detailed feedback on potential accessibilty pitfalls in a design.

Any kind of high fidelity prototype will allow you to spot issues with content, layout, colours, and page and journey flow. Components which have different states (such as focus styles on buttons) can also be included and checked.

Catching issues in components, page layout or journeys at this point will greatly reduce cost and time spent versus ironing these out after they have made into code.

If using flat prototypes, go the extra distance in the mockup to annotate the different states, how focus moves through the page and semantic markup. This will save time later as developers will not have to surface these questions when they come to build it.

When building an HTML prototype, you can use browser tools to help you check for simple accessibility issues. Some of the most popular ones are:

• axe
• Wave
• ARC Toolkit

An HTML prototype will also be able to be easily tested with screen-magnification users. A well-coded HTML prototype will also allow you to see how a design scales and even how assistive technology works with it.

However you want to be sure the prototype has been well tested before putting it in front of assistive technology users. This is because it is possible to have a lot of minor accessiblity issues prevent the user from providing true insights into more complex problems. Some testing and remediation in advance of the user testing could remove these obstacles and make the user testing less frustrating for the user and more valuable to the team. You need to know how this will be coded for production so the effort at this point is worth it.

Don't consider leaving testing with disabled users until the production version launches. At that point it becomes more difficult to argue for accessibility changes and it might be that the changes needed to make it accessible require wider rework than stakeholders will be comfortable with.

Build

The build stage is where the most intensive testing work will take place in terms of code and getting it production-ready. Team and user testing should continue throughout the build phase.

Even if using a component library of previously tested code the output should be tested. This is because support landscapes shift as browsers and assistive technology release new versions, but also the context and parameters for how those components are used are often unique to the current build. As mentioned, component libraries also depend on a community effort in feeding back improvements and both in-team testing and user-testing can greatly contribute to this.

During build there are several other testing mechanisms which can be added to help support writing accessible code.

• using linting on IDE to catch issues as you code
• adding accessibility checks into unit/component tests
• adding automated library checks (such as axe) to build pipelines
• adding specific scripted checks into end-to-end testing

See more on automated testing.

Maintenance

After launch testing should not stop. Sites rarely stay in their launch configuration as more features, improvements and bug-fixes are added.

Whenever the interface code is changed the accessibility testing should be re-run, both for the new code but also taking care to include any potential side-effects elsewhere in the site.

Even in periods of stagnation it is advisable to factor in regular accessibility sweeps due to the release timelines of browsers and assistive technology (especially screen-readers).

In-team testing responsibilities

As we have already explored, testing should not be the sole responsibility of one or two people in the team.

Let's examine the responsibilities for ensuring a new feature is accessible:

• discovery phase: user researcher, designer, content design
• prototype phase: designer, content design, developer
• build phase: designer, content design, developer, QA
• maintenance phase: QA, developer, user researcher

You can see design, content and developer are heavily involved. This is because good accessibility is often an ongoing conversation between team members due to the direct interaction you are having with the end-user. When one group makes all the decisions it can lead to an inferior product.

Even the project manager and business analyst need to be involved to ensure accessibility is treated as a priority and the team is given enough time to produce a quality and effective result.

See more about team processes and responsibilities

The aim of testing

The aim of testing is to not add issues to the backlog.

Whilst user testing will invariably result in tickets being generated, this should ideally be limited to insights from lived experience which the team could not be expected to add themselves.

Testing is there for 3 reasons:

1. help designers provide the development team with an accessible solution
2. assist the development team in creating accessible code
3. providing regression assurance

With user testing and interviews in advance of code being written, the aim is to have a design which is generally accessible before any of it is coded.

Complex components which have the potential for accessibility issues should be tested in isolation using HTML prototypes before being signed off for development.

Code should be robustly tested as it is developed, so that inaccessible code is not merged and certainly not released.

The combination of

• an accessible design solution which has been tested with users
• Test-Driven-Development (using tests which enforce accessible best practices)
• code linting
• developers running checks (including manual assistive technology tests) before committing code
• pull request reviews which look at accessibility

should result in fairly robust code and minimal need for rework.

By testing before merging code it reduces the number of resultant bugs which then need to be prioritised and fixed. By fixing issues before they are merged we avoid accessibility being de-prioritised on the backlog.

Finally pipeline testing provides assurance that we haven't missed any side effects.

How to test

Testing for accessibility can be broken down into three main areas:

• automated tests
• non-assistive technology tests
• assistive technology tests

Automated testing

Automated testing is done most often in the browser on either a local branch or on the live site, but can also be done as part of a build process.

Note that whilst automated testing is easy to do, it will only find 30-40% of accessibility issues out-of-the-box. Even custom test scripts written specifically to target accessibility cannot account for everything, so manual testing is still essential.

When done in the browser automated testing will use one of the many available browser plugins. This will provide you with a list of potential issues on the current page only and only in the state the page was in when the test was run. Different plugins will run different tests so it can be useful to run a couple of different ones from time-to-time, but find a plugin which you like to work with and use that.

The advantage of doing it locally does mean you have a clearer view on what is happening on the page, but also that you can test code before committing it.

When done as part of a build process it will normally be using an API from one of the browser plugins. The advantage of this is that it can piggyback on your end-to-end journey tests and check each page in turn, providing a report at the end.

See more about automated testing

Non-assistive technology testing

We can do a lot of accessibility testing even without learning how to use a screen-reader or other assistive technology.

You can check for a lot of accessibility problems by just using your standard keyboard. If you also learn how to use your browser developer tools and a couple of (non-automated) browser plugins, you can then cover a lot more potential issues too.

See more about keyboard testing.

Assistive technology testing

This is the part where a lot of people stop because they think using a screen-reader is really difficult and it costs money to buy any assistive technology.

But screen-readers are genuinely simple to use as you only need a few commands to get started. Speech-recognition is even easier and again only a handul of verbal commands will get you by.

The only tricky part might be understanding why there is an issue when you come across one and how to fix it.

Each OS also has a screen-reader and speech-recognition which ships with it or is installable for free, so chances are you already have the tools to get started.

Learn how to use screen-readers.

What a test strategy should include

A robust testing strategy should include the following:

• automated testing
• keyboard testing on mobile and desktop
• visual checks - including reflow, zoom, font-size, high contrast, reduced motion
• screen-readers
• speech-recognition
• content

You could expand this to include:

• text-to-speech (which reads the visible text only)
• user style overrides (how easy or difficult it is for a user to customise the look of your product to their needs)
• performance (how the product works with lower-powered devices on slower networks as disabled users are less likely to have disposable income for top-of-the-line or dedicated internet devices)

Accessibility audits

Accessibility testing should be done all through development of a site and when doing that you should follow the steps outlined above.

But it might be that you will need to perform a wider accessibility review. This could be because you have inherited a project and want to gauge how accessible it is before you start working with it, or you might be doing a full review of a site you have just built as an assurance step. This kind of in-depth review is often referred to as an accessibility audit. These are often carried out by specialists but there is no reason for a development team to not do this themselves.

Deciding what to review

How an audit is run depends on the type of site:

• a large freely-explorable website might benefit from a sampling technique, perhaps concentrating on large-traffic areas
• if components can be identified, these can be targeted along with some more general full-page sample testing
• a transactional site or one which has well-defined user journeys can have the journeys mapped out and each step tested as full pages

It is important that whatever technique is used is recorded so it can be repeated. This is essential both for the development team to be able to replicate the issue and for the tester to be able to verify any fixes (which may be some time after the original report).

Whilst the product itself may be the focus of the review, it is worthwhile looking at the wider landscape too. Ask the following questions:

• how do users find the product - if social media is used are the posts accessible?
• what are their entry points - are people signposted from other parts of the company digital estate?
• how do they get in touch if they have a question or need help - are there options for all users?
• does the product generate artifacts such as emails or letters - are these accessible?

Testing for compliance vs testing for user impact

It can be tempting to take a list of the WCAG criteria and review each page or component for failures against each item. However WCAG has well-known areas where it does not meet the needs of all users, especially in areas such as cognitive function. By only reviewing a site against WCAG issues, many impactful problems may be left unreported. Remember WCAG guidelines are just a way to ensure you have done the bare minimum to make a site accessible - we should be going beyond this.

Whilst a WCAG checklist can be a useful tool, it should not be the only method of assessment used as it can be easy to miss issues.

Here are some sample checklists - note that none of these have been updated to the current version of WCAG.

• Accessibility checklist - MagentaA11y
• Checklist - The A11Y Project

How to report an issue

First, make sure that you have actually found an issue. Especially if it concerns assistive technology (like a screen-reader), make sure you haven't made an error in testing (like using the wrong key combo or being in a different navigation mode).

Then check to see if there is a bug which is causing the issue. It might be that making a reduced example of the component causing an issue might help work out if it is an issue with the browser or assistive technology rather than the component. If it turns out to be a bug with the browser or assistive technology, look to add to or create a bug report on the relevant issue tracker so it can be fixed.

It is important as much information as possible about the issue is recorded in order for someone with no context of the location or issue to be able to understand and replicate the finding.

If you have determined it is a problem with the component then you will need to raise an issue for the team to look at it. This is my accessibility audit issue reporting template which helps produce a detailed issue.

Severity vs priority

Severity and priority might not always coincide. The severity of an issue is how much of a barrier it causes for the user.

However how this is then prioritised depends on what this barrier is preventing - for example is it a core journey step or a minor feature?

It can also be very tempting to find an issue and then try and make one of the WCAG Success Criteria fit in some convoluted way to ensure it gets fixed. This is often a result of the stakeholders refusal to fix anything not identified as a WCAG failure. Don’t do this.

You should always be able to defend your assignment of an issue against a WCAG criterion, citing the guidance when asked to. Always assume the person you are reporting issues to has a good grasp of the WCAG guidelines and will call you out on any misrepresentation. To do otherwise risks all of your issue reporting being brought into question.

If you find an issue which is a borderline WCAG issue, but you can’t make it stick, then report it as a high-priority ‘other’ issue and flag your concerns in the issue itself. A good prioritisation process will ensure issues are reviewed in accordance with user impact.

Reocurrence is also a factor in prioritising. A lower severity issue which is happening on every single page can form more of a barrier than a single more severe issue which only happens in one place. This is because a repeated barrier can be exhausting to have to by-pass on every page and the resulting compound effect can be higher than the single issue.

Read more about prioritising accessibility.

Wrap up

Testing for accessibility is a complex thing. It covers a lot of things which cannot be automated which itself can be present a barrier to implementing a robust testing strategy. But with a series of testing processes in place, across all team roles issues can be addressed long before they become problems for users.

• Introduction
• Why test for keyboards?
• Can we automate keyboard testing?
• Set-up for testing on Macs
• What are we testing?
• A quick look at navigating by keyboard
• Tools
• Skip links
• Can I see where my focus is?
• Functionality
• Logical tab order
• Preventing doubling up
• Managing focus when content updates
• Did we WCAG?
• Wrap-up

Introduction

There are many types of users for whom the keyboard is the only way they can access their computer. It also forms the basis for how other users, such as screen-reader and speech-recognition users interact.

Keyboard accessibility is both fundamental to wider accessibility and one of the easiest things to test when it comes to accessibility. Because most developers will primarily use a mouse when interacting with the end product they are coding it can be all too easy to make some simple errors which have a major impact on our end users.

By being aware of how excluding keyboard users can happen we can improve our code and testing practices.

Whilst this is a simple check to do, it actually covers several WCAG criteria because is such a core accessibility concern.

Why test for keyboards?

7% of working-age adults have a severe dexterity difficulty or impairment (​Microsoft / Forrester report​). In the UK of those who reported an impairment around 25% had a condition which impacted their dexterity. This can result in users prefering keyboard interaction over mouse or touch as it may be less prone to error, more easy physically or less painful.

Some users will be physically unable to use a mouse and so will need to use a keyboard to navigate your product.

Alongside dexterity or mobility impairments, the majority of screen-reader users will also use a keyboard. So by testing for keyboard accessibility we are already making headway into more complex accessibility testing requirements.

Can we automate keyboard testing?

Out-of-the-box automated testing (such as Wave or axe) will only tell you if something is:​

• focusable and should not be​
• focusable and is missing an accessible name​

Some automated tools also provide options to visualise focus order (more on that shortly).

But we need to test much more than that.​

Automated tests are effectively linters. ​They catch the simpler issues (although they can be super-useful).​

You would not ship code with the only testing being a linter. In fact with most of the examples we'll be looking at, automated browser plugins did not pick up the issues we will be fixing.

But all is not lost! We can add some checks to our custom scripted tests to help enforce better accessibility at build time. Read more about improving tests for accessibility.

Set-up for testing on Macs

If you are a Mac user, tabbing to navigate links and form controls in a webpage may be turned off by default. This affects Firefox and Safari. You should check your settings if you are on Mac and using either of these browsers.

How to enable tab navigation on Mac

Firefox

To fix Firefox you need to go make a change in the Mac system settings.

Before OS 13 it is in System Preferences > Keyboard > Shortcuts and check “Use keyboard navigation to move focus between controls”.

For OS 13 on it is in System Preferences > Keyboard and toggle on “Keyboard navigation”.

Safari

For Safari you need to make a change to Safari's own settings. In Safari > Settings > Advanced, check the option “press Tab to highlight each item on a web page”.

What are we testing?

There are a number of things we are going to be looking for during our testing:

• skip links - adding these allow keyboard users to jump past the repeated blocks which are present on every page, such as navigation
• visible focus - while we are navigating can we tell exactly where our focus is at any moment - that is to say if we hit the enter key do we know what would happen?
• access and operation - can we get to and then trigger the various controls on the page? Are there things we can reach which we should not be able to?
• focus management - when something is added or removed as a result of user action, are we handling the focus in an appropriate manner so they can continue without interruption?
• focus order - is the order in which focus happens logical based on the position of the elements or are we jumping all over the screen?

Check different states

Also remember we need to test any different view states. These can be:

• menus which appear when a button is clicked
• dialogs or notifications
• different types of content loaded into the same component

Check mobile viewports

We also need to check the mobile viewport of any page. Sometimes developers assume that a mobile user will be using a pointer (such as a finger or stylus), but external keyboards are a popular addition to mobiles or tablets.

A desktop browser can also trigger the mobile viewport when zoomed. It is important to also check that any interactions, especially menu and navigation related, are still operable with a keyboard.

Whilst looking at mobile viewports, also check how the page operates in landscape mode. This is often when you may find that a sticky header will overlay content preventing a user from seeing where their focus is.

Testing on mobile devices

Whether testing a native app or a website with a keyboard on iOS you will need to turn on “full keyboard access” under Accessibility in Settings. This will allow you to tab through as you might on a laptop.

On iOS you also have the option of using “keyboard gestures” by using the Tab + G command. This then allows you to make swipe gestures. However bear in mind that not all users will be aware of this and Android phone users (nor laptop users) do not have this option. It is always best to provide keyboard users with buttons to accomplish what other users may do with gestures.

A quick look at navigating by keyboard

When we are using our keyboard, we only want to navigate to things which are interactive. The main way of doing this is by using the tab key. This will place a focus indicator on the element to show us where our focus is and this indicator will move as you navigate between interactive elements. You can use enter or space to activate buttons and enter to activate links once your focus is on them.

A mistake that some people make when it comes to testing for keyboard use is that they assume that the tab key is all that is used. Some components might require arrow keys to be used to move around elements within them.

Radio button groups for example show focus on tab (either on the first or last depending on your direction of navigation) and then you can use space to select that radio or use arrow keys to move up and down the list. This behaviour means that long lists of options can be easily skipped over once we have made our choice.

Some library components such as a tab component may have what is called a roving focus (or roving tabindex) which operates in a similar way to radio buttons - you focus onto the first tab element and then use arrow keys to move from tab element to tab element.

This allows the user to avoid having to navigate through all the tabs of the component to get past it. However this also relies on the user being aware of this pattern so this should be used sparingly, else the user may be confused as to why they cannot tab to an element.

Remember that a user will not need to focus on content to scroll the page - this can be done with other keys (space bar, arrow keys or page up/down keys).

Tools

Testing for keyboards can raise some difficulties for us just as it might for a user.

Enhancing focus indicators

Sometimes the page we are checking may have poor focus indicators which make it difficult to work out where our focus is.

One way around this is to enhance the focus indicators with some css. Usually something like this should be enough:

*:focus {
    outline: 2px solid hotpink!important;
}

This will add a pink outline to each focusable element as you move to it.

I added this functionality into the Pattern Checker browser plugin to make it easy to check:

Viewing the focus order

Sometimes it can be valuable to be able to see each focusable item on the page or to plot where focus is moving. This is especially true when trying to report an issue. Fortunately there are some browser tools which can help us here.

I'm going to look at 3 tools which show the order in which focus is applied to elements on the page.

All these tools plot focus by adding a numbered tag next to the element to represent the order in which they will be accessed by the user. Some also draw lines to assist you in seeing where the next numbered tag is located.

However what they see as a focusable element is slightly different.

Firefox's built in "Show tabbing order" in the accessibility panel shows tab stops. These are just the items which are reached by the tab key.

IBM's Accessibility Assessment plugin shows all focusable items. This includes tab stops, but also items which can take focus in other ways.

Microsoft's Accessibility Insights works slightly differently. It doesn't show all the focusable items in one go. Instead it plots the items as you move through the page. Depending on how you navigate will determine how it plots.

The video below shows each of these in action.

It is strongly advisable that these tools are only used to support manual testing and not as a replacement. Also remember that these tools, just like other automated browser plugins only work on the current state of the page.

Skip links

These are primarily for keyboard users so are a good place to start.

The benefit of a skip link

A lot of sites will employ these but you may not have seen them as they are generally hidden until they recieve focus to avoid making the top of the page cluttered.

A skip link should be the first focusable element on a page, even before the navigation or logo. This is because their function is to allow a keyboard user to jump over the repeated header elements (which tend to be link-heavy with navigation) and allow them to more easily get to the unique content on each page.

If we didn't provide a skip link like this on each page a keyboard user would have to tab perhaps a dozen or more times when they land on each page in order to access the main content links. Remember that keyboard users may have difficulty in activating a key, so asking them to repeatedly do so when we can remove this need is not acceptable.

How skip links should work

The skip link is an in-page link and will typically take the user to the main element (usually done by temporaily assigning a tabindex="-1" to allow it to be programmatically focused). The next use of the tab key will take the user to the first focusable item within or after the main element. Some sites may take the user directly to the first focusable item which is acceptable also.

Potential mishaps

Despite being a simple interaction there is scope for issues with skip links, partly because their default state is to be hidden visually so they can be forgotten about when testing.

Skip link text

Because skip links are hidden it is easy for issues with their content to be missed. Check the content makes sense and if offering translations of a page that the skip link translates correctly.

Skip link appearance

We should check that the skip link is actually shown when it gets focus and sits above other content.

Skip link functionality

Our final check is to make sure that when clicked, the link actually takes the user down the page and focus is moved there.

It might be that the target of the link is missing or has been mis-spelled.

Can I see where my focus is?

Keyboard use relies heavily on being able to see where the focus currently is. If this is taken away by css or obscured (or just not added) it can make it very difficult to work out where you are on the page. Making focus states really obvious helps especially when focus can jump across large sections of the page.

As a quick test, go to the page in question and close your eyes. Hit the tab key several times. Can you see immediately where the focus is? If not then the focus indicators need some work.

Providing good focus indicators

Not having a focus indicator is like not having a mouse pointer for a mouse-user. It makes it a lottery as to what you will trigger when you click. Good focus indicators make interfaces immesurably more pleasant and less tiring to use.​

A good focus indicator makes it immediately clear that the item has focus. Remember that some keyboard users may also have poor eyesight.

Here is a video of a user navigating a site which has poor focus indicators - the user is pressing the tab key throughout the video. The focus is very difficult to see as it only appears on a few links and not at all on the primary navigation. (Note there are other issues apparant in the video which we will come to shortly.)

Now let's look at that again, but this time we add some good focus indicators (done using the Pattern Checker plugin). The focus is now immediately visible as the user tabs through the links.

If you can't see where the focus went on a page then you need to check if this is just down to a poor focus state or because the focus has gone to content which has been hidden from view. Disappearing focus indicators is something you will often find when content has been hidden off-screen until triggered (like a menu) - we will look at this in a moment.

Potential mishaps

Visual appearance

The most obvious issue with focus indicators is their lack of visibility. As we have already mentioned a good focus indicator is very clearly different from the non-focused state.

Focus indicator clarity can be provided in several ways - via the addition of a border or a background color change for example. However it is applied there should be a good colour contrast between the two states so users with vision impairments can easily percieve the difference.

Finally check your design in Windows High Contrast (WHC) to ensure that focus is still visible where expected. Note that WHC exposes native HTML buttons and links differently to ARIA-based ones, including focus states. So it is generally wise to use native HTML where possible.

Focus obscured

Focus indicators should not be hidden from the user by other content sitting over it. If other content is obscuring the focus indicator then the user will not be able to see either see that content or where their focus is. There are a few instances where this can happen.

Focus obscured by non-modal overlays

A non-modal overlay is one where the rest of the page can still be accessed without having to dismiss the overlay first.

A common use of these is in site menus. However drop-down or fly-out menus can become a hinderance to users when they allow the user to tab through them and onto content which sits behind them without the menu being removed.

Where a menu allows the user to interact with the rest of the page when it is open, the menu should either:

• be closable via the Esc key when focus is outside the menu so the user can dismiss it without having to backtrack to the close trigger​
• be auto-closing once focus exits the overlay​ - for example by moving to an adjacent link outside the menu

Without these considerations a user will be forced to try to go back to what triggered the menu in an attempt to dismiss it.

Focus obscured by modal overlays

Modal overlays are different from non-modal ones in that they need to be closed before the user can interact with the page which launched it. This might be through choosing from a set of options or by using a close button.

These type of overlays communicate this by either taking over the entire viewport (in a lightbox type pattern) or by adding a semi-transparent backdrop between the modal and the page, effectively focusing the user attention on the modal.

Just as with non-modal overlays the issue with modal overlays can be poor coding which allows the user to access content sitting behind them and then be unable to see where their focus is.

With a modal dialog the expected behaviour is that focus is restricted to the dialog in the same way as a mouse user cannot access the content behind it. For a keyboard user this would prevent a user from tabbing out of the modal and onto the rest of the page.

Focus disappearing

As well as focus disappearing due to other elements appearing in front of them, a common occurence is for focus to drop out of view entirely. This is most often the result of focusable elements which have been visually hidden still being reachable by keyboard.

A keyboard user will only ever want to access controls which they can see. A simple rule-of-thumb is if the user cannot see it when it has focus, then it should not have received focus.

Let's look at an example. This is part of a main navigation for a site. There is a drop-down for a language selector.

However for keyboard users, instead of being able to tab from the current selection to the next link in the navigation, their focus indicator disappears for half-a-dozen hits of the tab key before re-emerging on the register link.

This is because the method of hiding the collapsed menu options was incorrectly applied making the options available all the time.

This type of issue is especially harmful because putting content into collapsable components (or hiding off-screen behind a hamburger menu) is often used to hide large sets of options. The worst example I found of this was a filter component which was visually hidden but available to keyboard and screen-reader users and contained over 80 tab stops!

When hiding content from view, whether that is for a mobile-style menu, a set of filters or a drop-down like this, always check that the content inside cannot be tabbed to by keyboard users (or seen by screen-readers).

Scott O'Hara and CSS Tricks both have articles on how to hide content in an accessible way.

Focus wrap-up

If the user cannot see where they are on the page then it becomes very difficult to interact with the content and mistakes will be very likely, leading to further issues.

• check focused items can be easily differentiated from unfocused ones
• check the focused item is not obscured by other content, especially components like menus and dialogs

Functionality

There are two main questions we need to ask when looking at keyboard functionality.

• can the user reach the control with the keyboard?
• can the control be activated with the keyboard?

Check to see the user can reach any element on the page which they should be able to interact with. Pay particular attention to more complex components and navigation sections. Any component which utlises javascript is especially prone to omitting keyboard functionality.

Using the correct element

The easiest way to ensure a keyboard user can move focus to a control is to use the correct element. This most often means using input, button and a elements.

Whilst in theory a span or div can be made to act like one of the above, it requires a lot of consideration and additional technical complexity. This is often missed and only mouse users are accounted for, or only partially implemented and a poor experience is the result.

Example

The navigation on the Thomas Cook website does not allow keyboard users to access the “My Account” item, as shown by the IBM Equal Access tool below - there is not a focus-order marker for it.

Let's take a look at the code for the “My Account” option.

/*My Account*/
<tc-my-account-navigation-open class="⭐️umd9c1-1">
    <div class="tc-menu-toggle-icon"></div>
    <div class="tc-menu-toggle-name">My Account</div>
</tc-my-account-navigation-open>

Now let's compare it to the ”Wishlist” one which sits alongside. This one does take focus.

/*Wishlist*/
<tc-my-account-wishlist-icon class="⭐️umd9c1-1">
    <a href="/my-account/wishlist" class="wishlist-heart">
        <img src="heart-love-outline.svg" alt="Wishlist">
    </a>
</tc-my-account-wishlist-icon>

We can see the “My Account” one is made up only of generic elements (divs), whilst the wishlist is a link (a):

Generic elements (such as span and div) do not take focus, meaning our keyboard user cannot access them. Moreover, whilst a screen-reader user will be able to read the content, they will not know that it is clickable. This is because the elements which have that generic role will be announced purely as text.

The fix

We can fix these issues with a two step approach.

The first is to use the correct element for the job at hand. For this example I will use an a which will allow for a fallback in case javascript is not available and take the user to the account page. We can then progressively enhance this link to open the account menu when javascript is available.

Important to note that an a element without an href is not a link and cannot be focused. So if this was not going to be progressively enhanced I'd opt for a button instead.

I have also added two ARIA attributes on the link to tell screen-reader users that this link will trigger a same-page menu. As we wouldn't want these on a link which will cause a page load we should only add these as part of the javascript-applied progressive enhancement which also adds the event handlers.

This is the code as it would be rendered:

<tc-my-account-navigation-open class="⭐️umd9c1-1">
    <a href="/my-account/" aria-haspopup="true" aria-expanded="false">
        <div class="tc-menu-toggle-icon"></div>
        <div class="tc-menu-toggle-name">My Account</div>
    </a>
</tc-my-account-navigation-open>

With our change in place the navigation now allows keyboard users to access it:

Our next step would be to ensure that the keyboard user can then trigger the item to open the menu:

and make sure that our new aria-expanded attribute is updated to true when the menu is open.

This issue is more widespread than you might think. Here is another example, this time the Premier Inn main navigation is entirely unavailable to keyboard users.

If we take a look at one of those navigation links which does not work for keyboard users we can see a similar story.

<div class="css-1wgzkpb">
    <div id="popover-trigger-:r1:" 
        aria-haspopup="dialog" 
        aria-expanded="false" 
        aria-controls="popover-content-:r1:" 
        class="css-jls80j">
            <p class="chakra-text css-1tk9twk">
                Discover Premier Inn
            </p>
    </div>
</div>

As with the previous example we can see the elements are not focusable. Unfortunately whilst they have added aria attributes, they have omitted the most basic functionality. As these aria attributes are not permitted on generic elements these will not be communicated to a screen-reader.

Again, this is a simple fix and can be done by updating the code to use the correct element.

<div class="css-1wgzkpb">
    <button id="popover-trigger-:r1:" 
        aria-haspopup="dialog" 
        aria-expanded="false" 
        aria-controls="popover-content-:r1:" 
        class="css-jls80j">
            <p class="chakra-text css-1tk9twk">
                Discover Premier Inn
            </p>
    </button>
</div>

Tabindex

You may have come across the tabindex attribute. The order in which a user tabs through a page's HTML elements (links, buttons and form controls for example) is called the ”natural tab order”.

Very occasionally you may need to add an element to that tab order which would not normally be there. In this case you can use a zero value in the tabindex attribute to do this.

For example here we have two buttons with a div element between them. A user would tab from the first button to the second:

<button>One</button>
<div>I'm plain text</div>
<button>Two</button>

But if we add a tabindex to the div element:

<button>One</button>
<div tabindex="0">I'm plain text</div>
<button>Two</button>

The div will now be included in the natural tab order. The user will now tab from the first button, then to the div, then the second button. As it stands this is not useful or accessible but it demonstrates the principal.

This is something you should only very rarely need to do. Whilst the div can now take focus it is neither announcing as a button or link to screen-readers and will not respond to keyboard clicks. You can start to see why it is always a good idea to use the correct element for the job.

But there are occasions where it can be helpful where no existing HTML element is appropriate. For example, creating a scrollable container (such as a div) will necessitate the container to be focusable to allow keyboard users to scroll the contents. Focusable controls should also have an accessible name for assistive technology and as an aria-label can only be applied to certain roles the div will need to be promoted to something like a role="region". As you can see this process has several ways of being incorrectly applied and causing more barriers.

Tabindex can also take two other types of values. A negative (-1) will allow the element to be programmatically focussed (using javascript) without being added to the natural tab order. This can be occasionally useful, but again rare.

The other value is a positive integer. These should be used even more rarely than our first example as they entirely usurp the natural tab order. This can cause a lot of confusion for users as well as being problematic to maintain in a codebase.

Tabindex: it rarely pays to be positive

How styling can impact functionality

Even when we think we have covered all the bases and have progressively enhanced our interface, it is important to test!

Below we have a product view with various links and buttons. Here I have used the ARC Toolkit's tab order highlight option which works in the same way to the other tools we have used so far.

The sizing options are not showing as focusable items (confirmed by actual keyboard usage). Let's take a look at the HTML for them:

<label title="XS" for="XS" class="option_field">
    <input value="XS" type="radio" id="XS" name="SingleOption" class="list_option">
    XS
    <span class="checkmark"></span>
</label>

Everything looks ok here as an input has been used which should be focusable. The issue actually lies in the CSS used to hide the radio button:

.option_field input {
    display: none;
}

The use of display: none is the issue. This will remove the input from the rendered page. This then means there is effectively no input on the page to get focus.

This also has a knock-on effect for screen-reader users. No input in the page here means the label associated with it then becomes plain text. Screen-reader users will not be informed the sizes are selectable or be able to select one (just like the keyboard users).

To a screen-reader user the “XS” option will simply be announced as “XS”. The sold out size “XL” will also be read out just as “XL” - as the strikethough is not picked up by screen-readers and the disabled attribute on the input is unavailable as the input is not rendered.

That's a lot of inaccessible effects from some CSS!

The accessibility fix is simply amending the CSS to keep the input in the render but still hide it from sight:

.option_field input {
    position: absolute;
    opacity: 0;
}

Keyboard access is restored without affecting the visual appearance of the component:

Now screen-reader information also improves.

The “XS” option is now announced as:

XS, tickbox, unticked, 1 of 5

and the “XL” option is announced as:

XL, dimmed, tickbox, unticked, 5 of 5

A screen-reader user now can tell which sizes are sold out, how many sizes there are and which one they have selected.

We would then need to ensure that focus indicators are being applied and actioning the inputs with keyboard has the desired effect.

Reachable but not operable

It is also possible to have a control be reachable via keyboard, but then not be able to action it.

This is normally due to an issue with keyboard events not being handled. When a click handler is added to a link or button element this will include event handlers for keyboard too. However when a click handler is added to a div or span (or other non-native control element) we need to add specific event handlers for keyboard ourselves.

The Asda main navigation has a “More” link which for mouse users opens a drop-down with additional links.

For keyboard users, whilst they can seemingly reach this, no amount of key pressing will open this menu.

Let's examine how this control is coded:

<a class="sub-nav" id="nav-toggle">
    <span class="submenu-hamburger-label">More</span>
    <span role="button" 
        tabindex="0" 
        aria-label="More, list 11 items">
        <svg>...</svg>
    </span>
</a>

We have an a element without an href. Inside this is a span with role="button" and tabindex="0" attributes.

So what is happening? Well, as the a element is missing an href it is not classified as a link and nor will it capture focus. This means the keyboard focus skips past that and lands on the internal span thanks to its tabindex attribute having added it to the natural tab order.

The issue for the keyboard users is that the javascript event handlers on the span are only accounting for a click event. As we have already mentioned, on a span (even with a role="button") this will not include keyboard events.

The fix for this is to change the focus point from the span to the a element. Alternatively additional keyboard event listeners could be added, but we should always be using the correct element where possible. We also really want to remove the confusion of the nested controls and the repetition of text which that brings.

Let's remove the following attributes from the span:

• role - as we no longer want this to pretend to be a button
• tabindex - as we no longer want this to get focus (we will be using the link)
• aria-label - as it was mis-representing this as a list when it had its role set as a button, and we no longer need this with our changes

We should also add some ARIA (aria-expanded and aria-haspopup) to help screen-reader users determine how this operates (which will need to be updated when the menu opens).

This results in the following:

<a class="sub-nav" id="nav-toggle" 
    href="#"
    aria-expanded="false" 
    aria-haspopup="true">
    <span class="submenu-hamburger-label">More</span>
    <span>
        <svg>...</svg>
    </span>
</a>

We could probably tidy this up some more and ideally I'd want to use a button as it is not really a link, but this is a definite improvement.

Now the focus goes to the link (and is much larger and more visible as a result) and a keyboard user can action it. Additionally a screen-reader user gets the information they should.

Read more about ARIA and accessible names.

Worth noting that although this is a change to markup and that it greatly improves not only keyboard and screen-reader accessibility, there does not need to be any change in how the component looks to the user.

Functionality wrap-up

• use native HTML controls (inputs, links, buttons) as a first choice when you expect a user to click on something
• make sure a elements have an href even if you are using javascript to handle clicks
• if you need to use javascript make sure you cater for keyboard as well as mouse activation
• you don't get keyboard event handlers for free with generic roles (div and span)
• do not hide inputs if you expect the user to interact with them

Improving our tests to check for good keyboard accessibility

Logical tab order

Typically for a left-to-right language such as English, we expect focus order to follow the natural reading order, that is for it to move from left to right as it progresses down the page. If we deviate from this reading order expectation with our focus order it can be disorientating for the user and they have a larger chance of losing sight of the focus indicator.

Tabindex

As we have already touched on, it is possible to manipulate the focus order using the tabindex attribute with a positive number value.

Here is an example of where this can go wrong. On the Tesla Powerwall site, content halfway down the page has been given a positive tabindex.

<button 
    role="tab" 
    aria-selected="true" 
    aria-controls="energy-carousel-panel-0" 
    tabindex="1">
        <span role="heading">
            Store Extra Energy
        </span>
        <p class="tcl-carousel-v2__toggle-panel-copy">
            When your solar system ...
        </p>
</button>

This makes this content the first item which will be focused on the page, even before the logo or primary navigation. But this also means that this section will then be “skipped” as the user moves down the page, making for a confusing experience.

This is likely a mistake rather than a concious decision. The component in question is a tablist which normally has a “roving tabindex”. Rather than using tabindex="1", this should have been using tabindex="0" for the active tab and tabindex="-1" for the inactive tabs. However it shows the pitfalls accompanying the use of tabindex.

Source order vs visual order

There is another way in which we can inadvertently jumble up the focus order for the keyboard user, and that is by manipulating the visual order of our content.

Keyboard focus always follows the order of focusable items as they appear in the source code. When we apply CSS to that code it can visually alter the placement of content (and those focusable items), but this does not change the order in which they receive focus.

Let's look at a very much simplified example.

As you can see the focus follows the source order, not the visual order. This also affects screen-reader users in the same way, but not just for focuable items as screen-reader software reads all content.

Keyboard traps

These are relatively rare, but when found can be a complete blocker for a user. They occur when a user reaches an element or component and they cannot exit it using keyboard commands. They are often the result of javascript event handlers not accounting for people using keypresses to navigate.

For example, the National Express homepage has a journey planner at the top of the page. Below it there is also a lot of additional content, including timetables, booking management tools and more.

The user focus gets caught by the first input of the journey planner. The user cannot exit the input without entering data due to javascript event listeners which move the focus straight back to the input if no entry has been made. They cannot even use one of the options in the drop-down as they are not reachable via keyboard.

Similarly, even if they enter a valid stop they are immediately moved to the "Travel to" field which then prevents the user from moving back to the previous field to make any correction.

This is compounded by the result page where the “Edit journey” option is not reachable by keyboard.

This type of failure is simple to avoid if those designing and building them account for the different ways a user may interact with it.

Preventing doubling up

Something which will frustrate a keyboard user is where multiple elments are used to link to the same resource.

Let's take a look at this site navigation.

Note the “Help” and “Find a store” links which have the icons alongside? For a keyboard user there are two tab stops for each of those:

This is not ideal as we are asking the user to do twice the work they should. So why is this happening? If we take a look at the code we can see:

<a href="http://storelocator.asda.com">
    <span role="button" tabindex="0" aria-label="">
        <svg class="asda-icon">...</svg>
    </span>
    Find a store
</a>

Here we have the link, but inside is a span which has been made into a button using ARIA (unfortunately the latter is also missing an accessible name). There is no need for this secondary control, so we can simplify this to the following without loss of functionality:

<a href="http://storelocator.asda.com">
    <span>
        <svg class="asda-icon">...</svg>
    </span>
    Find a store
</a>

Which when applied to both links give us a much cleaner tab order:

Another place where doubling up is often seen is in card components. Here is a typical example with the links highlighted:

and the (simplified) HTML:

<a href="...">
    <img src="1827b921f1.jpg" alt="Carbonite Snow Jacket ">
    <h2 class="product-link__title">
        <a href="...">
            Carbonite Snow Jacket 
        </a>
    </h2>
    ...
    <div class="product-price-wrapper">
        €268.99
    </div>
    <button>Quick View</button>
    <a href="#">
        <span class="visually-hidden">Add to Wishlist</span>
    </a>
</a>

We can see the card has been entirely contained by a link to make the whole card clickable. The issue this creates is adding a repetition of links as this is the same link target as the one which wraps the heading. The other issue with a wrapping link like this is also that its accessible name becomes the link's contents - in this case the entire card contents - and is announced to a screen-reader as:

"Carbonite Snow Jacket Carbonite Snow Jacket Carbonite Snow Jacket 1 / 5 2 / 5 3 / 5 4 / 5 5 / 5 €169.99 QUICK VIEW Add to Wishlist"

As the link wrapping the entire card is only meant for mouse users, we can devolve that to a javascript event on the card wrapper instead, triggering the link on the heading. This allows us to then remove that link element. Something like this:

let cardWrapper = document.querySelector(".card-wrapper");
let cardLink = cardWrapper.querySelector("h2 > a");
cardWrapper.addEventListener('click', function(){
    cardLink.click();
});

The functionality of having the entire card clickable will remain for mouse users, but keyboard and screen-reader users will benefit.

Removing this duplication has the potential to remove a lot of unnecessary keypresses for users as these cards are used to display products in grids.

Managing focus when content updates

When content is removed from the page and the user has their focus on one of the elements which is removed it is important that the user's focus is placed elsewhere thoughtfully. If not then it is likely that their focus will drop back to the top of the page. This will be both disorientating but also mean they will need to make their way down to where they were all over again.

This is especially important when we look at things like:

• closing dialogs
• deleting items from a list
• adding new content to a section which causes the section to be re-rendered

Here is an example of how a dialog can be dismissed leaving the user back at the top of the page:

Because the dialog the user's focus was on has been removed from the page (either through CSS or by removing the element itself) the focus drops back to the top of the page. What should happen is the javascript should place the focus back onto the trigger for the dialog, in this case the passenger input. This helps the user orientate themselves and allows them to either edit the data they just entered or proceed to the next control.

Whilst browsers are beginning to assist with focus management, it is essential for us to be mindful of any effects on a user's focus when a page is updated.

Did we WCAG?

Despite this being a very simple accessibility test on the surface, you can see the complexities it can throw up, as well as pointers to how assistive technology such as screen-readers can be impacted.

If we take a look at the WCAG guidelines we can point to a lot of criteria which the issues we have described above could be failed against:

• 1.3.1 Info and relationships
• 1.3.2 Meaningful sequence
• 2.1.1 Keyboard
• 2.1.2 No keyboard trap
• 2.4.1 Bypass blocks
• 2.4.3 Focus order
• 2.4.7 Focus visible
• 2.4.11 Focus not obscured (minimum)

Wrap-up

As we have seen with our examples keyboard accessibility is something which is frequently overlooked, despite these examples being from sites which you might expect have thorough testing procedures.

Keyboard accessibility is something which is simple to test and requires no specialist software. It is a fundamental part of making a website usable by many groups of users, and even acts as a pointer towards deeper accessibility issues which can affect assistive technology users.

With no need for specialist software and simple testing techniques keyboard accessibility should be embedded into every team's accessibility processes.

• Contents
• Introduction
• Standards
  • WCAG
  • EN 301 549
  • Other standards
• All-encompassing UK legislation
  • Equality Act (2010)
  • Public Sector Equality Duty
• Public Sector legislation
  • UK: Public Sector Bodies Accessibility Regulations
  • Europe: EU Directive 2016/2102
  • USA: Section 508
• Private Sector legislation
  • Europe: The European Accessibility Act
    • Service areas covered
    • Products covered
    • Conformity
    • Current state of European accessibility
    • Further reading
• Examples of legal enforcement
  • Student Loans Company
  • Department for Work and Pensions (DWP)
• Standards and legislation are the baseline, not the target
• Wrap-up

Introduction

Accessibility is a large and complex subject, even when narrowed down to one area such as the web. To help those building websites or producing web content make their products as accessible as possible there are a set of standards produced by a central web body.

These standards are then used by law-makers around the world to enforce accessibility best practice.

(Of course we are talking about legal things here so I'm going to issue the standard “I am not a lawyer” statement. Do your own research.)

Standards

When we talk about accessibility laws, the actual legislation often does not provide details of what you need to do to comply. Instead they reference relevant standards. This allows the legislation to remain current by indicating that the most current version of that standard should be followed.

The two main standards are WCAG and EN 301 549.

WCAG

WCAG stands for Web Content Accessibility Guidelines. They are a set of criteria which encapsulate ways of validating web-based media to check it for accessibility best practice. The current version of WCAG is 2.2 which was released in October 2023, the previous version was released in June 2018.

They are published by the W3C (World Wide Web Consortium) who are the international body which produces standards and guidelines for the web. They produce standards for many web technologies, from HTML and CSS to Web Augmented Reality and WebDriver.

The criteria are split into 4 main sections:

• Perceivable - can the user observe the interface they need to interact with?
• Operable - can the interface be used?
• Understandable - can the user understand what they need to do and how to do it?
• Robust - can the interface be interpreted by assistive technologies?

The WCAG guidelines are further split into 3 conformance levels:

• A (25 criteria)
• AA (13 criteria)
• AAA (23 criteria)

If your product undergoes an accessibility audit (a review to determine if there are any accessibility issues), it will normally concentrate on the first two of these as they are what are referred to in the regulations.

You should always tackle Level A issues that have been found first as generally these are more obstructive than Level AA.

Level AAA issues tighten up a lot of the other criteria to be more strict but can be difficult to meet without compromising other aspects of usability and accessibility. However this doesn’t mean these criteria should be ignored.

Each criterion might have normative and non-normative sections:

• Normative sections are used to measure compliance.
• Non-normative sections are examples or used for education purposes and are not used for compliance.

WCAG is also an ISO Standard (ISO/IEC 40500:2012 ), however because ISO standards are only reviewed every 5 years it is still only tracking WCAG 2.0 in its ISO form. However having ISO status does mean it can be applied in more countries and situations that it might otherwise.

It's important to note that WCAG does not cover every potential accessibility issue or individual case. This means that a site which conforms to WCAG can still be inaccessible to a user.

EN 301 549

EN 301 549 (PDF) is also known as the “European Harmonised Standard for Accessibility requirements for ICT products and services” and has been around since 2014. It was updated in 2018 to use WCAG as a compliance metric. It sets out a standard for ICT procurement in the EU but has gone on to be adopted by other countries such as Japan, Canada and Australia.

This standard does go beyond WCAG in some cases, such as requiring authoring tools to guide the output of accessible content and provide accessible documentation and support (section 11.8). The W3C (authors of WCAG) defers this to the Authoring Tool Accessibility Guidelines (ATAG) so this would not otherwise be covered by EN 301 549. It also requires support of user preferences (section 11.7).

User preferences

One of the areas where EN 301 549 goes beyond WCAG is in support of user preferences. From the relevant section (11.7) these preferences include:

"units of measurement, colour, contrast, font type, font size, and focus cursor"

So where the website or app can get this preference information from the browser or operating system it should use it.

For some of the areas mentioned this is what we would normally be doing anyway. For example allowing the user to adjust font size by adjusting it in their browser settings. It’s worth noting the WCAG criteria for font size does not specify the mechanism of doing this, so page zoom is sufficient. However for the European directive this is not sufficient and so section 11.7 comes in.

Current state

EU 301 549 is currently being revised (as of July 2025) to further support the EU Accessibility Act (see below) and should see a new version released in 2025.

Other standards

Due to the complex nature of accessibility there are additional standards which the W3C publish to deal with specific cases. Some of the main ones are listed below.

“ARIA in HTML”, and “Accessible Rich Internet Applications (WAI-ARIA)” both which deal with making websites more accessible particuarly to users of assistive technology. Read more about ARIA. ARIA is sometimes mentioned in WCAG criteria as one way of satisfying the requirements.

“Authoring Tool Accessibility Guidelines (ATAG)” is a standard for making content authoring tools accessible. So if your product has an editorial interface then this standard would apply.

“Collaboration Tools Accessibility User Requirements” is a standard for any tools which allow collaboration ranging from tracking changes to real-time co-editing.

The W3C also publish “notes” which are reference documents rather than standards, but which can contain useful insights, such as:

• “Making Content Usable for People with Cognitive and Learning Disabilities”
• “Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile”. Whilst this uses the older WCAG 2.0 as a base this shows how the web-focused WCAG guidelines can be mapped to mobile apps.

All-encompassing UK legislation

There are some fundamental laws which exist which can be cited in discrimination claims. Whilst these do not cover digital aspects specifically, the outcomes of digital discrimination are covered.

Equality Act (2010)

Regardless of whether the site is commercial or public sector, internal or external, they will all be subject to the Equality Act 2010:

“all UK service providers must consider ‘reasonable adjustments’ for disabled people”

The law requires providers to anticipate the needs of disabled customers, not just respond to issues raised by them.

Public Sector Equality Duty

There is also the Public Sector Equality Duty which puts the onus on those orgnaisations to promote equality, find ways to avoid inequality within their organisations and publish policies which advance these aims.

Public Sector legislation

To meet accessibility legislation for UK and European public sector services, meeting WCAG A/AA guidelines is the main step to show compliance. However involvement of users with in development of products and services is heavily encouraged.

UK: Public Sector Bodies Accessibility Regulations

All websites and apps published by the Public Sector in the UK have to conform to the Public Sector Bodies Accessibility Regulations 2018 (PSBAR). This adds more specific markers as to what is expected of providers in ensuring their sites are accessible.

This means that if you are working on a website, app or service which is published for use internally or externally you have to ensure it complies with the regulations.

Where we use ‘website’ from here as shorthand, this covers websites, apps, intranets, internal services etc. For example internal services which are used by internal staff come under this regulation just as much as an external service for the general public.

This also covers any services which have been funded by a public body, even if they are not built, hosted or managed by it. So if a government department procures a company to build a service it must be accessible.

Although we are primarily talking about the newer PSBAR requirements, websites are still subject to other regulations such as the Equality Act.

There have been cases where departments have been referred to the European Commission over failure to meet these regulations, so compliance is important as it can become a legal matter.

Whilst WCAG is often cited as the requirement for PSBAR, the legislation references EN 301 549 which as already mentioned goes beyond WCAG in some places.

Europe: EU Directive 2016/2102

The EU Directive on the accessibility of websites and mobile applications of public sector bodies (2016/2102), also known as the European Web Accessibility Directive are the regulations which the UK’s PSBAR (see above) are harmonised to, so they are effectively the same. Just like PSBAR it is targeted at the public sector.

It references the European standard for digital accessiblity (EN 301 549, see above) which in turn references WCAG A/AA compliance amongst others. Member states undertake their own monitoring and have to submit reports to the European Commission.

USA: Section 508

Section 508 of the Rehabilitation Act of 1973 requires federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities.

It was updated in 2018 to incorporate conformance with WCAG but was written to reference the current version at the time which was WCAG 2.0 and hasn’t been updated since, which means Section 508 lags behind other legislation around the world.

Private Sector legislation

In the private sector the US and UK rely on the wider discrimination legislation to hold companies to account. In Europe however legislation has been passed which covers specific sectors and brings them more in line with the public sector.

Europe: The European Accessibility Act

The EU Directive on the accessibility requirements for products and services (2019/882), also known as the European Accessibility Act, is different from the two laws above in that it targets the private sector. Its primary aim is to establish a harmonised system across the trading block to ease trade between countries.

It covers a wide range of products and services and crucially includes both physical and digital aspects.

Just as with the European public sector directive, it also indicates EN 301 549 compliance as one way of meeting the requirements (but remember that the European legislation goes beyond WCAG in its scope):

“Products and services which are in conformity with harmonised standards […] shall be presumed to be in conformity with the accessibility requirements of this Directive in so far as those standards or parts thereof cover those requirements … (Article 15 para 1)”

Service areas covered

• electronic communications services
• audiovisual media services
• air, bus, rail and waterborne passenger transport services:
  • websites and mobile apps
  • electronic ticketing
  • transport service information
  • interactive self-service terminals
• consumer banking services
• e-books and dedicated software
• e-commerce services

See Article 2 of the directive for a full list.

Products covered

• computers and operating systems
• payment terminals
• the following self-service terminals dedicated to the provision of services listed above:
  • ATMs
  • ticketing machines and check-in machines
  • interactive self-service terminals providing information
• consumer terminal equipment with interactive computing capability, used for electronic communications services (eg modem and router interfaces) or for accessing audiovisual media services
• e-readers

Conformity

Crucially the law requires conformity for all products being imported into the member states (as well as those marketed internally). So non-EU companies wishing to sell products within the EU will need to conform to these regulations.

“When placing their products on the market, manufacturers shall ensure that the products have been designed and manufactured in accordance with the applicable accessibility requirements of this Directive.” (Article 7 para 1)

“Importers shall place only compliant products on the market.” (Article 9 para 1)

“Service providers shall ensure that they design and provide services in accordance with the accessibility requirements of this Directive.” (Article 13 para 1)

In addition to making sure products and services are compliant, manufacurers and suppliers must also document this and provide feedback mechanisms for users.

The member states have had several years in which to adopt and prepare. Member states can begin to apply the directive from 28 June 2025. All member states must be enforcing the directive by 28 June 2027. There are some transition allowances - service contracts already in place before the 2025 deadline can continue until they expire or for 5 years (whichever is the least) and self-service terminals in use prior to the 2025 deadline can continue in use until they become uneconomical, for a maximum 20-year lifespan (see Article 13).

There are areas where the new legislation does not cover (for example domestic appliances, computers integrated into vehicles), but it is a major step forward.

Current state of European accessibility

A 2024 survey of 260,000 European website homepages found that 94% fail automated accessibility checks. Most issues were found to be very simple fixes (although the caveat here is that simple issues are the only things that automated checks can find). Examples of issues found included:

• poor colour contrast
• buttons and links missing text
• links only identified by colour
• missing alt text on images
• missing page language definitions

Further reading

• What is the European Accessibility Act? - TPGi on YouTube

Examples of legal enforcement

Student Loans Company

A blind user was unable to complete an online form, so had to resort to filling it in over the phone. The court ruled in her favour and the Student Loans Company had to pay compensation and fix the issues.

Blind York student wins £5k claim over 'inaccessible' loan form

Department for Work and Pensions (DWP)

DWP failed to provide accessible documents to a blind user. The court ruled in his favour and DWP had to pay compensation and fix the issues.

DWP breached equality laws after failure to communicate accessibly with blind benefits claimants and 'I brought a judicial review against the DWP and won £7,000'

Standards and legislation are the baseline, not the target

It is important to remember that meeting the legal regulations mean that your product has only met the bare minimum for accessibility.

There is a great deal of difference between accessibility compliance and truly making a product accessible. Legislation needs a black-and-white way to signify compliance and for accessibility WCAG provides a set of criteria to test against. Accessibility release gates are often tied to meeting these legal requirements and so often by default WCAG A/AA compliance.

However even this can leave many users with a problematic experience. As with any specification there are use-cases which were not conceived of when writing, or which could not be transposed to a set of rules which could be robustly tested against.

So rather than use the WCAG guidelines as a target for your accessibility work, instead view it as a baseline and then build upon it.

Wrap-up

You should strive to go above and beyond the legal requirements, test with users with a wide range of abilities and backgrounds and ensure you are making your product as accessible as possible.

In other words - you met WCAG, well done, you have done the bare minimum for accessibility. Now how are you going to do better?

• Contents
• Introduction
• Browser plugins
• Linters
• Unit testing
• Site-wide journey testing
• Automated tests as a metric
• The misconception about automated tests
• Enhancing automated tests
• Automating screen-readers
• Incorporating automated testing into a workflow
• Wrap up

Introduction

Automated testing can be a valuable tool when it comes to testing for accessibility. The flexbility means they can be included in an existing workflow without too much disruption. By making considered adjustments to existing tests we can improve outcomes and provide greater assurance.

Browser plugins

The first introduction most people have to automated accessibility tests is one of the many accessibility plugins for browsers.

This list is not exhaustive, but these are the most well-known ones with single-click checks:

• axe - one of the most popular accessibility plugins, its axe-core ruleset forms the basis of some others such as Lighthouse. Axe-core also lends itself well to command-line testing as we will see.
• Wave - another well-known and possibly more starter-friendly than axe as it overlays the page with icons indicating where issues lie
• ARC Toolkit - fast and effective, but its simplicity might suit more experienced users - has a good range of manual testing helpers
• IBM Equal Access Accessibility Checker - similar to axe this also adds some other options for viewing results, such as grouped by element or violation. This is also available as a node package for command-line usage.
• Accessibility Insights for Web - primarily a guided test suite but does have a single-click test option - has a good tab stop visualiser

Some of these may have additional tools (often called “guided tests”), but these are normally used in manual testing. Here we are just looking at the part of the plugin where a suite of tests are run against a page with no input from the user.

Report output

These plugins all run on a single page and will generate a report detailing the failure, perhaps with a snippet of the offending code and suggestions for how to fix it.

There are differences in what each one reports as they are built on their own set of checks - especially when it comes to colour contrast. For this reason it can be helpful to use two different plugins to check the same subject.

Are plugins useful?

These plugins are all very easy to use, they are literally a push-button approach and are very visual. They generally also do a good job of highlighting the issue and providing additional information. As such they can be a good way to learn more about accessibility, especially WCAG.

Their simplicity is also part of the problem. They will only test the page in its current state and at the current viewport. Any interactions or parts of the page only exposed by interactions will not be tested.

They also only test for a small group of issues, primarily ones based on syntax use. Whilst this can be very valuable (as some of these can be difficult to spot otherwise), it does leave a lot of potential issues untested.

For example a plugin could tell you that a heading level has been skipped, but it cannot tell if the correct heading levels are being used to correctly relay content relationships.

Finally, as most plugins utilise their own set of custom rules, there can be variations in reporting.

These one-click reports are effectively linting the interface to find syntax issues (in fact as we'll see the same code is used in some linters). Just as you would not rely purely on a linter to check your application code we should not rely on accessibility linters to check for accessibility. We should always supplement these with additional manual checks.

Closer examination of most plugins will show that these one-click reports are only part of what they offer. Most will also have a suite of additional tools which assist with manual testing such as keyboard tab order.

Linters

What is better than running some code in the browser only to find issues with a plugin? Finding those issues as you code. This is where linters come in. Some have their own set of rules (such as eslint-plugin-jsx-a11y) whilst others leverage existing libraries such as axe-core.

These do have some limitations on what they can test - for example colour checks are often exempted - and depending on how your components are constructed they may have difficulties in making necessary associations.

Unit testing

We can run command-line compatible rulesets (like axe-core or IBM) against individual components.

// using Jest with axe-core

test("component passes automated accessibility checks", async () => {
    const render = () => `
        <label>Name</label>
        <input type="text" id="name" name="name">
        `;
    const html = render();
    // run the checker against our component
    // assert that we don't get any violations back
    expect(await axe(html)).toHaveNoViolations();
});

This opens up the possibility for additional scripting, such as providing optional data or performing interaction before running the accessibility check.

Site-wide journey testing

There are options to be able to run similar checks to the ones from browser plugins across multiple pages or entire sites. As mentioned most common is axe-core which is the rules engine which the axe browser plugin uses, but others such as Pa11y are available.

These can be set to run as part of a continuous integration build step to provide some confidence in development.

// using Playwright with axe-core

test("Pass automated tests", async ({ page }) => {
    await page.goto("http://www.example.com", {
        waitUntil: "domcontentloaded",
    });
    // run the checker on the page
    const a11yScan = await new AxeBuilder({page}).analyze();
    // assert that we don't get any violations back
    expect(a11yScan.violations).toEqual([]);
});

The results are rendered in the console but there is the potential to generate html reports. A similar level of detail to that provided by the browser plugins can be generated as the data is broadly the same.

Whilst more involved than the browser plugin version to set-up, this is still a relatively simple implementation. As long as it is set up to run site-wide then it also provides a useful baseline asurance that any changes to one page or component have not had unwanted effects elsewhere.

With a little thought, interactions could be triggered in scripts prior to running the checks to provide more in-depth coverage.

However, as with the browser plugins these checks will still only ever find a subset of the issues. As with any automated checks, these are also only truly effective if they are reguarly monitored. Unless a failing test also fails the build or features in a strong definition of done, it is common for these tests to be set up and forgotten about.

Automated tests as a metric

One of the most useful things about running automated tests as part of the pipeline is that they provide a measurable metric.

The easily-repeatable nature means they function well as a gauge for progress, especially with a remediation project where retrospective fixes are being addressed.

The misconception about automated tests

There is something of a misconception that if automated tests are run against a site, page or component and a pass is signalled, that this means the item is accessible. This is not the case.

A clear pass only means that the automated checks did not find any failures against the limited set of rules it tests against.

It is not telling you everything is ok.

It is very possible for the subject to pass automated tests whilst still failing the user and being inaccessible. This is why we still need to build manual testing into our test strategies.

With that said, automated tests form an important part of our toolkit and are a useful baseline and warning against potential regression.

Read more about testing strategies and accessibility

Enhancing automated tests

So we know that library-style accessibility checkers are good for capturing some issues, but what are the gaps we need to think about filling when we are adding custom scripts to our tests?

Some areas to consider are:

1. Semantic structures
2. Keyboard access
3. Reflow
4. Interaction and state

Enforcing semantic structures

Semantics are essential for good accessibility as they form the basis of good screen-reader experiences. However they can often be missed as their lack of presence can be masked by visual styles.

But we can improve this as part of our tests without often having to generate specific tests by making our selectors do the hard work.

Instead of using ID attributes to locate elements we can look for accessible hooks to assert-as-we-go. These can include element roles, accessible names or state information such as aria-expanded.

// using Playwright
// get button with accessible name of "login" and aria-expanded=false
await page.getByRole('button', {name: "login", expanded: false});

// using Playwright
// get h2 with accessible name of "conditions"
await page.getByRole('heading', {level: 2, name: "Conditions"});

This type of declarative test makes this a really good fit for TDD (test-driven development) as it enforces good accessiblity practice before any code has been written.

Enforcing good keyboard accessibility

It can be all too easy to test a component as we might access it ourselves and not think about other ways it might need to be accessed. For example keyboard access tends to get ignored as most developers use mouse-based navigation. But making sure our components are actionable with just a keyboard is an essential part of accessibility practice.

Ignoring keyboard accessibility is all too common and is easy to see the evidence when looking at various commerical websites.

Most of the action and locator events in test scripts act as mouse users - for example moving directly to a control and clicking it. This will not provide us with any assurance that a keyboard-only user can access the same item.

We need to write tests to check that the keyboard user:

1. can access the control
2. accesses the control in a logical order (for example the previous focusable element was the one expected)
3. can action the control

Let's write an example test for the above situation.

// using Playwright

test('user can access carousel items', async ({ page }) => {
    // use accessible selectors to get the left-hand carousel button
    const carouselPrev = page.getByRole('button', {name: 'previous'});
    
    // grab the first carousel item
    // using an ID as the content is dynamic (we could improve this)
    const firstDeal = page.getByTestId('first-deal-item');
    
    // focus on the carousel button
    carouselPrev.focus();
    
    // use the tab key to move
    await page.keyboard.press('Tab');
    
    // assert that the first carousel item has gained focus
    await expect(firstDeal).toBeFocused();

    // activate the carousel item using a key command
    await page.keyboard.press('Enter');

    //then we can assert that the page has updated as normal
    ...
});

Whilst this might not be something which you would probably want to do for normal content, it would be beneficial for any complex components or ones which involve interaction. It is here where mouse event listeners are most often employed at the expense of keyboard users.

Reflow

Reflow is not something which it is easy to generate TDD scripts for, but it is something which can have regression tests written to prevent issues appearing.

Reflow issues often occur when the content overflows either the viewport or its parent container. This can be due to:

• text size increases by the user which haven't been handled
• viewport size changes, such as moving from dektop to mobile
• changing viewport orientation, such as mobile being viewed in landscape rather than portrait mode

In these situations content can either sit off-screen (albeit sometimes readable by scrolling the screen) or can be cut off so it is entirely unreadable.

Reflow really needs to be manually tested as some of the triggers are not available to scripts (such as text-size or spacing increase), but we can add some automated tests to help us catch some regressions once we have a well-tested base.

By using visual regression testing we can take screenshots of each page at different viewport sizes. Then when making updates new screenshots are taken and compared to the 'good' originals. This could help isolate any overflow issues.

// Using Cypress
const baseUrl = "https://liptrot.org";
// determine screen sizes to test
const sizes = [[390, 844], [1024, 1366], [1024, 600]]
// list of pages to run against
const pages = [
  {url:"/",name:"home"},
  {url: "/guides", name:"guides"},
  {url: "/posts/accessible-names/", name:"blog-accessible-names"}
]
// loop through each page and size and take a screenshot
sizes.forEach((size) => {
  describe(`On ${size} screen`, () => {
    pages.forEach((page) => {
      it(`Render ${page.name}`, () => {
        if (Cypress._.isArray(size)) {
          cy.viewport(size[0], size[1])
        } else {
          cy.viewport(size)
        }
        cy.visit(siteUrl + page.url)
        // compare the new screenshot against the one held as the 'good' version
        cy.compareSnapshot(`${page.name}-${size}`)
      })
    })
  })
})

State tests

As we have already seen we can use thoughtful locator queries to assist in enforcing good accessible markup and these included using state information such as aria-expanded.

As these state attributes form the basis of important announcements to screen-readers, we should also check that they are being updated correctly.

We want to be particuarly mindful of attributes or content which get updated as the user interacts. These can include:

• aria-pressed
• aria-expanded
• aria-valid
• aria-live region content

test('open account menu actions', async ({ page }) => {
    // get the button - checking the attribute is set to false
    const logInButton = page.getByRole('button', {name: 'login', expanded: false});
    await logInButton.press('Enter');

    const accountMenu = page.locator('#account-menu');
    const accountMenuClose = page.locator('#account-menu-close')

    // check menu is visible
    await expect.soft(accountMenu).toBeVisible();               
    // check button aria attribute has updated
    await expect.soft(logInButton.toHaveAttribute('aria-expanded','true'));               
    // check close button in dialog is focused
    await expect.soft(accountMenuClose).toBeFocused();
});

Automating screen-readers

How about automating screen-readers directly? Well this can be done but as you will need a screen-reader installed it is unlikely something which would be achievable on a CI server.

There is a library called Guidepup which presents a bridge between Playwright and two screen-readers (NVDA and Voiceover).

I found that there were issues in getting the tests to run quickly and reliably, but it is certainly an area which is interesting and would be ideal for TDD.

// using Playwright and Guidepup with Voiceover
test("I can navigate the tables page", async ({ page, voiceOver }) => {

    await page.goto("http://liptrot.org/guides/vo-macos/tables/", {
      waitUntil: "domcontentloaded",
    });

    const header = await page.locator('header');
    await expect(header).toBeVisible();
    // start interacting with the page
    await voiceOver.interact();
    // jump to the next table (equivalent to VO + t command)
    await voiceOver.perform(voiceOver.keyboardCommands.findNextTable);
    await delay(1000);
    // next table
    await voiceOver.perform(voiceOver.keyboardCommands.findNextTable);
    // grab the last spoken announcement from VO
    const tableAnnouncement = await voiceOver.lastSpokenPhrase();
    // assert it contains the table caption
    expect(tableAnnouncement).toContain('Dates and amounts')
  });

Automating virtual screen-readers

An alternative to using real screen-readers is using a set of rules which follows how you would expect a screen-reader to act, by the specifications. For example, if you jump to an input you would expect the input's accessible name (eg the label) and accessible description to be announced.

This has the advantage of not being reliant on a screen-reader being installed and so can be run on a CI server.

// using Jest and Guidepup
test("should navigate to the input and announce the label and hint", async () => {
    document.body.innerHTML = `
    <form>
        <label for="ref">What is your reference?</label>
        <div class="hint" id="ref-hint">This is 10 characters.</div>
        <input type="text" name="ref" id="ref" aria-describedby="ref-hint" />
        <button>Save</button>
    </form>
    `;

    await virtual.start({ container: document.body });

    // Move to form
    await virtual.perform(virtual.commands.moveToNextForm);
    // Move to the input
    await virtual.next();
    await virtual.next();
    await virtual.next();
    // grab the last spoken announcement
    const lastSpokenPhrase = await virtual.lastSpokenPhrase();
    // check it contains the accessible name expected ...
    expect(lastSpokenPhrase).toContain("What is your reference?");
    // ... and the accessible description expected
    expect(lastSpokenPhrase).toContain("This is 10 characters");

    await virtual.stop();
});

Whilst this follows what the specifications say should happen, if you have done any screen-reader testing yourself you will know that screen-reader support often lags behind the specs, or screen-readers diverge from the specs to improve usability for their users.

For example with NVDA, moving through the content it will not announce the hint as above to avoid repetition, but if you jump directly to the input it will (as you have not already heard it).

So as with all our automated tests, this is another tool, but must not replace testing with actual screen-readers.

Incorporating automated testing into a workflow

Automated tests at their most basic out-of-the-box are relatively simple to introduce into an existing workflow and can be supplemented with some more thoughtful managed test scripts and practices:

• use browser plugins to check HTML prototypes for potential issues before writing the development team ticket, use the output to prompt questions
• use TDD to enforce accessibility best practice
• encourage the use of linters added to code editors to catch issues as the code is written
• run a browser plugin against any work which touches the user interface before the code is committed
• encourage code reviews to run browser plugins against pull requests
• add automated checks to unit tests and journey tests
• enhance journey tests with accessibility-focussed checks customised to the interface

Each of these can be written into a definition of ready or definition of done to help embed the practice.

Read more about team processes and testing strategies.

As with any kind of test, accessibility tests are only effective if the output is monitored, reviewed and acted upon. There is no point adding automated checks to a pipeline if no-one ever looks at the results of each run.

Wrap up

There are a lot of options we can employ when looking at improving automated accessibility testing, using out-of-the-box solutions is only the first step.

By considering all our users we can put in additional tests to improve the accessibility of our codebase.

Accessibility testing must not stop at automation, no matter how sophisticated it is. Manual testing is essential, but what automation testing does give us is a baseline. This baseline means that manual testing should be more effective and less time-consuming and noisy as a result.

• Introduction
• The Document Object Model
• The Accessibility Tree
• Viewing the accessibility tree
• What is not included in the tree
• The impact of CSS
• Accessibility APIs
• Where differences start to appear
• Wrap-up

Introduction

You might have heard a screen-reader reading through a page and providing a lot of extra information to the user, other than what is visible. This information is important to convey information which a user who can see the screen might infer from the visual display, but which a screen-reader user who relies purely on the audible cues might miss - for example “how many items are in this list and which item am I on?”.

So where is it getting this information from?

The Document Object Model

When the browser renders the page it generates the Document Object Model, or DOM.

The DOM is a representation of the page as a set of nodes for each element and you may have seen a visualisation of this in the Elements and Properties panels of your browser developer tools.

So an HTML page with a button:

<html>
  <head>
    <title>DOM</title>
  </head>
  <body>
    <button>Save and continue</button>
  </body>
</html>

Will be represented by this DOM:

Document
  HTML
    Head
      Title
        "DOM"
    Body
      Button
        "Save and continue"

When the browser creates the DOM, it also generates a version of it called the Accessibility Tree.

The Accessibility Tree

The Accessibility Tree provides specific information which is of use to assistive technology such as screen-readers. The two main pieces of information are the item's Name and its Role.

Name

More accurately "accessible name", this is way the user will interact with the element. For a screen-reader this is announced; for a speech-recognition user this is the thing they will need to say to interact with the item.

At its simplest it is the text contents of the element. The accessible name of the link below is "Bob":

<a href="...">Bob</a>

So this will be announced as "Bob, link" to a screen-reader, and a speech-recognition user may say "Click Bob" to activate the link.

Accessible names can come from sources other than just content. For example:

• an image's accessible name is generally its alt attribute
• a form input's accessible name normally comes from it's associated label

Read more about accessible names

Role

A role is the function of that element. Many HTML elements have implicit roles, for example an a element has a role of "link" and a nav element has a role of "navigation". For screen-reader users this is announced along with the accessible name to give the user an idea of what the purpose of the item is and perhaps what interactions may be possible.

For example, if we just created a button with a div and some javascript click handlers:

<div>Continue</div>

This would only be announced to a screen-reader user as plain text:

“Continue”

The user has no indication that this is clickable beyond the contained text. But if we use the correct element (and therefore the correct role):

<button>Continue</button>

Then as well as saving ourselves the effort of writing extra javascript, our screen-reader user now knows it is a button which can be clicked:

“Continue, button”

Other properties

There are other accessibility properties which give more information, such as state - is the button focussed or not, is the drop-down expanded or not, and so on. These are passed along in the accessibility tree.

The presence of these properties will depend on the particular type of element. Some HTML elements have implicit states. For example a checkbox input can have a "selected/checked" state.

ARIA allows us to expand on these implicit states where HTML does not have equivalents:

• aria-posinset - gives the position of an element within a set of elements
• aria-pressed - lets the user know the element is in a pressed state
• aria-expanded - lets the user know the element is in an expanded state
• aria-describedby - creates a relationship with other elements to provide more information
• aria-autocomplete - on an input this tells the browser it might be able to be filled from stored data

This helps ensure a user who cannot see the interface gets the same information which would otherwise only be presented visually.

Read more about ARIA

Putting it all together

In the image below we have an h1 highlighted. We can see from the developer tools that its accessible name is taken from the the text inside the heading. It also has a role of “heading” and a level of “1” both which come from the element (an h1 - an h2 heading would present as a "level 2").

To a screen-reader this is announced as:

“Cowell named Aston Martin team principal, heading, level 1”

As you can see, the name, role and other properties help the screen-reader user build a picture of the structure of the content. This also demonstrates the importance of good semantic HTML.

Viewing the accessibility tree

So how do we see this accessibility tree? In Chrome and Firefox this is part of the developer tools under the accessibility panel.

In both browsers you will see the tree represented as a tree-view of roles and accessible names (along with some other properties where assigned) like this:

main
  heading "Viewing the accessibility tree"
    StaticText "Viewing the accessibility tree"
    paragraph
      StaticText "So how do we see this ..."
    figure
      image "Chrome developer tools ..."

"StaticText" just refers to plain text. You can see how the text which sits inside the heading provides the accessible name for that heading, as does the alt text for the image. You can also see how a paragraph does not generate an accessible name, but the plain text will still be passed along.

So with this set of data we can begin to build a picture of this element and how it will be communicated.

What is not included in the tree

When you examine the Accessibility Tree you may notice that when compared to the DOM there is a lot of “structure” missing from the page.

A lot of this is attributes which are ignored (unless they affect how the element is exposed), but there are also whole elements which are not included.

You will see these marked as “Ignored” (in Chrome) or just not even represented at all (in Firefox). This is because only those elements which have meaning for assistive technology will be carried over from the DOM to the Accessibility Tree. For example a div has no meaning to a screen-reader so won’t make it, although its contents may.

This is where mis-use of ARIA can be a problem. For example, assigning a role="presentation" to a button will change how it is exposed to the accessibility tree.