Planning
Planning your approach
To ensure that people with disability can access content created by mainstream organisations, it is necessary for the creators of web content to make content accessible based on the international WCAG standard. To achieve the recommended WCAG 2.0 Level AA compliance, you will need to ensure that the success criteria listed here are implemented as part of your web content development processes.
It is likely that many of these requirements are already familiar to you, but for others it may take some time to consider the best way to incorporate them into your work practices. If you are new to WCAG, consider reading through all of the success criteria first to determine which requirements you are already doing, which requirements may take some practice to implement and which guidelines will require additional time to implement such as the guidelines related to captioning and audio described video.
If you wish to improve support for accessibility on mobile devices among other advantages, we recommend implementing WCAG 2.2.
1.1 Text Alternatives
1.1.1: Non-text Content
All non-text content presented to the user has a text alternative that serves the equivalent purpose.
Technique: This is viewed by many as the most important success criterion as it allows people who are blind or vision impaired to understand the visual aspects of a Web page. If something is represented visually, such as an image, it should have a brief text description embedded in the code. This description should reflect the purpose of the image and the context in which it is being used.
Exceptions:
- a control or accepts user input;
- time-based;
- part of a test or exercise that would be invalid if presented in text;
- primarily intended to create a specific sensory experience;
- CAPTCHAs (although if CAPTCHAs are used there needs to be both visual and audio versions);
- purely decorative.
WCAG 2.0 reference: Understanding Success Criterion 1.1.1
1.2 Time-based Media
1.2.1: Audio-only and Video-only (Prerecorded)
For prerecorded audio-only and prerecorded video-only media, alternatives need to be provided unless they are provided as alternatives for text.
Techniques:
- Create a text transcript for the audio recording that tells the same story and presents the same information as a prerecorded audio-only content. This may include the dialogue and any other sounds that may be important to the understanding of content.
- Create a text description that presents the same information as the prerecorded video-only content. This may include descriptions of scenery, actions or expressions on people’s faces that are part of the video presentation.
WCAG 2.0 reference: Understanding Success Criterion 1.2.1
1.2.2: Captions (Prerecorded)
Captions are provided for all prerecorded audio content in synchronised media, unless it is an alternative itself for text. This is viewed by many as the most important success criterion for people who are deaf or hearing impaired.
Technique: There are many free captioning tools including the excellent Amara. YouTube also has an automated captioning feature which can caption a video for you, but the quality of captions in this process varies significantly.
WCAG 2.0 reference: Understanding Success Criterion 1.2.2
1.2.3: Audio Description or Media Alternative (Prerecorded)
An alternative for time-based media or audio description of the prerecorded video content is provided for synchronised media, unless it is itself an alternative.
Technique: Audio Description (AD) is the inclusion of additional narration to explain the more visual aspects of a video. At Level AA, this success criterion is achieved at the same time as implementing 1.2.5 below.
WCAG 2.0 reference: Understanding Success Criterion 1.2.
1.2.4 Captions (Live)
Captions are provided for all live audio content in synchronised media.
Technique: Provide live captioning for webcasts to allow people who are deaf or hard of hearing to participate in presentations happening in real-time.
WCAG 2.0 reference: Understanding Success Criterion 1.2.4
1.2.5 Audio Description (Prerecorded)
Audio description is provided for all prerecorded video content in synchronised media.
Technique: Audio Description (AD) is a narration which explains what is happening visually in television, movies, or live performances. Delivered during gaps in the dialogue, it may include descriptions of scenes, settings, costumes, body language and ‘sight gags’ – anything that is important to understanding.
An example of audio description is the trailer for the hit Disney movie Frozen – audio described version.
WCAG 2.0 reference: Understanding Success Criterion 1.2.5
1.3 Adaptable
1.3.1: Info and Relationships
Information, structure, and relationships conveyed through presentation can be programmatically determined, or are available in text.
Technique: If a style is applied to visually indicate that something is a page heading, table heading or a list, make sure that the appropriate markup is used so that when the presentation changes, information and relationships are preserved. For example, table headings are often presented in bold font. They should also have the table heading tag included.
WCAG 2.0 reference: Understanding Success Criterion 1.3.1
1.3.2: Meaningful Sequence
When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
Technique: Structure the content of web content using the appropriate markup and use the style sheets for positioning to ensure that the logical order of content is maintained when tabbing through the page content.
WCAG 2.0 reference: Understanding Success Criterion 1.3.2
1.3.3: Sensory Characteristics
Instructions do not rely on components such as shape, size, visual location, orientation, or sound.
Technique: For example, a map of Australia can be accompanied by text links of states and territories so users can select either the visual representation or a text link to get to the same information.
WCAG 2.0 reference: Understanding Success Criterion 1.3.3
1.3.4: Orientation (WCAG 2.1)
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.
Technique: Toggle between portrait and landscape modes on a mobile device to confirm that content works effectively in both modes. Exceptions may include scenarios such as a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation.
WCAG 2.1 reference: Understanding Orientation
1.3.5: Identify Input Purpose (WCAG 2.1)
The purpose of each input field collecting information about the user can be programmatically determined when:
- The input field serves a purpose identified in the Input Purposes for User Interface Components section; and
- The content is implemented using technologies with support for identifying the expected meaning for form input data.
Technique: Help users better understand form inputs by attaching additional information to the identified form inputs. This allows for additional machine-processing for personalisation and other automation, such as identifying and applying familiar terms or symbols to the inputs, which may be needed for users with cognitive disabilities to use the web.
WCAG 2.1 reference: Understanding Identify Input Purpose
1.4 Distinguishable
1.4.1: Use of Colour
Colour should not be the only visual means of conveying information.
Technique: For example, if a menu item changes the link colour when it receives focus, add a border to reflect the change.
WCAG 2.0 reference: Understanding Success Criterion 1.4.1
1.4.2: Audio Control
If any audio on a Web page plays automatically for more than 3 seconds, the user should be able to either stop, pause or adjust the volume.
Technique: Always provide playback controls for audio and video files to ensure that users are in control of the playback at all times.
WCAG 2.0 reference: Understanding Success Criterion 1.4.2
1.4.3 Contrast (Minimum)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1.
Technique: Ensure that there is adequate contrast between text and its background. Most Web authoring tools will provide you with the ability to check the colour contrast.
Exceptions:
In some scenarios, the recommended contrast ratio is different, such as:
- Large text: 3:1 contrast ratio
- Incidental: not required if the picture or text is decorative
- Logotypes: not required for logos
WCAG 2.0 reference: Understanding Success Criterion 1.4.3
1.4.4 Resize text
Text can be resized without assistive technology up to 200 percent.
Technique: Use relative font sizes, such as ’em’ or ‘%’, rather than ‘px’ or ‘pt’.
WCAG 2.0 reference: Understanding Success Criterion 1.4.4
1.4.5 Images of Text
Text should be used to convey information rather than images of text.
Technique: Markup text for a visual presentation instead of using an image to display text.
Exceptions:
- Where a particular presentation is essential to the information being conveyed e.g. Logos.
- The image of text can be visually customised to the user’s requirements.
WCAG 2.0 reference: Understanding Success Criterion 1.4.5
1.4.10: Reflow (WCAG 2.1)
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
- Vertical scrolling content at a width equivalent to 320 CSS pixels;
- Horizontal scrolling content at a height equivalent to 256 CSS pixels.
Except for parts of the content which require two-dimensional layout for usage or meaning.
Technique: Ensure that your web content uses responsive design principles so that the content can be viewed on both a small and large screen.
WCAG 2.1 reference: Understanding Reflow
1.4.11: Non-text Contrast (WCAG 2.1)
The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent colour(s):
- User Interface Components: Visual 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 Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
Technique: Ensure that active user interface components such as controls) and meaningful graphics are distinguishable by people with moderately low vision.
WCAG 2.1 reference: Understanding Non-text Contrast
1.4.12: Text Spacing (WCAG 2.1)
In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
- Line height (line spacing) to at least 1.5 times the font size;
- Spacing following paragraphs to 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.
Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.
Technique: Confirm that if text spacing properties are overridden, the text can still be read.
WCAG 2.1 reference: Understanding Text Spacing
1.4.13: Content on Hover or Focus (WCAG 2.1)
Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:
- Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
- Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
- Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.
Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.
Technique: Ensure that if content such as a navigation menu is opened by hover or focus, that the user has control as to when that menu disappears.
WCAG 2.1 reference: Understanding Content on Hover or Focus
2.1 Keyboard Accessible
2.1.1: Keyboard
All functionality of the content is operable through a standard keyboard interface.
Technique: Tab through web content to ensure it is accessible by keyboard
WCAG 2.0 reference: Understanding Success Criterion 2.1.1
2.1.2: No Keyboard Trap
Navigation by keyboard should not result in a user losing navigation functionality due to inaccessible content.
Technique: Tab through the web content to see if a point is reached where a user cannot tab or back-tab through content.
WCAG 2.0 reference: Understanding Success Criterion 2.1.2
2.1.4: Character Key Shortcuts (WCAG 2.1)
If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:
- Turn off: A mechanism is available to turn the shortcut off;
- Remap: A mechanism is available 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 for a user interface component is only active when that component has focus.
Technique: Ensure that shortcuts used in web content do not interfere with shortcuts used by assistive technologies.
WCAG 2.1 reference: Understanding Character Key Shortcuts
2.2 Enough Time
2.2.1: Timing Adjustable
If a time limit is set, users should be able to do one of the following:
- turn it off;
- adjust it to a maximum of 10 times more than originally specified;
- extend it easily after warning the user.
Technique: Provide an option for the user to add additional time, such as ‘+5 minutes’ so that people with disability can take longer to complete the required task.
Exceptions:
- the time limit is part of a real-time event;
- extending the time would ruin the purpose of the activity; or
- the time limit is already longer than 20 hours.
WCAG 2.0 reference: Understanding Success Criterion 2.2.1
2.2.2: Pause, Stop, Hide
Controls for pausing, stopping or hiding content should be available if:
- moving, blinking, or scrolling starts automatically, lasts more than 5 seconds and is presented with other content; or
- auto-updating information starts automatically and is presented in parallel with other content.
Technique: Provide appropriate and accessible controls or keyboard shortcuts to allow users to pause movement or scrolling of content.
WCAG 2.0 reference: Understanding Success Criterion 2.2.2
2.3 Seizures and Physical Reactions
2.3.1: Three Flashes or Below Threshold
Nothing on the site should flash more than three times a second, unless it is below the general flash and red flash thresholds.
Technique: Avoid animations that flash rapidly.
WCAG 2.0 reference: Understanding Success Criterion 2.3.1
2.4 Navigable
2.4.1: Bypass Blocks
A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.
Technique: Add a ‘skip to content’ link and ARIA landmarks.
WCAG 2.0 reference: Understanding Success Criterion 2.4.1
2.4.2: Page Titled
Web pages must have descriptive titles.
Technique: Add concise and meaningful titles that accurately describe the content of a page. A common practice is to use a name of an organisation and the main heading on a particular page.
WCAG 2.0 reference: Understanding Success Criterion 2.4.2
2.4.3: Focus Order
If a sequential order is important for the context of the page, make sure that components are structured sequentially.
Technique: When creating forms, ensure that the tab order matches the order in which the form fields should be accessed.
WCAG 2.0 reference: Understanding Success Criterion 2.4.3
2.4.4: Link Purpose (In Context)
The purpose of each link can be determined from the link text alone or from the programmatic context of the link.
Technique: Keep links descriptive and avoid phrases like ‘click here’ or ‘read more’.
WCAG 2.0 reference: Understanding Success Criterion 2.4.4
2.4.5 Multiple Ways
More than one way is available to locate a Web page within a set of Web pages.
Technique: Use a combination of breadcrumbs, a site map and a search to allow users to locate pages in ways that best suit their needs.
WCAG 2.0 reference: Understanding Success Criterion 2.4.5
2.4.6 Headings and Labels
Headings and labels describe topic or purpose.
Technique: Write meaningful headings that accurately describe the content and relationships between its different parts. People who are blind or vision impaired rely on having headings read out by screen readers to scan the content of the page, and for navigation.
WCAG 2.0 reference: Understanding Success Criterion 2.4.6
2.4.7 Focus Visible
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
Technique: Ensure that there is a visual indication (e.g. a border) of where the keyboard focus is on the screen.
WCAG 2.0 reference: Understanding Success Criterion 2.4.7
2.4.11 Focus Not Obscured
Focused components are not entirely hidden by author-created content.
Technique: Avoid situations where keyboard focus moves behind page content such as modal windows and cookie notification banners. Where content can be repositioned by the user, testing should only consider the initial position of the content.
WCAG 2.2 reference: Understanding Success Criterion 2.4.11
2.5 Input Modalities
2.5.1: Pointer Gestures (WCAG 2.1)
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.
Technique: Confirm that core functionality that requires multiple clicks with a mouse or touchscreen taps can also be completed in one action.
WCAG 2.1 reference: Understanding Pointer Gestures
2.5.2: Pointer Cancellation (WCAG 2.1)
For functionality that can be operated using a single pointer, at least one of the following is true:
- No Down-Event: The down-event of the pointer is not used to execute any part of the function;
- Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
- Up Reversal: The up-event reverses any outcome of the preceding down-event;
- Essential: Completing the function on the down-event is essential.
Technique: In a scenario such as a button that can be clicked or tapped on a touchscreen, ensure that the activation of a selection can also be deactivated or undone.
WCAG 2.1 reference: Understanding Pointer Cancellation
2.5.3: Label in Name (WCAG 2.1)
For user interface components with labels that include text or images of text, the name contains the text that is presented visually.
Technique: Confirm that the visible text labels of controls match their accessible name.
WCAG 2.1 reference: Understanding Label in Name
2.5.4: Motion Actuation (WCAG 2.1)
Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:
- Supported Interface: The motion is used to operate functionality through an accessibility supported interface;
- Essential: The motion is essential for the function and doing so would invalidate the activity.
Technique: If motion is used as part of a web content experience, provide an alternative way for that activity to be completed for users that are unable to easily move the device in use.
WCAG 2.1 reference: Understanding Motion Actuation
2.5.7 Dragging Movements
A single-pointer alternative for dragging movements is provided, except where the dragging movement is essential.
Technique: Take care when creating interactive content such as embedded maps with panning functionality. In order to conform to this criterion, the alternative provided should be operable using a single pointer, meaning keyboard alternatives are not sufficient (although they may be required for conformance with 2.1.1 Keyboard).
WCAG 2.2 reference: Understanding Success Criterion 2.5.7
2.5.8 Target Size
The size of the target for pointer inputs is at least 24×24 CSS pixels. Exceptions include targets inline with text, targets with a conforming equivalent control provided elsewhere on the same page, targets that are required to be presented in a particular way and undersized targets where a 24 CSS pixel diameter circle centred on the bounding box of the control does not overlap with similar circles for other undersized targets or the pointer targets for other components.
Technique: Avoid tightly-spaced small pointer targets or provide a conforming equivalent.
WCAG 2.2 reference: Understanding Success Criterion 2.5.8
3.1 Readable
3.1.1: Language of Page
The default human language of a Web page can be programmatically determined.
Technique: Add language declaration to the markup of the page.
WCAG 2.0 reference: Understanding Success Criterion 3.1.1
3.1.2 Language of Parts
The human language of each passage or phrase in the content can be programmatically determined.
Technique: Use the lang attribute to indicate that the default language of a web page has changed, e.g. when quoting a foreign language phrase.
WCAG 2.0 reference: Understanding Success Criterion 3.1.2
3.2 Predictable
3.2.1: On Focus
When a page component receives focus, it should not initiate a change of context.
Technique: Do not launch pop-up windows on mouse or keyboard focus.
WCAG 2.0 reference: Understanding Success Criterion 3.2.1
3.2.2: On Input
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the change.
Technique: Provide a submit button to initiate a change of context. For example, if a drop-down box is used to select an option, do not take the use immediately to their choice but rather use a ‘submit’ button so the user can confirm their choice.
WCAG 2.0 reference: Understanding Success Criterion 3.2.2
3.2.3 Consistent Navigation
Navigation items that are repeated on each Web page should occur in the same relative order on each page, unless an item is selected by a user.
Technique: Keep Web page menus consistent in appearance, location and function.
WCAG 2.0 reference: Understanding Success Criterion 3.2.3
3.2.4 Consistent Identification
Components that have the same functionality within a set of Web pages are consistently identified.
Technique: Ensure that identical functions or page components have consistent labels throughout the website. For example, do not interchange between ‘Western Australia and ‘WA’.
WCAG 2.0 reference: Understanding Success Criterion 3.2.4
3.2.6 Consistent Help
Any of the following help mechanisms must be positioned consistently relative to other page content when they are repeated across multiple web pages in a set:
- Human contact details;
- A Human contact mechanism;
- A Self-help option;
- A fully automated contact mechanism.
Technique: Ensure that help mechanisms are positioned in a similar location across all web pages in a set.
WCAG 2.2 reference: Understanding Success Criterion 3.2.6
3.3 Input Assistance
3.3.1: Error Identification
If an input error is automatically detected, the item and its error should be described in text.
Technique: Notify a user when they’ve made an error in filling out a form.
WCAG 2.0 reference: Understanding Success Criterion 3.3.1
3.3.2: Labels or Instructions
Labels or instructions are provided when content requires user input.
Technique: Provide descriptive labels and expected data format and examples for form fields.
WCAG 2.0 reference: Understanding Success Criterion 3.3.2
3.3.3 Error Suggestion
If an input error is automatically detected, provide suggestions for corrections to the user.
Technique: Add an error message on e-mail address field that appears when a wrong format is used; suggest the correct format of username@domain.
WCAG 2.0 reference: Understanding Success Criterion 3.3.3
3.3.4 Error Prevention (Legal, Financial, Data)
For Web pages that require legal commitments or for financial transactions, the user must be allowed to:
- cancel or reverse the submission;
- correct errors identified by the system;
- review information before proceeding.
Technique: Provide users with an option to reverse actions, and an opportunity to review and correct mistakes that could result in serious consequences.
WCAG 2.0 reference: Understanding Success Criterion 3.3.4
3.3.7 Redundant Entry
Information previously entered by or provided to the user should be auto-populated or available for selection in subsequent steps, except when re-entering is essential for security or if the previously entered information is no longer valid.
Technique: Avoid requiring users to input the same data multiple times in the same process.
WCAG 2.2 reference: Understanding Success Criterion 3.3.7
3.3.8 Accessible Authentication
Cognitive function tests should not be required, such as remembering a password or solving a puzzle, unless:
- An alternative process that doesn’t require a cognitive function test is available
- Mechanisms, like a password manager, are provided to assist users in completing the test
- The test involves recognising objects.
- The test involves recognising non-test content previously provided by the user.
Technique: This criterion can usually be satisfied by allowing users to paste credentials from a password manager. Any CAPTCHA puzzles required by the authentication process should provide an option that does not require a cognitive function test or meets an exception.
WCAG 2.2 reference: Understanding Success Criterion 3.3.8
4.1 Compatible
4.1.1: Parsing
In content implemented using mark-up languages, elements have complete start and end tags, nested correctly, no duplicate attributes, and unique IDs. Please note that this criterion is not included in 2.2 and is considered satisfied for any content using HTML or XML.
Technique: Ensure that web content validates correctly.
WCAG 2.0 reference: Understanding Success Criterion 4.1.1
4.1.2: Name, Role, Value
For all user interface components, such as form elements, links and components generated by scripts, the name and role are available to user agents such as assistive technologies.
Technique: If you are scripting your own form components, rather than using standard HTML, make sure that the focus state of a form controls can be programmatically determined.
WCAG 2.0 reference: Understanding Success Criterion 4.1.2
4.1.3: Status Messages (WCAG 2.1)
In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
Technique: If a status message appears in content such as prompting the user to enable their location, ensure that assistive technologies are able to access this content.
WCAG 2.1 reference: Understanding Status Messages