The quick accessibility score

Every domain scan, the app's full scan and signed-out check, the App Clip and the website assessment include an accessibility score. It is computed from the page's HTML without a browser, so it is fast, free and limited to what the markup shows.

What it checks

Thirteen checks that can be judged from the markup:

• Image Alt Text: images with no alt attribute, or a file name used as the alt text. An empty alt="" on decoration is correct and passes; hidden images, 1-pixel trackers and <noscript> copies are left out
• Form Labels: inputs, selects and text areas with no <label>, wrapping label, aria-label, title or placeholder (the same set axe-core accepts). Hidden spam-trap fields are skipped
• Button Names, Link Text and Icon Links: buttons and links with no accessible name (icon-only buttons are part of Button Names), or with vague link text such as "read more"
• Language Attribute: a valid language code on <html>
• Landmark Regions and Skip Navigation: a <main> landmark, and a skip link whose target exists (a page with <main> and no skip link passes; the landmark is the way past the menu)
• Heading Hierarchy: a sensible heading order (guidance, low impact)
• ARIA Attributes: aria-labelledby or aria-describedby pointing at an id that does not exist, and aria-hidden covering a link or control. Having no ARIA at all is not a fault
• SVG Accessibility: inline SVGs marked role="img" with no name. A plain icon SVG is not announced as an image and is not flagged
• Table Structure: data tables with header cells (layout tables and form layouts are skipped)
• Focus Indicators: rules in the page's own inline CSS that remove the focus outline and put nothing in its place

Every finding names the check, the WCAG criterion, the impact (high, medium or low) and the affected elements. Where a name or label is missing the scan drafts one from the element's own class, id, address or nearby text, quotes what it based the draft on, and says plainly when nothing in the markup gave it anything to go on.

Colour contrast is not a check here: it cannot be measured from HTML. The in-browser scan and the accessibility audit measure it with axe-core.

The score

The same weighting as the SEO score: high-impact checks weigh 3, medium 2, low 1; a pass earns the full weight and a warning 0.4 of it. A page with no accessibility checks at all scores null and shows a dash.

Where

• Web: a domain's SEO & search tab, Accessibility. iOS: the Website module's accessibility row; Content & SEO and Accessibility in the signed-out check from the welcome screen, both of which run on the device even for a guest.
• API/MCP: GET /api/score-accessibility?url=… (signed in); tool score_page_accessibility, which takes any public URL outside the protected list of major sites.

What it cannot see

Anything that needs the page rendered: contrast from a stylesheet, keyboard focus order and traps, dynamic content, ARIA that is applied by script, and anything hidden until interaction. Only the CSS written into the page is read; external stylesheets are not. For those, run the accessibility audit, which loads the page in a real browser.

Common questions

The quick score is 100 and the audit found 40 issues. Expected. The quick score only sees markup; the audit sees the rendered page with its stylesheet and scripts.

Is a good score legal compliance? No. Neither score establishes conformance. They are evidence for the work.