Skip past section navigation

WCAG AA and AAA

With the Web Content Accessibility Guidelines there are different levels of compliance from A (Lowest), AA, and AAA (Highest).

Some of the impacts of making your service AAA will involve changing how a user interacts with your service and will go against security and GDS patterns, however, some will be fulfilled by default.

We have a legal requirement to meet AA, however to meet AAA we have to meet every single one of the WCAG criteria.

It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.

Understanding Conformance

AAA differences

There is a number of additional elements in standard that we need to consider, some are not relevant, some are covered by doing other parts of the standard.

Formats

Some of the AAA criteria relate to additional formats that may not be relevant to your service, however, if you are providing video you will want to consider how these are consumed.

AAA criteria relating to video:

• 1.2.6 Sign Language (Pre-recorded)
• 1.2.7 Extended Audio Description
• 1.2.8 Media Alternative
• 1.2.9 Audio-only
• 1.4.7 Low or No Background Audio
• 1.4.9 Images of Text

Content

There are a number criteria relating purely to content. Because the Service Standard says we should aim for a reading age of 9, you might meet some of these by default:

• 2.4.9 Link Purpose
• 3.1.3 Unusual Words
• 3.1.4 Abbreviations
• 3.1.5 Reading Level
• 3.1.6 Pronunciation

Edge considerations

Due to the way we build services in Government, there are some criteria which we probably can’t meet, and some which will probably never be relevant:

• 2.2.3 No Timing
• 2.2.4 Interruptions
• 2.3.2 Three Flashes
• 2.3.3 Animation from Interactions

Semantics

Some of the criteria should be covered by making sure we code our services to a high standard and everything is valid:

• 1.3.6 Identify Purpose
• 2.4.10 Section Headings
• 2.5.6 Concurrent Input Mechanisms

GDS Changes

Some elements of AAA would likely require you to deviate from the GDS design system styles, such as:

• 1.4.6 Contrast
• 2.5.5 Target Size

Considerations

Some criteria would need consideration, as they may change how the service is built and designed.

2.2.6 Timeouts

Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions.

As part of 2.2.1 Timing adjustable we need to allow the user to do one of the following:

• extend the session time out at least 10 times
• adjust the session timeout to 10 times the original length before encountering it
• turn off session timeout before encountering it
• set the default session timeout to be at least 20 hours

To meet the AAA WCAG 2.2 criterion - 2.2.6 Timeouts you need to include a warning on the start page that the session will timeout after the duration defined in the timeout itself.

If you meet the AAA criterion by providing a warning, you still need to meet the AA criterion for Timing adjustable.

1.4.8 Visual Presentation

Foreground and background colors can be selected by the user.

Some of the 1.4.8 Visual Presentation specification will already have been met, such as allowing the user to zoom, however, to meet the AAA for this we would also to provide options for the user to customize the service.

2.2.5 Re-authenticating

When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating.

Often services do not require you to authenticate, but if they do this is a consideration about how a user might save their data before submission.

2.4.8 Location

Information about the user's location within a set of Web pages is available.

The suggestion for this was ‘A breadcrumb trail’, however, when this is a multiple page service we’d need to give the user an idea of where they are in that process.

This may be better suited to a task list pattern approach.

3.2.5 Change on Request

Changes of context are initiated only by user request or a mechanism is available to turn off such changes.

For example, if you have a content which is updated in realtime such as a news feed, then you would need to provide the user with a way to turn off the automatic updates and provide a way for them to update the feed in their own time.

3.3.5 Help

Context-sensitive help is available.

For this, we already provide text hints on the format, and error messages for when a user has made an error, we should also be mindful of being flexible in what data we accept.

An assisted digital route might also cover this criterion.

3.3.6 Error Prevention

A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

There are three ways to satisfy this:

• allow the user to reverse their submission. For example, recall their application after it has been sent.
• provide the user with input errors and give the user an opportunity to correct any mistakes. This method won’t usually work for personal data as their isn’t anything to check it against.
• allow the user to confirm their information before they send it. For example, using the GOV.UK check your answers pattern.