Sound file must have a text transcript.

Does the audio file have a text transcript?

Check that any linked audio files on this page have a text transcript available for users. Without a transcript, people who are deaf or hard of hearing, or anyone who can’t play the audio, will miss the information in the audio file.

Anchor should not open new window without warning.

Does the anchor element open a new window without warning?

Check if anchor links open a new window or tab without letting users know in advance. Unexpectedly opening new windows can be confusing or disruptive, especially for people using screen readers or keyboard navigation. If a link opens a new window, make sure this is clearly indicated. For example: “Opens in a new window.”

Links to multimedia require a text transcript.

Is there a text alternative for the multimedia file?

Verify that any linked audio or video files have a text alternative, such as a transcript or captions. Without text alternatives, people who are deaf, hard of hearing, or cannot access multimedia content will miss important information.

<code>blink</code> element is not used.

Blinking text must not be used

The <blink> element should not be used because blinking text can trigger seizures or headaches in some users, and it is difficult for people with vision or cognitive disabilities to read.

<code>area</code> link to sound file must have text transcript.

Is there a text alternative for the linked audio file?

Check that any audio files linked through image maps or clickable areas provide a text transcript. Without a transcript, users who are deaf or hard of hearing, or anyone unable to play audio, will miss the information.

<code>marquee</code> element is not used.

Marquee element must not be used

The <marquee> element should not be used because moving text can be distracting and hard to read, especially for users with cognitive or vision disabilities. Marquees can also cause accessibility problems for users who rely on screen readers or have motion sensitivity, making your content less accessible and harder to understand.

Auto-redirect must not be used.

Auto-redirect must not be used

Automatic redirects using the <meta http-equiv="refresh"> element should not be used, as they can unexpectedly move users away from the page without warning. This can be confusing for all users and especially problematic for those using screen readers or with cognitive disabilities, making navigation unpredictable and difficult.

All <code>p</code> elements are not used as headers.

Are p elements used as headers?

Review the page to see if any paragraphs are being styled to look like headings using bold, italics, underline, or font changes instead of real heading tags (like <h1>, <h2>, etc.). Using proper heading tags is important for screen reader users and helps everyone navigate content more easily.

All layout <code>tables</code> have an empty <code>summary</code> attribute or no <code>summary</code> attribute.

Layout tables should have an empty summary attribute or none at all

Adding unnecessary summaries to layout tables can confuse assistive technology users, making it harder to understand the actual structure and purpose of the content.

All layout tables do not contain <code>caption</code> elements.

Layout tables must not contain caption elements

Using captions in layout tables can mislead assistive technology users by making non-data tables appear to contain important tabular information.

<code>pre</code> element should not be used to create tabular layout.

Is the pre element used to create a table?

Check whether the <pre> tag is being used to display data in a table or columns. Using <pre> for layout makes it difficult for screen readers and other users to understand and navigate the data. If the content represents a table, use proper HTML table markup (<table>, <tr>, <td>) to ensure it’s accessible to everyone.

All data table summaries describe navigation and structure of the table.

Is the data table summary describing the navigation and structure of the table?

Review each data table to ensure the summary text clearly explains how to navigate and understand the table’s structure. The summary should not be random or meaningless, but help screen reader users know what information the table presents and how it’s organized.

Table markup is used for all tabular information.

Is table markup used for all table information consistently?

Check that all data presented in a table or grid format is marked up using proper HTML table elements (<table>, <tr>, <th>, <td>). This ensures that screen readers and other assistive technologies can accurately convey relationships between data.

Table captions identify the table.

Are the table captions identifying the table?

Verify that each table caption clearly describes what the table is about. Captions should help users, including those using screen readers, understand the purpose or subject of the table at a glance.

Table summaries do not duplicate the table captions.

Table summary and caption must be different

The caption is meant to identify the table, while the summary provides additional details about its contents for users, especially those relying on assistive technology.

Data tables that contain more than one row/column of headers use the <code>id</code> and <code>headers</code> attributes to identify cells.

Complex data table is missing ID and/or header attributes to associate headers with data cells

ID and header attributes are needed to properly link table headers to their corresponding data cells. Without these attributes, screen readers cannot accurately communicate relationships in the table, making it difficult for users to understand the data structure.

All visual lists are marked.

Are all visual lists correctly coded as lists?

Make sure that any content presented visually as a list, like bullet points or numbered items, is marked up with proper HTML list tags (<ul>, <ol>, <li>). This helps screen reader users and others easily understand and navigate listed information.

Sensory Characteristics.

Are enough instructions provided for everyone to understand and operate the content?

Review any instructions given on the page to ensure they don’t rely only on things like color, shape, size, or sound. Make sure all users, including those who are colorblind or use screen readers, can follow the instructions without missing important details.

The luminosity contrast ratio between text and background color in all images is at least 4.5:1.

Does text over background image meet minimum contrast requirements?

Check that any text placed on top of a background image is easy to read and stands out clearly (Contrast should be minimum 4.5:1 for normal text, 3:1 for large text). Insufficient contrast makes it hard for users, especially those with low vision or color blindness, to see and understand the information.

The luminosity contrast ratio between text and background color in all images is at least 7:1.

Does text over background image meet enhanced contrast requirements?

Verify that any text placed on a background image has a strong, high-contrast color combination (minimum 7:1 for normal text, 4.5:1 for large text). Enhanced contrast ensures that even users with low vision or color blindness can easily read and understand the text, providing an even higher standard of accessibility.

Information deleted using a web page can be recovered.

Can users recover deleted information?

Make sure users have a way to restore or undo deleted information. This helps prevent serious problems if someone removes content by mistake, especially for users who may find it harder to correct errors.

Logical focus order.

Are elements focused in a logical order when navigating with keyboard?

Test keyboard navigation to ensure that focus moves through the page in a sequence that matches the intended reading and interaction order. If focus jumps around unpredictably, it can confuse users and make the site difficult or impossible to use, especially for those relying on a keyboard and assistive technology.

The visual presentation of UI and graphics components have a contrast ratio of at least 3:1 against adjacent color(s).

Are important UI and graphical components distinguishable?

Ensure that buttons, controls, and key graphics stand out clearly against their backgrounds with enough color contrast (at least 3:1). Good contrast helps everyone and especially users with low vision, easily find and use important parts of the interface.

The purpose of User Interface Components icons and regions can be programmatically determined.

Is the purpose of UI components, icons, and regions programmatically determined?

Verify that interactive elements like buttons, icons, and content regions are coded so their purpose can be identified by assistive technologies (such as screen readers). Proper labeling and use of semantic HTML or ARIA attributes help all users understand and interact with these elements.

Scrolling in more than one direction is not necessary for small displays and zoomed content.

Are users forced to scroll in two dimensions when zoomed in?

Check that when the page is zoomed in or viewed on a small screen, users only need to scroll in one direction (usually up and down) to access all content. If both horizontal and vertical scrolling are required just to read or use the site, it can be difficult, especially for people with low vision or mobility impairments.

No loss of content or functionality occurs when changing certain text style properties.

Are users able to use the fonts, spacing, and font size of their choice, without loss of content?

Make sure that increasing font size, line spacing, or letter/word spacing does not cause content to overlap, disappear, or become unusable. Users should be able to personalize text settings for better readability without breaking the layout or hiding information.

Additional content that appears and disappears in coordination with keyboard focus or pointer hover does not obstruct operation.

Does content that appears on hover or focus block important information or disappear before users can interact with it?

Review any tooltips, popups, or menus that appear when hovering with a mouse or focusing with the keyboard. Make sure they don’t cover up other important content, disappear before users can interact with them, or become hard to dismiss. This ensures everyone, including keyboard and screen reader users, can access all information.

Users are warned of the duration of any user inactivity that could cause data loss.

Are users warned if inactivity could cause them to lose work?

Check that users receive a clear notification if their session will expire or if unsaved information might be lost after a period of inactivity. This helps prevent accidental data loss, especially for users who may need more time to complete tasks.

Motion animation triggered by interaction can be disabled unless the animation is essential to the functionality or the information being conveyed.

Can users turn off motion animation triggered by interaction?

Make sure that users can disable motion animations that play when they interact with elements, unless those animations are essential for understanding or using the content. This helps people who are sensitive to motion use your site comfortably.

Functionality that can be operated by device motion or user motion can be disabled to prevent accidental actuation.

Are there alternatives for features that require device or user motion?

Check that any actions triggered by device movement (like shaking, tilting, or gesturing) can also be performed using buttons or other interface controls—and that users have a way to turn off motion activation. This prevents accidental triggers and ensures everyone can use the feature, regardless of their device or abilities.

