Welcome to UserWay University!

The fastest way to learn the underlying technical requirements of WCAG 2.1

Design related WCAG 2.1 A and AA Success Criteria

Here are the details of the success criteria that are related to design.

Perceivable

1.3 Adaptable

1.3.4 Orientation (A)

A page view must not be locked to either horizontal or vertical views only, unless this is essential. ‘Essential’ orientation may considered to be in a messaging app, or when making music using a piano type application, viewing slides for a projector show, television or virtual reality content.

Why is this a problem?

Users with low-vision should be able to view content in the orientation that works best for them, due to the need for increased text size. For users with dexterity impairments, who mount a mobile device or tablet, they will need to see content in their preferred way.

Requirements / What to do?
  • Each page should be viewed in an orientation that suits the user. Use CSS to allow both landscape and portrait.
  • Users with low-vision should be able to view content in the orientation that works best for them.
  • Users with low-vision should be able to view content in the orientation that works best for them, due to the need for increased text size and users with dexterity impairments, who mount a mobile device or tablet, will be able to use the content in their preferred way.
  • Use show/hide controls to allow access to content in different orientations.
Common mistakes
  • Locking the orientation of the device so it is set in one way only, and does not adapt.
Useful resources

1.4 Distinguishable

1.4.1 Use of Colour (A)

Colour must not be the only thing used to tell different content apart. This ensures that people who are unable to see colours, or who have difficulty telling different colours apart, have some other way to do so.

Requirements / What to do?
  • When rendered in monochrome, information does not disappear.
  • Text identified by colour as having special meaning has another indicator - a visible border and label, underline or other visual effect.
  • Information graphics and charts that use colour as a key also provide distinctive non-colour differences - hatching patterns or directly applied labels.

    Common mistakes
  • A form uses only colour to indicate a required field.

  • Colour-coding text or backgrounds to indicate essential content, pass/fail categorisation, etc.

  • Links are only distinguished from plain text by colour and the colour may not vary from the main body text.

  • Text alternatives that do not include information conveyed by colour differences in the original image.

    Useful resources
  • Understanding Colour Blindness

  • Colour Blindness in Gaming

  • More Colour Blindess in Gaming

1.4.2 Audio control (A)

When audio or video plays automatically on a page, it should last for less than three seconds or there must be a way to pause/stop it. This ensures that people who listen to content with a screen reader can do so without it being drowned out by the audio/video.

Requirements / What to do?
  • Audio or video content that plays automatically lasts for three seconds or less;
  • Audio or video that plays automatically and lasts for more than three seconds, can be paused and/or stopped.
Common mistakes
  • Audio or video plays automatically for more than three seconds, but cannot be paused or stopped by the user.
Useful resources
  • TBC

1.4.3 Contrast minimum (AA)

Text must have a contrast ratio of at least 4.5:1 against its background colour. This makes content easier for everyone to read, but especially partially sighted people.

Requirements / What to do?
  • Text (whether plain text or in an image) has a contrast ratio of at least 4.5:1 against its background colour.
Common mistakes
  • Text does not have a contrast ratio of at least 4.5:1 against its background colour.
Useful resources
  • TBC

1.4.4 Resize text (AA)

It must be possible for people to increase the size of text by up to 200%. This ensures that partially sighted people can comfortably read content.

Requirements / What to do?
  • We need to decide whether we want to use text resize or zoom as the preferred mechanism.

1.4.5 Images of text (AA)

Text must not be presented as part of an image because it cannot be resized, and it deteriorates in quality when magnified. This means that everyone is able to read and access information presented in text.

Requirements / What to do?
  • Text is not presented as part of an image;
  • Text is presented using plain text and styled with CSS.
Common mistakes
  • Images contain text.
Useful resources
  • TBC.

1.4.10 Reflow (AA)

Where content is zoomed there should be no loss of information or functionality. In particular on smaller devices or resolutions of 320px (vertically) or 256px (horizontally) there should be no scrolling in two directions when resized.

