🗣️ Improve screen reader support for reactive output changes #2768
Labels
accessibility
Accessibility improvements of the frontend, like screen reader support and internationalization
frontend
Concerning the HTML editor
PR #2757 makes a first step to get Pluto closer to being usable keyboard-only with a screen reader.
When you edit and run code, it will start running, and when finished, the result is returned by updating the cell's output. Because this is asynchronous, this information is currently not surfaced with a screen reader. The solution is to use an "ARIA live region": you can declare a DOM element to be "live", meaning that any update that happens to it should be announced with speech.
This PR makes the
<pluto-output>
a live area.xyz =
, it reads "Result of variable xyz:", otherwise "Result of unlabeled cell:".<pluto-output>
is marked as "atomic": screen readers should always announce its full contents when anything changes. E.g. if the output changes from[1,2]
to[1,2,3]
, don't just announce3
. It also means that the label will be read on any change.aria-relevant
setting isall
: additions, deletions, modifications.Here is a screen recording (no audio but subtitles). Notice that the third cell runs reactively, and the new result gets announced.
Schermopname.2023-12-18.om.15.06.49.mov
Recorded on Chrome with MacOS voice-over enabled (default settings, dutch).
TODO:
aria-live="polite"
setting, some announcements still interrupt others. E.g. in the recording above, I sometimes saw that the tiny delay between the two cells caused the first announcement to be interrupted. We could use thearia-busy
setting to deliver the multiple updates in a batch (I think), but we also don't want to hold all updates until all cells completed running.The text was updated successfully, but these errors were encountered: