Accessibility Rules Index

Browse all accessibility rules by WCAG ID. Use search to filter by title or WCAG.

Perceivable (WCAG 1.x.x)46 rules

Active <area> elements must have alternative text
WCAG 1.1.1
Non-text Content
Screen reader users rely on text alternatives to understand the purpose of images and image-based controls. Without accurate alternatives, critical information
ARIA meter elements must have accessible names
WCAG 1.1.1
Non-text Content
A meter represents a value within a known range — such as progress, usage, or a score — but without an accessible name, screen readers can only announce a numbe
ARIA progressbar elements must have accessible names
WCAG 1.1.1
Non-text Content
Progress bars communicate the status of ongoing tasks, such as uploading files or submitting forms. Without a clear accessible name, users relying on screen rea
ARIA tooltips must have accessible names
WCAG 1.1.1
Non-text Content
Tooltips provide essential contextual help. Without an accessible name, assistive technologies cannot announce the tooltip’s purpose or content, leaving users u
Provide alternative text for all meaningful images
WCAG 1.1.1
Non-text Content
Screen readers cannot interpret images. Without alternative text, users who are blind or have low vision miss important information or context. Alt text ensures
Image input buttons must have alternative text
WCAG 1.1.1
Non-text Content
Screen reader users rely on text alternatives to understand the purpose of images and image-based controls. Without accurate alternatives, critical information
Provide text alternatives for embedded objects or plugins
WCAG 1.1.1
Non-text Content
Objects such as Flash, Java applets, or custom embeds may not be accessible. Without fallback text, users relying on assistive technology will have no way to ac
[role="img"] elements must have an accessible name
WCAG 1.1.1
Non-text Content
Screen reader users rely on text alternatives to understand the purpose of images and image-based controls. Without accurate alternatives, critical information
<svg role="img"> must have an accessible name
WCAG 1.1.1
Non-text Content
Screen reader users rely on text alternatives to understand the purpose of images and image-based controls. Without accurate alternatives, critical information
Provide captions for all prerecorded audio content
WCAG 1.2.2
Captions (Prerecorded)
Deaf and hard-of-hearing users rely on captions to understand audio content. Without captions, they miss key information, especially for spoken dialogue or soun
Provide captions for all video content with audio
WCAG 1.2.2
Captions (Prerecorded)
Captions make video content accessible to deaf and hard-of-hearing users. They also help in noisy environments and improve comprehension for non-native speakers
Do not hide the document body with aria-hidden
WCAG 1.3.1
Info and Relationships
Setting aria-hidden="true" on the <body> or any top-level container removes all page content from the accessibility tree. Screen readers will have nothing to an
Ensure elements with ARIA roles that require children contain them
WCAG 1.3.1
Info and Relationships
Certain container roles such as list, menu, or tree rely on required child roles to define structure. Missing children prevent assistive technologies from under
Ensure ARIA elements are inside required parent roles
WCAG 1.3.1
Info and Relationships
Some ARIA roles depend on specific parent contexts to provide meaning. A listitem outside of a list or a menuitem outside of a menu leaves screen-reader users w
<dl> must contain properly-ordered <dt>/<dd> groups
WCAG 1.3.1
Info and Relationships
Assistive technologies depend on semantic structure to convey relationships (terms/definitions, list items, table headers). Invalid structures break navigation
<dt> and <dd> must be inside a <dl>
WCAG 1.3.1
Info and Relationships
Assistive technologies depend on semantic structure to convey relationships (terms/definitions, list items, table headers). Invalid structures break navigation
Headings should not be empty
WCAG 1.3.1
Info and Relationships
Screen reader users rely on headings to understand and navigate page structure. Empty headings create false landmarks in the accessibility tree, causing confusi
Use proper heading hierarchy
WCAG 1.3.1
Info and Relationships
Headings define the structure of your content for screen readers and keyboard users. When heading levels are skipped or out of order, navigation becomes confusi
Hidden content on the page should be analyzed
WCAG 1.3.1
Info and Relationships
Hidden content can create confusion for screen reader and keyboard users if it remains programmatically available when not visible. For example, off-screen menu
Banner landmark should not be contained in another landmark
WCAG 1.3.1
Info and Relationships
A banner landmark identifies site-wide content like a header. Nesting it inside another landmark breaks landmark navigation for assistive technologies.
Aside should not be contained in another landmark
WCAG 1.3.1
Info and Relationships
Complementary landmarks identify supporting content (like sidebars). Nesting them inside other landmarks makes them difficult for screen readers to locate.
Contentinfo landmark should not be contained in another landmark
WCAG 1.3.1
Info and Relationships
The contentinfo (typically <footer>) represents site-level information. If it’s nested, screen readers may announce it in the wrong context.
Main landmark should not be contained in another landmark
WCAG 1.3.1
Info and Relationships
The main landmark represents the unique primary content of a page. Nesting it breaks navigation and may confuse assistive technologies.
Document should not have more than one banner landmark
WCAG 1.3.1
Info and Relationships
Multiple banners confuse screen reader users because they expect only one header landmark representing the site’s top-level identity.
Document should not have more than one contentinfo landmark
WCAG 1.3.1
Info and Relationships
Screen reader users expect one contentinfo landmark (footer). Multiple confuse navigation and document structure.
Document should not have more than one main landmark
WCAG 1.3.1
Info and Relationships
There must only be one <main> landmark per page so assistive tech can jump directly to the primary content.
Ensure exactly one <main> landmark per page
WCAG 1.3.1
Info and Relationships
Multiple <main> elements confuse assistive technologies, as there should only be one main content area per page.
Landmarks should have a unique role or role/label/title (i.e. accessible name) combination
WCAG 1.3.1
Info and Relationships
Screen reader users rely on unique landmark regions for quick navigation. When multiple landmarks share the same role and name, they become indistinguishable —
Ensure lists are structured with semantic HTML
WCAG 1.3.1
Info and Relationships
Lists must use <ul>, <ol>, and <li> elements so assistive technologies can announce list lengths and items properly.
<li> elements must be inside a <ul> or <ol>
WCAG 1.3.1
Info and Relationships
Assistive technologies depend on semantic structure to convey relationships (terms/definitions, list items, table headers). Invalid structures break navigation
Do not use <p> as a heading
WCAG 1.3.1
Info and Relationships
Assistive technologies depend on semantic structure to convey relationships (terms/definitions, list items, table headers). Invalid structures break navigation
Provide landmark regions for major page areas
WCAG 1.3.1
Info and Relationships
Landmarks like banner, navigation, and main allow screen reader users to jump directly to key sections without reading everything linearly.
scope attribute should be used correctly
WCAG 1.3.1
Info and Relationships
Screen readers use the `scope` attribute on table headers to understand how header cells relate to data cells. Incorrect or misplaced scope values can make data
Use <caption> to provide a table caption
WCAG 1.3.1
Info and Relationships
Assistive technologies depend on semantic structure to convey relationships (terms/definitions, list items, table headers). Invalid structures break navigation
Data cells in larger tables must have associated headers
WCAG 1.3.1
Info and Relationships
Assistive technologies depend on semantic structure to convey relationships (terms/definitions, list items, table headers). Invalid structures break navigation
Cells using headers attribute must reference cells in the same table
WCAG 1.3.1
Info and Relationships
Assistive technologies depend on semantic structure to convey relationships (terms/definitions, list items, table headers). Invalid structures break navigation
Table headers must have data cells
WCAG 1.3.1
Info and Relationships
Assistive technologies depend on semantic structure to convey relationships (terms/definitions, list items, table headers). Invalid structures break navigation
Do not lock display orientation with CSS
WCAG 1.3.4
Orientation
Some users lock device orientation or cannot rotate the device. Forcing a single orientation can block access to content or controls.
Use valid autocomplete attributes for input fields
WCAG 1.3.5
Identify Input Purpose
Proper autocomplete values help browsers and assistive technologies identify input purposes (like name, email, or address). Invalid or missing values reduce acc
Ensure links within text blocks are visually distinguishable
WCAG 1.4.1
Use of Color
Users should be able to identify links without relying solely on color differences. If links blend with surrounding text, users may not realize they are interac
Do not autoplay audio
WCAG 1.4.2
Audio Control
Auto‑playing audio interferes with screen reader output and concentration, making pages unusable for many users.
Ensure sufficient color contrast between text and background
WCAG 1.4.3
Contrast (Minimum)
Low contrast text is difficult or impossible to read for users with low vision or color blindness. This includes common real-world cases like gray-on-gray text
Do not disable zoom with meta viewport
WCAG 1.4.4
Resize Text
Disabling zoom prevents users from enlarging text for readability and comfort.
Users should be able to zoom and scale the text up to 500%
WCAG 1.4.4
Resize text
Many users with low vision or on small screens rely on pinch-to-zoom or browser text scaling. Preventing zoom or limiting scaling makes text unreadable and viol
Provide enhanced contrast for critical UI components
WCAG 1.4.6
Contrast (Enhanced)
Enhanced contrast benefits users with more severe visual impairments or in low-light environments. While not mandatory for AA conformance, it reflects accessibi
Inline text must support user spacing overrides
WCAG 1.4.12
Text Spacing
Users may increase line and letter spacing for readability. Content must remain usable when spacing is adjusted.