Why is this a problem?
  • People who are sight impaired often use screen magnification to resize page content and this can cause info to get lost.
  • Scrolling can often be difficult for some disabled users, more so when horizontally or both horizontally and vertically at the same time.
  • Some languages scroll vertically like Chinese, Japanese, Mongolian or Korean.
Requirements / What to do?
  • Make sure your pages are responsive and the content will ‘reflow’ to a single column gracefully.
  • A simple browser based test is to try a width of 1280px at 400% zoom. You can zoom in on a Mac in Chrome by pressing CMD and + key (until you see the resolution hit 400%).
  • For web content which is designed to scroll horizontally with vertical text, set viewport height of 1024px and then the 400% zoom.
Common mistakes
  • Content does not reflow to a single column when zoomed.
  • Horizontal scrolling appears in both directions at some low resolutions when content is zoomed.
  • Using fixed sized containers and fixed position content (CSS)
  • Use of <code><pre> formatted content (such as code) can cause horizontal scrolling. Using the CSS declarations such as word-wrap: break-word; on <code><pre> in small viewports will help to avoid horizontal scrolling at all.
Useful resources

1.4.11 Non-Text Contrast (AA)

This is like ‘colour contrast for charts, icons and controls’. User Interface components and graphical objects have contrast ratio of at least 3:1. This also covers where the state of a control changes - a button on mouse over for example.

  • User Interface ComponentsVisual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
  • Graphical ObjectsParts of graphics required to understand the content of a page. These can be charts, graphs, infographics and so on.
Why is this a problem?

Many sight impaired users cannot see important controls or understand graphics if they have poor colour contrast.

Requirements / What to do?

Check that buttons or other inputs and controls have a ratio of 3:1 or higher. This also includes their ‘state’.

NOTE: This does not apply if inactive or if their look is made purely by the browser and not the author.

Make sure parts of any graphics required to understand the content (like a warning icon) have good colour contrast.

Common mistakes
  • The purpose and meaning of important images that relate to page content - like if a medicine is poisonous, or other warnings - are hard to make out for a user who is sight impaired.
  • The purpose or ‘state’ of a control isn’t clear to the user.
Resources
For User Interface Component contrast
For graphics with sufficient contrast
For text in or over graphics
Resources

Find out more about Accessibility Requirements for People with Low Vision.

1.4.12 Text Spacing (AA)

For regular HTML page content, no loss of content or functionality happens with some changes to line height, letter or word spacing.

Why is this a problem?
  • People with low vision may require increased space between lines, words, and letters are able to read text.
  • People with dyslexia may increase space between lines, words, and letters to increase reading speed.
  • White space between blocks of text can help people with cognitive disabilities comprehend sections of a page and call out boxes.
Requirements / What to do?

You can use a browser plug in or directly edit typographic CSS on a page to change the styles so that:

  • Line height (line spacing) is at least 1.5 times the font size;
  • Spacing following paragraphs is at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.

Make sure that all text fits within its containing box without being cut off or without overlapping other boxes.

Common mistakes
  • Not allowing or restricting the user from overriding text style.
Resources
Techniques for:

1.4.13 Content on Hover or Focus (AA)

This is for mobile or tablet devices - where pointer hover or keyboard focus triggers additional content to become visible and then hidden (like pop-ups or other options) you need make sure:

  • The ‘extra’ content can be dismissed without moving focus and it does not obscure other page content.
  • If the user needs to hover or interact with the extra content, then the pointer can move to it and use it, without it disappearing.
  • The content stays visible until focus is moved, or the user dismissed it, or it is no longer useful.
Why is this a problem?
  • For disabled users on your website who may accidentally trigger content or are using keyboards only or mobile devices it is frustrating when pop up content either doesn’t ‘stay’ on the screen if they need to use it or won’t go away without loosing their place.

  • This also helps sight impaired users who don’t want to zoom in/out a lot to see if content is still active on the page (or not). It also gives all user enough time to understand the ‘extra’ content that appears and what they need to do.

Requirements / What to do?

