Use case
I am requesting an accessibility improvement for Flutter web.
An accessibility audit using axe Auditor found that a Flutter-generated focusable semantics node has no visible focus indicator when it receives keyboard focus.
Audit details:
Issue: Focus indicator is missing
WCAG checkpoint: 2.4.7 Focus Visible
Standard: WCAG 2.1 Level AA
Platform: Flutter web / desktop web
Impact: Critical
Audit tool: axe Auditor, axe-core 4.10.2
Example semantics node generated by Flutter web:
Baby's date of birth
The element is keyboard-focusable and exposed as a button, but there is no visible focus ring or other visual indication when it receives focus. This fails accessibility audits for keyboard users because sighted keyboard users cannot identify the active control.
In the application, this pattern appears around a date-of-birth control that opens a Flutter date picker. App-side workarounds such as wrapping custom controls with FocusableActionDetector can help for app-owned widgets, but they are difficult or impossible to apply consistently to framework-owned/internal semantics nodes generated by Flutter web or Material widgets.
Proposal
Flutter web should provide a framework-supported way to show a visible focus indicator for focusable semantics nodes that are exposed to the web accessibility DOM, especially nodes with interactive roles such as button, link, or tappable controls.
Possible approaches:
Provide a default visible focus indicator for focusable flt-semantics nodes on Flutter web when they receive keyboard focus.
Expose a public theming/configuration hook so applications can style the focus indicator for Flutter-generated semantics nodes.
Ensure Material widgets such as date picker controls expose visible keyboard focus states consistently on web.
Document the recommended framework-supported approach for WCAG 2.4.7 compliance when Flutter web creates focusable semantics nodes.
Alternatives considered
Adding FocusableActionDetector around app-owned controls.
This works only when the application owns the focused visual widget.
It does not fully solve framework-owned/internal semantics nodes.
Replacing Flutter showDatePicker or related Material controls with a custom picker.
This is heavy and duplicates framework behavior.
Styling flt-semantics directly with CSS.
This relies on Flutter web engine internals and is not a stable public API.
Minimal reproduction
I can provide a reduced Flutter web sample if needed. The relevant generated DOM pattern is a focusable flt-semantics node with tabindex="0" and an interactive role, but no visible focus indicator when focused by keyboard.
Use case
I am requesting an accessibility improvement for Flutter web.
An accessibility audit using axe Auditor found that a Flutter-generated focusable semantics node has no visible focus indicator when it receives keyboard focus.
Audit details:
Issue: Focus indicator is missing
WCAG checkpoint: 2.4.7 Focus Visible
Standard: WCAG 2.1 Level AA
Platform: Flutter web / desktop web
Impact: Critical
Audit tool: axe Auditor, axe-core 4.10.2
Example semantics node generated by Flutter web:
Baby's date of birth
The element is keyboard-focusable and exposed as a button, but there is no visible focus ring or other visual indication when it receives focus. This fails accessibility audits for keyboard users because sighted keyboard users cannot identify the active control.
In the application, this pattern appears around a date-of-birth control that opens a Flutter date picker. App-side workarounds such as wrapping custom controls with FocusableActionDetector can help for app-owned widgets, but they are difficult or impossible to apply consistently to framework-owned/internal semantics nodes generated by Flutter web or Material widgets.
Proposal
Flutter web should provide a framework-supported way to show a visible focus indicator for focusable semantics nodes that are exposed to the web accessibility DOM, especially nodes with interactive roles such as button, link, or tappable controls.
Possible approaches:
Provide a default visible focus indicator for focusable flt-semantics nodes on Flutter web when they receive keyboard focus.
Expose a public theming/configuration hook so applications can style the focus indicator for Flutter-generated semantics nodes.
Ensure Material widgets such as date picker controls expose visible keyboard focus states consistently on web.
Document the recommended framework-supported approach for WCAG 2.4.7 compliance when Flutter web creates focusable semantics nodes.
Alternatives considered
Adding FocusableActionDetector around app-owned controls.
This works only when the application owns the focused visual widget.
It does not fully solve framework-owned/internal semantics nodes.
Replacing Flutter showDatePicker or related Material controls with a custom picker.
This is heavy and duplicates framework behavior.
Styling flt-semantics directly with CSS.
This relies on Flutter web engine internals and is not a stable public API.
Minimal reproduction
I can provide a reduced Flutter web sample if needed. The relevant generated DOM pattern is a focusable flt-semantics node with tabindex="0" and an interactive role, but no visible focus indicator when focused by keyboard.