01.27.21 Meeting Minutes
01.27.21 Meeting Minutes#
(oops! No one signed in today so I gave my best guess.) Max @telamonian Thomas @manfromjupyter Martha @marthacryan Jason @jasongrout Tony @tonyfast Alex @ajbozarth Karla @karlasupldaro Isabela @isabela-pf
What are people working on?#
How is everyone doing?
Come up with different intro questions :upside_down_face:
Does it make sense to have these meeting notes documented outside an issue? I think there’s enough content there that it’s hard to navigate if you aren’t just looking for the first or last comment. - Yes! Let’s propose a place in the Jupyter accessibility repo.
Can we make an issue about adding accessibility tests to the JupyterLab development process? - I was reminded by the discussion started on JupyterLab Classic #80. - I’ve also listed some existing tests. We should review these to see if they could work or give us a baseline for working with lumino or jupyterlab components. - squizlabs / HTML_CodeSniffer - IBM’s accessibility-checker - AccessLint / accesslint.js - pa11y / pa11y - dequelabs / axe-core
Should we also make an issue reminding us to make accessibility docs as we make all the WCAG and other changes?
Check in! In the JLab team meeting, we have accessibility listed as an issue people are working on within the JLab 4.0 timeline. What scope do we want to report? Are we working on #9339 and #9491 only right now, or is someone planning to work on the editor? - #9339 and #9491 for sure. Editor changes are still being researched so mark it as possible but uncertain.
Max started working on #9491
Probably JupyterLab and not lumino level fixes.
With Max’s PR, this should cover #9491!
Tony’s PR should cover all landmarks.
Only thing left is making it so screen readers can access those different labels.
How does this interact with JLab themes? We need to test what this PR means visually.
Spatial experience and vision
Thomas says you are generally not supposed to label things that will be accessed via screen reader with left, right, here, so on because it doesn’t really mean anything to those users.
In CSS classes or other areas not accessed by a screen reader, this is okay.
Tab index convention
Seems like the main recommendation is to set everything to tabindex 0 (because it defaults to the browser).
Does this work for JupyterLab?
-1 means you aren’t going to see it. For example a is a tab and buttons are tabbed, so there is possibility for things being tabbed twice. So sometimes -1 is to avoid redundancy.
Tabs are only for people to jump to those regions. They do not define the region or header/hierarchy. But tab puts you in those places to then announce the region or header.
Merged PRs (let’s celebrate!)#
Martha merged lumino #149! :tada:
Max merged lumino #150! :confetti_ball:
Isabela merged jupyterlab #9335! :sunflower:
Propose moving accessibility meeting notes to the accessibility repo so they are easier to search.
Follow up on test/CI ideas
Update accessibility project with merged PRs
Start issue for adding accessibility page to docs
Add resources to contributing guidelines encouraging people to read up on accessibility.
Will note the next five steps they recommend focusing on and make relevant issues.
Work on #9622
Review Martha’s #149 PR
Work on PR for #9491
Continue on #9648 reviewing visual impact and with a JupyterLab-style class name.