Perceivable

Users must be able to perceive the content.

Text alternative for non-text content such as images and charts, captions and other alternatives for video should be provided, and content should be adaptable by the user to fit their requirements.

Criteria

Text Alternatives

1.1.1 - Non text content

Time based media

1.2.x - Alternatives for audio and video

Adaptable

Distinguishable

Text Alternatives

1.1.1 - Non Text content

Level A

All non-text content like images, charts, icons and infographics, must have an appropriate text equivalent. This ensures that information conveyed by non-text content is available to people who cannot see it, like screen reader users.

The exception to this is decorative images which should not be described or announced to screen reader users.

Understanding Success Criterion 1.1.1: Non-text Content

How to implement

All images must have an alternative text description that describes its meaning, not what the image is:

  • images that communicate information (for example icons and logos) have short text descriptions
  • editoral images that support the text around them have short descriptions
  • images that communicate complex information (for example infographics and diagrams) have longer text descriptions within the same page
  • charts or graphs contain the same data in a corresponding table
  • decorative images have the null (or empty) alternative description alt="" (no space between the quotations)

You can use the W3C alt decision tree to help you with determining whether to use alt text or not on images.

Example: The image is editorial 

<img src='/path-to-image/filename.png' alt='A child in a classroom sitting at a desk listening to a teacher talk' />

Example: The image is purely decorative, like a background pattern or non-functional icon

<img src='/path-to-image/background-pattern.png' alt='' />

How to test

  • identify images on the page, right click on them and select ‘Inspect’
  • check the image tag to see if the alt attribute exists
  • for decorative images, the alt attribute should be alt="" or just alt
  • for editoral images and images which communicate information check that the descriptions are appropriate
  • for images of complex information, check that the description refers to the availabiltiy of a longer description and that this is present on the page

How to test with JAWS

Use the G key to navigate to the images on the page and check that a meaningful textual description is read out for informative images, and that decorative images are not announced.

How to test with VoiceOver

With VoiceOver (VO) turned on, use the command VO + command + G to navigate through images on the page and check that a meaningful textual description is read out for informative images, and that decorative images are not announced.

Guidance for using VoiceOver on Mac and iPhone to navigate pages and content

Helpful links

Time based media

1.2.x - Alternatives for audio and video

Level A Level AA

Audio and video content has appropriate alternatives to ensure that everyone has a comparable experience when interacting with this content. This may include transcripts, captions and audio description depending on the type of audio or video content.

How to implement

The alternative required depends on the context of the audio or video, but broadly:

  • always provide a transcript
  • always provide captions for videos
  • if the narration of a video does not include all the detail required, then provide audio description

Provide accessible transcripts and alternative versions of content next to the original multimedia content.

Closed Captions (where the captions are separate from the video content) should be used where the video player supports this. Captions should be checked for accuracy, especially where auto generated.

For live video content like livestreams of events, captions should be provided which are synchronised with the audio.

How to test with a visual check

If the page contains multimedia content, check that the required alternative is available.

The transcipt should be available near to the multimedia content but can be a link to another page.

If a second version of the content is available with audio description then this must be easily accessible from the non-audio described version.

Adaptable

1.3.1a - Info and relationships - Tables

Level A

When information is visually presented as a table, this structure must be conveyed appropriately to assistive technologies. This ensure that tables are available to screen reader, screen magnification and speech recognition tool users.

Where possible, you should use semantic HTML to implement content structures.

Understanding Success Criterion 1.3.1: Info and Relationships

How to implement

Tabular data is presented using proper HTML markup (<table>, <tr>, <th>, and <td> elements).

Tables include a <caption> element which summarises the overall purpose of the table.

Avoid creating complex tables (with multiple rows or columns of headings).

If semantic tables are not possible, as a last resort, use ARIA roles to replicate the structure of a table. This is highly complex and involves a lot of additional coding, so avoid it if you can. See https://developer.mozilla.org/en-US/docs/Web/accessibility/aRIA/Roles/Table_Role for implementation advice.

How to test

  • right click on any tables and select the ‘Inspect’ option
  • manually review the table structure to identify the presence of the correct mark up
  • note - <thead> and <tbody> are not semantic HTML and are used for formatting purposes. The only valid semantic tags are shown
  • if there are no semantic tags, check for ARIA roles related to tables. All appropriate roles, descriptions and indexes need to be available to pass this requirement

How to test with JAWS/NVDA

Use the t key to reach the tables on the page, use ctrl+alt+arrow keys to navigate the tables and check that the correct row or column headers are announced by the screen readers for each data cell.