Previously entered information is available afterwards.

Is information the user previously entered automatically available when needed in later steps of the process?

Make sure that any information a user has already entered or provided for instance in a form is automatically filled in or easy to select when needed again in later steps of a process. This saves time and reduces errors, especially for users who may have difficulty re-entering information.

Authentication Form is accessible for cognitively challenged people.

Is a congnitive function test required for authentication?

Review the login process to see if users are required to perform tasks that demand significant memory or problem-solving, like recalling complex passwords or answering riddles. Ensure there is an alternative method for logging in that doesn’t require strong memorization skills, such as allowing users to paste their password or use another authentication option. Without alternatives, users with cognitive disabilities or memory difficulties may be unable to log in, blocking access.

Available help is consistently easy to find.

Is available help easy to find?

Look for any help or support options provided on the page and make sure they are always in the same place throughout the site. If help is hard to locate or its position changes from page to page, users may struggle to get assistance when they need it, especially those with cognitive or visual disabilities.

Pointer-interactive elements such as linked icons must be easy to target.

Are interactive elements big enough to target easily?

Check that buttons, links, and clickable icons are large enough, at least 44x44 pixels, so they can be easily tapped or clicked, even by people with limited dexterity or on touch screens. Small targets can be difficult or frustrating to use and may cause errors, especially on mobile devices.

Any dragging movements required for functionality must have a proper alternative.

Does functionality requiring dragging movements have a proper alternative?

If users need to drag something (like a slider or item) to perform an action, make sure there’s another way to do the same thing, such as clicking, tapping, or using the keyboard. This ensures that people who can’t easily drag, such as those using assistive technologies or with limited mobility, can still use all features of your site.

Scrolling in more than one direction is not necessary for display on mobile phones.

Do users need to scroll in two dimensions on mobile?

Check the page on a mobile device to ensure users only need to scroll either vertically (up and down) or horizontally (side to side), to read or interact with content. Requiring both directions of scrolling can be frustrating and difficult for users on small screens or with mobility challenges.

Audio Control.

Are users able to shut off content with sound?

Check if any audio or video that plays for more than three seconds has an obvious and accessible control to pause or stop the sound. Without this, users, especially those with visual impairments or who use screen readers, can be distracted or unable to focus on other content.

Authentication Form is accessible for cognitively challenged people (enhanced criterion).

Is a cognitive function test required for authentication? (Enhanced)

Check whether users must solve memory-based tasks, like recalling a password or answering riddles, to log in. If such steps are required, be sure there is an accessible alternative, so that users with cognitive disabilities can log in without barriers.

Interface components receiving focus are not entirely hidden.

Are all focusable elements at least partially visible when focused?

When you tab through the page, make sure that every button, link, or form field stays visible when it receives keyboard focus. If part of the screen, for instance a chat widget, covers a focused element, users relying on keyboard navigation may not know where they are or what they’re interacting with.

No part of interface components receiving focus is hidden.

Are all focusable elements entirely visible when focused?

When you tab through the page, make sure that every button, link, or form field stays entirely visible when it receives keyboard focus. If part of the screen, for instance a chat widget, covers a focused element, users relying on keyboard navigation may not know where they are or what they’re interacting with.

Focus Appearance meets the criteria for conformance.

Is the focus indicator distinguishable?

When you use the keyboard to navigate, ensure that a clear, visible outline or highlight appears on the focused element, standing out from the background and nearby content. A strong focus indicator helps keyboard users know exactly where they are on the page, preventing confusion or navigation errors.

Element with role attribute has required states and properties

Element with role attributes is missing required states or properties

Elements that have a specific role should have ARIA states or properties that go with that role. Without the right states and properties, assistive technologies may not present the element’s purpose or status correctly to users.

Form field has non-empty accessible name

Form field is missing an accessible name

Form fields must have accessible names. Without a clear label or name, screen reader users may not understand what information is required, making it hard or impossible to complete the form.

Menuitem has non-empty accessible name

Menu item doesn't have an accessible name

Menu items must have accessible names. Without an accessible name, users of screen readers or other assistive technologies cannot identify or navigate the menu option effectively.

Element with aria-hidden has no content in sequential focus navigation

Element marked as hidden must not be included in tab navigation

Elements marked as hidden with aria-hidden="true" must not be included in keyboard tab navigation. If hidden elements are accessible by keyboard or assistive technology, it can confuse users and disrupt smooth navigation.

iframe elements with identical accessible names have equivalent purpose

Do the iframe elements with same name have same purpose?

Check that all iframes that share the same accessible name actually serve the same function or display similar content. Using the same name for different purposes can confuse users, especially those using assistive technology, by making it unclear what each iframe is for.

Link has non-empty accessible name

Link is missing an accessible name

Without a clear, descriptive name, users may not know where the link goes or what it does.

Iframe element has non-empty accessible name

Iframe element is missing an accessible name

Without an accessible name, users of screen readers won’t know the purpose or content of the embedded frame, making navigation and understanding more difficult.

Element with presentational children has no focusable content

Elements intended as presentation-only contain focusable content

When elements are marked as presentational but contain focusable items like links or buttons, users of assistive technology may encounter interactive elements that aren’t announced or expected.

Button has non-empty accessible name

Button is missing an accessible name

Without a descriptive name, screen reader users won’t know the purpose or function of a button.

SVG element with explicit role has non-empty accessible name

SVG element with defined role is missing an accessible name

Without an accessible name, users of assistive technologies won’t know what the graphic represents or its purpose.

Image has non-empty accessible name

Image is missing alternative text

Without alternative text, users of screen readers won’t know what the image shows or if it’s important.

<code>object</code> element rendering non-text content has non-empty accessible name

Non-text object element is missing an accessible name

A non-text <object> element, such as an embedded chart, video, or interactive feature, is missing an accessible name. Without a descriptive name, users of assistive technology won’t know what this embedded content is or what information or functionality it provides.

Image not in the accessibility tree is decorative

Are the hidden images decorative?

Review any images, SVGs, or canvases that are hidden from assistive technologies to make sure they are purely decorative. Hiding meaningful images can prevent users with disabilities from accessing important information or context.

Image accessible name is descriptive

Is the image alternative text descriptive enough?

Ensure that each image’s alt text or accessible name clearly describes its purpose or meaning. If the description is too vague or generic, users who rely on screen readers may not understand the image's relevance or intent.

Image button has non-empty accessible name

Image button is missing an accessible name

Without a clear name, users of screen readers won’t know what the button does or how to use it.

Use of Color

Is color alone used to convey meaning?

Check that color isn’t the only way information, actions, or differences are shown on the page. Make sure there are also text labels, symbols, or patterns, so everyone, including people with color blindness, can understand and use the content.

All functionality of the content is operable through a keyboard interface

Can all functionality be operated with keyboard?

Go through the site using only the keyboard (Tab, Enter, arrow keys) and ensure that every feature like links, buttons, forms, and menus can be accessed and used without a mouse. This ensures that users who rely on keyboard navigation, including those with mobility impairments, can fully interact with all parts of the site.

Scrollable content can be reached with sequential focus navigation

Scrollable content is not accessible using the keyboard

When scrollable content can’t be accessed or scrolled using the keyboard or assistive technology, users may find it difficult or impossible to interact with the content.

Iframe with interactive elements is not excluded from tab-order

Iframe with interactive elements is not keyboard navigable

When an iframe contains interactive elements, users navigating with keyboard or assistive technology need to be able to reach the important features within the frame. This does not happen if the element is excluded from sequential focus navigation.

Scrollable content can be reached with sequential focus navigation

Scrollable content is not accessible using the keyboard (No exception)

Users must be able to access scrollable content using the keyboard, with no exceptions allowed. When scrollable content is not accessible, keyboard-only and assistive technology users are not able to reach and interact with the content.

Keyboard Trap

Is keyboard focus trapped in any component?

As you navigate the site with the keyboard, make sure you can move freely in and out of all components (like modals or menus). If focus gets stuck and you can’t tab away, users relying on keyboards or assistive technologies might be unable to use or exit that part of the site.

HTML page has non-empty title

Page is missing a title

Without a title, users, especially those using screen readers or with multiple browser tabs open, may not know what the page is about or easily find it.

HTML page title is descriptive

Is the page title descriptive enough?

Look at the page’s title and make sure it clearly describes what the page is about. A descriptive title helps users, especially those using screen readers or switching between multiple tabs, quickly understand the page’s purpose and find the information they need.

Element in sequential focus order has visible focus

Is the keyboard focus visible at all times?

As you navigate through the page using the keyboard, make sure elements receive a clear outline or highlight is always visible on the currently focused element. This helps users know exactly where they are and prevents them from getting lost while using the site.

