FR-UI-030 (Must, Verify: M) requires the interface to be usable with assistive technology. Its manual-test document is NOT EXECUTED — but the more important point is recorded inside that document and nowhere else: running the script today would fail, not pass.
The gap is in the product, not in the verification
egui builds an accesskit tree. Getting that tree to a screen reader requires a platform adapter — the piece that bridges to UI Automation on Windows, AT-SPI on Linux, or NSAccessibility on macOS. egui-baseview 0.6.0 wires none. So the accessible names Namir sets are computed and then discarded before any assistive technology can observe them, and a screen reader announces nothing.
This is the same shape as R-16 (no Wayland backend): a limitation inherited from the pinned windowing stack rather than from Namir's own code, and not fixable by changing anything in namir-ui.
Why it needs a decision, not a test run
Unlike the other five unexecuted Verify: M Musts (#34), no amount of human time at a machine closes this one. The options are:
- Wire an adapter.
accesskit_winit exists but baseview is not winit; a baseview adapter would have to be written against each platform's accessibility API, which is new unsafe surface under D-5.3 in a crate that currently has none, and is realistically upstream work in egui-baseview or baseview.
- Narrow FR-UI-030 to what the pinned stack can deliver — keyboard navigability and visible focus, which are achievable and testable — and record the screen-reader clause as unmet with a
*Consequence* note, the shape FR-CLAP-030 used.
- Ship with the requirement unmet and unrecorded. Not acceptable at a 1.0 gate; accessibility claims are the kind users and procurement rely on.
Option 2 is the honest one for 1.0 unless accessibility is a stated product commitment, in which case option 1 becomes real scoped work rather than a wish.
Related: #19 (same class — a limitation of the baseview pin), #34 (the six unexecuted Verify: M Musts, of which this is the one that cannot be closed by running the script).
FR-UI-030 (Must,
Verify: M) requires the interface to be usable with assistive technology. Its manual-test document isNOT EXECUTED— but the more important point is recorded inside that document and nowhere else: running the script today would fail, not pass.The gap is in the product, not in the verification
eguibuilds anaccesskittree. Getting that tree to a screen reader requires a platform adapter — the piece that bridges to UI Automation on Windows, AT-SPI on Linux, or NSAccessibility on macOS.egui-baseview0.6.0 wires none. So the accessible names Namir sets are computed and then discarded before any assistive technology can observe them, and a screen reader announces nothing.This is the same shape as R-16 (no Wayland backend): a limitation inherited from the pinned windowing stack rather than from Namir's own code, and not fixable by changing anything in
namir-ui.Why it needs a decision, not a test run
Unlike the other five unexecuted
Verify: MMusts (#34), no amount of human time at a machine closes this one. The options are:accesskit_winitexists butbaseviewis notwinit; abaseviewadapter would have to be written against each platform's accessibility API, which is newunsafesurface under D-5.3 in a crate that currently has none, and is realistically upstream work inegui-basevieworbaseview.*Consequence*note, the shape FR-CLAP-030 used.Option 2 is the honest one for 1.0 unless accessibility is a stated product commitment, in which case option 1 becomes real scoped work rather than a wish.
Related: #19 (same class — a limitation of the
baseviewpin), #34 (the six unexecutedVerify: MMusts, of which this is the one that cannot be closed by running the script).