TL;DR: HTML elements carry accessibility semantics for free — a <button> announces itself as a button with zero extra work. Flutter builds a separate Semantics tree you must annotate by hand, and on the web it doesn't exist until a hidden "Enable accessibility" control fires. Role, name, value, and state are the same vocabulary either way — the delivery mechanism isn't.
Say the ticket lands on your desk: "make the Flutter app accessible — it's already accessible on the web version." The instinct, if you've spent years writing semantic HTML, is to assume the two surfaces share a foundation. They don't. The web version gets its accessibility tree from the browser parsing native elements: a <nav> is a landmark, a <button> is operable, an <input type="checkbox"> reports its checked state, all without a line of ARIA. Flutter renders everything — including on the web — through its own engine, with no native DOM elements underneath. There is no free accessibility tree waiting to be discovered; there's only the one you build.
That gap is exactly where cross-platform teams get burned, and it's also where "just port it over" stops being a reasonable estimate. If your product ships a standards-compliant website alongside a Flutter mobile or desktop app, accessibility parity isn't a given — it's a second implementation, with its own API and its own failure modes. Teams that get this right usually bring in a Flutter development team that already knows the semantics layer, rather than discovering the gaps one screen-reader complaint at a time. The rest of this piece is the structural difference, the role mapping, and the specific defaults that catch people off guard.
Every Flutter widget tree has a shadow structure sitting next to it: the Semantics tree. It's not generated from your layout automatically — Flutter's rendering layer draws pixels, and by default those pixels carry no meaning for assistive technology. On mobile, the engine translates whatever Semantics nodes exist into the platform's native accessibility APIs (the iOS accessibility API, the Android Accessibility API). On the web, Flutter's own documentation confirms that same tree is translated into an ARIA-annotated DOM overlay, positioned on top of the canvas or HTML rendering users actually see.
The practical difference from HTML is annotation effort. A native <button> is a button because the browser's parser says so — role, focus behavior, and keyboard activation all ship with the element. A Flutter equivalent built from a GestureDetector wrapping a Container is, as far as the Semantics tree is concerned, nothing at all until you say otherwise:
<!-- HTML: accessible by default -->
<button>Save changes</button>
// Flutter: accessible only if you annotate it
Semantics(
button: true,
label: 'Save changes',
child: GestureDetector(
onTap: save,
child: Container(child: Text('Save changes')),
),
)Both end up exposing the same role, name, and operability to a screen reader. One of them required you to know that.
Here's the gotcha that catches even teams who annotated everything correctly: Flutter's engineering blog confirms that semantics are not enabled by default on the web, for performance reasons. Building and maintaining the ARIA-annotated DOM overlay has a runtime cost, so Flutter Web ships with it dormant until something turns it on — typically a hidden button rendered with aria-label="Enable accessibility", which a screen reader user encounters (and activates) as the very first focusable element on the page, or which an app can trigger programmatically.
The consequence for anyone running an audit: an automated scanner — or a screen reader that never lands on that hidden control — will report a Flutter Web app as having no accessibility tree at all, even if every widget underneath is annotated with perfect Semantics calls. This is a frequent silent-failure point in Flutter Web accessibility reviews. The annotation work was correct; the activation step just never happened.
Once semantics are active, the vocabulary converges. Flutter's SemanticsRole enum and related Semantics properties translate to the same role, name, value, and state primitives ARIA defines — checked, pressed, selected, disabled, expanded, and invalid all have a direct counterpart on both sides. The table below is a starting map, not an exhaustive spec:
| ARIA role / attribute | Flutter equivalent | Notes |
|---|---|---|
role="button" | Semantics(button: true) | Covers tap targets built from gesture detectors, not real buttons. |
role="navigation" | Semantics(container: true) with a landmark-style label | Flutter has no native landmark role; label the container explicitly. |
aria-checked | Semantics(checked: true/false) | Works the same for checkboxes, switches, and radio-style widgets. |
aria-disabled | Semantics(enabled: false) | Flutter inverts the boolean — it tracks "enabled," not "disabled." |
aria-expanded | Semantics(expanded: true/false) | Needed on any custom accordion or disclosure widget. |
aria-invalid | Semantics(validationResult: ...) | Pair with visible error text — the role alone won't announce why. |
Role mapping solves names and states; it doesn't solve navigation and live feedback, which HTML gives you from document order and native events for free. Two gaps show up in nearly every Flutter accessibility audit.
Tab order. A native page's keyboard tab order follows source order, automatically. Flutter has no implicit equivalent — you wrap the relevant widget subtree in a FocusTraversalGroup and define the order explicitly, or focus jumps in widget-build order instead of visual or logical order.
Live announcements. HTML's aria-live region tells a screen reader "announce this when it changes," with no extra wiring. Flutter's equivalent is an explicit call on every change:
<!-- HTML: live region, declared once -->
<div aria-live="polite">3 items added to cart</div>
// Flutter: announced explicitly, every time
SemanticsService.announce(
'3 items added to cart',
TextDirection.ltr,
);Skip either of these and the app can be fully role-mapped and still unusable with a keyboard or screen reader — the gaps are structural, not cosmetic.
Most of the failures above are avoidable with a short list, checked before a Flutter accessibility ticket is called "done":
Semantics; nothing is accessible by inheritance the way HTML elements are.SemanticsRole before you start building the Flutter screen, not after a complaint.Role mapping and the checklist above cover the mechanical translation — what stays genuinely hard is depth. A web team fluent in ARIA can follow the table above and ship a passable Flutter screen, but SemanticsRole's edge cases — custom scrollables, nested semantic merging, platform-specific screen reader behavior — take real time to learn, the same way WCAG itself took time to learn on the web side. If the Flutter surface is a small settings screen, doing it in-house with this checklist is reasonable. If it's the primary product surface, the one most of your users actually touch, the honest move is pairing your web standards knowledge with specialists who already know Flutter's semantics API cold — the same way you wouldn't improvise a complex ARIA widget on launch day either.
No — ARIA is an HTML/DOM vocabulary, and Flutter doesn't render HTML elements even on the web. Flutter uses its own Semantics widget and SemanticsRole enum, which the engine then translates into ARIA-annotated HTML when targeting the web. You never write aria-* attributes directly in Flutter code.
Not quite. The underlying Semantics tree is shared, but mobile translates it straight into the native iOS/Android accessibility APIs with no activation step. Flutter Web's ARIA overlay, by contrast, stays dormant until the "Enable accessibility" control fires — a web-only gotcha with no mobile equivalent.
No, and you can't even if you wanted to — you annotate with the Semantics widget, and Flutter's rendering layer emits the corresponding ARIA attributes in the DOM overlay it builds. Your job is the Semantics annotation; the ARIA markup itself is generated.
Almost always the activation gap: automated scanners, and screen readers that don't happen to land on the hidden toggle, see an app with accessibility never turned on, regardless of how thorough your Semantics annotations are underneath. Confirm the "Enable accessibility" control is reachable, or trigger activation programmatically, before trusting any scan result.
No framework is WCAG-compliant out of the box — compliance depends on what you build with it. Flutter gives you the primitives needed to meet WCAG 2.2 (roles, states, focus grouping, live announcements), but every one of them requires explicit use. Skipping the Semantics widget, FocusTraversalGroup, or SemanticsService.announce calls leaves real conformance gaps even on a recent Flutter SDK.
Start by confirming activation on the web build, then run a real screen reader through the core user flows, not just an automated scanner, checking focus order, announcements on dynamic changes, and whether every interactive element has a role, name, and state. Cross-reference against the role-mapping table above for anything that still reads as unlabeled or inert.