Accessibility (WCAG) issues we check — and how to fix them
Ecommerce stores are among the most frequent recipients of ADA accessibility demand letters. We run WCAG 2.1 AA checks across your catalog, surface the barriers that most often appear in demand letters, and track each one through to a verified fix.
66 catalogued Accessibility (WCAG) issues, each with step-by-step, platform-specific fixes.
Filter:
- Aria allowed attrModerate effortAudit every element that uses ARIA attributes and ensure each attribute is permitted for that element's role — removing or correcting any mismatched aria-* attributes.
- Aria allowed roleQuick winRemove or replace any ARIA `role` attribute that is not permitted on the HTML element it is applied to — in particular, do not add `role="textbox"` (or other interactive roles) to elements that already have a native semantic role which conflicts with it.
- Aria command nameModerate effortGive every button, link, and menuitem a clear, accessible name so screen readers can announce what it does.
- Aria dialog nameModerate effortAdd a visible or programmatic accessible name to every dialog element so screen readers can announce what the dialog is about when it opens.
- Aria hidden focusModerate effortRemove `aria-hidden="true"` from any element that contains focusable children (links, buttons, inputs), or remove those focusable children from the keyboard tab order so they cannot receive focus while hidden from assistive technology.
- Aria input field nameModerate effortAdd a descriptive accessible name (aria-label, aria-labelledby, or a visible <label>) to every ARIA input field so assistive technologies can identify it.
- Aria meter nameQuick winAdd a descriptive accessible name (via aria-label, aria-labelledby, or a visible <label>) to every element with role="meter" so screen readers can announce what the meter represents.
- Aria progressbar nameQuick winAdd an accessible name (aria-label or aria-labelledby) to every progress bar element so screen readers can announce its purpose.
- Aria prohibited attrModerate effortRemove or replace any ARIA attributes that are prohibited for the role assigned to each HTML element, so assistive technologies receive accurate, unambiguous information.
- Aria required attrModerate effortAdd all required ARIA attributes (such as aria-expanded and aria-controls) to every interactive element that uses an ARIA role, so assistive technologies can communicate widget state to users.
- Aria required childrenModerate effortAdd the required child ARIA roles (e.g. `role="option"` inside `role="listbox"`, or `role="group"`/`role="option"` inside `role="combobox"`) so every composite ARIA widget contains the child roles the ARIA specification demands.
- Aria required parentModerate effortWrap every ARIA role that requires a parent container (e.g. `menuitem`, `option`, `listitem`) inside the correct parent element carrying the matching ARIA role (e.g. `menu`/`menubar`, `listbox`, `list`).
- Aria rolesQuick winAudit every element that has a `role` attribute and replace any invalid or misspelled role value with a valid WAI-ARIA role from the official specification.
- Aria toggle field nameQuick winAdd a visible or programmatic accessible name to every toggle control (checkbox, switch, or button with role="switch") so screen readers can announce what the control does.
- Aria tooltip nameModerate effortGive every tooltip element an accessible name so screen readers can announce its content to users who cannot see the screen.
- Aria valid attrQuick winFind and replace every misspelled or non-existent ARIA attribute name (e.g. `aria-labeledby`) with the correct, spec-defined name (e.g. `aria-labelledby`) across your entire site's HTML and templates.
- Aria valid attr valueModerate effortAudit every ARIA attribute on your pages and correct any that have invalid or mismatched values so assistive technologies can interpret them correctly.
- Autocomplete validModerate effortAdd valid `autocomplete` attribute values to every form field that collects personal information, using the exact tokens specified by the HTML standard.
- Avoid inline spacingModerate effortRemove hard-coded text-spacing CSS values from inline `style` attributes so users can override them with their own stylesheets or browser settings.
- Button nameModerate effortAdd a descriptive, screen-reader-accessible name to every button on your site so assistive technology users know what each button does.
- Color contrastQuick winIncrease the contrast ratio between your text color and its background color to meet the WCAG 4.5:1 minimum, so all users — including those with low vision — can read your content clearly.
- Definition listModerate effortEnsure every `<dl>` (definition list) element contains only properly nested `<dt>` and `<dd>` children, with no stray text, divs, or other elements placed directly inside it.
- DlitemModerate effortWrap every `<dt>` (term) and `<dd>` (description) element inside a parent `<dl>` element so description list items have their required container.
- Document titleQuick winAdd a descriptive, non-empty `<title>` element to every page so browsers, screen readers, and search engines can identify it.
- Empty headingQuick winFind every empty heading tag on your store and add visible, descriptive text (or remove the tag entirely) so screen readers and search engines can interpret your page structure.
- Empty table headerQuick winAdd visible or screen-reader-accessible text to every empty `<th>` table header cell so assistive technology users can understand what each column or row represents.
- Error not associatedModerate effortAdd `aria-invalid="true"` and a linked `aria-describedby` error message to every form field that fails validation, so screen reader users are told exactly what went wrong.
- Focus not visibleQuick winAdd a clearly visible focus indicator to every interactive element so keyboard users can always see which element is currently selected.
- Frame titleQuick winAdd a descriptive `title` attribute to every `<iframe>` and `<frame>` element on your store so screen-reader users know what each embedded frame contains before entering it.
- Heading orderModerate effortRestructure your page headings so they follow a logical, sequential order (H1 → H2 → H3) with no levels skipped.
- Html has langQuick winAdd a valid `lang` attribute to the `<html>` element so browsers, screen readers, and search engines know what language your page is written in.
- Html lang validQuick winAdd a valid BCP 47 language code to the `lang` attribute on your site's `<html>` element so browsers and assistive technologies know what language your content is written in.
- Image altModerate effortAdd descriptive alt text to every meaningful image, and mark purely decorative images with an empty alt attribute or role="presentation".
- Image redundant altQuick winRemove or clear the alt text on images whose description is already provided by visible text immediately surrounding them, so screen readers don't read the same information twice.
- Input button nameQuick winAdd a visible label or accessible name to every input button so assistive technologies can announce what the button does.
- Input image altQuick winAdd a descriptive `alt` attribute to every `<input type="image">` element so screen readers can announce its purpose to visually impaired shoppers.
- LabelQuick winAdd a visible or programmatic label to every form input so assistive technologies can identify it for users.
- Label title onlyModerate effortAdd a visible text label to every form field so it is not labeled only by a hidden tooltip (title attribute) or supplementary description (aria-describedby).
- Landmark banner is top levelModerate effortMove your site's `<header>` element (or `role="banner"` landmark) so it is a direct child of `<body>`, not nested inside another landmark region.
- Landmark complementary is top levelModerate effortMove your <aside> element (or role="complementary") to the top level of the page so it is not nested inside another landmark region.
- Landmark contentinfo is top levelQuick winMove your site's footer element (or role="contentinfo") so it is a direct child of the page body, not nested inside another landmark region.
- Landmark main is top levelQuick winMove the `<main>` element (or `role="main"`) so it is a direct child of `<body>`, not nested inside any other landmark element such as `<header>`, `<nav>`, `<aside>`, or `<footer>`.
- Landmark no duplicate bannerModerate effortEnsure your page has only one banner landmark (one `<header>` or `role="banner"` element that is not nested inside another landmark), so screen reader users can navigate your site reliably.
- Landmark no duplicate contentinfoModerate effortEnsure your page has only one footer/contentinfo landmark by removing or re-marking any duplicate `<footer>` elements or `role="contentinfo"` attributes.
- Landmark no duplicate mainQuick winFind and remove every duplicate `<main>` element or `role="main"` attribute so that exactly one main landmark exists on each page.
- Landmark one mainQuick winAdd a single `<main>` landmark element (or `role="main"`) to every page so assistive technologies can identify and navigate directly to the primary content.
- Landmark uniqueModerate effortAdd a unique aria-label (or aria-labelledby) to every repeated landmark role on the page so screen-reader users can tell them apart.
- Link in text blockQuick winIncrease the color contrast between inline links and their surrounding body text to at least 3:1, or add a non-color visual distinction (such as underline) so links are identifiable without relying on color alone.
- Link nameQuick winAdd a descriptive, screen-reader-accessible text label to every link on your store so assistive technology can announce its purpose.
- ListModerate effortFix all HTML lists so that only valid child elements appear directly inside `<ul>` and `<ol>` tags, and only `<ul>` or `<ol>` elements wrap `<li>` items.
- ListitemModerate effortEnsure every `<li>` element is a direct child of a `<ul>` or `<ol>` element (or an element explicitly given `role="list"`), so that screen readers can correctly announce list structure to users.
- Meta refreshQuick winRemove or disable the `<meta http-equiv="refresh">` tag that forces an automatic page reload, or replace any redirect use-case with a server-side redirect instead.
- Meta viewportQuick winRemove `user-scalable=no` (and any `maximum-scale` below 5) from your site's `<meta name="viewport">` tag so visitors can pinch-to-zoom on mobile devices.
- Meta viewport largeQuick winRemove or raise the `maximum-scale` value in your meta viewport tag so users can pinch-zoom on mobile devices.
- Nested interactiveModerate effortRemove or restructure nested interactive elements so that no focusable control (button, link, input, etc.) is placed inside another interactive control, and never rely on tabindex="-1" or aria-hidden="true" to hide an inner interactive element from assistive technologies.
- Object altQuick winAdd a meaningful text alternative (via `title` attribute or `aria-label`) to every `<object>` element so screen readers can describe its content to users who cannot see it.
- Page has heading oneQuick winAdd a single, descriptive `<h1>` heading to every page so assistive technologies and search engines can identify the page's main topic.
- Presentation role conflictModerate effortRemove conflicting ARIA attributes (global ARIA properties and tabindex) from any element that has been marked as purely presentational with role="presentation" or role="none".
- RegionModerate effortWrap all visible page content inside HTML landmark regions (e.g. `<header>`, `<main>`, `<nav>`, `<footer>`) so screen-reader users can navigate the page by section.
- Role img altModerate effortAdd a meaningful aria-label (or aria-labelledby) to every element with role="img" so screen readers can announce what the image represents.
- Scrollable region focusableQuick winMake every scrollable region on your site reachable by keyboard by adding tabindex="0" (or placing focusable content inside it) so keyboard and assistive-technology users can scroll it.
- Select nameQuick winAdd a visible or programmatic label to every `<select>` dropdown so assistive technologies can announce its purpose to users.
- Skip linkQuick winAdd a valid, focusable target element (with a matching `id`) for every "Skip to main content" link so keyboard and assistive-technology users can bypass repeated navigation.
- Svg img altModerate effortAdd a meaningful text alternative to every SVG image so screen readers can describe it to visually impaired shoppers.
- TabindexModerate effortRemove or replace all positive tabindex values (tabindex="1" or higher) on your page elements, using tabindex="0" for focusable elements and tabindex="-1" only when programmatic focus is needed.
- Valid langQuick winAdd or correct the `lang` attribute on every HTML element that contains content in a different language, using a valid BCP 47 language code.
Accessibility (WCAG) — common questions
What WCAG level do ecommerce stores need to meet?+−
WCAG 2.1 Level AA is the standard most legal frameworks reference for US ecommerce. The Department of Justice's March 2022 guidance says Title III of the ADA applies to the websites of businesses open to the public. It doesn't mandate a specific technical standard, but WCAG 2.1 AA is the benchmark most often referenced in demand letters and settlements.
What are the most common WCAG violations on ecommerce stores?+−
The most common violations are: missing or empty image alt text (usually a template problem affecting all product images), insufficient color contrast in promotional elements, missing form labels on checkout inputs, keyboard-inaccessible interactive components (carousels, filters, modals), missing skip navigation links, and incorrect ARIA usage from third-party app injections.
Why does SEOLZ use a real browser for WCAG scanning?+−
Static HTML checkers miss violations that only exist after JavaScript executes — inaccessible carousels, broken keyboard focus in modals, ARIA states set incorrectly at runtime. SEOLZ renders pages in a real headless Playwright browser with JavaScript fully executing, then runs axe-core against the live DOM. This is the only accurate way to check dynamic sites.
What is the ADA legal risk for ecommerce stores?+−
Ecommerce stores regularly receive ADA accessibility demand letters, often from firms that scan sites for WCAG barriers in volume, and some claims proceed to litigation. Costs vary widely with the store and the claim. SEOLZ surfaces the barriers that most often appear in those claims so you can fix them; it isn't legal advice — for questions about your obligations, consult a qualified attorney.