Accessibility Search Experience, Not Just a Legal Problem

The legal frame is mature and getting sharper. WCAG 2.2 became a W3C Recommendation in October 2023. The European Accessibility Act's obligations started applying to covered products and services on 28 June 2025. The Department of Justice's ADA Title II rule set WCAG 2.1 AA for US state and local government web content, with the first compliance deadline landing in April 2026 for larger entities. If you sell into any of those markets, someone in your company already tracks a conformance number.

The search experience frame is not mature at all, and it asks a different question.

Both frames are legitimate, and they produce different work orders. The conformance list sorts by severity and success criterion. The search experience list sorts by position on the path a searcher walks. A contrast failure on a footer link is a real conformance defect and close to zero search experience cost. A focus trap in your cookie banner is one line on the audit and the entire visit for the person who hit it.

Work the audit list top to bottom and you will spend real money before you touch the thing actually costing you searchers.

The SEO industry sells accessibility on its overlap with crawlers. That overlap is real, and it is smaller than the pitch.

Read the middle column top to bottom. It goes quiet after the fourth row.

Roughly the first third of an accessibility program is crawler-visible, so it shows up in SEO reporting and gets funded. The rest is invisible to every machine that ranks you and decisive for the human who clicked. That asymmetry, not indifference, is why accessibility keeps losing the sprint planning argument: two thirds of the work has no scoreboard.

No. No search engine publishes accessibility conformance as a ranking factor, no scanner score feeds a ranking system, and there is no accessibility report in Search Console because there is nothing to report.

Claims that accessible sites rank better collapse into two real mechanisms once you push on them:

1. Some accessibility artifacts are also ordinary crawler inputs. Alt text, heading structure, descriptive link text and semantic markup help for content reasons that have nothing to do with accessibility. They would help an inaccessible site too.
2. Accessibility overlaps with page experience work you were already doing. Reflow discipline, layout stability and not stacking things on top of the content are documented Core Web Vitals concerns. The accessibility framing is a coincidence of overlap, not a causal chain.

What a search engine can observe of an accessibility failure is what it observes of every other post-click failure: the single bit of whether that searcher came back to the results and picked a different listing. The industry calls that pogo sticking, a coinage rather than a published metric, with no threshold anyone can quote and no report you can open.

So do not sell this internally as a ranking lever. You will be asked for evidence you do not have. The honest case is stronger: this is revenue work in the half of search you measure best, which is the case that carries the rest of search experience optimization.

Here is the structural problem, and it explains the deferral better than any argument about priorities.

The last row is the only one carrying a No in both dashboard columns.

Search Console does not see it because Search Console covers the pre-click half of search. Your analytics does not see it for a more interesting reason: assistive technology does not announce itself. Screen readers do not identify in the user agent string, no JavaScript API reports one, and that absence is deliberate. A reliable "is this person using a screen reader" signal would be a fingerprinting vector attached to a protected characteristic, which is a worse outcome than the missing metric.

So a session that died at a focus trap and a session where somebody simply changed their mind produce the identical row in your reports. You cannot A/B test your way to this. You cannot dashboard it.

That leaves three options, in ascending order of honesty:

• Wait for the complaint. The complaint becomes the metric, and it arrives through counsel rather than through analytics.
• Run a scanner and report its number. W3C's Web Accessibility Initiative states plainly that evaluation tools cannot determine conformance and can only assist with it. Most success criteria need human judgment: whether alt text is meaningful, whether focus order matches reading order, whether an error message explains the fix rather than just flagging the field.
• Test the answer path by hand. Twelve minutes a page, described below.

For scale on the scanner-visible slice alone, WebAIM's annual Million report, which scans the home pages of the top one million sites, has found detectable WCAG failures on more than 94 percent of them in every edition it has published. The same failure types dominate each year: low contrast text, missing alternative text, empty links, missing form input labels and empty buttons. Note the word detectable. That is the floor, not the total.

One partial signal you can actually instrument, and almost nobody does. Browsers expose user preference media queries, which describe settings rather than disabilities but let you size a population instead of guessing at one:

