The nine barrier patterns
The same handful of accessibility barriers turn up again and again in the demand packages sent to small businesses. We wrote the nine down, and your scan says which of them are on your pages, which need a person to look, and what fixing each one takes.
This scores your pages against nine barrier patterns that recur in ADA demand packages sent to small businesses. It is a list of patterns, drawn from a real case and generalised — it is not a copy of any auditor's own checklist of success criteria. We do not hold such a checklist, and a list that claimed to be one and was not would be worse than none, because you would act on it. It is not a full WCAG 2.2 AA audit either: WCAG 2.2 has 86 success criteria and these nine patterns cite seven of them.
What the nine patterns are
Each one is written the way the person who owns the website would describe it, not the way a success criterion is worded. You cannot act on “1.4.5 Images of Text”. You can act on “the menu is a picture”.
The logo at the top of the page announces nothing
The logo is a picture inside a link, and the picture has no text alternative. A screen reader reaches the first link on the page and has nothing to read out — not your business name, not "home", nothing.
What fixing it takes: Type a description into the alternative-text box on the image. In most website builders this is a content change, not a developer task.
Our automated checks can settle this one in both directions: they can find it, and their finding nothing on a page they read in full means something.
A link is named only by the tooltip that appears on hover
The link's only text is the little box that appears when a mouse hovers over it. Touch-screen users never see it, keyboard users never trigger it, and several screen readers do not read it out.
What fixing it takes: Give the link real text, or an aria-label that says what it is and where it goes. Usually a few minutes per link.
Our automated checks can settle this one in both directions: they can find it, and their finding nothing on a page they read in full means something.
A link opens a new window without saying so
The link opens a new tab and nothing in its name mentions it. Someone using a screen reader or a magnifier does not notice, and their Back button stops working with no explanation.
What fixing it takes: Either drop the new-tab behaviour, or add four words to the link text: "(opens in a new window)".
Our automated checks can settle this one in both directions: they can find it, and their finding nothing on a page they read in full means something.
Slideshow arrows are announced but lead nowhere
The previous/next arrows on a slider sit in the keyboard tab order and announce themselves as "Previous" and "Next", but they name a direction rather than a purpose and, in the page as delivered, they go nowhere.
What fixing it takes: Hide decorative arrows from assistive technology, or rebuild them as buttons whose names say what they do — "Next dish", not "Next".
Our automated checks can find this one but can never clear it. If they report nothing, your scan says a person needs to look — not that the pattern is absent.
There is no main area for a screen reader to jump to
The page never marks where its content starts, so the "jump to main content" command has nothing to jump to. Someone has to listen through the header and the whole menu on every page before reaching what they came for.
What fixing it takes: Wrap the content in a <main> element — one per page. In most themes this is a single template edit that fixes the whole site.
Our automated checks can find this one but can never clear it. If they report nothing, your scan says a person needs to look — not that the pattern is absent.
There is no way to skip past the navigation
Every page starts with the same menu and there is no link at the top to jump over it, so a keyboard user tabs through every navigation item before reaching the content. It is one of the terms most often written into settlement agreements, because it is cheap and it is visible.
What fixing it takes: Add a "Skip to content" link as the first focusable thing on the page. Many themes have a setting for it already.
Our automated checks can find this one but can never clear it. If they report nothing, your scan says a person needs to look — not that the pattern is absent.
The menu is a picture
The food menu is published as an image or a PDF of a printed menu rather than as text. A screen reader announces nothing for it — not one dish, not one price — and zooming a picture of text only produces blurry text. This is the most-alleged barrier in restaurant demand packages, and it is total: it does not make the menu harder to read, it removes it.
What fixing it takes: Publish the menu as real text on the page: headings for the sections, a list for the dishes, the price as text. Keep the picture too if you want the look. This is the one on this list worth paying someone to do properly.
Our automated checks can find this one but can never clear it. If they report nothing, your scan says a person needs to look — not that the pattern is absent.
A control cannot be reached with the keyboard
Something behaves like a button — a "back to top" control, an icon that opens a panel — but is built so that it can never receive keyboard focus. Anyone who does not use a mouse cannot reach it at all.
What fixing it takes: Build it as a real <button>. That one change gives it keyboard focus, Enter and Space, and the right announcement, with no extra code.
Our automated checks can find this one but can never clear it. If they report nothing, your scan says a person needs to look — not that the pattern is absent.
A control has no name and no role
The same kind of element seen from the screen reader's side: it is not announced as a button and it has no name, so it is skipped over or read out as an unlabelled something. Even someone who can reach it cannot tell what it is for.
What fixing it takes: Give it a role and a name. A real <button> supplies the role; the name is the text inside it, or an aria-label when it is only an icon.
Our automated checks can find this one but can never clear it. If they report nothing, your scan says a person needs to look — not that the pattern is absent.
What our checks can and cannot settle
Of the nine, 3 can be settled by our automated checks in both directions. The other 6 cannot, and your scan says so on the row rather than quietly reporting them as clear.
Automated checks cannot settle every one of these. Some are answered by checks that decline to decide from the page as delivered; some ask a question about every control on a page, and the set of things that behave like a control is not something the delivered code lists. Where a check could not decide, the row says a person needs to look — never that the pattern is absent. That is the whole discipline of this feature: a result you can rely on is worth more than a clean-looking page you cannot.
What this does not tell you
This predicts nothing. It does not tell you whether anyone will write to you, whether a claim would be brought, whether you would come through an audit, or whether your site is likely to be looked at — it is not lawsuit protection, and no row in it changes your legal position one way or the other. What it does tell you is narrower and checkable: these are patterns that recur in real demand packages, this is whether our checks found them on the pages you scanned, and this is what fixing them takes.
We also do not tell you who sends these letters, or describe them. The pattern is what generalises and the pattern is what you can act on; everything else would be us making statements about identifiable people to sell you a subscription.
Learn more
- What AccessWiser does — and what it doesn't
- Plain-English guide to WCAG 2.2 AA
- Plain-English guide to the ADA and web accessibility
- Plans and what a scan includes
Automated testing detects only a portion of possible accessibility barriers (industry studies put it at roughly a third to a half). This report does not by itself establish conformance with WCAG, the ADA, Section 508, the EAA or any other law. Items marked "Needs human review" could not be verified automatically and require manual and assistive-technology testing. Full conformance requires remediating your site's code and content. This report is not legal advice.