Operable (WCAG 2.x.x)18 rules

Iframes with focusable content must be keyboard reachable
WCAG 2.1.1
Keyboard
Keyboard‑only users must be able to reach and operate all content, including iframes and scrollable regions.
Scrollable regions must be focusable
WCAG 2.1.1
Keyboard
Keyboard‑only users must be able to reach and operate all content, including iframes and scrollable regions.
Avoid server-side image maps
WCAG 2.1.1
Keyboard
Keyboard‑only users must be able to reach and operate all content, including iframes and scrollable regions.
accesskey attribute value should be unique
WCAG 2.1.4
Character Key Shortcuts
When multiple elements share the same access key, or when access keys conflict with browser or assistive technology shortcuts, users can lose control of navigat
Avoid timed refresh/redirects under 20 hours
WCAG 2.2.1
Timing Adjustable
Unexpected time limits can cause loss of data and disorientation, especially for users who need more time.
<blink> elements must not be used
WCAG 2.2.2
Pause, Stop, Hide
Moving, blinking, or scrolling content can distract or cause discomfort. Users need the ability to pause, stop, or hide it.
<marquee> elements must not be used
WCAG 2.2.2
Pause, Stop, Hide
Moving, blinking, or scrolling content can distract or cause discomfort. Users need the ability to pause, stop, or hide it.
Avoid timed refresh/redirects
WCAG 2.2.4
Interruptions
Unexpected updates and redirects interrupt users and can break assistive technology workflows.
Provide a way to bypass repeated blocks
WCAG 2.4.1
Bypass Blocks
Bypassing repeated navigation lets keyboard users reach main content quickly.
Provide a skip link to bypass repetitive navigation
WCAG 2.4.1
Bypass Blocks
Screen reader and keyboard users shouldn’t have to tab through navigation menus on every page before reaching the main content. Skip links provide a faster, mor
Ensure each page has a descriptive and unique title
WCAG 2.4.2
Page Titled
The page title is the first thing screen readers announce when a new page loads. Missing or generic titles make navigation confusing, especially for users relyi
Maintain logical and semantic focus order across the page
WCAG 2.4.3
Focus Order
The order in which elements receive focus should match the visual and logical reading order. A mismatch confuses screen reader users and causes navigational err
Elements should not have tabindex greater than zero
WCAG 2.4.3
Focus Order
Keyboard-only and assistive technology users rely on predictable tab order to navigate a page. Using positive tabindex values (greater than 0) breaks the natura
Ensure links have descriptive accessible names
WCAG 2.4.4
Link Purpose (In Context)
Links like 'Click here' or 'Read more' are meaningless to screen reader users out of context. Descriptive link text makes navigation easier.
Ensure each page has one top-level heading
WCAG 2.4.6
Headings and Labels
Screen readers use the main heading to summarize page content. Missing a top-level heading makes orientation harder for users navigating between pages.
Identical link text should have the same purpose
WCAG 2.4.9
Link Purpose (Link Only)
When multiple links have the same text but different destinations, users can’t tell them apart.
Visible label must be included in the accessible name
WCAG 2.5.3
Label in Name
Voice control and screen reader users rely on the visible label being included in the accessible name.
Ensure interactive targets are large enough to activate easily
WCAG 2.5.5
Target Size
Small or tightly packed touch targets are difficult to activate for users with limited dexterity or tremors. Increasing target size and spacing improves usabili