Heading is descriptive

Is the heading descriptive enough?

Review each heading and make sure it clearly explains the topic or purpose of the section that follows. Descriptive headings help all users, including those using screen readers, easily navigate and understand the structure of your content.

Each label describes its associated <code>input</code> element.

Are the labels describing the input fields accurately?

Check that every form field label clearly and specifically describes the information users need to enter. Accurate labels help everyone, including screen reader users, know what is expected in each field and reduce the chance of errors.

Video element visual-only content has accessible alternative.

Does visual-only video content have an accessible alternative?

If a video has no audio, make sure there is a text or audio description available that explains what’s happening visually. This ensures that users who cannot see the video can still access the information it provides.

Audio element content has text alternative

Does audio element have text alternative?

Check that every audio element is accompanied by a text transcript. This allows users who are deaf, hard of hearing, or unable to play audio to access the same information as everyone else.

Video element auditory content has accessible alternative

Does audio content in a video have an accessible alternative?

Make sure that all important sounds or spoken information in a video are provided as captions or transcripts. This helps users who are deaf or hard of hearing understand the content of the video.

<code>object</code> to multimedia file require alternative for time-based media or audio description

Does the multimedia object provide alternatives for time-based content?

If an embedded video or audio file is included using an <object> element, ensure that captions, transcripts, or audio descriptions are available. These alternatives make the multimedia content accessible to users who are deaf, hard of hearing, or blind.

Video element visual content has accessible alternative

Does video have an accessible alternative?

For videos that include audio, make sure there is an audio description or a text summary that explains what’s happening visually. This ensures users who are blind or have low vision can fully understand the video’s content.

HTML layout tables should make sense when linearized

Does the layout table make sense when read line by line?

Check that if a layout table is used, the content still appears in a logical order when read line by line, such as with a screen reader or on a small screen. This helps ensure that everyone, including users with assistive technologies, can easily understand the information.

Using white space characters to control spacing within a word

Are white space characters used for spacing?

Check that extra spaces, tabs, or line breaks are not used to visually adjust the layout of words or text. Using white space for formatting can cause confusion and may not be interpreted correctly by screen readers or on different devices.

Using white space characters to create multiple columns or to format tables in plain text content

Are white space characters used to format tables?

Make sure columns or tables aren’t created by inserting spaces, tabs, or line breaks in plain text. This kind of formatting is often misread by screen readers and can break the layout on different devices, making data difficult for many users to understand.

Captions (Live)

Does the live video have captions?

Check that any live video includes real-time captions so that viewers who are deaf or hard of hearing can follow along with what’s being said as it happens. Live captions make your content accessible to everyone and are essential for deaf and hard of hearing users.

Audio-only (Live)

Does the live audio have an accessible alternative?

Check that any live audio includes a real-time text alternative or transcript. This ensures that people who are deaf or hard of hearing can access the same information being shared during the live audio.

Links inside text are sufficiently distinguishable

Link inside text is difficult to see or identify

Links that are surrounded by words must be clearly distinguishable so that all users and especially those with low vision, colorblindness or cognitive disabilities are able to recognize and use them.

ARIA state or property is permitted

Incorrect use of ARIA state or property

When ARIA states or properties are incorrectly used on certain elements it can confuse assistive technologies, making it harder for users with disabilities to understand or interact with the content.

Role attribute has valid value

Role attribute is missing a valid value

When a role attribute is either missing or has an invalid value it is possible that assistive technologies misinterpret or ignore those elements. This will make navigation and understanding more difficult for users with disabilities.

ARIA attribute is defined in WAI-ARIA

Undefined ARIA attribute must not be used

ARIA attributes not defined in WAI-ARIA can confuse assistive technologies and lead to accessibility issues for users with disabilities.

ARIA state or property has valid value

ARIA state or property has invalid value

If ARIA states or properties have invalid values assistive technology may interpret or announce content wrong, making the site less accessible.

ARIA required context role

ARIA element is missing required context

When an element with an ARIA role is missing its required context or parent element assistive technologies may not understand or present the element correctly to users.

ARIA required ID references exist

ARIA refers to a non-existing ID

When ARIA attributes reference IDs that don’t exist in the code, accessibility for users with assistive technologies will break, as linked elements are not announced or connected properly.

Use a quote element to mark up quotations.

Is quote element used to mark up quotations?

Review your content to make sure all quotations are marked up with the appropriate HTML quote elements (such as <q> or <blockquote>). This helps users of assistive technologies easily recognize and understand quoted text within your content.

Non-decorative content in pseudo classes

Is there non-decorative content in pseudo classes?

Check that any content added with CSS ::before or ::after pseudo-classes is decorative only, not essential information. Important content placed here may not be read by screen readers or accessed by all users, leading to gaps in understanding.

Headers attribute specified on a cell refers to cells in the same table element

Header attribute is referring to wrong ID or cell

Some table cells have a header attribute that points to an ID or cell outside their own table. This can make it difficult for screen readers to accurately explain table relationships, leading to confusion for users.

ARIA required owned elements

Parent element is missing required children

When elements are missing the required child elements for their assigned role, assistive technology users will find it more difficult to interact with the page. For instance, a list element must have list items, otherwise it should not be a list.

Table header cell has assigned cells

Table header is not associated to any data cells

When table headers aren’t linked to any data cells, it can be disorienting for screen reader users as it will be difficult to understand how table data is organized.

Changing the meaning of content by positioning information with CSS.

Is CSS modifying the visual layout and changing the meaning of content?

Ensure that CSS is not used to rearrange or position content in a way that gives it new meaning, unless the same structure is present in the underlying HTML. Using visual tricks to change meaning can confuse screen reader users and those who rely on the logical order of the content.

Element needs to have the right semantic role

Do elements have the right semantic role?

Verify that all interactive elements like buttons, links, and controls are coded with the correct semantic HTML or ARIA roles. This ensures that assistive technologies can accurately identify and announce each element, helping all users interact with your site effectively.

Media Alternative (Prerecorded)

Does prerecorded time-based media have an accessible alternative?

Check that any prerecorded videos or audio-visual media include accessible alternatives, such as captions, transcripts, or audio descriptions. These alternatives ensure that everyone, including users who are deaf, hard of hearing, or blind, can access the information in your media.

Extended Audio Description

If audio descriptions are insufficient, are extended audio descriptions provided?

For prerecorded videos, if regular audio descriptions don’t allow enough time to explain what’s happening visually, ensure that you provide extended audio descriptions. This ensures blind or low vision users have full access to important visual details, even when there isn’t enough natural pause in the original audio.

Sign Language (Prerecorded)

Is sign language interpretation provided for all prerecorded audio?

Ensure that all prerecorded audio content in videos includes sign language interpretation, so deaf users who prefer sign language can fully access and understand the information being presented.

Heading has non-empty accessible name

Heading is missing an accessible name

Without clear heading text, users, especially those using screen readers, cannot easily identify the section of text or purpose of the content.

Meta element has no refresh delay

Meta refresh should not cause the page to reload or redirect automatically after a short delay

When a page uses a meta refresh that automatically reloads or redirects after a short delay, the sudden change can confuse or disrupt users, especially those using assistive technologies.

Bypass Blocks

Is there a mechanism to bypass blocks of repeated content?

Make sure the site provides a shortcut or link, such as “Skip to main content”, that lets users bypass navigation menus or other repeated content on every page. This helps users, especially those using screen readers or keyboards, get to the main information quickly and efficiently.

Video has audio description. (AA)

Do prerecorded videos have audio descriptions?

Check that any prerecorded videos include audio description tracks or narration that explains important visual details. This ensures that people who are blind or have low vision can fully understand the content of videos.

Ensure input fields with autocomplete attributes align with their intended purpose.

Do autocomplete attributes align with their purpose?

Check that every input field with an autocomplete attribute uses a value that accurately matches the kind of information being collected (like name, email, or postal code). Proper autocomplete settings make forms faster and easier for everyone, especially people using assistive technologies or browsers’ autofill features.

HTML page has lang attribute

Page is missing a language attribute

Without a language tag that defines the language of the page, screen readers may not pronounce or interpret the content correctly, creating confusion for users.

Link text colour must contrast sufficiently with its background colour.

Link text fails minimum contrast requirements

Lack of contrast can make links difficult to distinguish and read, especially for users with low vision or color blindness, and may prevent them from identifying and using links effectively. Ensuring adequate contrast (minimum 4.5:1 for normal text, 3:1 for large text) helps all users, including those in bright environments or on low-quality screens, to access your content.