// Sizes the audience with an accessibility-adjacent preference set.
const prefs = {
  reduced_motion: matchMedia('(prefers-reduced-motion: reduce)').matches,
  more_contrast:  matchMedia('(prefers-contrast: more)').matches,
  forced_colors:  matchMedia('(forced-colors: active)').matches,
}
gtag('set', 'user_properties', {
  a11y_prefs: Object.keys(prefs).filter(k => prefs[k]).join(',') || 'none',
})

Two caveats you have to hold onto: a setting is not a disability, and a population count is not an outcome. This tells you how many people arrived with a preference expressed, not whether any of them found the answer.

A page does not have one search experience. It has one per query it ranks for. Accessibility inherits that rule and almost no accessibility guide applies it.

An audit hands you a list sorted by severity and success criterion. That is the correct output for conformance and the wrong input for search experience triage, because the list has no idea which query brought anyone here or what they came to read.

So define what the list is missing. The answer path is the shortest route from the top of the landing page to the specific sentence, table, price or form that answers the query that produced the click. Then ask three questions per defect:

1. Does the defect sit on the answer path?
2. Does it block, or does it only slow?
3. How many search clicks walk that path a month?

A blocking defect on the answer path of a page taking four thousand organic clicks a month outranks thirty contrast warnings in a footer, in both frames. That is the useful part: query-scoped triage does not fight the conformance program, it tells you what order to work the same list in.

Search Console cannot diagnose a single accessibility defect. It is still where this starts, because it is the only tool that tells you which answer paths are load-bearing.

Step 1. Open Performance, then Search results. Set the date range to Last 3 months, which is steadier than 28 days at page level. Turn on all four metric toggles. Open the Pages tab and export to CSV.

Step 2. Sort by clicks descending and keep the top twenty landing pages. That is your test queue, already in priority order.

Step 3. For each page, get the query it is actually answering. Click the page row, which applies a page filter, then switch to the Queries tab. Take the top query by clicks and write it next to the URL. That query is your test script.

Step 4. Add device context. With the page filter still applied, open the Devices tab and note the mobile share of clicks. Anything above roughly 60 percent gets tested on a real phone first, because target size, reflow and focus visibility fail harder there and fail for more people.

Step 5. Build the sheet. Column five is the one everybody skips and the one that makes the rest work.

Illustrative figures for the method, not SparkCliks data.

Writing down what the answer is converts a vague "audit this page" into a claim you can test in one pass. Without column five, testers wander the page and report whatever they notice, which is how you end up with a bug list full of footer contrast warnings.

Nothing here needs a license. Run it per page, against the query and the answer from your sheet.

1. Hands off the mouse. Load the page and press Tab. If you cannot see where focus landed, that is a 2.4.7 Focus Visible failure and every observation after it is guesswork.
2. Count tab stops to the answer. More than about fifteen with no skip link is a real cost, paid by everyone who navigates by keyboard.
3. Kill every dialog with the keyboard alone. Consent banner, newsletter modal, chat bubble. Press Esc, then Tab. If focus cycles inside something you cannot close, the visit is over, and it ends for plenty of people who use a mouse too. The full cost of an interruption stack is bigger than the accessibility slice of it.
4. Zoom to 400 percent in a 1280 pixel window. That is the WCAG 1.4.10 Reflow condition, equivalent to a 320 CSS pixel viewport. Read the answer. If a line of text needs sideways scrolling, that is a reflow failure and it is the same defect a small phone hits.
5. Block images and reload. Does the answer survive, or was it inside a screenshot carrying an empty alt attribute?
6. Check contrast on the answer, not sitewide. Browser DevTools reports a contrast ratio in the color picker. The AA thresholds are 4.5:1 for normal text, 3:1 for large text at 18pt or 14pt bold, and 3:1 for interface component boundaries and meaningful icons under 1.4.11.
7. Measure the tap targets on a real phone. WCAG 2.2 added 2.5.8 Target Size at a 24 by 24 CSS pixel minimum for AA. Check the primary action and anything else sitting on the answer path.
8. Submit the form wrong on purpose. Leave a required field empty and put a bad value in another. Is the error announced, tied to its field, and written so it says how to fix the problem? Does focus move to it?