Understandable (WCAG 3.x.x)6 rules

Specify the primary language of the page
WCAG 3.1.1
Language of Page
Assistive technologies rely on the page's language to use correct pronunciation and grammar rules. Missing or incorrect `lang` attributes can cause mispronuncia
Use valid language codes in the lang attribute
WCAG 3.1.1
Language of Page
Invalid language codes prevent assistive technologies from determining pronunciation rules. For example, `lang='english'` is invalid — it must be `lang='en'`.
lang and xml:lang values must match
WCAG 3.1.1
Language of Page
Correct language declarations ensure proper pronunciation and processing by assistive technologies.
Use valid language codes in the `lang` attribute
WCAG 3.1.1
Language of Page
Assistive technologies depend on standardized language codes to apply correct pronunciation and braille translation rules. Invalid or misspelled codes can cause
Avoid assigning multiple labels to a single form field
WCAG 3.3.2
Labels or Instructions
Having multiple labels for one field creates ambiguity — screen readers may read only one or merge them incorrectly, confusing users about the purpose of the fi
Ensure every form control has an accessible label
WCAG 3.3.2
Labels or Instructions
Users of assistive technologies depend on labels to understand the purpose of each input field. A missing or unclear label makes it impossible for screen reader

Robust (WCAG 4.x.x)24 rules