The contrast between the colour of link text and its background is not sufficient to meet WCAG2.0 Level AAA.

Link text fails enhanced contrast requirements

Not meeting enhanced color contrast requirements (minimum 7:1 for normal text, 4.5:1 for large text) is making reading and identifying links difficult particularily for users with low vision or color blindness. Enhanced contrast ensures the strongest visibility and accessibility for all users, particularly in challenging lighting or display situations.

Text has minimum contrast

Text fails minimum contrast requirements

When text doesn’t have enough color contrast with its background, it will be harder to read, especially for users with low vision or color blindness, and may prevent some people from accessing your content comfortably. Appropriate contrast is minimum 4.5:1 for normal text and 3:1 for large text, preferrably more.

Text has enhanced contrast

Text fails enhanced contrast requirements

Not meeting enhanced color contrast requirements (minimum 7:1 for normal text, 4.5:1 for normal text) is making reading text difficult particularily for users with low vision or color blindness. Enhanced contrast ensures the strongest visibility and accessibility for all users, particularly in challenging lighting or display situations.

Text on top of image gradient or backdrop-filter or using Text Shadows should have minimum contrast

Does text on top of images have minimum contrast?

Check that any text placed over a background image, gradient, or filter is easy to read, with at least a 4.5:1 contrast ratio against the background. Good contrast ensures everyone, including users with low vision or color blindness, can comfortably read your content.

Text on top of image gradient or backdrop-filter or using Text Shadows should have enhanced contrast

Does text on top of images have enhanced contrast?

Ensure that any text appearing over a background image, gradient, or filter has a strong contrast, at least 7:1, with the background. Enhanced contrast makes your content much easier to read for those with low vision or color blindness, and meets a higher accessibility standard.

Link text on top of image gradient or backdrop-filter or using Text Shadows should have minimum contrast

Do links on top of images have minimum contrast?

Check that all links placed over a background image, gradient, or filter maintain a contrast ratio of at least 4.5:1 with the background in every state (normal, hovered, focused, and visited). This helps ensure everyone, especially users with low vision or color blindness, can easily see and use your links.

Link text on top of image gradient or backdrop-filter or using Text Shadows should have enhanced contrast

Do links on top of images have enhanced contrast?

Ensure that all links appearing over a background image, gradient, or filter have a strong contrast of at least 7:1 with the background, in every state (normal, hovered, focused, and visited). Enhanced contrast makes links much easier to see and use, especially for people with low vision or color blindness.

All heading elements are not used for formatting.

Are headings used for formatting?

Check that heading tags (<h1>, <h2>, etc.) are only used to define section titles, not just to make text look bigger or bolder. Using headings correctly helps users and assistive technologies understand the structure of your content.

An image button has a name that describes its purpose.

Do image buttons have alt text?

Make sure every image button includes clear alt text or an accessible name that describes its purpose or action. This helps screen reader users understand what will happen if they activate the button.

Status messages can be programmatically determined through role or properties.

Are status messages presented clearly to assistive technology users?

Ensure that important status messages like confirmations, errors, or alerts are coded so they are announced by screen readers, even if they don’t receive keyboard focus. This allows all users, including those relying on assistive technology, to know about important changes or updates on the page.

Low or no background audio

Does audio containing speech have distracting background audio?

Check that any audio where speech is the main focus does not have loud or distracting background sounds. Keeping background audio low or absent ensures everyone, including people with hearing loss or attention difficulties, can clearly understand the spoken content.

HTML page lang attribute has valid language tag

Page language attribute has invalid language tag

When the language (lang) attribute defining the language of the page uses an invalid or unrecognized language code, it can cause screen readers and browsers to mispronounce or misinterpret the content, making it harder for users to understand. This error happens often, if there is a spelling mistake in the language code.

Orientation of the page is not restricted using CSS transform property

Orientation of the page should not be restricted

If pages restrict content to a single orientation, such as only landscape or only portrait, users, especially those on mobile devices or with specific accessibility needs such as users who need screens mounted in a certain orientation, will struggle to view and interact with your content comfortably.

Meta viewport allows for zoom

Meta viewport is preventing zoom

Restricting zoom makes it difficult for people with low vision or other accessibility needs to adjust text size and view content comfortably.

Element with lang attribute has valid language tag

Element language attribute has invalid language tag

When the language (lang) attribute defining the language of a particular element on the page uses an invalid or unrecognized language code, it can cause screen readers and browsers to mispronounce or misinterpret the content, making it harder for users to understand. This error happens often, if there is a spelling mistake in the language code.

autocomplete attribute has valid value

Autocomplete attribute is missing a valid value

Without a correct autocomplete value, users may not benefit from browser autofill features, making form completion less efficient and less accessible.

Links with identical accessible names and same context serve equivalent purpose

Do links with the same name serve the same purpose?

Verify that any links with identical accessible names in the same area of the page lead to the same or equivalent destinations. This helps users, especially those using screen readers, understand where each link goes and prevents confusion.

Text is Justified

Text is incorrectly aligned

When text is justified, meaning it is aligned to both the left and right margins, it can create uneven spacing between words, making the text harder to read especially for people with dyslexia or low vision.

Images of Text

Do the images contain text?

Check that images on your page do not include text, unless that text is absolutely essential and can’t be provided another way. Text in images can’t be resized, translated, or read by screen readers, making it harder for many users to access the information.

An input error is described to the user in text.

Are input errors described in text?

Make sure that whenever a user makes a mistake in a form (like leaving a required field empty), the error is clearly explained in text. This helps all users, especially those using screen readers, understand what went wrong and how to fix it.

Form submission error messages provide assistance in correcting the errors.

Are form submission errors helpful?

When users make mistakes submitting a form, check that the error messages clearly explain what the problem is and, whenever possible, include suggestions on how to fix it.

Error Prevention (Legal Financial Data)

If legal financial data is processed, are there safeguards for form submission?

If your page handles legal agreements, financial transactions, or important personal data, make sure users can review, confirm, and correct their entries before final submission, or reverse the submission if needed. These safeguards help prevent costly or irreversible mistakes, benefiting all users and especially those who may need extra time or support to check their information.

Visible label is part of accessible name

Is the visible label of an interactive element part of the accessible name?

Make sure any button, link, or other interactive element that shows a label on the page also includes that same text in its accessible name or ARIA label. This helps screen reader users recognize and understand the action, just like sighted users do.

Abbreviations must be described

Is the capitalized word an abbreviation that should be described?

Review any capitalized words or acronyms in your content to see if they are abbreviations that might not be familiar to all users. If so, provide a description or definition so everyone, including those using screen readers or unfamiliar with the term, can understand it.

The local language attribute matches the actual language

Does the local language attibute match the language of the content?

Check that any lang attribute on specific words, phrases, or sections correctly reflects the actual language used. This helps screen readers and translation tools pronounce and interpret the content correctly for all users.

Labels or instructions are provided when content requires user input

Do all input fields have permanently visible labels?

Make sure every form field has a label that’s always visible on the page, not just as placeholder text. This ensures all users, including those with memory or cognitive difficulties, always know what information is required.

Context-sensitive help is available for forms

If input label is not sufficient, is additional help provided?

If a form label doesn’t fully explain what’s needed, make sure there’s extra help available, such as a tooltip, hint, or help link, so users can complete the form accurately and confidently. This is especially important for anyone who may be confused or unfamiliar with the required input.

Links with identical accessible names have equivalent purpose

Do links with the same accessible name have the same purpose?

Make sure that links with identical names or text in the same context always lead to the same place or equivalent content. This prevents confusion for users, especially those using screen readers, by ensuring link meanings are predictable.

Pointer-interactive elements such as linked icons must be easy to target(extended)

Are interactive elements, such as linked icons, easy to target?

Check that buttons, links, and icons are large enough, at least 44x44 pixels, so users can easily tap or click them without making mistakes. Larger targets are especially important for people using touch screens or with limited dexterity.

Link text colour in user induced states must meet minimum contrast or better with its background colour.

Is link text distinguishable in all interactive states? (Minimum)

Ensure that link text always maintains sufficient color contrast with its background in every state: normal, hovered, focused, and visited. The contrast ratio should be at least 4.5:1 for regular text and at least 3:1 for large text. This helps everyone, including people with low vision or color blindness, easily see and use links.

Link text colour in user induced states must meet enhanced contrast or better with its background colour.

Is link text distinguishable in all interactive states? (Enhanced)

Check that link text always maintains strong color contrast with its background in every state: normal, hovered, focused, and visited. The contrast ratio should be at least 7:1 for regular text and at least 4.5:1 for large text. Enhanced contrast ensures links are even more visible and accessible for users with low vision or color blindness.

