Added aria-live to the tab bar to improve screen reader accessibility.

[m158261]

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

jupyterlab/jupyterlab#15048

[welcome]

Thanks for submitting your first pull request! You are awesome! 🤗

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! 👋

Welcome to the Jupyter community! 🎉

[tonyfast]

@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:

• this contents of the log has a configurable aria-live attribute that can be off, polite, or assertive.
• there are there logging elements for each 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]

@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:

• this contents of the log has a configurable aria-live attribute that can be off, polite, or assertive.
• there are there logging elements for each 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`)

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!

[tonyfast]

@m158261 this seems like a really feasible flexible solution. i think it makes sense to me.

i think in a future PR we should consider the location of the user log. the user log would be most accessible if its contents can be explored. i like to use a principle of "if its audible it should be visible, if its visible it should be audible". i could see the user log being its own pane that someone could explore later if they are trying to find something they did in their history. but, i'd say handle that in another place if someone asks.