id attribute values must be unique
WCAG 4.1.1
Parsing
Duplicate IDs and malformed markup confuse assistive technologies and scripts that depend on unique identifiers.
IDs of active elements must be unique
WCAG 4.1.1
Parsing
Duplicate IDs and malformed markup confuse assistive technologies and scripts that depend on unique identifiers.
IDs used by ARIA and labels must be unique
WCAG 4.1.1
Parsing
Duplicate IDs and malformed markup confuse assistive technologies and scripts that depend on unique identifiers.
Use only valid ARIA attributes for each role
WCAG 4.1.2
Name, Role, Value
ARIA attributes help assistive technologies interpret interactive components on a page. When developers use attributes not supported for a given role, screen re
Provide non-braille equivalents for braille ARIA attributes
WCAG 4.1.2
Name, Role, Value
Some assistive technologies display information through refreshable braille devices. ARIA braille attributes, such as aria-braillelabel or aria-brailleroledescr
Ensure ARIA buttons, links, and menu items have accessible names
WCAG 4.1.2
Name, Role, Value
ARIA buttons, links, and menu items that lack accessible names are completely silent to screen readers. While visual users can see the label or icon, non-visual
Use ARIA attributes only when allowed for a role
WCAG 4.1.2
Name, Role, Value
Misusing ARIA attributes can create contradictory signals for assistive technologies. For instance, using aria-label on a purely decorative element or combining
Avoid deprecated ARIA roles
WCAG 4.1.2
Name, Role, Value
Deprecated ARIA roles have been removed or replaced in newer versions of the WAI-ARIA specification. Continuing to use them can lead to inconsistent or incorrec
Do not allow focus on aria-hidden elements
WCAG 4.1.2
Name, Role, Value
When focusable elements remain active inside containers marked aria-hidden="true", keyboard and screen-reader users can reach elements that are visually and sem
ARIA input fields must have an accessible name
WCAG 4.1.2
Name, Role, Value
Every form control or input field must have an accessible name so assistive technologies can communicate its purpose to users. Without a name, screen reader use
Avoid ARIA attributes that are prohibited for an element’s role
WCAG 4.1.2
Name, Role, Value
Each ARIA role defines a specific set of supported and prohibited attributes. Adding attributes that are not allowed for a given role can create conflicting sem
Include all required ARIA attributes for elements with roles
WCAG 4.1.2
Name, Role, Value
If an element uses a role that requires specific ARIA attributes, assistive technologies expect them to be present. Missing required attributes can cause incomp
Use aria-roledescription only when an explicit role exists
WCAG 4.1.2
Name, Role, Value
aria-roledescription allows developers to customize how a role is announced, but applying it without a base role removes semantic clarity. Screen readers may sk
Use only valid ARIA role values
WCAG 4.1.2
Name, Role, Value
ARIA roles define how assistive technologies interpret elements. When an element uses an invalid or misspelled role value, screen readers cannot identify its pu
ARIA toggle fields must have accessible names
WCAG 4.1.2
Name, Role, Value
Toggle controls such as switches or checkboxes indicate binary states. Without an accessible name, screen reader users know a control exists but not what it doe
Use only valid ARIA attributes
WCAG 4.1.2
Name, Role, Value
Invalid or misspelled ARIA attributes break compatibility with assistive technologies. Because screen readers depend on standardized attribute names, a small ty
ARIA attribute values must be valid
WCAG 4.1.2
Name, Role, Value
Assistive technologies require correct names, roles, and states to announce and operate controls reliably.
Buttons must have discernible text
WCAG 4.1.2
Name, Role, Value
Assistive technologies require correct names, roles, and states to announce and operate controls reliably.
Iframes must have a descriptive title
WCAG 4.1.2
Name, Role, Value
Assistive technologies require correct names, roles, and states to announce and operate controls reliably.
Iframe titles must be unique
WCAG 4.1.2
Name, Role, Value
Assistive technologies require correct names, roles, and states to announce and operate controls reliably.
Provide accessible names for buttons and input elements
WCAG 4.1.2
Name, Role, Value
Buttons and inputs without accessible names are invisible to screen reader users. They can tab to them but will hear 'button' or 'input' with no description of
Do not nest interactive controls
WCAG 4.1.2
Name, Role, Value
Assistive technologies require correct names, roles, and states to announce and operate controls reliably.
Select elements must have accessible names
WCAG 4.1.2
Name, Role, Value
Assistive technologies require correct names, roles, and states to announce and operate controls reliably.
<summary> must have discernible text
WCAG 4.1.2
Name, Role, Value
Assistive technologies require correct names, roles, and states to announce and operate controls reliably.