Sound file must have a text transcript.

Does the audio file have a text transcript?

Check that any linked audio files on this page have a text transcript available for users. Without a transcript, people who are deaf or hard of hearing, or anyone who can’t play the audio, will miss the information in the audio file.

Anchor should not open new window without warning.

Does the anchor element open a new window without warning?

Check if anchor links open a new window or tab without letting users know in advance. Unexpectedly opening new windows can be confusing or disruptive, especially for people using screen readers or keyboard navigation. If a link opens a new window, make sure this is clearly indicated. For example: “Opens in a new window.”

Links to multimedia require a text transcript.

Is there a text alternative for the multimedia file?

Verify that any linked audio or video files have a text alternative, such as a transcript or captions. Without text alternatives, people who are deaf, hard of hearing, or cannot access multimedia content will miss important information.

<code>blink</code> element is not used.

Blinking text must not be used

The <blink> element should not be used because blinking text can trigger seizures or headaches in some users, and it is difficult for people with vision or cognitive disabilities to read.

<code>area</code> link to sound file must have text transcript.

Is there a text alternative for the linked audio file?

Check that any audio files linked through image maps or clickable areas provide a text transcript. Without a transcript, users who are deaf or hard of hearing, or anyone unable to play audio, will miss the information.

<code>marquee</code> element is not used.

Marquee element must not be used

The <marquee> element should not be used because moving text can be distracting and hard to read, especially for users with cognitive or vision disabilities. Marquees can also cause accessibility problems for users who rely on screen readers or have motion sensitivity, making your content less accessible and harder to understand.

Auto-redirect must not be used.

Auto-redirect must not be used

Automatic redirects using the <meta http-equiv="refresh"> element should not be used, as they can unexpectedly move users away from the page without warning. This can be confusing for all users and especially problematic for those using screen readers or with cognitive disabilities, making navigation unpredictable and difficult.

All <code>p</code> elements are not used as headers.

Are p elements used as headers?

Review the page to see if any paragraphs are being styled to look like headings using bold, italics, underline, or font changes instead of real heading tags (like <h1>, <h2>, etc.). Using proper heading tags is important for screen reader users and helps everyone navigate content more easily.

All layout <code>tables</code> have an empty <code>summary</code> attribute or no <code>summary</code> attribute.

Layout tables should have an empty summary attribute or none at all

Adding unnecessary summaries to layout tables can confuse assistive technology users, making it harder to understand the actual structure and purpose of the content.

All layout tables do not contain <code>caption</code> elements.

Layout tables must not contain caption elements

Using captions in layout tables can mislead assistive technology users by making non-data tables appear to contain important tabular information.

<code>pre</code> element should not be used to create tabular layout.

Is the pre element used to create a table?

Check whether the <pre> tag is being used to display data in a table or columns. Using <pre> for layout makes it difficult for screen readers and other users to understand and navigate the data. If the content represents a table, use proper HTML table markup (<table>, <tr>, <td>) to ensure it’s accessible to everyone.

All data table summaries describe navigation and structure of the table.

Is the data table summary describing the navigation and structure of the table?

Review each data table to ensure the summary text clearly explains how to navigate and understand the table’s structure. The summary should not be random or meaningless, but help screen reader users know what information the table presents and how it’s organized.

Table markup is used for all tabular information.

Is table markup used for all table information consistently?

Check that all data presented in a table or grid format is marked up using proper HTML table elements (<table>, <tr>, <th>, <td>). This ensures that screen readers and other assistive technologies can accurately convey relationships between data.

Table captions identify the table.

Are the table captions identifying the table?

Verify that each table caption clearly describes what the table is about. Captions should help users, including those using screen readers, understand the purpose or subject of the table at a glance.

Table summaries do not duplicate the table captions.

Table summary and caption must be different

The caption is meant to identify the table, while the summary provides additional details about its contents for users, especially those relying on assistive technology.

Data tables that contain more than one row/column of headers use the <code>id</code> and <code>headers</code> attributes to identify cells.

Complex data table is missing ID and/or header attributes to associate headers with data cells

ID and header attributes are needed to properly link table headers to their corresponding data cells. Without these attributes, screen readers cannot accurately communicate relationships in the table, making it difficult for users to understand the data structure.

All visual lists are marked.

Are all visual lists correctly coded as lists?

Make sure that any content presented visually as a list, like bullet points or numbered items, is marked up with proper HTML list tags (<ul>, <ol>, <li>). This helps screen reader users and others easily understand and navigate listed information.

Sensory Characteristics.

Are enough instructions provided for everyone to understand and operate the content?

Review any instructions given on the page to ensure they don’t rely only on things like color, shape, size, or sound. Make sure all users, including those who are colorblind or use screen readers, can follow the instructions without missing important details.

The luminosity contrast ratio between text and background color in all images is at least 4.5:1.

Does text over background image meet minimum contrast requirements?

Check that any text placed on top of a background image is easy to read and stands out clearly (Contrast should be minimum 4.5:1 for normal text, 3:1 for large text). Insufficient contrast makes it hard for users, especially those with low vision or color blindness, to see and understand the information.

The luminosity contrast ratio between text and background color in all images is at least 7:1.

Does text over background image meet enhanced contrast requirements?

Verify that any text placed on a background image has a strong, high-contrast color combination (minimum 7:1 for normal text, 4.5:1 for large text). Enhanced contrast ensures that even users with low vision or color blindness can easily read and understand the text, providing an even higher standard of accessibility.

Information deleted using a web page can be recovered.

Can users recover deleted information?

Make sure users have a way to restore or undo deleted information. This helps prevent serious problems if someone removes content by mistake, especially for users who may find it harder to correct errors.

Logical focus order.

Are elements focused in a logical order when navigating with keyboard?

Test keyboard navigation to ensure that focus moves through the page in a sequence that matches the intended reading and interaction order. If focus jumps around unpredictably, it can confuse users and make the site difficult or impossible to use, especially for those relying on a keyboard and assistive technology.

The visual presentation of UI and graphics components have a contrast ratio of at least 3:1 against adjacent color(s).

Are important UI and graphical components distinguishable?

Ensure that buttons, controls, and key graphics stand out clearly against their backgrounds with enough color contrast (at least 3:1). Good contrast helps everyone and especially users with low vision, easily find and use important parts of the interface.

The purpose of User Interface Components icons and regions can be programmatically determined.

Is the purpose of UI components, icons, and regions programmatically determined?

Verify that interactive elements like buttons, icons, and content regions are coded so their purpose can be identified by assistive technologies (such as screen readers). Proper labeling and use of semantic HTML or ARIA attributes help all users understand and interact with these elements.

Scrolling in more than one direction is not necessary for small displays and zoomed content.

Are users forced to scroll in two dimensions when zoomed in?

Check that when the page is zoomed in or viewed on a small screen, users only need to scroll in one direction (usually up and down) to access all content. If both horizontal and vertical scrolling are required just to read or use the site, it can be difficult, especially for people with low vision or mobility impairments.

No loss of content or functionality occurs when changing certain text style properties.

Are users able to use the fonts, spacing, and font size of their choice, without loss of content?

Make sure that increasing font size, line spacing, or letter/word spacing does not cause content to overlap, disappear, or become unusable. Users should be able to personalize text settings for better readability without breaking the layout or hiding information.

Additional content that appears and disappears in coordination with keyboard focus or pointer hover does not obstruct operation.

Does content that appears on hover or focus block important information or disappear before users can interact with it?

Review any tooltips, popups, or menus that appear when hovering with a mouse or focusing with the keyboard. Make sure they don’t cover up other important content, disappear before users can interact with them, or become hard to dismiss. This ensures everyone, including keyboard and screen reader users, can access all information.

Users are warned of the duration of any user inactivity that could cause data loss.

Are users warned if inactivity could cause them to lose work?

Check that users receive a clear notification if their session will expire or if unsaved information might be lost after a period of inactivity. This helps prevent accidental data loss, especially for users who may need more time to complete tasks.

Motion animation triggered by interaction can be disabled unless the animation is essential to the functionality or the information being conveyed.

Can users turn off motion animation triggered by interaction?

Make sure that users can disable motion animations that play when they interact with elements, unless those animations are essential for understanding or using the content. This helps people who are sensitive to motion use your site comfortably.

Functionality that can be operated by device motion or user motion can be disabled to prevent accidental actuation.

Are there alternatives for features that require device or user motion?

Check that any actions triggered by device movement (like shaking, tilting, or gesturing) can also be performed using buttons or other interface controls—and that users have a way to turn off motion activation. This prevents accidental triggers and ensures everyone can use the feature, regardless of their device or abilities.