This has several approaches depending on the control. For content to be dismissed:

  • Position the additional content so that it does not obscure any other content including the trigger, with the exception of white space and purely decorative content, such as a background graphic which provides no information.
  • Provide a way to easily dismiss the additional content, such as by pressing Escape or selecting a close button.

For content to be hoverable:

  • Manage focus and move the mouse pointer directly from the trigger onto the new content.

For content to be persistent:

Once it appears, the content should remain visible until:

  • The user removes hover or focus from the trigger and the extra content;
  • The user dismisses the extra content.
  • The information conveyed by the additional content becomes unnecessary.
Common mistakes
Resources
  • TBD

Operable

2.1 Keyboard Accessible

2.1.1 Keyboard (A)

It must be possible for someone using a keyboard or touch device to complete all tasks in a service. This ensures that people with mobility impairments who do not use a mouse can successfully complete their goals.

Requirements / What to do?
  • All interaction and functionality is usable with a keyboard;
  • All interaction and functionality is usable on a touch-screen device.
Common mistakes
  • A custom widget has been created, but the necessary keyboard support has not been provided;
  • An <a> element has been used as the basis for a button, but the additional keyboard interaction (activation with the space key) has not been provided;
  • A dialogue opens but cannot be dismissed by touch, because it does not have a close button;
  • The tabindex attribute has been used with a value of “-1” to mistakenly remove it from the tab order.
Useful resources

2.1.2 No keyboard trap (A)

When someone using a keyboard to navigate content moves to an element, they must be able to move away from it again. This ensures that people who use a keyboard do not get stuck on any part of the page.

Requirements / What to do?
  • Keyboard focus can move to an element and away again.
Common mistakes
  • A dialogue opens but cannot be closed with the keyboard, preventing the user from accessing the original content underneath;
  • Content is presented in an infinite scroll, so a keyboard user is forced to tab through everything before they can exit the scroll area.
Useful resources
  • TBC

2.1.4 Character Key Shortcuts (A)

If your webpage has keyboard shortcuts then one of the following must be true: * Turn off: The user must be able to turn them off; * Remap: The user must be able to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc); * Active only on focus:The keyboard shortcut is only active when it has focus.

NOTE: This success criteria does not apply if you have not implemented keyboard shortcuts.

Why is this a problem?
  • This can be a real problem for users of speech recognition software (like Dragon). Without the ability to turn off single-key shortcuts, they can be triggered accidentally and fire with the user wanting it to happen.

  • Also Keyboard-only users who who may accidentally hit keys, or have involuntary movement will benefit from turning off single character shortcuts or modifying them.

Requirements / What to do?

Make sure your users have a way to turn off single-key shortcuts. This could be in a preference section of your site.

Or provide a way to allow users to change character-key shortcuts.

The alternative shortcuts could be longer strings that would act as native speech commands for any speech engine.

Common mistakes
  • Not allowing the user to switch off or remap keyboard shortcuts.
Resources

You can see the issue in these character key shortcut video, with thanks to Kim Patch.

The remapping method can include non-printing characters.

2.2 Enough Time

2.2.1 Timing adjustable (A)

When a time limit like a session timeout is set, it must be possible for the user to turn it off, delay it, or extend the length of time. This ensures that people who need longer to complete tasks because of cognitive or mobility impairments, are able to do so comfortably.

Requirements / What to do?
  • A mechanism is available to let users turn off, delay or extend time limits.
Common mistakes
  • A time limit is set, but a user is unable to turn it off, delay it, or extend it;
  • A time limit warning is displayed, but a user’s attention is not drawn to it in an appropriate way.
Useful resources

2.2.2 Pause, stop, hide (A)

When content moves (is animated, blinks or scrolls) automatically for more than five seconds, or when content automatically updates on the page, it must be possible for users to pause, stop or hide it. This ensures that people with cognitive disabilities that affect focus and concentration, are not distracted by movement.

Requirements / What to do?
  • A mechanism is available that lets users pause, stop or hide the moving or updating content;
  • Content does not move (animate, blink or scroll) for more than five seconds;
  • Content does not update automatically.
