Accessibility Checker for Mac Help

The Mac app has three parts that work together: a Safari extension that audits any page you're viewing with axe-core, the Reports Hub where those results become organised, triaged client reports, and two quick tools that live in your menu bar — the contrast checker and the color-blindness Lens. This page covers all of them.

1. Who is this for — honestly?

Accessibility Checker is built for a specific way of working: audit a meaningful sample of pages, fix what you find, re-test, and show the difference. If that is your loop, the app removes the spreadsheet from it. It is not an enterprise monitoring platform, and it does not pretend to be — here is where it genuinely earns its place, and where it doesn't.

Independent consultants and freelance auditors

The engagement loop is the product: create a project for the client, audit their key pages from Safari, deliver the round’s report, and when the fixes land, start a new round — the diff (“5 fixed since the previous audit, 2 new”) is your progress evidence, and issues you marked resolved or dismissed stay that way without re-triaging from scratch. Two things matter disproportionately here. First, client data never leaves your Mac — findings live in a local file, not on a vendor’s servers, which keeps you on the right side of most NDAs without a procurement conversation. Second, per-issue status that survives re-audits is precisely the feature the browser-extension tools reserve for their paid cloud tiers — here it works offline, per client, with no per-seat subscription.

The person who “owns” accessibility at a small team

Most companies below enterprise size have one designer or developer who inherited accessibility alongside their actual job. For them the app is a menu-bar contrast checker and a color-blindness Lens during the workday, and a lightweight ledger the rest of the time: one project per product, a new round each release, dismissals with notes for the third-party widgets you can’t fix (“raised with vendor”), and a report you can hand your manager that shows the trend rather than a wall of red. When procurement or an EU customer asks for an accessibility statement, you can produce an honest one in minutes instead of a panic.

Agencies shipping client sites

A repeatable pre-launch pass: project per client site, an audit round at each milestone, and the report plus statement attached to the handover. Because rounds are preserved forever, the “state at launch” snapshot is always retrievable when questions come back six months later.

Small businesses facing the European Accessibility Act

The EAA has applied since June 2025, and the most common first requirement a small business actually meets is a request for an accessibility statement. The workflow here is deliberately honest: audit your key pages, fix what you can, and publish a statement that discloses the remaining issues as known limitations. The generator never claims more than partial conformance from automated checks — which is exactly the claim an automated audit can support, and far more defensible than the “100% compliant” badges the accessibility community rightly distrusts.

Where this app is the wrong tool. Automated checks — here and everywhere — detect only a portion of WCAG failures; a full audit still needs manual testing with a keyboard and a screen reader, and this app manages your automated findings and notes, not a manual-testing methodology. It audits the pages you visit rather than crawling thousands of URLs on a schedule — sampling representative pages is the professionally accepted approach for an audit, but if you need continuous whole-site monitoring, dashboards, and team seats, that is enterprise-platform territory (Siteimprove, Pope Tech, axe Monitor) at enterprise prices. And it is single-user by design: your hub is yours, on your machine.

2. The consultant workflow: the Reports Hub

The Reports Hub is the app's home base for audit work. The sidebar holds your projects — one per client or site — each with its count of open WCAG issues and its audit rounds nested beneath. Select a round to see its findings, triage them, and export a report or accessibility statement when you're done.

The Reports Hub window. The sidebar lists projects, each with an open-issue count and its audit rounds. The toolbar has buttons to add, group, filter and share, and a search field. Chips above the findings table filter by All, Open, Resolved, Dismissed, Regressed and Verified, and the line beside them reads: Pages in scope: 1 of 3, 1 verified, 1 regressed since Audit 1. The table is grouped by rule; the selected color contrast finding carries a Regressed pill. The detail pane below shows its WCAG reference, the evidence 3.1:1 — needs 4.5:1, the triage buttons, a note field, and the affected element with copy and open buttons. — A re-test round: a contrast issue marked Resolved after the first audit was detected again, so the Hub shows it as Regressed. It follows your system's light or dark appearance.

Open the Reports Hub

