Fix the accessibility issues that fail WCAG
Plain-language guides to the most common WCAG 2.2 AA failures, each with the exact before-and-after code. Find yours below, or scan your site to see which ones you have.
Scan your site freeInteractive elements
Links must have discernible text
A link needs text that describes where it goes. Icon-only or empty links are announced as just “link”, leaving screen-reader users with no idea of their purpose.
Buttons must have an accessible name
Every button needs a discernible name. An icon-only button with no label is announced as “button”, so nobody using a screen reader knows what it does.
Form fields must have labels
Every input, textarea and select needs an associated label so users know what to enter and screen readers can announce the field.
Select menus must have an accessible name
A dropdown needs an associated label, otherwise its purpose is never announced and users cannot tell what they are choosing.
Avoid positive tabindex values
A tabindex greater than zero forces an unnatural focus order that confuses keyboard users. Keep the DOM order meaningful and use 0 or -1 only.
Hidden elements must not be focusable
An element with aria-hidden="true" must not contain focusable controls, or keyboard users tab onto targets a screen reader cannot see.
Tap targets must be big enough
Buttons, links and other controls should be at least 24×24 CSS pixels, or have 24px of spacing around them, so people with limited dexterity or on touchscreens do not hit the wrong one. New in WCAG 2.2.
Page structure & navigation
Every page needs a title
A unique, descriptive <title> lets people tell browser tabs and history entries apart, and is the first thing a screen reader announces.
The page must declare its language
The <html> element needs a lang attribute so screen readers use the right pronunciation and voice for the content.
Every page needs a top-level heading
A single <h1> that names the page’s main topic anchors the heading outline and orients assistive-tech users as soon as they arrive.
Headings must follow a logical order
Heading levels should not skip (an h2 followed by an h4), because the heading structure is how many assistive-tech users understand and navigate a page.
Every page needs one main landmark
Exactly one <main> landmark should mark the primary content, so screen-reader users can jump past navigation straight to it.
Content should sit inside landmarks
Wrapping content in landmark regions (header, nav, main, footer) lets screen-reader users jump straight to the part they want.
Provide a way to skip to the content
Keyboard and screen-reader users need a skip link, landmarks or headings to bypass the repeated header and reach the main content quickly.
Lists must be marked up as lists
Related items should use real <ul> or <ol> markup so assistive tech announces how many there are and that they belong together.
List items must be inside a list
An <li> must sit directly inside a <ul> or <ol>. On its own it loses the list semantics screen readers depend on.
ARIA references must point to unique IDs
When an id used by an ARIA attribute appears more than once, assistive tech resolves the wrong element and the relationship breaks.
Text alternatives & media
Images must have alt text
Every meaningful image needs alternative text so screen-reader users know what it shows. Decorative images should have an empty alt attribute so they are skipped.
Frames must have a title
Every <iframe> needs a title describing its content so screen-reader users can decide whether to move into it.
Color & zoom
Text must have enough color contrast
Text needs to contrast with its background so people with low vision can read it. The minimum is 4.5:1 for normal text and 3:1 for large text.
Do not block zoom
The viewport meta tag must not disable pinch-to-zoom or cap the scale. People with low vision rely on zooming text to read it.
Which of these does your site have?
Run a free scan to get a 0-100 score and the exact list of issues on your pages, each linked to its fix.
Scan your site free