Common mistakes
  • Content moves for more than five seconds but there is no mechanism for a user to pause, stop or hide it.
Useful resources
  • TBC

2.3 Seizures

2.3.1 Three flashes or below (A)

A page must not contain content that flashes more than three times a second. This ensures that people with conditions like photosensitive Epilepsy are protected from harmful seizures.

Requirements / What to do?
  • Content does not flash more than three times a second.
Common mistakes
  • Content flashes at more than three times a second.
Useful resources
  • TBC

2.4 Navigable

2.4.1 Bypass blocks (A)

When there is repeated content (like a header) at the top of the page, there must be a way for keyboard users to move focus directly to the start of the main content area of the page. This ensures that people who do not use a mouse can quickly and easily reach the primary content of the page.

Requirements / What to do?
  • A “Skip to main content” link is provided, and the link is located close to the start of the page;
  • The <main> element is used to represent the main content area of the page.
Common mistakes
  • The <main> element has been used, but there is no skip link that points to it;
  • A skip link has been provided, but it does not work in all supported browsers;
  • A skip link is provided, but it is only available to screen reader users.
Useful resources
  • TBC

2.4.3 Focus order (A)

It must be possible to navigate through content in a way that makes sense. This ensures that content can be navigated in a logical way by screen reader users, keyboard users, and people who choose to use their own CSS style sheets.

Requirements / What to do?
  • The visible focus order matches the DOM focus order.
Common mistakes
  • The DOM order does not match the visual order because CSS properties like flexbox and grid-layout have been used to alter the visual presentation;
  • When CSS styles are disabled, the focus order is meaningless;
  • When a user interaction causes content to be displayed, it does so before the trigger control in the DOM order.
Useful resources
  • TBC

2.4.4 Link purpose (in context) (A)

The purpose of every link must be clear from its link text, or its link text plus associated content if assistive technologies recognise the association. This ensures that screen reader users can understand the purpose of links without reading nearby content, and that speech recognition users can target links accurately using voice commands.

Requirements / What to do?
  • Link text clearly indicates the purpose of the link;
  • Multiple links that point to the same destination have the same link text;
  • Links have accessible names.
Common mistakes
  • A link has text that does not indicate its purpose;
  • A link points to the same destination as another link, but uses different link text;
  • A link points to a unique destination, but uses the same text as other links;
  • A link has text that depends on nearby content to be understood, but that content is not automatically identified by assistive technologies;
  • A link uses a CSS background image, and has no visible accessible name.
Useful resources

2.4.5 Multiple ways (AA)

Unless the service is a series of steps, there must be different ways for people to locate and navigate content. Different people will have different preferences, for example someone with a cognitive disability may prefer to browse a sitemap to locate content, whereas someone using magnification may prefer to use search instead of scroll through a lengthy navigation block.

2.4.6 Headings and labels (AA)

Headings must indicate the topic or purpose of the content in that section of the page, and labels must indicate the purpose of the field they relate to. This ensures people with reading difficulties can understand the purpose of content, and that screen reader users can easily navigate to relevant sections of content on the page.

Requirements / What to do?
  • Headings describe the purpose or topic of the content that follows;
  • Labels indicate the purpose of the fields they relate to.
Common mistakes
  • A heading does not indicate the purpose or topic of the content that follows;
  • A label does not indicate the purpose of the field it relates to.
Useful resources
  • TBC

2.4.7 Focus visible (AA)

It must be easy to tell which element has keyboard focus. This helps sighted keyboard users orient themselves within the page, and confidently interact with it.

Requirements / What to do?
  • Interactive elements like links, buttons, and form fields, have a visible focus indicator.
Common mistakes
  • The browser default focus indicator has not been replaced with something that is easier to see;
  • An indicator has been provided for mouse hover, but not duplicated for keyboard focus.
Useful resources
  • TBC.

2.5 Input Modalities

2.5.1 Pointer Gestures (A)

On mobile devices where you can use a touch - and need more than one finger or need to follow a path type gesture, functionality can still be operated using a single pointer.