Helpful links

1.3.1b - Info and relationships - Lists

Level A

When presenting lists of information, you must communicate this list in a way that assistive technology users can understand.

Where possible, you should use semantic HTML list options which are appropriate to the information being presented.

Understanding Success Criterion 1.3.1: Info and Relationships

How to implement

Use appropriate and proper HTML markup for lists of items:

  • ordered lists for structured data like the steps in a process (<ol> and <li>elements)
  • unordered lists for unstructured data like the ID documents required for a process (<ul> and <li>)
  • description list/definition list to group a series of key terms and their descriptions/definitions together (<dl>, <dt> and <dd>)

If semantic options are not available, use the ARIA list and listitem roles to replicate semantic structure. This is a last resort. Note: ARIA lists do not have list types - they are all just lists.

How to test

  • right click on any list of information and select the ‘Inspect’ option
  • manually review the list to ensure the appropriate list type has been used for the data and that no additional tags exist inside the list tag
  • if no semantic tags exist, check for the presence of ARIA roles relating to lists. Note that ARIA lists don’t have different types and are all just ‘lists’

How to test with JAWS/NVDA

Use the L key to reach the lists on the page and check that all content that visually and logically represents a list is announced as ‘list’; that content that does not represent a list is not announced as a list.

Helpful links

Web Accessibility Tutorials - Content Structure - Lists

1.3.1c - Info and relationships - Headings

Level A

Where visual headings are used to communicate the structure of a page, they must also be communicated in a way that supports assistive technology users to access this structure.

You should use semanatic HTML headings to structure your page. Heads should cascade from H1-H6. Each page must have at least a Level 1 Heading (H1).

Understanding Success Criterion 1.3.1: Info and Relationships

How to implement

Use proper HTML markup for headings (<h1> through <h6> elements).

Each page should have a H1 which describes the overall purpose of the page.

This should be similar to the Title of the page (see 2.4.2 - Page title).

Do not skip heading levels or use multiple H1s on a page if you can avoid it.

If you cannot use semantic headings, use the ARIA heading role and aria-level attribute to provide heading structure to the page. This is a last resort.

How to test

  • right click on any heading and select the ‘Inspect’ option
  • manually review the correct heading structure has been applied to visual headings
  • if no semantic tags exist, check for the presence of ARIA heading role and the aria-level attribute

How to test with JAWS

Use the H key to reach the headings on the page and check that all text that visually and logically represents a heading is announced as ‘heading’; that the correct level is announced for each heading; that text that does not represent a heading is not announced as a heading.

Use the JAWS Key + F6 to open the Heading List dialog. Review this to check that the heading structure matches the visual document outline

How to test with NVDA

Use the H key to reach the headings on the page and check that all text that visually and logically represents a heading is announced as ‘heading’; that the correct level is announced for each heading; that text that does not represent a heading is not announced as a heading.

Use the NVDA Key + F7 to show the elements list that should show you all the headings available on the page. Review this to check that the heading structure matches the visual document outline

Helpful links

1.3.1d - Info and relationships - Form fields

Level A

All form fields have an associated visible label. Where this isn’t possible a non-visible label must be present.

Sets of radio buttons or checkboxes must be grouped together so that assistive technology users can understand the relationship between these controls.

Where specific format or input requirements need to be met, hint text linked to the form fields is provided.

Understanding Success Criterion 1.3.1: Info and Relationships

How to implement

If you can, use the <label> tag and ‘for’ attribute to give form field elements visible labels.

Group sets of radio buttons or checkboxes using the <fieldset> tag and have an appropriate <legend> tag to label the group.

If you cannot use <fieldset> and <legend>, use the radiogroup and radio ARIA roles and associated attributes for radio buttons. Use the group and checkbox ARIA roles and associated attributes for checkboxes. This is a last resort.

Use aria-describedby to reference hint text from the form control if specific format or input requirements need to be met by users.

Ensure information on entry format isn’t given by placeholders alone and that this is available to screen reader users.

If you cannot use visible labels, follow the requirements of 4.1.2 - Name, Role, Value.

How to test with a quick check

The following quick check will show you if this requirement has been implemented. It will not necessarily show you if it’s failed. If this check doesn’t work then complete the other manual code checks.

  • click on the visible label for the form control you’re testing
  • if focus moves to the control or activates it then the control and the label are correctly associated
  • if focus doesn’t move or the control is not activated, complete further testing

