Lighthouse gives your Flutter app a perfect accessibility score. It's lying

SaHland — Wed, 01 Jul 2026 12:58:23 +0000

A few months ago I opened Lighthouse on a Flutter web build, ran the accessibility audit, and got a near-perfect score. Then I turned on a screen reader and tried to use the app. It was unusable. Buttons announced as "button" and nothing else. A form where the reader never said which field I was in. That gap — a green score next to a broken experience — is what sent me down this hole.

Here's the thing nobody tells you when you pick Flutter: every accessibility tool you already know is blind to it. axe-core, Lighthouse, WAVE, Pa11y — they all read the DOM. Flutter doesn't have one. It paints everything to a single canvas, so to those tools your entire app is one anonymous <canvas> element. They literally cannot see your buttons, your text, your contrast, anything.

What does exist on pub.dev is useful but doesn't close the loop. accessibility_tools gives you a debug overlay you click through by hand. A couple of scanners walk the tree once. None of them fail a pull request, none map a finding to the actual standard clause you'll be asked about, and none give you an artifact you can hand to a compliance person. So I built the thing I wanted: something that runs in a normal widget test, in CI, and tells me exactly what's wrong and where.

What using it looks like

You add one call to a widget test:

testWidgets('Checkout screen is accessible', (tester) async {
  await tester.pumpWidget(const MyApp(home: CheckoutScreen()));
  final report = await tester.auditAccessibility();
  expect(report, passesAccessibilityGate());
});

That one line walks the live semantics tree, rasterizes the screen to check real contrast, re-pumps everything at 200% text size to catch overflow, and comes back with a report where every finding cites a WCAG success criterion and an EN 301 549 clause — pointed at the file:line that produced it.

I pointed it at a random app to see if it actually works

Fixtures prove nothing, so I grabbed an open-source Rick and Morty client off GitHub — a real app, BLoC, go_router, the usual — and wrote three lines of test against its widgets. First run, it flagged the favorite-star button:

✗ [error] attest/interactive-name — WCAG 4.1.2 (A) / EN 301 549 §11.4.1.2
  Interactive element has no accessible name; a screen reader announces only its role.
  lib/uikit/widgets/buttons/character_favorite_button.dart:20
  Fix: wrap it in Semantics(label: …, button: true) or use IconButton(tooltip: …)

That's a genuine bug. The button is an IconButton with an SVG star and no tooltip, so TalkBack reads it as "button" and the user has no idea it toggles a favorite. The report told me the WCAG criterion, the clause, and the line to fix — and it did not flag the app bar title next to it, which was fine. That last part matters more than the finding. A tool that cries wolf gets deleted after one afternoon.

What's in the box

Twelve checks across three detection methods that source-level tools can't touch:

Names and roles — unlabeled buttons, images with no alt, form fields with no label, generic "Button" labels.
Rendered output — real contrast measured from the actual pixels, and layout overflow when the system font goes to 200%.
Reachability — touch targets that are too small, tap targets hidden from assistive tech.

On top of that: a CI baseline gate that fails only on new findings (like coverage, by a coordinate-free fingerprint so a layout shift doesn't count as a regression), SARIF output for GitHub's Problems panel, and a screen-reader transcript — the literal sequence a screen reader would read out, in traversal order. I haven't seen another Flutter tool do that last one.

Where I'm being honest with you

Automation catches maybe a third of accessibility problems. Nobody's automated tool catches "is this alt text actually meaningful" or "does this error message make sense" — those need a human. attest does not make you EAA-compliant and I don't claim it does. What it does is take the machine-checkable third off your plate and give you a structured checklist for the rest. Some of the heuristic checks can be noisy on unusual UIs; they're warnings, tagged as heuristic, and you can mute any rule in one line. It complements real TalkBack/VoiceOver testing. It doesn't replace it.

Why now

The European Accessibility Act became enforceable on 28 June 2025. Within days, French disability groups sent formal legal notices to several large retailers over their websites and apps. Native mobile apps are explicitly in scope under EN 301 549 chapter 11. Penalties differ by country — Germany caps around €100k, Spain runs to €1M plus possible suspension of activity, Ireland even attaches criminal liability. Enforcement so far has gone after the web first because it's easier to test, with apps clearly next in line. Wiring a gate into CI while it's cheap beats finding out during an audit.

It's early — 0.9.x, API still moving — and I'd genuinely like the feedback, especially false positives from real apps.

Package: pub.dev/packages/attest_flutter
Source: github.com/sahland/attest