Six of those eight are invisible to every automated scanner. All eight are invisible to your analytics.

Microsoft's inclusive design work popularized a spectrum worth borrowing: permanent, temporary, situational. One arm. A broken arm. Holding a baby.

Search traffic sits overwhelmingly in that third column. Someone arriving from a results page on a phone, one thumb, outdoors in daylight, on a connection that dropped your web font, is operating under the constraints the standard was written for.

This is why the business case does not need an invented percentage. The right-hand column is most of your search traffic on most days, and it shows up in ordinary mobile engagement data. You never have to estimate the size of a population you cannot detect in order to justify fixing a 20 pixel button.

An accessibility overlay is a third-party widget that promises conformance in exchange for a script tag. Set aside the legal argument, which others have made at length, and look only at what it does to the search experience:

• It puts a third-party script on the critical path of the exact page you are trying to make usable. You pay in LCP and INP, both documented page experience measures, for a benefit that is contested. If rendering is already where you struggle, that is a technical SEO problem you just made worse.
• It does not fix the source. The defect stays in your DOM and the widget patches over it at runtime. Your next release can move the element that patch was targeting.
• Practitioners published a rebuttal you can read. The Overlay Fact Sheet at overlayfactsheet.com documents the technical problems and carries signatures from accessibility professionals, many of whom report that overlays interfere with the assistive technology their users already run.
• The legal cover is weaker than advertised. The US Federal Trade Commission acted against overlay vendor accessiBe over claims that its automated tool could make any website WCAG compliant, with an order finalized in 2025 that included a one million dollar payment.

When a vendor tells you a script tag makes your site conformant, the two frames are being sold to you as one thing. They are not, and the version in the box does nothing for the searcher.

The standard before-and-after design does not work here, because you cannot isolate the affected population. Measure two other things instead, and stay explicit about which is which.

The direct read: task completion on the answer path. Five people, the query from column two, the answer from column five, at least one of them keyboard-only. The metric is binary plus a stopwatch: did they reach the answer, and how long did it take. Run it, ship the fix, run it again with different people. This is not statistics and does not pretend to be. It is the only direct evidence available, and a handful of testers surface most of what a larger group would.

The proxies, read as a set and never alone:

The rules that keep any of this honest are the ones that govern the rest of the post-click half: change one thing, hold a control set of comparable pages you deliberately do not touch, confirm average position did not move between your two windows before reading any Search Console number, use 28 days minimum on each side, and segment bought traffic out first.

That last rule bites hardest here. SparkCliks products put clicks and sessions into your reports on purpose. Per the SparkCliks FAQ, the SERP Clicks pool is paid human clickers who search your keyword, scroll the results until they find your listing, click it, stay roughly 60 seconds, optionally visit a second internal page, and never press the back button. Realistic Traffic runs an engine that scrolls in short steps, moves a pointer along curved paths and clicks a link, tapping instead when the session runs a mobile user agent. None of them is a screen reader user, none is running at 400 percent zoom, and none will ever fail at your focus trap and tell you about it. Bought sessions are useful for exercising a new layout and populating session recordings before real traffic arrives. As an accessibility signal they are worthless, and left in the same segment they will flatten every proxy in the table above.

1. Export the Pages tab from Search Console for the last 3 months and keep your top twenty landing pages by clicks.
2. For each one, pull the top query from the Queries tab with the page filter applied.
3. Write down, in words, what the answer to that query is and where it lives on the page.
4. Note the mobile share per page and sort the phone-heavy ones to the front.
5. Run the twelve-minute answer-path pass on the top three pages. Keyboard first, zoom second.
6. Separate the findings into two lists: on the answer path, and everywhere else.
7. Fix every blocking defect on an answer path before you touch anything on the second list.
8. Hand the second list to whoever owns the conformance program, because it still has to get done.
9. Instrument the preference media queries so you know the size of the population you are guessing about.
10. Book five task-completion tests, one of them keyboard-only, and run them before and after the fix.