Previously entered information is available afterwards.

Is information the user previously entered automatically available when needed in later steps of the process?

Make sure that any information a user has already entered or provided for instance in a form is automatically filled in or easy to select when needed again in later steps of a process. This saves time and reduces errors, especially for users who may have difficulty re-entering information.

Authentication Form is accessible for cognitively challenged people.

Is a congnitive function test required for authentication?

Review the login process to see if users are required to perform tasks that demand significant memory or problem-solving, like recalling complex passwords or answering riddles. Ensure there is an alternative method for logging in that doesn’t require strong memorization skills, such as allowing users to paste their password or use another authentication option. Without alternatives, users with cognitive disabilities or memory difficulties may be unable to log in, blocking access.

Available help is consistently easy to find.

Is available help easy to find?

Look for any help or support options provided on the page and make sure they are always in the same place throughout the site. If help is hard to locate or its position changes from page to page, users may struggle to get assistance when they need it, especially those with cognitive or visual disabilities.

Pointer-interactive elements such as linked icons must be easy to target.

Are interactive elements big enough to target easily?

Check that buttons, links, and clickable icons are large enough, at least 44x44 pixels, so they can be easily tapped or clicked, even by people with limited dexterity or on touch screens. Small targets can be difficult or frustrating to use and may cause errors, especially on mobile devices.

Any dragging movements required for functionality must have a proper alternative.

Does functionality requiring dragging movements have a proper alternative?

If users need to drag something (like a slider or item) to perform an action, make sure there’s another way to do the same thing, such as clicking, tapping, or using the keyboard. This ensures that people who can’t easily drag, such as those using assistive technologies or with limited mobility, can still use all features of your site.

Scrolling in more than one direction is not necessary for display on mobile phones.

Do users need to scroll in two dimensions on mobile?

Check the page on a mobile device to ensure users only need to scroll either vertically (up and down) or horizontally (side to side), to read or interact with content. Requiring both directions of scrolling can be frustrating and difficult for users on small screens or with mobility challenges.

Audio Control.

Are users able to shut off content with sound?

Check if any audio or video that plays for more than three seconds has an obvious and accessible control to pause or stop the sound. Without this, users, especially those with visual impairments or who use screen readers, can be distracted or unable to focus on other content.

Authentication Form is accessible for cognitively challenged people (enhanced criterion).

Is a cognitive function test required for authentication? (Enhanced)

Check whether users must solve memory-based tasks, like recalling a password or answering riddles, to log in. If such steps are required, be sure there is an accessible alternative, so that users with cognitive disabilities can log in without barriers.

Interface components receiving focus are not entirely hidden.

Are all focusable elements at least partially visible when focused?

When you tab through the page, make sure that every button, link, or form field stays visible when it receives keyboard focus. If part of the screen, for instance a chat widget, covers a focused element, users relying on keyboard navigation may not know where they are or what they’re interacting with.

No part of interface components receiving focus is hidden.

Are all focusable elements entirely visible when focused?

When you tab through the page, make sure that every button, link, or form field stays entirely visible when it receives keyboard focus. If part of the screen, for instance a chat widget, covers a focused element, users relying on keyboard navigation may not know where they are or what they’re interacting with.

Focus Appearance meets the criteria for conformance.

Is the focus indicator distinguishable?

When you use the keyboard to navigate, ensure that a clear, visible outline or highlight appears on the focused element, standing out from the background and nearby content. A strong focus indicator helps keyboard users know exactly where they are on the page, preventing confusion or navigation errors.

Element with role attribute has required states and properties

Element with role attributes is missing required states or properties

Elements that have a specific role should have ARIA states or properties that go with that role. Without the right states and properties, assistive technologies may not present the element’s purpose or status correctly to users.

Form field has non-empty accessible name

Form field is missing an accessible name

Form fields must have accessible names. Without a clear label or name, screen reader users may not understand what information is required, making it hard or impossible to complete the form.

Menuitem has non-empty accessible name

Menu item doesn't have an accessible name

Menu items must have accessible names. Without an accessible name, users of screen readers or other assistive technologies cannot identify or navigate the menu option effectively.

Element with aria-hidden has no content in sequential focus navigation

Element marked as hidden must not be included in tab navigation

Elements marked as hidden with aria-hidden="true" must not be included in keyboard tab navigation. If hidden elements are accessible by keyboard or assistive technology, it can confuse users and disrupt smooth navigation.

iframe elements with identical accessible names have equivalent purpose

Do the iframe elements with same name have same purpose?

Check that all iframes that share the same accessible name actually serve the same function or display similar content. Using the same name for different purposes can confuse users, especially those using assistive technology, by making it unclear what each iframe is for.

Link has non-empty accessible name

Link is missing an accessible name

Without a clear, descriptive name, users may not know where the link goes or what it does.

Iframe element has non-empty accessible name

Iframe element is missing an accessible name

Without an accessible name, users of screen readers won’t know the purpose or content of the embedded frame, making navigation and understanding more difficult.

Element with presentational children has no focusable content

Elements intended as presentation-only contain focusable content

When elements are marked as presentational but contain focusable items like links or buttons, users of assistive technology may encounter interactive elements that aren’t announced or expected.

Button has non-empty accessible name

Button is missing an accessible name

Without a descriptive name, screen reader users won’t know the purpose or function of a button.

SVG element with explicit role has non-empty accessible name

SVG element with defined role is missing an accessible name

Without an accessible name, users of assistive technologies won’t know what the graphic represents or its purpose.

Image has non-empty accessible name

Image is missing alternative text

Without alternative text, users of screen readers won’t know what the image shows or if it’s important.

<code>object</code> element rendering non-text content has non-empty accessible name

Non-text object element is missing an accessible name

A non-text <object> element, such as an embedded chart, video, or interactive feature, is missing an accessible name. Without a descriptive name, users of assistive technology won’t know what this embedded content is or what information or functionality it provides.

Image not in the accessibility tree is decorative

Are the hidden images decorative?

Review any images, SVGs, or canvases that are hidden from assistive technologies to make sure they are purely decorative. Hiding meaningful images can prevent users with disabilities from accessing important information or context.

Image accessible name is descriptive

Is the image alternative text descriptive enough?

Ensure that each image’s alt text or accessible name clearly describes its purpose or meaning. If the description is too vague or generic, users who rely on screen readers may not understand the image's relevance or intent.

Image button has non-empty accessible name

Image button is missing an accessible name

Without a clear name, users of screen readers won’t know what the button does or how to use it.

Use of Color

Is color alone used to convey meaning?

Check that color isn’t the only way information, actions, or differences are shown on the page. Make sure there are also text labels, symbols, or patterns, so everyone, including people with color blindness, can understand and use the content.

All functionality of the content is operable through a keyboard interface

Can all functionality be operated with keyboard?

Go through the site using only the keyboard (Tab, Enter, arrow keys) and ensure that every feature like links, buttons, forms, and menus can be accessed and used without a mouse. This ensures that users who rely on keyboard navigation, including those with mobility impairments, can fully interact with all parts of the site.

Scrollable content can be reached with sequential focus navigation

Scrollable content is not accessible using the keyboard

When scrollable content can’t be accessed or scrolled using the keyboard or assistive technology, users may find it difficult or impossible to interact with the content.

Iframe with interactive elements is not excluded from tab-order

Iframe with interactive elements is not keyboard navigable

When an iframe contains interactive elements, users navigating with keyboard or assistive technology need to be able to reach the important features within the frame. This does not happen if the element is excluded from sequential focus navigation.

Scrollable content can be reached with sequential focus navigation

Scrollable content is not accessible using the keyboard (No exception)

Users must be able to access scrollable content using the keyboard, with no exceptions allowed. When scrollable content is not accessible, keyboard-only and assistive technology users are not able to reach and interact with the content.

Keyboard Trap

Is keyboard focus trapped in any component?

As you navigate the site with the keyboard, make sure you can move freely in and out of all components (like modals or menus). If focus gets stuck and you can’t tab away, users relying on keyboards or assistive technologies might be unable to use or exit that part of the site.

HTML page has non-empty title

Page is missing a title

Without a title, users, especially those using screen readers or with multiple browser tabs open, may not know what the page is about or easily find it.

HTML page title is descriptive

Is the page title descriptive enough?

Look at the page’s title and make sure it clearly describes what the page is about. A descriptive title helps users, especially those using screen readers or switching between multiple tabs, quickly understand the page’s purpose and find the information they need.

Element in sequential focus order has visible focus

Is the keyboard focus visible at all times?

As you navigate through the page using the keyboard, make sure elements receive a clear outline or highlight is always visible on the currently focused element. This helps users know exactly where they are and prevents them from getting lost while using the site.

