-
-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added aria-live to the tab bar to improve screen reader accessibility. #627
Conversation
Updated forked repo with changed from main
Thanks for submitting your first pull request! You are awesome! 🤗 |
@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
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! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
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