Closed m158261 closed 11 months ago
Thanks for submitting your first pull request! You are awesome! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please make sure you followed the pull request template, as this will help us review your contribution more quickly.
You can meet the other Jovyans by joining our Discourse forum. There is also a intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:
@m158261 thanks for bringing up the topic of aria live. we are going to have to cross this bridge eventually.
it seems that notebook applications in general should likely have an accessible log of user actions. the idea is an element with role=log
which is an aria live region that updates when contents are appended to the element. the log
role has an implicit aria-live="polite"
. i noticed you're using assertive
which makes me think there are two possible solutions:
log
has a configurable aria-live
attribute that can be off
, polite
, or assertive
.aria-live
state. application developers could userLog.debug
, userLog.warn
, userLog.error
to map include visual, polite, and assertive updates.application authors would rely on a visually hidden, but focusable element; i guess this is why a dialog makes sense. they'd include messages likes:
userLog.debug(`visual message recieved`)
userLog.warn(`Restart and run all activated`)
userLog.warn(`Cell 10 completed`)
userLog.error(`Cell 12 failed`)
@m158261 thanks for bringing up the topic of aria live. we are going to have to cross this bridge eventually.
it seems that notebook applications in general should likely have an accessible log of user actions. the idea is an element with
role=log
which is an aria live region that updates when contents are appended to the element. thelog
role has an implicitaria-live="polite"
. i noticed you're usingassertive
which makes me think there are two possible solutions:
- this contents of the
log
has a configurablearia-live
attribute that can beoff
,polite
, orassertive
.- there are there logging elements for each
aria-live
state. application developers coulduserLog.debug
,userLog.warn
,userLog.error
to map include visual, polite, and assertive updates.application authors would rely on a visually hidden, but focusable element; i guess this is why a dialog makes sense. they'd include messages likes:
userLog.debug(`visual message recieved`) userLog.warn(`Restart and run all activated`) userLog.warn(`Cell 10 completed`) userLog.error(`Cell 12 failed`)
Hey @tonyfast, thanks for the feedback on aria-live. I have tried some different implementations and found one that works with the scenario I'm working with. I've found appending the live region to the tab bar works as it's high up in the DOM and always visible. Previously I had tried appending it to the command palette but as this is hidden most of the time, the screen reader wasn't picking up changes.
Please let me know what you think and if any improvements can be made. I think this is a good starting point for adding aria-live to jupyterlab and improves accessibility for users running commands using the command palette/keyboard commands.
Thanks in advance!
I have added an aria-live region to the tab bar to aid with screen reader accessibility. For this scenario I want a custom message to be read when a user runs a command either from the command palette or via a keyboard command. Please see the linked jupyterlab PR for the implementation.
Here is the aria-live documentation...
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions
Expected Functionality
This functionality provides an aria-live region that when a command is triggered, custom text will be read by a screen reader. This works by text being appended to the region when a command is used.
This is two part pull request with the additional required code being in Jupyter Lab.
Linked PR
https://github.com/jupyterlab/jupyterlab/pull/15048