NOTE: This is true unless multi point or path based gestures are essential.

Why is this a problem?

Some disabled users may need simple inputs or gestures to complete tasks and make selections. Complex movement or gestures requiring dexterity or accuracy may be hard for them.

What is a path-based gesture?

If an interaction is not just the end-to-end part but important but also the road or path taken. These gestures could be swiping, dragging items or drawing.

What is a multi-point gesture?

This can be zooming into content using a ‘pinch’ type motion with two fingers, a swipe with multiple fingers and so on.

Requirements / What to do?

Design your interface so controls and content can be used without these path or multi-point gestures.

Single point activation is like it sounds. This means ensuring that on a touchscreen or touchpad users will be able to do everything using only taps, double taps, and long presses.

For a mouse, trackpad, head-pointer, or similar device include single clicks, click-and-hold and double clicks.

Some examples are:

  • In a map where you can pinch gesture to zoom the zooming can be done via [+] and [-] buttons.
  • In a Carousel with a horizontal content slider, hidden content can be moved into the viewport with swiping or forward and backward arrow buttons to navigate instead.
  • Do not rely only on path-based gestures.
  • Do not rely only on multi-point gestures.
Common mistakes
  • Requiring complex gestures to do things.
  • Functionality can be operated by pointer input but not with single-point activation alone.
Resources

2.5.2 Pointer Cancellation (A)

For mobile devices or tablets where if there is functionality triggered by a single pointer, at least one of the following is true:

No Down-Event
The down-event of the pointer is not used to ‘fire’ the function;

Stop the action or Undo
The function is triggered on the up-event, and a method is available to stop completion or undo the function;;

Up Reversal
The up-event reverses what happens on the down-event;

Essential
Completing the function on the down-event is essential.

Why is this a problem?

This aims to reduce accidentally triggering things on a page. Any interaction were a control fires as soon as it is touched is problematic for a range of users (and not just disabled users). It is better when there is a way to ‘undo’ or change your mind. This is what the success criterion aims to address and will help people with visual disabilities, cognitive disabilities, and motor impairments.

However, it can present problems for users with dexterity issues.

Requirements / What to do?
  • Simply make activation of any function occur on the up-event. This is where the control is released by the user. This can be by the users finger or a mouse for example. Using the click event by default will only trigger the event on release.
  • To ‘Cancel’ or ‘Undo’ a function. You can add a ‘confirmation dialog’ or an ‘undo button’. This asks the user to confirm the interaction and by doing so, you give them time to reflect and choose one way or another.
  • Up Reversal: You can design a control where the down-event trigger an action that can be reversed when the up-event is ended. Examples of this include press-and-hold actions such which make a popup appear and on release it disappears.
  • Some just things will need to fire on the ‘down-event’such as games or on screen keyboards.
What are down-events?

A down-event is when an action is caused to ‘fire’ when the trigger stimulus of a pointer (like a finger) is pressed.

The down-event may have different names, such as “touchstart” or “mousedown”.

What are up-events?

A up-event is when an action is caused to ‘fire’ when the trigger stimulus of a pointer (like a finger) is released.

The up-event may have different names, such as “touchend” or “mouseup”.

Common mistakes
  • Allowing controls or user interface components to fire as soon as they are touched.
  • After a user has made a selection of a user interface component, there is no way to dismiss the selection or undo the function.
Resources

2.5.3 Label in Name (A)

For user interface components with labels that include text or images of text, the Accessible namecontains the text that is presented visually.

Why is this a problem?

The ‘name’ is text by which software can identify a component within Web content to the user. The ‘Accessible Name’ is text in the DOM that is understood by both the AT (like a screen reader) and the browser. This is often hidden in code.

These need to match so that:

  • Speech input users can activate controls on a page.
  • Text-to-speech users will have a better experience because the labels that they hear match the visible text labels that they see on the screen.
Requirements / What to do?

The accessible name can be the ‘label’ used on a form input. This can be provided by the label element in HTML or by an aria-label or similar. There are other ARIA and HTML elements that can provide the accessible name for a component.