Heading is descriptive

Is the heading descriptive enough?

Review each heading and make sure it clearly explains the topic or purpose of the section that follows. Descriptive headings help all users, including those using screen readers, easily navigate and understand the structure of your content.

Each label describes its associated <code>input</code> element.

Are the labels describing the input fields accurately?

Check that every form field label clearly and specifically describes the information users need to enter. Accurate labels help everyone, including screen reader users, know what is expected in each field and reduce the chance of errors.

Video element visual-only content has accessible alternative.

Does visual-only video content have an accessible alternative?

If a video has no audio, make sure there is a text or audio description available that explains what’s happening visually. This ensures that users who cannot see the video can still access the information it provides.

Audio element content has text alternative

Does audio element have text alternative?

Check that every audio element is accompanied by a text transcript. This allows users who are deaf, hard of hearing, or unable to play audio to access the same information as everyone else.

Video element auditory content has accessible alternative

Does audio content in a video have an accessible alternative?

Make sure that all important sounds or spoken information in a video are provided as captions or transcripts. This helps users who are deaf or hard of hearing understand the content of the video.

<code>object</code> to multimedia file require alternative for time-based media or audio description

Does the multimedia object provide alternatives for time-based content?

If an embedded video or audio file is included using an <object> element, ensure that captions, transcripts, or audio descriptions are available. These alternatives make the multimedia content accessible to users who are deaf, hard of hearing, or blind.

Video element visual content has accessible alternative

Does video have an accessible alternative?

For videos that include audio, make sure there is an audio description or a text summary that explains what’s happening visually. This ensures users who are blind or have low vision can fully understand the video’s content.

HTML layout tables should make sense when linearized

Does the layout table make sense when read line by line?

Check that if a layout table is used, the content still appears in a logical order when read line by line, such as with a screen reader or on a small screen. This helps ensure that everyone, including users with assistive technologies, can easily understand the information.

Using white space characters to control spacing within a word

Are white space characters used for spacing?

Check that extra spaces, tabs, or line breaks are not used to visually adjust the layout of words or text. Using white space for formatting can cause confusion and may not be interpreted correctly by screen readers or on different devices.

Using white space characters to create multiple columns or to format tables in plain text content

Are white space characters used to format tables?

Make sure columns or tables aren’t created by inserting spaces, tabs, or line breaks in plain text. This kind of formatting is often misread by screen readers and can break the layout on different devices, making data difficult for many users to understand.

Captions (Live)

Does the live video have captions?

Check that any live video includes real-time captions so that viewers who are deaf or hard of hearing can follow along with what’s being said as it happens. Live captions make your content accessible to everyone and are essential for deaf and hard of hearing users.

Audio-only (Live)

Does the live audio have an accessible alternative?

Check that any live audio includes a real-time text alternative or transcript. This ensures that people who are deaf or hard of hearing can access the same information being shared during the live audio.

Links inside text are sufficiently distinguishable

Link inside text is difficult to see or identify

Links that are surrounded by words must be clearly distinguishable so that all users and especially those with low vision, colorblindness or cognitive disabilities are able to recognize and use them.

ARIA state or property is permitted

Incorrect use of ARIA state or property

When ARIA states or properties are incorrectly used on certain elements it can confuse assistive technologies, making it harder for users with disabilities to understand or interact with the content.

Role attribute has valid value

Role attribute is missing a valid value

When a role attribute is either missing or has an invalid value it is possible that assistive technologies misinterpret or ignore those elements. This will make navigation and understanding more difficult for users with disabilities.

ARIA attribute is defined in WAI-ARIA

Undefined ARIA attribute must not be used

ARIA attributes not defined in WAI-ARIA can confuse assistive technologies and lead to accessibility issues for users with disabilities.

ARIA state or property has valid value

ARIA state or property has invalid value

If ARIA states or properties have invalid values assistive technology may interpret or announce content wrong, making the site less accessible.

ARIA required context role

ARIA element is missing required context

When an element with an ARIA role is missing its required context or parent element assistive technologies may not understand or present the element correctly to users.

ARIA required ID references exist

ARIA refers to a non-existing ID

When ARIA attributes reference IDs that don’t exist in the code, accessibility for users with assistive technologies will break, as linked elements are not announced or connected properly.

Use a quote element to mark up quotations.

Is quote element used to mark up quotations?

Review your content to make sure all quotations are marked up with the appropriate HTML quote elements (such as <q> or <blockquote>). This helps users of assistive technologies easily recognize and understand quoted text within your content.

Non-decorative content in pseudo classes

Is there non-decorative content in pseudo classes?

Check that any content added with CSS ::before or ::after pseudo-classes is decorative only, not essential information. Important content placed here may not be read by screen readers or accessed by all users, leading to gaps in understanding.

Headers attribute specified on a cell refers to cells in the same table element

Header attribute is referring to wrong ID or cell

Some table cells have a header attribute that points to an ID or cell outside their own table. This can make it difficult for screen readers to accurately explain table relationships, leading to confusion for users.

ARIA required owned elements

Parent element is missing required children

When elements are missing the required child elements for their assigned role, assistive technology users will find it more difficult to interact with the page. For instance, a list element must have list items, otherwise it should not be a list.

Table header cell has assigned cells

Table header is not associated to any data cells

When table headers aren’t linked to any data cells, it can be disorienting for screen reader users as it will be difficult to understand how table data is organized.

Changing the meaning of content by positioning information with CSS.

Is CSS modifying the visual layout and changing the meaning of content?

Ensure that CSS is not used to rearrange or position content in a way that gives it new meaning, unless the same structure is present in the underlying HTML. Using visual tricks to change meaning can confuse screen reader users and those who rely on the logical order of the content.

Element needs to have the right semantic role

Do elements have the right semantic role?

Verify that all interactive elements like buttons, links, and controls are coded with the correct semantic HTML or ARIA roles. This ensures that assistive technologies can accurately identify and announce each element, helping all users interact with your site effectively.

Media Alternative (Prerecorded)

Does prerecorded time-based media have an accessible alternative?

Check that any prerecorded videos or audio-visual media include accessible alternatives, such as captions, transcripts, or audio descriptions. These alternatives ensure that everyone, including users who are deaf, hard of hearing, or blind, can access the information in your media.

Extended Audio Description

If audio descriptions are insufficient, are extended audio descriptions provided?

For prerecorded videos, if regular audio descriptions don’t allow enough time to explain what’s happening visually, ensure that you provide extended audio descriptions. This ensures blind or low vision users have full access to important visual details, even when there isn’t enough natural pause in the original audio.

Sign Language (Prerecorded)

Is sign language interpretation provided for all prerecorded audio?

Ensure that all prerecorded audio content in videos includes sign language interpretation, so deaf users who prefer sign language can fully access and understand the information being presented.

Heading has non-empty accessible name

Heading is missing an accessible name

Without clear heading text, users, especially those using screen readers, cannot easily identify the section of text or purpose of the content.

Meta element has no refresh delay

Meta refresh should not cause the page to reload or redirect automatically after a short delay

When a page uses a meta refresh that automatically reloads or redirects after a short delay, the sudden change can confuse or disrupt users, especially those using assistive technologies.

Bypass Blocks

Is there a mechanism to bypass blocks of repeated content?

Make sure the site provides a shortcut or link, such as “Skip to main content”, that lets users bypass navigation menus or other repeated content on every page. This helps users, especially those using screen readers or keyboards, get to the main information quickly and efficiently.

Video has audio description. (AA)

Do prerecorded videos have audio descriptions?

Check that any prerecorded videos include audio description tracks or narration that explains important visual details. This ensures that people who are blind or have low vision can fully understand the content of videos.

Ensure input fields with autocomplete attributes align with their intended purpose.

Do autocomplete attributes align with their purpose?

Check that every input field with an autocomplete attribute uses a value that accurately matches the kind of information being collected (like name, email, or postal code). Proper autocomplete settings make forms faster and easier for everyone, especially people using assistive technologies or browsers’ autofill features.

HTML page has lang attribute

Page is missing a language attribute

Without a language tag that defines the language of the page, screen readers may not pronounce or interpret the content correctly, creating confusion for users.

Link text colour must contrast sufficiently with its background colour.

Link text fails minimum contrast requirements

Lack of contrast can make links difficult to distinguish and read, especially for users with low vision or color blindness, and may prevent them from identifying and using links effectively. Ensuring adequate contrast (minimum 4.5:1 for normal text, 3:1 for large text) helps all users, including those in bright environments or on low-quality screens, to access your content.

