Why this page exists
The implementation breakdown reports findings from one screen reader on one operating system: VoiceOver on macOS 26, driving WebKit and Chromium. That is enough to have already changed one conclusion — the boundary-space mitigation showed no observable effect on VoiceOver — but it is not enough to call any approach the best practice for 2026.
This page lists what still needs to be tested, what each test would prove, and which test could overturn a current finding. The goal is to decide the approach on evidence across the assistive technologies people actually use, not on one platform.
What has been established so far
| Claim | Status | Confidence |
|---|---|---|
:focus-within reveals hidden wrappers | Real and differential | High — measured on WebKit and Blink; purely CSS behavior |
Skip target without tabindex="-1" resumes focus in <main> | Works | Medium-high — measured on WebKit and Blink; desktop only so far |
| Boundary spaces change spoken output | Real on NVDA + Chrome; neutral on Firefox and VoiceOver | Medium — confirmed on the most common Windows combination (NVDA 2026.1.1 + Chrome 151, reported in review); JAWS still unverified |
Testing still needed
Ordered by how much each would change the decision.
| Test | What it would prove | Could it overturn a finding? |
|---|---|---|
| NVDA + Firefox and Chrome (Windows) — partially done | Whether the boundary-space mitigation actually helps on the most-used screen reader. NVDA and JAWS are where the \00a0 pattern originated. |
Answered for the boundary claim (reported in review). NVDA 2026.1.1 + Chrome 151 concatenated Place blockin the Header regionwithout the spaces and spoke a clean boundary with them; Firefox 154 exposed separate nodes (neutral). This overturned the VoiceOver-only "no effect" reading. Re-running the other claims (skip target, margin: 0 order) on NVDA is still open. |
| JAWS (Windows) | Second most-used screen reader; dominant in government and enterprise, which is Drupal's core audience. | Yes, for the boundary claim. |
| Chrome / Blink + VoiceOver (macOS) | Whether Blink's accessibility tree changes the boundary result versus WebKit. | Possibly, for the boundary claim. Blocked in automation here by a macOS Automation-authorization quirk when Chromium is frontmost; needs a machine where that gate can be cleared. |
| iOS VoiceOver and the back gesture | Whether tabindex="-1" on a landmark actually interferes with the iOS back gesture, the specific mobile argument for removing it. |
Yes, for the skip-target claim — it could add a concrete mobile benefit currently only asserted. |
| Android TalkBack | Boundary and skip-target behavior on the dominant mobile screen reader outside iOS. | Yes, for the boundary claim. |
| 400% zoom and screen magnification | Whether revealing the whole wrapper (rather than only the focused child) actually helps a magnification user locate context — the magnification argument for :focus-within. |
No, but it would confirm a benefit currently asserted rather than shown. Best done as manual review with screenshots at 100/200/400%. |
margin: 0 and VoiceOver announcement order |
Whether a negative margin actually causes VoiceOver on macOS to announce visually hidden text in the wrong order — the GOV.UK 2019 rationale for keeping margin: 0. Automated by npm run test:margin-order (standalone VoiceOver runner), comparing margin: 0 against a negative margin. |
No, but it confirms or refutes a specific untested rationale in the proposed CSS. Ready to run when VoiceOver automation (Full Disk Access) is available. |
Clipboard behavior (user-select) |
Whether GOV.UK's user-select: none meaningfully prevents copying hidden text, and whether Drupal wants that behavior. |
No, but it isolates a real behavioral difference between the models that is easy to demonstrate. |
How each screen reader would be driven
- VoiceOver (macOS) — already automated with Guidepup. See the Guidepup setup notes. VoiceOver capture runs as a standalone Node runner, not under the Playwright test runner, because the test runner's browser has no frontable window.
- NVDA and JAWS (Windows) — Guidepup supports both on Windows. This requires a Windows machine or virtual machine; it cannot be run from macOS. This is the single highest-value gap.
- iOS VoiceOver / Android TalkBack — mobile screen readers are harder to automate. Start with manual scripted passes on a simulator or device, capturing spoken output and the back-gesture behavior.
- Magnification and clipboard — partly deterministic (computed
user-select, wrapper reveal) and partly manual (visual tracking at zoom, actual copy-paste into another application).
What "proven" would mean
An approach is ready to recommend as 2026 best practice when, for each claimed benefit, there is either:
- a deterministic check that the difference exists (CSS or markup), and
- screen-reader evidence, on more than one screen reader, that the difference reaches the user — or an explicit, recorded decision that the change is neutral and retained for another reason (for example clipboard protection, or forward compatibility).
Until then, findings are reported with their platform and their confidence, and no single-platform result is treated as settled. That discipline is the difference between demonstrating an improvement and rearranging the deck chairs.