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?