How to test form elements with a manual code check

  • right click on a form element and select the ‘Inspect’ option
  • manually review the form element and check that a label has been associated with it
  • if there is a visible label start by checking the label. It should be wrapped in a <Label> tag and should have a for attribute which references the ID of the form element it labels
  • if there is no visible label or it doesn’t have a for attribute, look for aria-label or aria-labelledby on the form element
  • check that any additional hint information is linked using aria-describedby
  • check that any additional hint information is not only provided using placeholder text

How to test radio buttons or checkboxes with a manual code check

  • right click on a radio button or checkbox group and select the ‘Inspect’ option
  • manually review to identify if the group of elements are enclosed within a <fieldset> tag and the question/statement is within a <label> tag.
  • if this is missing, check for appropriate ARIA alternatives
  • check that any additional hint information is linked using aria-describedby

How to test with JAWS

Use the F key to reach all the form elements on the page and check that they have an associated label and that any hint text is read out.

Use the JAWS Key + F5 to list form fields. Review this to check that everything is labelled.

Ensure that any additional hint text is announced by the screen reader you’re using.

How to test with NVDA

Use the F key to reach all the form elements on the page and check that they have an associated label and that any hint text is read out.

Use the NVDA Key + F7 to show you a list of the form elements on the page. Review this to check that everything is labelled.

Ensure that any additional hint text is announced by the screen reader you’re using.

Helpful links

Web Accessibility Tutorials - Forms Concepts

1.3.1e - Info and relationship - Landmarks

Level A

Content sections within a page should have an appropriate HTML5 section element or ARIA landmark role defined.

Understanding Success Criterion 1.3.1: Info and Relationships

How to implement

As a minimum, you must include a main landmark (either the HTML 5 <main> or ARIA role="main") on each page.

Add extra landmarks, for example navigation and footer content, if the page has these areas.

All the section’s content or functionality must be contained within a landmark.

Where multiple landmarks of the same type are used e.g. navigation, use aria-label to add a descriptive label to the navigation area e.g. ‘Related Links’ for a secondary navigation area.

How to test

  • right click on the page and select the ‘Inspect’ option
  • review the code to ensure that the main section of the page either uses the <main> tag or has role="main"
  • check that navigation areas have either <nav> or role="navigation"
  • check that where multiple areas of navigation exist, they all have a landmark and an appropriate label

Testing with JAWS

Use the R key to get the screen readers to announce all landmarks on the page and check that the right landmark is announced for each page section (e.g. ‘main’ for the main content area).

Testing with NVDA

  • use the D key to hear all the landmarks on the page and check tha tthe right landmark is announced for each section
  • use the NVDA Key + F7 to show you the list of landmark elements on the page. Review this to check that all the required landmarks exist and that they are labelled appropriately

1.3.2 - Meaningful sequence

Level A

When the order of content is important, the content order must be preserved no matter how it is presented to the user.

This ensures that the order of content is meaningful whether someone is looking at it, listening to it with a screen reader, or has stripped out visual styling using a browser plugin.

Understanding Success Criterion 1.3.2: Meaningful Sequence

How to implement

The structure of your code should reflect the visual structure of the page.

This keeps the order of content meaningful for screen reader users, or users who have turned off visual styling.

The underlying structure must still make sense if it is different to the visual structure.

How to test with a visual check

  • to check the reading order of the page, the visual styling needs to be switched off
  • you can do this by using a simple bookmarklet like https://dorward.uk/software/disablecss or, depending on the browser, using the ‘Reading view’ option in the browser
  • you can also manually review the DOM to see how content appears
  • regardless of the method, once enabled, you should read through the linerised content to check that the reading order follows the reading order with styles enabled

Testing with JAWS/NVDA

Use the arrow keys (or insert + down arrow) to go through the whole page and check that its content is read out in a logical order.

1.3.3 - Sensory Characteristics

Level A

Instructions must not depend on sensory characteristics like shape, size, colour, or location. This ensures that instructions can be understood by users who are unable to see or recognise information communicated using sensory characteristics.

Understanding Success Criterion 1.3.3: Sensory Characteristics

How to implement

Do not rely on visual descriptions like ‘green’ or ‘below’ to communicate user instructions. For example, in ‘Press the green ‘Next’ button to continue’, the colour is supplemented by non-sensory information.

How to test with a visual check

If the page contains any instructions around where to find, or how to interact with, content on the website, check that these instructions do not rely on the ability of users to perceive shape, size, visual location or sound.

1.3.4 - Orientation

Level AA

A page view must not be locked to either horizontal or vertical views only, unless this is essential.

Understanding Success Criterion 1.3.4: Orientation

Implementation gudance

Let the user view pages in their prefeed orientation.

