WCAG 1.1.1Non-text Content
Screen reader users rely on text alternatives to understand the purpose of image map controls. Without an accessible name on an <area> element, users cannot det
Accessibility Guidelines Explained
A practical WCAG guide covering requirements, code examples, and testing considerations to help teams understand and implement accessible interfaces.
These accessibility guidelines complement the official WCAG 2.2 standards. Each guide provides actionable, developer-focused explanations with real-world code examples to help you identify and resolve accessibility issues effectively.
Browse by WCAG principle or search for specific guidelines to find detailed implementation guidance, code examples, and testing strategies.
Sort:
Perceivable (WCAG 1.x.x)
58 guidelines · Perceivable
- WCAG 1.1.1Non-text Content
If a meaningful image has no alt text, screen reader users miss the same information sighted users get instantly. That can hide key instructions, statuses, or o
- WCAG 1.1.1Non-text Content
When the same information is conveyed both in an image and in nearby text, providing alt text that repeats the same text causes screen reader users to hear it t
- WCAG 1.1.1Non-text Content
Screen reader users need alternative text to understand what an image-based button does. Without an `alt` attribute, the control is announced only as 'button' o
- WCAG 1.1.1Non-text Content
Assistive technologies cannot interpret the visual content of embedded objects like custom charts, maps, media players, PDFs, or legacy applets. If an `<object>
- WCAG 1.1.1Non-text Content
Elements with role="img" are treated as images by assistive technologies. If they do not have an accessible name, screen readers announce nothing — users miss i
- WCAG 1.1.1Non-text Content
When an inline <svg> is given role="img", assistive technologies treat it like an image. Without an accessible name, screen readers announce nothing — users hav
- WCAG 1.1.1Non-text Content
Decorative images do not provide meaningful information. If they are announced by assistive technology, they add noise to the reading experience and make it har
- WCAG 1.1.1Non-text Content
Meaningful SVGs are often used as icons or data visuals. Without a text alternative, screen reader users cannot understand what the graphic represents, leading
- WCAG 1.2.1Audio-only and Video-only (Prerecorded)
Users who are deaf or hard of hearing cannot access audio-only content without a text alternative. Transcripts provide full access to spoken dialogue and import
- WCAG 1.2.1Audio-only and Video-only (Prerecorded)
Audio-only and video-only media each block a different user group unless you provide an equivalent alternative. Without that equivalent, users miss core content
- WCAG 1.2.2Captions (Prerecorded)
Captions are essential for deaf and hard-of-hearing users to understand video content. They also support comprehension in noisy or muted environments and help n
- WCAG 1.2.2Captions (Prerecorded)
Without captions, prerecorded video audio is unavailable to deaf and hard-of-hearing users, and difficult in muted/noisy environments. Captions are often the on
- WCAG 1.2.3Audio Description or Media Alternative (Prerecorded)
Captions cover audio, but they do not describe visual-only meaning. If key information appears only on screen, blind and low-vision users miss content unless yo
- WCAG 1.2.4Captions (Live)
Live events are often time-sensitive. Without live captions, deaf and hard-of-hearing users can miss announcements, decisions, and instructions in real time.
- WCAG 1.2.5Audio Description (Pre-recorded)
Users who are blind or have low vision cannot perceive essential visual information in videos. Without audio descriptions, they miss key actions, scene changes,
- WCAG 1.2.5Audio Description (Prerecorded)
When key meaning is visual-only, blind and low-vision users miss essential information unless audio description is provided.
- WCAG 1.3.1Info and Relationships
Setting `aria-hidden="true"` on `<body>` or top-level containers removes all content from the accessibility tree. Screen readers announce nothing, making the pa
- WCAG 1.3.1Info and Relationships
ARIA container roles rely on specific child roles to convey structure. For example, a `list` must contain `listitem`s and a `menu` must contain `menuitem`s. Mis
- WCAG 1.3.1Info and Relationships
Some ARIA roles only function correctly within specific parent roles. For example, a `listitem` must be inside a `list`, and a `menuitem` inside a `menu`. Missi
- WCAG 1.3.1Info and Relationships
Screen readers announce definition lists by pairing each term (<dt>) with its corresponding definition (<dd>). If the structure is broken, users cannot understa
- WCAG 1.3.1Info and Relationships
<dt> and <dd> communicate a term–description relationship. Screen readers announce <dt> as the label and <dd> as the value. If these elements are used outside o
- WCAG 1.3.1Info and Relationships
Screen reader users navigate pages by jumping between headings. An empty heading creates a meaningless stop in the navigation order, forcing users to guess what
- WCAG 1.3.1Info and Relationships
Screen reader users rely on table headers to understand what each column or row represents. If a <th> is empty or unclear, users cannot make sense of the associ
- WCAG 1.3.1Info and Relationships
Headings form the structural outline of the page and guide screen reader navigation. If heading levels are skipped or used inconsistently, users lose understand
- WCAG 1.3.1Info and Relationships
Hidden UI that is still focusable or announced creates a broken experience: users can land on controls they cannot see and lose context.
- WCAG 1.3.1Info and Relationships
The banner landmark identifies site-wide header content. Assistive technology users rely on landmark navigation to move quickly across major regions of a page.
- WCAG 1.3.1Info and Relationships
The complementary landmark identifies content that supports, but is not essential to, the main content. Screen reader users rely on landmark navigation to move
- WCAG 1.3.1Info and Relationships
The `contentinfo` landmark identifies site-wide footer information such as copyright, legal links, or global navigation aids. Screen reader users rely on landma
- WCAG 1.3.1Info and Relationships
The `main` landmark identifies the unique, primary content of a page. Screen reader and keyboard users rely on this region to skip repetitive navigation and rea
- WCAG 1.3.1Info and Relationships
The `banner` landmark identifies the site-wide header region. Screen reader users rely on this landmark to understand where the global identity and navigation b
- WCAG 1.3.1Info and Relationships
The `contentinfo` landmark identifies the site-level footer that applies to the whole experience. Screen reader users rely on it to jump to global information o
- WCAG 1.3.1Info and Relationships
The `main` landmark identifies the primary content of the page. Screen reader and keyboard users rely on landmark navigation to jump directly to it. If multiple
- WCAG 1.3.1Info and Relationships
The `main` landmark identifies the primary content of the page. Assistive technology users rely on it to skip past navigation and reach the main content efficie
- WCAG 1.3.1Info and Relationships
Screen reader users navigate pages by jumping between landmarks such as navigation, main content, and complementary regions. If multiple landmarks share the sam
- WCAG 1.3.1Info and Relationships
Assistive technologies rely on semantic lists to communicate list structure, including the number of items. When lists are faked using <div> or <p> elements, sc
- WCAG 1.3.1Info and Relationships
Screen readers expect list items to be part of a semantic list structure. When `<li>` elements are placed outside of `<ul>` or `<ol>`, assistive technologies ca
- WCAG 1.3.1Info and Relationships
Screen reader and keyboard users rely on headings to navigate a page quickly. If a paragraph tag is visually styled to look like a heading, assistive technologi
- Do not use role="presentation" or role="none" on elements that contain meaningful or interactive contentWCAG 1.3.1Info and Relationships
The role="presentation" and role="none" attributes remove an element's semantics from the accessibility tree. If the element (or its children) contains interact
- WCAG 1.3.1Info and Relationships
Landmarks such as header, navigation, main content, complementary sidebars, and footer allow screen reader users to jump directly to key areas of a page. Withou
- WCAG 1.3.1Info and Relationships
Screen readers rely on table header associations to announce column and row context while navigating cells. If `scope` is missing, incorrect, or placed on the w
- WCAG 1.3.1Info and Relationships
Screen readers announce the table caption and may also announce the summary. If both contain the same text, the user hears the same information twice. This incr
- WCAG 1.3.1Info and Relationships
Screen reader users depend on a table's caption to understand its purpose before navigating any rows. If a table title is visually placed inside the first row i
- WCAG 1.3.1Info and Relationships
Screen reader users navigate tables by having header cells announced alongside each data cell. If <td> cells are not associated with <th> headers, the table bec
- WCAG 1.3.1Info and Relationships
Screen readers use the `headers` attribute on <td> to announce which header cells apply to that data cell. If the `headers` value points to an ID that does not
- WCAG 1.3.1Info and Relationships
A <th> defines a label for one or more data cells. If a table contains <th> elements without any corresponding <td> cells, screen readers treat the table as hav
- WCAG 1.3.1Info and Relationships
If a label is visible on screen but hidden from assistive technology, screen reader users receive no label and cannot understand the purpose of the form field.
- WCAG 1.3.1Info and Relationships
Screen reader users rely on landmarks to navigate quickly. Multiple page-level contentinfo regions cause confusion because each one appears as a separate footer
- WCAG 1.3.1Info and Relationships
When lists contain elements other than <li>, assistive technologies cannot interpret the list structure. Screen readers may skip items or fail to announce the c
- WCAG 1.3.4Orientation
Some users cannot rotate devices easily or use system orientation lock. If content works in only one orientation, critical tasks can become unusable.
- WCAG 1.3.5Identify Input Purpose
Correct autocomplete tokens help browsers and assistive tech identify field purpose and reduce typing effort. Invalid tokens break autofill and make forms harde
- WCAG 1.4.1Use of Color
If links are distinguished by color alone, many users cannot reliably detect what is interactive.
- WCAG 1.4.2Audio Control
When audio plays automatically, it competes with screen reader speech and overwhelms users who rely on auditory processing. It can also startle users, cause con
- WCAG 1.4.3Contrast (Minimum)
Low contrast text is difficult or impossible to read for users with low vision, color blindness, or visual fatigue. When contrast is insufficient, essential inf
- WCAG 1.4.4Resize Text
Many users rely on pinch-to-zoom or browser zoom to read text comfortably. If zooming is disabled, users with low vision or cognitive fatigue may struggle to re
- WCAG 1.4.4Resize text
Users who need larger text depend on browser/device zoom. If zoom is restricted, reading and form completion can fail for low-vision users.
- WCAG 1.4.6Contrast (Enhanced)
Enhanced contrast helps users with low vision, users in bright or low-light environments, and users viewing screens on glare-heavy displays. While WCAG AA defin
- WCAG 1.4.12Text Spacing
Users with low vision, dyslexia, ADHD, or other cognitive needs may increase text spacing to improve readability. Fixed layouts or clipped text can make content
Operable (WCAG 2.x.x)
26 guidelines · Operable
- WCAG 2.1.1Keyboard
If keyboard focus cannot enter and operate embedded content, users lose access to that functionality entirely.
- WCAG 2.1.1Keyboard
If a container scrolls but cannot receive keyboard focus, users who rely on keyboard navigation cannot reach or scroll the content inside it. This often traps e
- WCAG 2.1.1Keyboard
Server-side image maps require users to click specific pixel coordinates to activate links. Keyboard and assistive technology users cannot target those coordina
- WCAG 2.1.2No Keyboard Trap
A keyboard trap blocks navigation and can prevent users from reaching primary actions or exiting components.
- WCAG 2.1.4Character Key Shortcuts
Single-character shortcuts can conflict with browser, OS, and assistive technology commands. Duplicate mappings add ambiguity, so users may trigger the wrong co
- WCAG 2.2.1Timing Adjustable
Timed page changes can interrupt reading, reset focus, and discard user input before tasks are complete.
- WCAG 2.2.2Pause, Stop, Hide
Uncontrolled blinking and moving content can distract users and make content hard to read or operate. If users cannot pause or stop the behavior, core tasks may
- WCAG 2.2.2Pause, Stop, Hide
Scrolling or automatically moving text can be distracting, disorienting, or even harmful for users with attention, vestibular, or cognitive conditions. The `<ma
- WCAG 2.2.4Interruptions
Unexpected refreshes or redirects interrupt reading and task completion, and can cause input loss. Users need control over when updates occur, especially during
- WCAG 2.4.1Bypass Blocks
When repeated headers, menus, and promo blocks come first, keyboard users must tab through the same controls on every page before reaching core content. This ad
- WCAG 2.4.1Bypass Blocks
Screen readers announce the title of a frame when focus enters it. If the title is missing or vague, users cannot understand what the embedded content is for (e
- WCAG 2.4.1Bypass Blocks
Screen readers announce the iframe title when users move focus into it. If the title is missing or generic, users cannot understand what the embedded content is
- WCAG 2.4.1Bypass Blocks
Screen readers announce the iframe title when users navigate between frames. If multiple iframes share the same title, users cannot tell which one contains whic
- WCAG 2.4.1Bypass Blocks
Keyboard and screen reader users must navigate sequentially. Without a skip link, they must tab through site navigation and repeated UI headers on every page lo
- WCAG 2.4.2Page Titled
The page title is the first orientation cue announced by screen readers and the primary label shown in browser tabs and history. Reused or vague titles make nav
- WCAG 2.4.2Page Titled
A blank or missing <title> leaves users—especially screen reader and tab-switching users—without context about what page they are on. The title is the first ele
- WCAG 2.4.3Focus Order
Keyboard and assistive-technology users depend on a predictable focus sequence. When focus jumps in an order that does not match the visual and semantic flow, u
- WCAG 2.4.3Focus Order
Keyboard and assistive technology users rely on a predictable, logical tab order. Positive tabindex values override the natural DOM order, causing focus to jump
- WCAG 2.4.4Link Purpose (In Context)
Assistive technology users often navigate by link lists outside of surrounding paragraph context. Generic link text forces guesswork and slows navigation becaus
- WCAG 2.4.6Headings and Labels
Clear, descriptive headings help users understand page structure and quickly find relevant sections. If headings are missing, vague, or inconsistent, both scree
- WCAG 2.4.7Focus Visible
Keyboard users depend on a visible focus indicator to understand where they are on the page. Without a clear focus outline or highlight, users can lose their po
- WCAG 2.4.7Focus Visible
Focusable elements without clear meaning create dead-end navigation for keyboard and assistive technology users. Users need a reliable name/purpose at every foc
- WCAG 2.4.9Link Purpose (Link Only)
Screen reader users often navigate by reading a list of links. If multiple links share the same text but lead to different destinations, users cannot tell which
- WCAG 2.5.3Label in Name
Speech recognition, voice control, and screen reader users expect that the words they see on the screen match what they must speak or navigate to. If the visibl
- WCAG 2.5.3Label in Name
The `title` attribute is inconsistently announced by screen readers and is not visible to keyboard or touch users. If it is the only label, users relying on ass
- WCAG 2.5.8Target Size (Minimum)
Small or tightly packed interactive elements require precision that many users do not have. People using touch screens, users with motor disabilities, tremors,
Understandable (WCAG 3.x.x)
7 guidelines · Understandable
- WCAG 3.1.1Language of Page
Screen readers and other assistive technologies rely on the page’s declared language to determine pronunciation, grammar rules, and reading patterns. Without a
- WCAG 3.1.1Language of Page
Screen readers and braille displays rely on the `lang` attribute to choose the correct pronunciation, accent, and reading rules. If the value is misspelled or n
- WCAG 3.1.1Language of Page
Some assistive technologies read language from `lang`, while others (especially those processing XML-based formats such as EPUB, XHTML, or PDF generators) use `
- WCAG 3.1.1Language of Page
Screen readers and translation tools rely on standardized language codes to select the correct voice and pronunciation. Invalid or misspelled codes lead to inco
- WCAG 3.3.2Labels or Instructions
Screen readers derive an input's accessible name from its label. If multiple labels reference the same input, only one label may be announced, or the text may b
- WCAG 3.3.2Labels or Instructions
Labels tell users what information is expected in each form field. Without an accessible label, screen readers announce only the control type (e.g., 'edit text'
- WCAG 3.3.2Labels or Instructions
Screen reader and keyboard-only users rely on labels to understand the purpose of form controls. If a form field has no visible label, the user may hear only 'e
Robust (WCAG 4.x.x)
36 guidelines · Robust
- WCAG 4.1.1Parsing
IDs are used to create explicit relationships in accessibility (e.g., labels, error messages, descriptions). If two elements share the same ID, assistive techno
- WCAG 4.1.1Parsing
IDs are used to form accessibility relationships, such as associating labels with form inputs or linking elements using aria-controls and aria-describedby. If m
- WCAG 4.1.1Parsing
ARIA relationships such as aria-labelledby, aria-describedby, aria-controls, and aria-owns rely on unique IDs to bind elements together. If multiple elements sh
- WCAG 4.1.2Name, Role, Value
Assigning ARIA attributes that are not supported by an element's role can cause assistive technologies to ignore or misinterpret the element’s behavior. This le
- WCAG 4.1.2Name, Role, Value
Screen readers rely on roles to interpret elements. Assigning an invalid or conflicting role can cause incorrect or misleading announcements, breaking accessibi
- WCAG 4.1.2Name, Role, Value
Braille-specific ARIA attributes (like `aria-braillelabel` and `aria-brailleroledescription`) are only read on braille displays. Without a standard accessible n
- WCAG 4.1.2Name, Role, Value
Screen readers announce interactive elements by their accessible name. Without a name, ARIA buttons, links, or menu items are announced generically, making them
- WCAG 4.1.2Name, Role, Value
Roles like `presentation` or `none` remove semantic meaning. Adding ARIA attributes (like `aria-label` or `aria-describedby`) creates conflicting information fo
- WCAG 4.1.2Name, Role, Value
Deprecated ARIA roles are no longer recognized by modern assistive technologies. Using them can cause screen readers to ignore elements or announce them incorre
- WCAG 4.1.2Name, Role, Value
Screen readers announce dialogs immediately when they appear. Without an accessible name, users only hear 'dialog' with no context, making it unclear what the d
- WCAG 4.1.2Name, Role, Value
Elements inside containers with `aria-hidden="true"` are removed from the accessibility tree. If focusable elements remain inside, keyboard users can tab into t
- WCAG 4.1.2Name, Role, Value
Elements with `aria-hidden="true"` are removed from the accessibility tree. If such elements remain keyboard-focusable, users may tab into controls that provide
- WCAG 4.1.2Name, Role, Value
Screen readers rely on an accessible name to convey the purpose of form fields. Without it, users hear only a generic role such as 'edit text', making form comp
- WCAG 4.1.2Name, Role, Value
A meter conveys a numeric value within a range, such as storage usage or battery level. Without an accessible name, screen readers announce only the numeric val
- WCAG 4.1.2Name, Role, Value
Progress bars convey the state of an ongoing process. Without an accessible name, screen reader users hear only numeric values without context, making it imposs
- WCAG 4.1.2Name, Role, Value
Each ARIA role specifies which attributes are allowed. Using prohibited attributes sends conflicting signals to assistive technologies, causing elements to be i
- WCAG 4.1.2Name, Role, Value
Many ARIA roles need specific attributes to convey state and behavior. Missing required attributes can cause screen readers to announce controls incorrectly or
- WCAG 4.1.2Name, Role, Value
`aria-roledescription` customizes how an element's role is announced, but does not replace underlying semantics. Using it without a valid role or with misleadin
- WCAG 4.1.2Name, Role, Value
ARIA roles inform assistive technologies about the type of UI component an element represents. Misspelled, outdated, or undefined roles are ignored, causing con
- WCAG 4.1.2Name, Role, Value
The `role="text"` causes assistive technologies to treat the content as plain text and ignore semantic meaning. Placing links, buttons, or other interactive ele
- WCAG 4.1.2Name, Role, Value
Toggle controls like switches or checkboxes communicate a binary state. Without an accessible name, screen reader users cannot understand what the toggle contro
- WCAG 4.1.2Name, Role, Value
Tooltips without accessible text or proper association are invisible to screen reader users. This prevents users from accessing supplemental information, leadin
- WCAG 4.1.2Name, Role, Value
Tree items without accessible names are announced only as 'treeitem' by screen readers. Users cannot understand the purpose or content of nodes, making hierarch
- WCAG 4.1.2Name, Role, Value
Assistive technologies depend on correct ARIA attribute names. Misspelled, outdated, or unsupported attributes are ignored, which can remove labels, hide descri
- WCAG 4.1.2Name, Role, Value
ARIA attributes convey state and behavior to assistive technologies. Using unsupported or incorrect values can cause screen readers to misinterpret or ignore th
- WCAG 4.1.2Name, Role, Value
Screen readers announce buttons using their accessible name. If a button has no name, users cannot determine what action it performs, making key interactions in
- WCAG 4.1.2Name, Role, Value
Screen reader users rely on accessible names to understand what a control does. If a button or input has no name, the screen reader announces only its type (e.g
- WCAG 4.1.2Name, Role, Value
Interactive elements such as links, buttons, and form controls are meant to be independent focusable controls. If one is nested inside another (e.g., a button i
- WCAG 4.1.2Name, Role, Value
Without an accessible name, screen reader users only hear “combo box” or “menu” with no indication of what information is expected. This makes it impossible to
- WCAG 4.1.2Name, Role, Value
The <summary> element is the interactive label for the <details> disclosure widget. If <summary> has no visible text, assistive technologies cannot announce wha
- WCAG 4.1.2Name, Role, Value
Screen readers announce the purpose of controls based on their accessible name. Icon-only buttons and controls without visible text need an explicit name or the
- WCAG 4.1.2Name, Role, Value
When a control has visible text, screen readers should announce that same text to ensure consistent understanding for all users. Without accessible naming, user
- WCAG 4.1.2Name, Role, Value
If a focusable element has no accessible name, screen reader users cannot determine its purpose. They may hear only 'button' or 'link', which provides no meanin
- WCAG 4.1.2Name, Role, Value
Invalid or misspelled ARIA attributes are ignored by assistive technologies. This results in elements not being announced as intended, causing confusion and pot
- WCAG 4.1.2Name, Role, Value
If an element can receive keyboard focus but lacks an accessible name, screen reader users cannot understand its purpose. The user may hear only 'button' or 'li
- WCAG 4.1.2Name, Role, Value
If a disabled element can still receive focus, keyboard and assistive technology users may assume it is interactive. This creates confusion and disrupts expecte
Need a WCAG 2.2 compliance test reference your team can execute?
For QA: Map each failure to a specific WCAG requirement with clear pass/fail logic.
For engineering: Use implementation-focused guidance and examples to resolve issues without guesswork.
For compliance: Build audit-ready documentation aligned with WCAG 2.2, EAA, and EN 301 549 expectations.
Also use our accessibility scanner for websites and WCAG contrast checker while aligning policy requirements in the EAA compliance guide.