The contrast between the colour of link text and its background is not sufficient to meet WCAG2.0 Level AAA.

Link text fails enhanced contrast requirements

Not meeting enhanced color contrast requirements (minimum 7:1 for normal text, 4.5:1 for large text) is making reading and identifying links difficult particularily for users with low vision or color blindness. Enhanced contrast ensures the strongest visibility and accessibility for all users, particularly in challenging lighting or display situations.

Text has minimum contrast

Text fails minimum contrast requirements

When text doesn’t have enough color contrast with its background, it will be harder to read, especially for users with low vision or color blindness, and may prevent some people from accessing your content comfortably. Appropriate contrast is minimum 4.5:1 for normal text and 3:1 for large text, preferrably more.

Text has enhanced contrast

Text fails enhanced contrast requirements

Not meeting enhanced color contrast requirements (minimum 7:1 for normal text, 4.5:1 for normal text) is making reading text difficult particularily for users with low vision or color blindness. Enhanced contrast ensures the strongest visibility and accessibility for all users, particularly in challenging lighting or display situations.

Text on top of image gradient or backdrop-filter or using Text Shadows should have minimum contrast

Does text on top of images have minimum contrast?

Check that any text placed over a background image, gradient, or filter is easy to read, with at least a 4.5:1 contrast ratio against the background. Good contrast ensures everyone, including users with low vision or color blindness, can comfortably read your content.

Text on top of image gradient or backdrop-filter or using Text Shadows should have enhanced contrast

Does text on top of images have enhanced contrast?

Ensure that any text appearing over a background image, gradient, or filter has a strong contrast, at least 7:1, with the background. Enhanced contrast makes your content much easier to read for those with low vision or color blindness, and meets a higher accessibility standard.

Link text on top of image gradient or backdrop-filter or using Text Shadows should have minimum contrast

Do links on top of images have minimum contrast?

Check that all links placed over a background image, gradient, or filter maintain a contrast ratio of at least 4.5:1 with the background in every state (normal, hovered, focused, and visited). This helps ensure everyone, especially users with low vision or color blindness, can easily see and use your links.

Link text on top of image gradient or backdrop-filter or using Text Shadows should have enhanced contrast

Do links on top of images have enhanced contrast?

Ensure that all links appearing over a background image, gradient, or filter have a strong contrast of at least 7:1 with the background, in every state (normal, hovered, focused, and visited). Enhanced contrast makes links much easier to see and use, especially for people with low vision or color blindness.

All heading elements are not used for formatting.

Are headings used for formatting?

Check that heading tags (<h1>, <h2>, etc.) are only used to define section titles, not just to make text look bigger or bolder. Using headings correctly helps users and assistive technologies understand the structure of your content.

An image button has a name that describes its purpose.

Do image buttons have alt text?

Make sure every image button includes clear alt text or an accessible name that describes its purpose or action. This helps screen reader users understand what will happen if they activate the button.

Status messages can be programmatically determined through role or properties.

Are status messages presented clearly to assistive technology users?

Ensure that important status messages like confirmations, errors, or alerts are coded so they are announced by screen readers, even if they don’t receive keyboard focus. This allows all users, including those relying on assistive technology, to know about important changes or updates on the page.

Low or no background audio

Does audio containing speech have distracting background audio?

Check that any audio where speech is the main focus does not have loud or distracting background sounds. Keeping background audio low or absent ensures everyone, including people with hearing loss or attention difficulties, can clearly understand the spoken content.

HTML page lang attribute has valid language tag

Page language attribute has invalid language tag

When the language (lang) attribute defining the language of the page uses an invalid or unrecognized language code, it can cause screen readers and browsers to mispronounce or misinterpret the content, making it harder for users to understand. This error happens often, if there is a spelling mistake in the language code.

Orientation of the page is not restricted using CSS transform property

Orientation of the page should not be restricted

If pages restrict content to a single orientation, such as only landscape or only portrait, users, especially those on mobile devices or with specific accessibility needs such as users who need screens mounted in a certain orientation, will struggle to view and interact with your content comfortably.

Meta viewport allows for zoom

Meta viewport is preventing zoom

Restricting zoom makes it difficult for people with low vision or other accessibility needs to adjust text size and view content comfortably.

Element with lang attribute has valid language tag

Element language attribute has invalid language tag

When the language (lang) attribute defining the language of a particular element on the page uses an invalid or unrecognized language code, it can cause screen readers and browsers to mispronounce or misinterpret the content, making it harder for users to understand. This error happens often, if there is a spelling mistake in the language code.

autocomplete attribute has valid value

Autocomplete attribute is missing a valid value

Without a correct autocomplete value, users may not benefit from browser autofill features, making form completion less efficient and less accessible.

Links with identical accessible names and same context serve equivalent purpose

Do links with the same name serve the same purpose?

Verify that any links with identical accessible names in the same area of the page lead to the same or equivalent destinations. This helps users, especially those using screen readers, understand where each link goes and prevents confusion.

Text is Justified

Text is incorrectly aligned

When text is justified, meaning it is aligned to both the left and right margins, it can create uneven spacing between words, making the text harder to read especially for people with dyslexia or low vision.

Images of Text

Do the images contain text?

Check that images on your page do not include text, unless that text is absolutely essential and can’t be provided another way. Text in images can’t be resized, translated, or read by screen readers, making it harder for many users to access the information.

An input error is described to the user in text.

Are input errors described in text?

Make sure that whenever a user makes a mistake in a form (like leaving a required field empty), the error is clearly explained in text. This helps all users, especially those using screen readers, understand what went wrong and how to fix it.

Form submission error messages provide assistance in correcting the errors.

Are form submission errors helpful?

When users make mistakes submitting a form, check that the error messages clearly explain what the problem is and, whenever possible, include suggestions on how to fix it.

Error Prevention (Legal Financial Data)

If legal financial data is processed, are there safeguards for form submission?

If your page handles legal agreements, financial transactions, or important personal data, make sure users can review, confirm, and correct their entries before final submission, or reverse the submission if needed. These safeguards help prevent costly or irreversible mistakes, benefiting all users and especially those who may need extra time or support to check their information.

Visible label is part of accessible name

Is the visible label of an interactive element part of the accessible name?

Make sure any button, link, or other interactive element that shows a label on the page also includes that same text in its accessible name or ARIA label. This helps screen reader users recognize and understand the action, just like sighted users do.

Abbreviations must be described

Is the capitalized word an abbreviation that should be described?

Review any capitalized words or acronyms in your content to see if they are abbreviations that might not be familiar to all users. If so, provide a description or definition so everyone, including those using screen readers or unfamiliar with the term, can understand it.

The local language attribute matches the actual language

Does the local language attibute match the language of the content?

Check that any lang attribute on specific words, phrases, or sections correctly reflects the actual language used. This helps screen readers and translation tools pronounce and interpret the content correctly for all users.

Labels or instructions are provided when content requires user input

Do all input fields have permanently visible labels?

Make sure every form field has a label that’s always visible on the page, not just as placeholder text. This ensures all users, including those with memory or cognitive difficulties, always know what information is required.

Context-sensitive help is available for forms

If input label is not sufficient, is additional help provided?

If a form label doesn’t fully explain what’s needed, make sure there’s extra help available, such as a tooltip, hint, or help link, so users can complete the form accurately and confidently. This is especially important for anyone who may be confused or unfamiliar with the required input.

Links with identical accessible names have equivalent purpose

Do links with the same accessible name have the same purpose?

Make sure that links with identical names or text in the same context always lead to the same place or equivalent content. This prevents confusion for users, especially those using screen readers, by ensuring link meanings are predictable.

Pointer-interactive elements such as linked icons must be easy to target(extended)

Are interactive elements, such as linked icons, easy to target?

Check that buttons, links, and icons are large enough, at least 44x44 pixels, so users can easily tap or click them without making mistakes. Larger targets are especially important for people using touch screens or with limited dexterity.

Link text colour in user induced states must meet minimum contrast or better with its background colour.

Is link text distinguishable in all interactive states? (Minimum)

Ensure that link text always maintains sufficient color contrast with its background in every state: normal, hovered, focused, and visited. The contrast ratio should be at least 4.5:1 for regular text and at least 3:1 for large text. This helps everyone, including people with low vision or color blindness, easily see and use links.

Link text colour in user induced states must meet enhanced contrast or better with its background colour.

Is link text distinguishable in all interactive states? (Enhanced)

Check that link text always maintains strong color contrast with its background in every state: normal, hovered, focused, and visited. The contrast ratio should be at least 7:1 for regular text and at least 4.5:1 for large text. Enhanced contrast ensures links are even more visible and accessible for users with low vision or color blindness.