Ensure that the:

  • Accessible name matches the visible label: The accessible name and visible label of a control match.
  • Accessible name starts with visible label: The accessible name of a “Start here” button begins with the same text as the visible label.
Common mistakes
  • The Accessible name does not contain the visible label text
  • The Accessible name contains the visible label text, but the words of the visible label are not in the same order.
  • The Accessible name contains the visible label text, but there are extra words in the label.
Resources

2.5.4 Motion Actuation (A)

In a page or on a mobile device functionality that can be operated by device motion or user motion can also be operated by alternatives like buttons, links or other controls. There should be a way for disabling responding motion, unless the motion can operate in an accessible way or is essential

Why is this a problem?

This Success Criterion helps people who may be unable to perform tilting, shaking, or gesturing to use an interface - or the device may be mounted. Fixing this will ensure users can still operate all functionality by other means.

Notice how most of these following example are just about common sense alternatives to using motion to do things on a mobile device.

  • A user can’t hold and move the device to navigate content. A control exists to navigate also.
  • When inputting text - shaking a device shows a dialog where you can undo the text input. A cancel button next to the text field offers the same functionality.
  • A user can tilt a device to advance to the next or a previous page. Buttons or links are also provided to perform the same function.
  • A user can move the device to change the view of an image. A control is also available to do the same thing.
Requirements / What to do?
  • Do not use the devicemotion event to activate content functionality.
  • Ensure that alternative means of input exist when using device motion sensor input.
  • Provide a user preference to disable motion actuation.
  • Support OS features which allow the user to disable motion actuation.
  • Use the new prefers-reduced-motion CSS declaration. This will detect if the user would like to reduce animation or motion on the pages they visit.
Common mistakes
  • Functionality that can only be activated via device motion events (e.g., shaking or tilting)
  • The user is unable to disable motion actuation.
  • The author has turned off system level features which allow the user to disable motion actuation.
Resources

Understandable

3.2 Predictable

3.2.1 On Focus (A)

When a keyboard user focuses on a control it must not cause a change of context, such as loading a new page/tab. This stops unexpected things happening without screen reader and screen magnifer users being aware of it.

Requirements / What to do?
  • focus events do not cause navigation, nor form submission
  • components that respond to focus do not initiate a “focus trap”, where it is impossible or unclear how to navigate out of the component using the keyboard.
Common mistakes
  • Dropdown menus trigger navigation as the user tabs between options
  • Javascript triggers navigation when a user is merely leaving a form control
  • focus is moved by script in ways that surprise the user
Useful resources
  • TBC

3.2.2 On Input (A)

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component.

Requirements / What to do?
  • Users can predict what a control such as a button or drop-down menu will do
  • User interface components built with javascript have adequate and accurate ARIA labelling.
Common mistakes
  • Controls built with javascript lack appropriate ARIA information
  • Form controls are used to trigger navigation without an explicit submit step, and without warning
Useful resources

3.2.3 Consistent navigation (AA)

When ways to navigate content are repeated on multiple pages, they must be presented in a consistent manner. This makes it easier for people to learn how to navigate the service, and it enables people to develop strategies (like using screen reader shortcuts) for more efficient navigation.

Requirements / What to do?
  • Navigation mechanisms are presented consistently wherever they are used.
Common mistakes
  • A main navigation block is used on multiple pages, but is located in a different place on each page;
  • A breadcrumb navigation is used on multiple pages, but is presented in a different format on each page.
Useful resources
  • TBC.

3.2.4 Consistent identification (AA)

When features with the same functionality are used in multiple places, they must be identified in a consistent way. This helps screen reader users correctly identify the type and purpose of the functionality.

Requirements / What to do?
  • An icon has the same alternative text wherever it is used;
  • Buttons for “Next”, “Previous”, and “Continue”, are labelled consistently wherever they are used;
  • Form fields with the same purpose are consistently labelled wherever they are used.
Common mistakes
  • An icon is used to denote a file download, but has a different alternate text whenever it is used;
  • A search facility is provided on every page, but the text field and button have different labels on each page.
