Identify accessibility targets for Lumino 2

[afshin]

Let's identify whether there are API and/or implementation changes for accessibility enhancements that we should be targeting for Lumino 2 paying particular attention to backward-incompatible APIs that benefit most from the major version bump.

[gabalafou]

Couple questions.

What's the best way for me to get a good grasp of the API changes from version 1 to 2?

If I compare 1.x to main does that represent the most current set of code changes between version 1 and 2?

Briefly skimming that diff, it looks like a lot of the lines are about removing all of the deprecated phosphor stuff. If there were some way I could easily filter out those changes...

Another question. What kinds of accessibility enhancements are within scope? Specifically, I'm wondering about some work I started on (but didn't get to complete) to fix tab traps in the JupyterLab UI. This requires making code changes to Lumino, for example changing the menubar to no-op on keypress if the key is a tab.

[afshin]

Aside from things that involve iterators, most of the other API changes are removals of old classes and things that should not have a big effect on accessibility.

Any enhancements you think are viable are within scope, but those that require an API change are especially urgent because otherwise, we'd have to wait until Lumino 3.

[gabalafou]

With reference to my question in today's accessibility meeting about what counts as an API change, I'm curious to get your take on the idea of changing div to button. Mostly to help me to get a better understanding of how to think about it.

[afshin]

In general it is probably fine to make a DOM change like that, assuming most things are styled with CSS classes. But it's plausible to imagine a CSS rule like:

div.foo-class {
  color: red;
}

... in which case changing the HTML does change the CSS.

But as a fast and loose rule, I don't think changing a div to a button is a backward-incompatible API change.

[krassowski]

During the accessibility meeting the topic of the datagrid package, which is using HTML canvas, came up. In addition to the csv viewer, the debugger also uses the data grid (to display variables table). When reviewing a PR fixing a bug in that table, we delved into the datgrid mouse and keyboard handler API and accessibility needs.

Briefly, in JupyterLab we should not re-implement selection handling (as debugger does) but delegate it to lumino so that both keyboard, mouse and other devices are handled correctly; instead we should listen to SelectionModel.changed (jupyterlab/jupyterlab#12943 (comment)). These changes should be possible with current lumino API because the selection model seems public as seen in csvviewer and debugger.

Accessibility-wise, I think that there should be a listener to the SelectionModel.changed event which would trigger some kind of silent notification to let the screen reader user know that the selection (focus) changed. It should probably be implemented in lumino itself to avoid re-re-implementing this downstream (c-f jupyterlab/jupyterlab#9031 and jupyterlab/jupyterlab#6583).

While I only touched upon a tiny bit of datagrid accessibility, I hope it helps you get a better picture of where things stand.

[gabalafou]

Thanks @krassowski!

Just to clarify, if I understood you correctly, you're saying that as far as what you looked into with respect to DataGrid, you don't currently see any breaking API changes that we would need or want to make to Lumino in order implement your recommendations. At least as far as DataGrid goes. Is that correct?

[isabela-pf]

Following up on the datagrid discussion, I'm summarizing what we talked about in a JupyterLab accessibility meeting today.

• Creating accessibility tree and exporting it ourselves. @krassowski brought up that "xterm.js has accessibility tree and is based on canvas too."
• How would this impact performance? That's a major motivation for the current implementation and not one we want to get rid of.
• Can we have a media query to detect screen readers and automatically switch to a version that is focused on more on accessibility and less on performance?
• Are there reasons we want people to be able to change the status manually? In case we assume wrong that someone is using assistive tech? In case it benefits people with setups we aren't querying for?
• Querying for screen readers is tricky because that is information people shouldn't have to disclose, and there's been concern that it creates two different code paths with different experiences.
• Apps that do try and workaround this look for other behavior that is associated with a screen reader. For example, they look for repeated tab key use or other keyboard shortcuts that they presume are associated with this assistive tech.
• Debugger and file browser already have tree views, which seems like a reference for the steps we may want to take.

In summary, I don't think we found a single solution. We were able to discuss more options since we have more insight than in previous discussions.