Click the app's icon in the Dock, choose Window → Reports Hub (⌘0), or choose Reports Hub… from the contrast checker's gear menu. After sending an audit from Safari, Open in Reports Hub in the popup takes you straight to it.

Create a project for each client

Choose File → New Project… (⌘N), or click + at the bottom of the sidebar. Give it a name and the site it covers, such as example.com. A site also covers its www. address; write *.example.com to cover every subdomain too. Project Settings… (⌘I) edits the name, the list of sites, and the organisation, contact and other details the accessibility statement uses.

Each project remembers the status of every issue you triage, and its scope — the pages it covers — fills in as audits arrive. Keep one project per client and the Hub keeps their histories separate. The free plan includes one project; Pro adds as many as you need.

Audit pages in Safari

Turn on the extension once. Open Safari Settings → Extensions, turn on Accessibility Checker, and allow it on the sites you audit. The app's welcome tour walks you through this and shows whether it's on; see Turn the extension on for details.
Browse to a page and click the Accessibility Checker button in Safari's toolbar. The audit runs with axe-core — the same engine professional accessibility teams use — as soon as the popup opens.
Check the Destination and click “Send to Reports Hub”. The results transfer to the Mac app privately, on-device, through the shared App Group container — no network request, no account. Then click Open in Reports Hub to see them.

Welcome tour page titled Turn on the Safari extension. A mock of Safari Settings, Extensions, shows Accessibility Checker unticked, with a status line reading Extension is off, and an Open Safari Settings button. — The welcome tour shows where the extension is switched on, and whether it's on yet.

Sent pages land in the right place automatically: the page's address is matched against your projects' sites and filed in that project's newest audit round. If no project covers the site, Pro creates one named after it; on the free plan, the page goes into your most recent project, tagged Other site. Either way the popup's Destination menu shows where it will go before you send, and lets you choose another project or round.

Audit rounds: re-test without losing history

When you re-test a site — say, after the client ships fixes — choose File → New Audit Round (⇧⌘N), or + at the bottom of the sidebar; pages you send from Safari after that land in it. Earlier rounds stay intact, so you can always reopen “the July audit” exactly as it was. Within a round, re-sending a page replaces that page's result, so re-checking a single page never duplicates it. Right-click a project or round in the sidebar to rename or delete it — deleting a round never touches your issue statuses, which belong to the project.

Triage findings

Set a status with the buttons in the detail pane, the Issue menu — Mark Resolved (⌥⌘R), Dismiss (⌥⌘⌫), Reopen (⌥⌘O), Add Note… (⌥⌘N) — or by right-clicking. A dismissed issue might be a false positive or out of scope; a note records why, and notes appear in exported reports.
Select several findings (⌘- or ⇧-click) to triage them together. A status or note set on a rule applies to every page it was found on.
Statuses stick. Each issue is fingerprinted by page, rule, and element, so the status you set survives new rounds and re-audits — you triage an issue once, not once per re-test.
Filter with the status chips above the table, by severity with the toolbar's Filter button, or with View → Show Open Issues (⌘3). Search (⌘F) matches titles, rules, pages, selectors and notes.
Group the table By Rule (⌘1, one row per rule across every page) or By Page (⌘2).
The detail pane shows the selected finding's WCAG success criterion, its evidence (such as the measured contrast), and each affected element with Copy Selector, Copy HTML and Open Page in Safari. Double-click a finding, or click Rule Documentation, for the axe rule's documentation.
Misfiled result? Drag the row onto another round in the sidebar, or right-click and choose Move Page Result To.
Import Audits… (⌘O) brings in audit JSON files saved from the Safari extension with Save JSON — handy for audits a colleague ran, or ones you archived.

Verified fixes and regressions (Pro)

When you mark an issue Resolved and later re-audit its page, the Hub checks the new result. If the issue is gone, it shows as Verified. If it's still detected, it shows as Regressed and counts as open again, in the sidebar count, reports and the accessibility statement. Your own status is never overwritten. The Regressed and Verified chips filter to them, and the line beside the chips sums up the round: pages in scope, pages from other sites, and what's been verified or regressed since the round before. On the free plan the two chips show their counts with a lock.

