#69 asked for two things. The contrast half is done and is now a test: pyxray/tests/test_theme.py works the WCAG ratios out from the hex values in pyxray.theme and fails when a pair drops under the bar. That found and fixed two real problems, chip text and the edge of a control, and it will keep finding them.
The keyboard half is half done, and this issue is the half that a test cannot do.
What is already checked
xraywidgets/tests/test_xraywidgets_access.py reads the rendered markup and the stylesheet back and asserts:
- Nothing pressable is a styled
<div>. Every control is a real <button type="button"> with aria-pressed.
- The source box is a real
<textarea>, never a contenteditable div.
- Every
role="group" has a name on it, which it did not before.
- Every
<th> carries scope="col", and the table has a name.
- Every control has a
:focus-visible outline with an offset, and nothing anywhere in the sheet removes an outline.
- The focus outline is one colour in both themes, and it clears 3:1 against both pages.
- The front end saves and restores focus across a redraw, for a toggle as well as for the caret in the source box.
- Shift and Tab is not swallowed by the source box, so it is not a keyboard trap.
What is not checked, and needs a person
None of the above says the thing works. It says the pieces that would make it work are present. The rest needs somebody sitting at a machine, in the two places these widgets have to run, which is a marimo notebook locally and the WASM export served from the site:
- Tab reaches the source box and every toggle, in an order that makes sense when you cannot see the layout.
- Space and Enter both activate a toggle, and the state change is announced rather than silently applied.
- The focus outline is actually visible against both pages, not merely present in the sheet. 3:1 is a floor and a thin outline at the floor on a dim laptop screen is a different experience from the number.
- Focus lands somewhere sensible after the table redraws, in practice and not only in the code that intends it.
- A screen reader reads the table as a table, announces the column with the cell, and says whether a toggle is on.
The last one is the one most likely to be wrong, because it is the one that cannot be checked by reading the markup. VoiceOver, NVDA and Orca do not agree with each other and none of them agrees with the specification in every case.
What would close this
A comment on this issue saying which screen reader and which browser, what was tried, and what happened, including anything that was fine. A note that says "VoiceOver on Safari 26, tabbed through the disassembler, the toggles announce as toggle buttons and say pressed, the table announces columns, the focus outline is hard to see on the dark page" is worth more than a green tick, because the last clause is the thing that would otherwise never get written down.
Anything that turns out to be broken gets its own issue and gets fixed. This one is the measurement.
#69 asked for two things. The contrast half is done and is now a test:
pyxray/tests/test_theme.pyworks the WCAG ratios out from the hex values inpyxray.themeand fails when a pair drops under the bar. That found and fixed two real problems, chip text and the edge of a control, and it will keep finding them.The keyboard half is half done, and this issue is the half that a test cannot do.
What is already checked
xraywidgets/tests/test_xraywidgets_access.pyreads the rendered markup and the stylesheet back and asserts:<div>. Every control is a real<button type="button">witharia-pressed.<textarea>, never acontenteditablediv.role="group"has a name on it, which it did not before.<th>carriesscope="col", and the table has a name.:focus-visibleoutline with an offset, and nothing anywhere in the sheet removes an outline.What is not checked, and needs a person
None of the above says the thing works. It says the pieces that would make it work are present. The rest needs somebody sitting at a machine, in the two places these widgets have to run, which is a marimo notebook locally and the WASM export served from the site:
The last one is the one most likely to be wrong, because it is the one that cannot be checked by reading the markup. VoiceOver, NVDA and Orca do not agree with each other and none of them agrees with the specification in every case.
What would close this
A comment on this issue saying which screen reader and which browser, what was tried, and what happened, including anything that was fine. A note that says "VoiceOver on Safari 26, tabbed through the disassembler, the toggles announce as toggle buttons and say pressed, the table announces columns, the focus outline is hard to see on the dark page" is worth more than a green tick, because the last clause is the thing that would otherwise never get written down.
Anything that turns out to be broken gets its own issue and gets fixed. This one is the measurement.