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.
Perceivable (WCAG 1.x.x)
58 guidelines · Perceivable
- 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
- WCAG 1.1.1Non-text Content
Screen readers cannot interpret images. Without alternative text, users who are blind or have low vision miss important information or context. Alternative text
- 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)
Prerecorded audio-only content (like podcasts or announcements) and video-only content (like silent demos or animations) are not usable for everyone by default.
- 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)
Prerecorded video content without captions is inaccessible to people who are deaf, hard of hearing, or who cannot play audio in their environment. Captions ensu
- WCAG 1.2.3Audio Description or Media Alternative (Prerecorded)
Many videos contain important visual information that is not spoken aloud — such as actions, scene changes, text on screen, or graphical instructions. Users who
- WCAG 1.2.4Captions (Live)
Live video events—such as webinars, announcements, interviews, and streaming sessions—often contain spoken information that deaf or hard-of-hearing users cannot
- 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)
Many prerecorded videos contain important visual information—such as actions, gestures, scene changes, or on-screen text—that is not spoken aloud. Users who are
- 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
If content is hidden visually but still exposed to screen readers or remains focusable, users may hear or tab to elements they cannot see. This breaks navigatio
- 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 physically rotate their device or may have orientation lock enabled. If the UI is forced into only portrait or landscape, those users may be u
- WCAG 1.3.5Identify Input Purpose
Valid `autocomplete` values allow browsers, password managers, and assistive technologies to recognize the purpose of form fields. Missing or incorrect values i
- WCAG 1.4.1Use of Color
Users must be able to identify what is clickable without relying on color alone. Relying solely on color excludes users with low vision, color blindness, differ
- 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
Many users with low vision or on small screens depend on system zoom and pinch-to-zoom to read comfortably. If zoom is disabled or limited, users may be unable
- 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
Keyboard-only and screen reader users must be able to move focus into an iframe to interact with its content. If an iframe is removed from the tab order or has
- 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
Keyboard users must be able to move focus freely throughout the interface. If focus becomes stuck inside a component and cannot be moved using Tab and Shift+Tab
- WCAG 2.1.4Character Key Shortcuts
If two or more elements share the same access key, or if access keys conflict with system, browser, or assistive technology shortcuts, users may trigger uninten
- WCAG 2.2.1Timing Adjustable
Timed refreshes and automatic redirects can cause users to lose progress, context, or entered information without warning. People with mobility, cognitive, or s
- WCAG 2.2.2Pause, Stop, Hide
Blinking text can distract or harm users with attention, vestibular, or cognitive disabilities. The <blink> element cannot be paused, stopped, or hidden, and is
- 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
Automatic refreshes or redirects interrupt a user's workflow without their consent. These interruptions can reset context, break form entry, disrupt screen read
- WCAG 2.4.1Bypass Blocks
Without a skip link, keyboard and screen reader users must tab through navigation and repeated interface elements on every page load. This creates unnecessary e
- 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
Screen readers announce the page title first when a page loads. The title is also what appears in browser tabs, bookmarks, window switchers, and task switchers.
- 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 users move through interactive elements using the Tab key. If the visual layout does not match the focus order (e.g., due to CSS reordering, flex direc
- 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)
Screen reader users often navigate by bringing up a list of links. If link text is vague — like “Click here,” “Read more,” or “Learn more” — the user cannot det
- WCAG 2.4.6Headings and Labels
The <h1> is the page's main subject. Screen reader users rely on it to understand where they are and what the page is about. If the page lacks a clear <h1>, or
- 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
If focusable elements have no visible or meaningful text, users who rely on keyboard or screen readers cannot determine the element's purpose. This leads to con
- 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