Unmapped (no WCAG ID)10 rules

ARIA role should be appropriate for the element
Unmapped
Assistive technologies rely on accurate names, roles, states, and relationships. Incorrect ARIA makes controls confusing or silent.
ARIA dialog and alertdialog nodes should have an accessible name
Unmapped
Assistive technologies rely on accurate names, roles, states, and relationships. Incorrect ARIA makes controls confusing or silent.
"role=text" should have no focusable descendants
Unmapped
Assistive technologies rely on accurate names, roles, states, and relationships. Incorrect ARIA makes controls confusing or silent.
ARIA treeitem nodes should have an accessible name
Unmapped
Assistive technologies rely on accurate names, roles, states, and relationships. Incorrect ARIA makes controls confusing or silent.
Table header text should not be empty
Unmapped
Table header text should not be empty
Frames should be tested with axe-core
Unmapped
Semantic structure communicates relationships and hierarchy to assistive technologies and keyboard navigation.
Alternative text of images should not be repeated as text
Unmapped
Screen reader users need text alternatives to understand images and image-based controls.
Form elements should have a visible label
Unmapped
Form controls need clear, programmatic labels so assistive technologies can announce purpose and instructions.
Ensure elements marked as presentational are consistently ignored
Unmapped
Assistive technologies rely on accurate names, roles, states, and relationships. Incorrect ARIA makes controls confusing or silent.
Tables should not have the same summary and caption
Unmapped
Tables should not have the same summary and caption