Use CSS to allow both landscape and portrait.

Do not try to force a specific orientation or aspect ratio.

Do not show a ‘please rotate your device’ screen at particular orientations.

As best practice, make sure content works appropriately in both landscape and portrait orientation.

How to test with a visual check on mobile

View the page on a mobile device and change the orientation.

How to test with a visual check on desktop

  • right click on the page and select ‘Inspect’
  • activate the device toolbar
  • select the ‘rotate’ option in the toolbar and observe whether the content moves into the new orientation successfully
  • resize the browser window to have a portrait or landscape aspect ration. Observe if a ‘Please rotate your device’ message is shown.

1.3.5 - Identify Input Purpose

Level AA

In an input field, the purpose of each input field that collects information about the user can be understood by assistive technologies and browsers by using autocomplete.

Understanding Success Criterion 1.3.5: Identify Input Purpose

How to implement

If a form field relates to the user’s personal information (from the set of input purposes listed at https://www.w3.org/TR/WCAG/#input-purposes), include an explicit autocomplete attribute with the relevant value.

This ensures that the purpose of the input can be programmatically determined/understood by user agents and third party tools (such as password managers).

How to test

Right click on each form field requiring information that can be suggested by the browser, select ‘Inspect’ and check that the autocomplete attribute is included in its source code and that the correct value has been given to this attribute.

Distinguishable

1.4.1 - Use of colour

Level A

Information conveyed with colour must also be identifiable from context, labelling, or alternative forms

Understanding Success Criterion 1.4.1: Use of Color

How to implement

When rendered in monochrome, information does not disappear.

Do not only use colour to indicate important content. Use a visible border and label, underline or other visual effect as well.

Do not only use colour as a key for information graphics and charts. Use distinctive non-colour differences, like patterns or directly applied labels, as well.

Underline links instead of relying on colour contrast.

How to test

If colour is used to convey information or distinguish between items, check that the same information is provided via an alternative means.

Use of colour also applies to links that aren’t underlined.

Check that all links within the content (not navigation).

Use this bookmarket to simulate colour-blind users on your webpage.

For Mac users, you can download Sim Daltonism from the App store and overlay a color blind filter to your screen.

1.4.2 - Audio control

Level A

Audio/video must not play automatically unless the user is pre-warned and can control the audio

Understanding Success Criterion 1.4.2: Audio Control

How to implement

Audio or video content that plays automatically, for example an alert sound, 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 using on screen controls.

How to test

  • listen to the page without any assistive technology running
  • ensure that any sounds that play automatically only last for 3 seconds or less
  • if a sound lasts for more than 3 seconds, check that audio controls are available

1.4.3 - Contrast

Level AA

There should be enough difference (contrast) between a background and the foreground content so that user can easily differentiate the two.

Understanding Success Criterion 1.4.3: Contrast (Minimum)

How to implement

Text, including text in images, must have a contrast ratio of at least 4.5:1 against its background colour.

Where text crosses different background colours or an image, all of the text must meet the contrast requirement.

This requirement does not include incidental text in photographs, images or illustrations.

How to test with Colour Contrast Analyser

Use the Colour Contrast Analyser to check that the contrast ratio between text and background colours is at least 4.5:1 for standard text.

How to test with developer tools

  • open developer tools in Chrome or Edge
  • use the inspector tool to highlight content
  • a tooltip will appear with contrast information. Check that it shows as pass

How to test with manual code check

  • use an online contrast checker e.g. https://webaim.org/resources/contrastchecker
  • identify the HEX values from the CSS for text and background colours
  • use the design specification for the site to identify the HEX values and use the site to check these meet or exceed the 4.5:1 requirement

1.4.4 - Resize text

Level AA

Users should be able to resize text up to 200% without any problems with the presentation and structure of the page (for example truncated text, overlaps or missing items).

Understanding Success Criterion 1.4.4: Resize text

How to implement

Avoid setting specific width and height sizes for containers if you can, so they will adapt to the size of the content they contain.

Avoid using CSS absolute positioning, as these layouts can easily end up overlapping other content or containers.

Do not disable pinch-zoom functionality on mobile/tablet devices with <meta> tags such as user-scalable=no or maximum-scale=1.

Use relative text sizing, like percent sizes, em units or named font sizes.

How to test with browser zoom

Use the Zoom functionality of the browser to enlarge the page to 200% and check that you can access all content without having to scroll horizontally. Check that changed content structures - ie burger navs can still be reached.

Common browser sizes should be used when testing. Ideally you should test at 1024x768, 1280x1024 and 1920x1080 to cover the most common layouts for desktop.

How to test with browser settings

Use the settings within a browser to resize text without zooming

How to test on mobile/tablet

Check that you can pinch/zoom on a mobile/tablet device.

How to test

Inspect the page code to see if <meta name="viewport"> includes code which blocks user pinch/zoom control such as user-scalable=no or maximum-scale=1

1.4.5 - Images of text

Level AA

Meaningful text must not be presented as part of an image because it cannot be resized, it deteriorates in quality when magnified and is not customisable by the end user.

Meaningful text is anything which is used to aid understanding for users.

Understanding Success Criterion 1.4.5: Images of Text

How to implement

Do not use images for meaningful text that gives users information. Text in some types of images, like SVGs, can resize without deterioration, but cannot be customised. As a result no images of text are allowable.

How to test with browser settings

Turn images off and check that no text disappears

How to test

Select all the text on the page - any images of text will not be selectable

1.4.10 - Reflow

Level AA

Users should be able to magnify the page up to 400% and content should reflow - move into one column - and not add horizontal scroll bars (exemptions apply).

Content should not be cut off or omitted entirely when magnified.

Understanding Success Criterion 1.4.10: Reflow

How to implement

Make sure your pages are responsive, so the content will ‘reflow’ to a single column gracefully.

There are a small number of exemptions for this requirement:

  • Maps and diagrams where scrolling is necessary to understand content, or where stacking information would change the meaning
  • Complex tables with many columns (although individual cells must not scroll).

How to test with browser zoom

Use the Zoom functionality of the browser to enlarge the page to 400% and check that you can access all content without having to scroll horizontally.

Note the exemptions to this requirement in implementation advice.

1.4.11 - Non text contrast

Level AA

Interactive controls, keyboard focus, icons and content required for understanding e.g. charts and infographics must have enough contrast (at least 3:1) with adjacent colours.

Understanding Success Criterion 1.4.11: Non-text Contrast

How to implement

Buttons or other inputs and controls must have a contrast ratio of 3:1 or higher in all their states.

Parts of graphical objects, like icons, that convey information must have a minimum contrast ratio of 3:1 with adjacent colours.

The keyboard focus must meet colour contrast requirements and be easy to identify.

How to test with Colour Contrast Analyser

Use the Colour Contrast Analyser to check that

  • the contrast ratio between each informative object within icons and its suounding colours is at least 3:1
  • the contrast ratio between the border and focus indicator of form fields and buttons/links and the background colour is at least 3:1

How to test

  • Use an online contrast checker e.g. https://webaim.org/resources/contrastchecker
  • Identify the HEX values from the CSS for outline styles and states and input these into the colour contrast checker
  • Use the design specification for the site to identify the HEX values and use the site to check these meet or exceed the 3:1 requirement

1.4.12 - Text spacing

Level AA

For regular HTML page content, no loss of content or functionality happens when a user changes line height, letter or word spacing.

Understanding Success Criterion 1.4.12: Text Spacing

How to implement

Make sure your CSS lets users adjust:

  • 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

Users should be able to adjust text spacing without breaking layouts, overlapping elements or problems seeing content.

How to test with a visual check

Use the Text Spacing Bookmarket (drag to bookmarks bar or right click and save as bookmark) to test text spacing on a webpage.

1.4.13 - Content on hover or focus

Level AA

Ensuring that extra content eg tooltips:

  • can be viewed easily
  • don’t cover up key content
  • can be dismissed without moving focus or hover
  • can be hovered over (i.e. it doesn’t disappear if you move the mouse)
  • is persistent and doesn’t disappear until the user moves focus / hover away

Understanding Success Criterion 1.4.13: Content on Hover or Focus

How to implement

Position the additional content so that it does not obscure any other content, including the trigger. This does not include white space and purely decorative content, such as a background graphic which provides no information.

Provide an easy way to dismiss the additional content, such as by pressing Escape or selecting a close button.

The additional content should stay on screen until dismissed by the user.

The additional content should stay on screen if the user hovers over it.

How to test using a visual check

When new content appears on mouse over or on keyboard focus complete the following checks:

  • check that you can dismiss the new content by pressing the Esc key or a close button
  • check that you can move the mouse pointer to the new content
  • check that the new content does not disappear until you move the mouse pointer or keyboard focus to the next item on the page
Information about this page
Created
18 July 2024
Last reviewed
18 July 2024
Last updated
18 July 2024
Reason this page exists
This page exists to help people understand each of the WCAG Criteria
Suggest a change or comment
Issue