[Flutter web-semantics] Feature request: Enable Accessibility button upper left 1 pixel instead of offscreen 1 pixel

[ecolab-neil]

Use case

Automation tools such as Maestro and probably Appium seem to not be able to tap on
document.querySelector('flt-semantics-placeholder[aria-label="Enable accessibility"]') .click(); because it is at absolute positivion -1 left and -1 top of the screen (offscreen).

Maestro does appear to be able to tap on an invisible button with no text if it is at 1,1.

I am not sure if i have bandwidth to PR this but i wanted to get the discussion going.
See: https://docs.flutter.dev/ui/accessibility/web-accessibility#invisible-button

Can anyone think of a reason that the ('flt-semantics-placeholder[aria-label="Enable accessibility"]' has to be offscreen rather than "just" onepixel, invisible, transparent etc?

Proposal

Change just 2 characters in the code to make the button be "+" 1 left and "+" one top insteda of "-" (or remove the negative)

[tirth-patel-nc]

@ecolab-neil thanks for the report. Could you please confirm if the solution mentioned in #125415 (comment) helps in your case? Also, is this issue related to #174016?

[ecolab-neil]

@tirth-patel-nc thanks for the response.
I would like to be able to tap on the button to enable semantics for automation with no changes to the system under test for a few reasons

1. Best practice and ease of team communication (not modifying SUT
2. enabling semantics on web slows down performance which is why it's off by default (at least as of Oct 2025)
3. There are bugs that affect users with semantics on such as overlay

therefore I would like to "give' control in a reliable way to automation.
I think /hope we could make only a few small modifications and achieve the basic A/C of

1. No performance or UX at all is bothered by this change for default semantics off
2. all automation frameworks can easily tap it in all browsers etc
3. No problems are caused in any way for screen readers etc

i'm not a css or javascript expert though or really web even, i came from mobile and flutter mobile, but maestro is much much easier to set up than selenium and works for mobile and web

• @bartekpacia :)

[tirth-patel-nc]

keeping it open for team's tracking.

#137736 #77507 might be related.

[ecolab-neil]

@tirth-patel-nc @darshankawar 77507 is a good point . In general i think more guidance about accessibility would be very helpful such as helping companies know "how significant" the performance hit is.

ie
Use Case 1 - Hello world, flutter web demo purposes - any performance hit is not good
use Case 2 - Heavy use by accessibility users - surely we would not want them to have to click anything
Use Case 3 (ours) - Enabling semantics broke overlays/dropdowns at least for now - has to be off by default in dart code
Use Case.4 - "mainstream" - 80% of "enterprise" usage where accessibility use is "expected to be significant in the near future" - Guidance on how to do decide whether on or off, based on if the peformance issue is "significant" or "noticeable" to non-screen-reader users