Export reports and accessibility statements

The toolbar's Share button previews the round's report (Preview Report…), exports it as HTML (use your browser's Print command to make a PDF) or Markdown, or copies the Markdown with Copy Markdown; File → Export Report… (⌘E) does the same. Reports reflect your triage: statuses, notes and affected elements appear alongside the findings.

File → Accessibility Statement… (⇧⌘E) previews an accessibility statement structured on EN 301 549 and the W3C statement format, in your choice of 17 languages. It's built from the project's current results — the latest result for every page across rounds — and lists only issues that are still open, including regressions. Edit Details… fills in the organisation, contact, website address, review date, and optional sections for the enforcement procedure, disproportionate burden and content out of scope. Then Save HTML… for the client's site, or Copy Hosted Link — the statement travels in the link itself, so nothing is stored on a server.

On the free plan you can preview reports and statements; saving, copying and hosted links are part of Pro.

The statement never claims full conformance. Automated checks can't prove a site meets every WCAG criterion, so the statement's wording is fixed template text that reports a partial, self-assessed status. See the FAQ for why.

3. The Safari extension

The Safari extension comes with the Mac app — there's nothing extra to download. It audits the page you're looking at, overlays its keyboard tab order, and checks color contrast, all inside Safari. It runs the same axe-core engine and version as the iPhone and iPad app, so results are comparable across devices. Nothing is uploaded: audits run in the page on your Mac.

Turn the extension on

Open the extension settings. In Accessibility Checker, choose Settings… (⌘,) → Safari & Hub → Open Safari Settings… — or in Safari, choose Safari → Settings… → Extensions. The Safari & Hub tab also tells you whether the extension is on.
Tick Accessibility Checker in the list. Its button appears in Safari's toolbar: the accessibility figure.
Allow it on the sites you audit. Safari needs your permission before an extension can read a site. When Safari asks, choose Always Allow on This Website, or Always Allow on Every Website if you audit many sites; you can change it later in Safari Settings → Websites → Accessibility Checker. Without permission the audit can't run.

The popup has four tabs: Audit, Tab Order, Contrast, and About.

Audit a page

Click the toolbar button. The audit starts as soon as the popup opens, and the Run Audit button becomes Refresh for when the page changes. Close the popup and open it again on the same tab and your last results are still there, with the time they were taken (“Audited 2 minutes ago”).

The summary counts errors (axe's critical and serious issues), warnings (moderate and minor issues), items that need review, and rules passed.
Violations are listed errors first. Each shows its impact, the WCAG success criteria it maps to (or Best practice when it isn't a WCAG requirement), the number of affected elements, and a Learn more link to the rule documentation.
Needs review is a separate list of things axe-core couldn't decide automatically — check each one by hand.
Click an issue (or Tab to it and press Return) to list the affected elements by CSS selector, then click an element (or its ⌖ button) to outline it in red on the page and scroll to it. Clear highlights removes the outlines.

The whole popup works from the keyboard: arrow keys move between the tabs, and VoiceOver announces when an audit finishes.

Send, copy, or save the results

Send to Reports Hub hands the audit to the Mac app on-device. The Destination menu above it shows where it will go — the project whose sites include this page, and its latest audit round — and you can pick another project or round, or a new project for this site. After sending, Open in Reports Hub takes you straight to it (see section 2).
Copy report puts a Markdown summary on the clipboard — the page, the counts, each issue with its rule link and affected elements, and the tab order summary if you've run it — ready to paste into a ticket, email, or chat.
Save JSON downloads the findings as a file named after the site and date, for archiving or sending to a colleague. The Reports Hub can Import… it later.

See the keyboard tab order

Open the Tab Order tab and click Show Tab Order. The extension walks the page (scrolling once to load lazy content), then draws a numbered badge on every stop a keyboard user reaches with the Tab key, joined by a path in order. The popup summarises what it found:

the number of tab stops, and how long the scan took;
positive tabindex values, which override the natural order;
stops whose order jumps against the page's reading order;
stops that are off-screen or zero-size — focus lands somewhere a sighted keyboard user can't see;
signs of infinite scrolling or sticky headers that can make later stops unreliable.

The tab order overlay on the W3C demo page: 56 stops, with the path jumping from the header up to the logo in the corner and back across the navigation.

Clear overlay removes the badges. If you close the popup with the overlay still showing, the button is there again next time you open it.

Why Safari's own Tab key may skip links: by default Safari only Tab-focuses form fields. Turn on Safari → Settings → Advanced → Press Tab to highlight each item (or press ⌥Tab) to move through links and buttons too. The overlay shows the order the page itself defines, which is what other browsers and assistive technology follow.

Check contrast in the popup

The Contrast tab checks a foreground and background pair: type hex values, or click a swatch to open the macOS color panel, whose eyedropper samples any pixel on screen — images included. You get the ratio, pass or fail for AA and AAA at normal and large text sizes, a live text preview, and suggested foregrounds that pass AA on your background. Click a suggestion to try it. For APCA, color-blindness simulation, and copy-as-code, use the full contrast checker.

The Safari extension's Contrast tab: foreground 8A8A8A on background FFFFFF gives 3.45 to 1, which fails AA and AAA for normal text and AAA for large text but passes AA for large text; six suggested foreground colors are shown below. — A gray on white that only passes AA for large text, with passing foregrounds suggested underneath.

If something doesn't work

“This page can't be audited (browser-internal page).”: Safari's own pages — a new tab, Settings, the Start Page — can't be audited. Browse to a website first.
Nothing happens, or the audit fails: Check the extension is allowed on this website in Safari Settings → Websites → Accessibility Checker, then reload the page and open the popup again.
“Couldn't reach Accessibility Checker.”: The extension couldn't reach the Mac app. Open Accessibility Checker once, then send again. The popup's Copy report and Save JSON still work either way.
The Destination says “(other site)”: No project lists this page's site. On the free plan, with its one project already made, the audit is filed in your most recent project and marked as another site. Add the site to a project in the Reports Hub, or upgrade to Pro to create a project for it.

4. The contrast checker

The contrast checker lives in your menu bar (the accessibility figure icon). Open it from there, with the global shortcut ⌃⌥C (Control-Option-C) from any app, or with the Checker button in the Reports Hub toolbar.

The contrast checker card in light mode: a sample-text preview, foreground and background color swatches with hex fields, the contrast ratio 5.3:1 with the verdict Meets AA, pass or fail marks for AA and AAA at both text sizes, and a Graphics and UI row passing 3:1. — The checker card in light and dark mode: swatches, hex fields, the ratio with a plain verdict, per-level results for regular and large text, and the 3:1 check for graphics and UI.

The same contrast checker card in dark mode. — The checker card in light and dark mode: swatches, hex fields, the ratio with a plain verdict, per-level results for regular and large text, and the 3:1 check for graphics and UI.

Picking colors

Click a color swatch to open the native macOS color panel. Its magnifier eyedropper samples any pixel on screen — images and video included.
Click the eyedropper button next to the hex field for the quick screen sampler — a crosshair magnifier for grabbing a color in one move.
Type or paste hex, rgb(), or hsl() values directly into the fields.
The swap button (⇄) exchanges foreground and background — useful for checking both polarities of a pairing.

Reading the results

You get the WCAG contrast ratio with a plain verdict — “Meets AA” — plus a pass or fail mark for AA and AAA at regular and large text sizes, and for Graphics & UI: the 3:1 minimum for icons, input borders and other non-text elements (WCAG 1.4.11). The APCA Lc value from the WCAG 3.0 draft sits alongside; hover over it for what each level is good for, or hide it in Settings → Checker.

Suggest fixes appears when the ratio is below 4.5:1 (it's also in the </> menu) and offers the smallest color change that meets AA, AAA or 3:1. Choose one to try it.
Preview All 8 Types… in the menu beside the Lens button shows your pair through every type of color vision deficiency side by side.

Getting results into your work

Contrast checker actions and shortcuts
Action	Shortcut
Open the checker from anywhere (global hotkey)	`⌃⌥C`
Copy the result	`⌘C`
Copy as code — SwiftUI, UIKit/AppKit, CSS, or Android XML — or Export Check Report…, via the </> menu	—
Open the result in your browser	`⌘B`
Share the result, or open it in your browser, with the share button	—
Toggle the Lens	`⌘L`
Open the Reports Hub	`⌘0`
Open Settings	`⌘,`

Key symbols: ⌃ Control · ⌥ Option · ⌘ Command.

The gear button on the checker card holds quick toggles — Show Text Preview, Show APCA Result, Translucent Background and the preview's Sample text — plus History (your last checks: choose one to load that pair again), Reports Hub… and Settings…

The Settings window (⌘,) has four tabs:

General — open at login, the checker's shortcut, and the welcome tour.
Checker — the card's preview, APCA and translucency, sample text, the share template, and clearing your history.
Safari & Hub — whether the Safari extension is on, and how sends are filed in the Reports Hub.
Account & Purchases — sign in or out, delete your account, your plan, Restore Purchases and Manage Subscription…

5. The Lens: color-blindness simulation

The Lens (macOS 14 or later) is a draggable, resizable glass panel that shows the live screen beneath it through a color-vision simulation. Because it sits over the real screen, it works on anything — designs in Figma, photos, video, data visualisations, another app entirely.

Toggle it from the checker's Lens button, the Reports Hub toolbar, or ⌘L.
Eight simulations: protanopia, deuteranopia, and tritanopia; their milder -anomaly variants (protanomaly, deuteranomaly, tritanomaly); and achromatopsia and achromatomaly.
Zoom from 1× to 8×, or switch to full-screen mode to view the whole display through the simulation.

The Lens needs macOS's Screen Recording permission to read the pixels beneath it. macOS prompts once, and the app guides you through granting it.

Illustration of the Lens: a row of color swatches shown with typical color vision next to the same swatches through the deuteranopia simulation, where the red and green swatches become nearly indistinguishable. — What the Lens shows: the same palette with typical vision and through deuteranopia, where red and green collapse together.

6. Frequently asked questions

Is my audit data private?

Yes. Audits run in Safari on your Mac, and Send to Reports Hub moves the results between the extension and the app through the shared App Group container on disk — it never touches the network, and there is no account. What you audit stays on your Mac.

Does the Safari extension send my browsing anywhere?

No. The extension only runs when you click its button, the audit runs inside the page on your Mac, and results go to the Mac app through the on-disk App Group container. There's no account, no server, and no tracking.

Do I need an account or a subscription?

No account: the welcome tour offers Sign in with Apple, but you can skip it and everything works signed out. You can sign out or delete your account at any time in Settings → Account & Purchases.

Free: the whole contrast checker, the Lens, the Safari extension, and the Reports Hub with one project — send audits, triage, notes and Import JSON. Pro: report export (HTML, Markdown and copy), accessibility statements (save and hosted link), unlimited projects, and verified fixes and regressions across audit rounds. Free users can preview reports and statements before upgrading. Pro is yearly with a 7-day free trial, or a one-time lifetime purchase, and one purchase also unlocks the iPhone and iPad app.

Where does the Reports Hub keep its data?

Projects, audit rounds, findings, and your triage statuses are stored locally in the app's Application Support folder. Back up your Mac and you've backed up your audit history.

Why does the statement say “partially conformant” and never “fully conformant”?

Because automated checks can't prove full conformance — many WCAG criteria require human judgement that no scanner can supply. A statement generated from automated results alone that claimed full conformance would be misleading, so the statement's wording is fixed template text: it reports a self-assessed, partial status based on the open issues in your project, in the structure used by EN 301 549 and the W3C statement format.

Which languages can the statement be generated in?

Seventeen: English (en), Czech (cs), Danish (da), German (de), Greek (el), Spanish (es), Finnish (fi), French (fr), Croatian (hr), Hungarian (hu), Italian (it), Dutch (nl), Polish (pl), Portuguese — Portugal (pt-PT), Romanian (ro), Slovak (sk), and Swedish (sv). The statement language is independent of the app's language.

Accessibility Checker for Mac: Help