Useful resources
  • TBC.

3.3 Input Assistance

3.3.1 Error identification (A)

When an error occurs the user is informed what caused the error, and the error is described in text. This ensures that the error is available to people who cannot see, distinguish colours, or understand icons and other visual cues.

Requirements / What to do?
  • Each error is described in text;
  • Each error is associated with the field it relates to;
  • Multiple errors are summarised at the top of the form.
Common mistakes
  • An error is only indicated by a red border around the field;
  • An error is only indicated by an icon near to the field;
  • An error is described in text, but it is not associated with the field it relates to;
  • Multiple errors occur, but no summary is provided.
  • An error summary is provided, but keyboard focus is not taken to it.
Useful resources
  • TBC

3.3.2 Labels or instructions (A)

When data must be entered in a specific format or in a particular way, clear instructions must be associated with the form field. This ensures that everyone understands any requirements for entering data, and does so in a way that ensures that people unable to see the information are made aware of it by their screen readers.

Requirements / What to do?
  • Instructions are provided for fields that require data to be entered in a specific format;
  • Instructions are properly associated with the relevant form field.
Common mistakes
  • Data is expected in a specific format, but no instructions have been provided;
  • Instructions have been provided, but they are not associated with the relevant field.
Useful resources

3.3.3 Error suggestion (AA)

When an error is detected, suggestions for correcting the issue must be provided unless the suggestion compromises security. This helps everyone resolve issues more easily, but especially people with cognitive disabilities who find processing information difficult.

Requirements / What to do?
  • When an error is detected, a suggestion is provided to help the user correct the issue.
Common mistakes
  • An error is detected and the user is notified, but no suggestion is given to help them resolve it; A login error is detected and a suggestion is provided, but it comprimises security by revelaing that a particular username exists.
Useful resources
  • TBC.

When completion of a form causes a legal commitment, triggers a financial transaction, or gives consent for personal data to be updated or changed, the user must be able to review, correct, and confirm that the information they have entered is correct, or they must be able to reverse the decision. This provides safeguards to prevent people with disabilities, and indeed all users, from making avoidable mistakes.

Requirements / What to do?
  • When data is submitted leading to a legal commitment, financial transaction, or an update to personal data, an interim page, alert or status message is presented that allows the user to review, correct, and confirm the information they have entered.
Common mistakes
  • An online shop where order or personal details are not displayed so the user can confirm them or make changes.
Useful resources

Robust

4.1 Compatible

4.1.3 Status Messages (AA)

There are different situations where a status message needs to be shown in a way that assistive technologies understand. These messages need to be presented to the user without receiving focus themselves, or disturbing the user’s place in a page.

Why is this a problem?
  • A sighted person can quickly see status messages on a page, and them go back to what they were doing or reading. Moving focus to a message can be disruptive for screen reader users, users of speech recognition software and keyboard only users.
  • If focus is always moved to the message users with cognitive impairments may also be confused by unpredictable focus changes.
Requirements / What to do?

The following are different situations where you will need to cover.

When a status message tells the user something is successful

When a status message tells the user something is successful or is the results of an action. This can also be used for a state change when part of a page updates:

You can use these following techniques:

Use the ARIA role=status to present status messagesin combination with the technique Providing success feedback when data is submitted successfully.

If a status message conveys a suggestion, or a warning or error:

NOTE: There may be time when you do want to move focus to a message, such as an error, as a part of form validation etc.

Use the following techniques:

Use ARIA role=alert or Live Regions to Identify Errorsin combination with any of the following:

If a status message conveys information on the progress of a process:

The ARIA role="progressbar" can be used but may not be enough on its own (depending on AT and browser support). For some examples of progressbar role see:

You can use the following techniques:

Common mistakes
  • Status messages are not to be shown in a way that the AT understands or receive focus.
  • Using role="alert" or aria-live="assertive" on content which is not important.
  • On a page with ARIA live regions - if regions are hidden or not needed - always make sure to switch their active and inactive states accordingly.