Main template layout

[tonyfast]

this pull request represent cells as a table body, and in action they are a layout table. layout tables should now have a thead, but tabular data should. in practice, we have a thead as a widget for choosing cell visibility and tfoot as a region to describe the notebook statistics. these two new features as critical content that create richer to aria-labelledby aria-describedby aria-details attributes.

we also introduce activity log regions that capture changes and provide aria-live announcements to screen reader users. the activity logs need to be placed in each dialog; the dialog destroys the accessibility tree and does not expose any non-dialog aria live changes. currently the announcements confirm configuration changes. they will be used for kernel started cell completed messages.

[tonyfast]

at this moment, the browse mode for cells uses list semantics. most screen reader users can navigate to lists with L or skip to cells as items with I, this is not true for voiceover.

the landmarks created too much noise in the landmark navigation. this became apparent when the toolbar for the notebook controls was used as a footer.

[tonyfast]

@smythp i have a demo that has a lot of flaws, but i just made a modification to the screen reader experience that i'd love feedback about. i've included a link to test at the end of the message.

the cells are representation as a list. now you have list and item navigation. the first line of the markdown is announced when you enter markdown cell items. code cells announce the cell number, but could/should announce the cell type.

please offer suggestions, but first i am like for a thumb up or down on the list navigation.

here is a page to test: https://iota-school.github.io/notebooks-for-all/branch/tpl-update/exports/html/Imaging_Sky_Background_Estimation-table-default.html

[tonyfast]

this In[*] elements should be labels that focus the source textarea.

[smythp]

Blocked off some time to go over this tomorrow, let me know if any links have changed, etc.

[tonyfast]

sorry for not confirming sooner @smythp . the current test link is https://iota-school.github.io/notebooks-for-all/branch/tpl-update/exports/html/Imaging_Sky_Background_Estimation-table-default.html.

i've added configuration in the settings dialog that allows you to toggle screen reader navigation roles.

• the default list option supports list and item navigation
• the table options supports table navigation which means you can navigation rows & columns
• the landmark navigation option exposes all of the cells as landmarks

further in the settings dialog, there are options for dark/light themes and changing some font features.

ultimately, i am interested in the best navigation approach for cells and what the best default role is. the settings dialog was added to make changing the screen reader experience more flexible and reduce the need for more exported html.

let me know if you find some time to experiment. i'd love to hear your experience.

[smythp]

Cool, going to have a bite and take a look at it. :)

[tonyfast]

thanks @smythp for sharing this audit! https://www.youtube.com/watch?v=sv5l5bVNE20

the default layout now has anchors for both markdown and code cells. this can backfire when markdown is applied poorly, but with thought it will improve the navigability of the document.

ultimately, i believe the user knows their needs better than i do so i want everything configurable. i think it makes sense to use the thead element as a region for adding interactive widgets. they are not visible now, but a peek into the dom will reveal the structure. the thead contains rows to toggle the visibility of all, code, and markdown cells. this small shape is applied to the tfoot that summarizes the document contents.

[tonyfast]

ugh. my VoiceOver tests have been total shit with the table layou. they are noisy and made me doubt the whole approach laid out here. we are encountering a bug where VoiceOver skips tables with captions. with the caption removed we can test VoiceOver iOS.

[smythp]

My feeling is that the notebook-as-x approach might or might not work out, but I do think you should walk the path to the end and see if it makes sense. The big plus is the unified paradigm so you know how to move around. The downside is that it is, or could be, unsemantic, since a notebook is not strictly a table or sa list. When you stretch the semantics too much, there's a fragility there.

Really what this needs is a new semantic structure recognized by W3, but yeah. Big work there, and uphill.

Let's see this through, I'll test for you and write it up at the end. Think of it as science. If nothing else maybe we will have data for a notebook proposal. If we're lucky someone else will sit on those committees, though...

[tonyfast]

My feeling is that the notebook-as-x approach might or might not work out, but I do think you should walk the path to the end and see if it makes sense.

thanks for the encouragement. i think approach is sound and i'm nearing an end. one of the real bottlenecks is testing with so many systems: axe, equal access checker, w3c validator, nvda, orca, voiceover ios. when we arrive at the end of this study we will have created a hull of semantics for notebooks. the knowledge of this landscape will help making accessibility decisions on the complex states of interactive notebooks.

The big plus is the unified paradigm so you know how to move around. The downside is that it is, or could be, unsemantic, since a notebook is not strictly a table or sa list.

so i think the most flexible and robust implementation will be the table. i like to consider the table as non-semantic, or pre-semantic. the table provides the right semantics to capture the data structure of the notebook in xml independent of the visual context. the table predates semantic html and has the most permissive aria roles and attributes. we exploit the pre-semantic table's permissive ability to many different semantic contexts for the screen role using consistent aria patterns. the table becomes that unified element with a consistent semantic structure for the underlying data supplemented with roles that consistent with semantic html elements.

Really what this needs is a new semantic structure recognized by W3, but yeah.

well can hint at that with web components. i think one of the extensions of the work we are entertaining now are notebook and cell web components that hint at that future. maybe they do presentation a new kind of interactive element or pattern.

Let's see this through, I'll test for you and write it up at the end. Think of it as science.

:heart: its good science. i believe in this study and approach. thanks for joining along with me. science is def better than proposal writing.

[smythp]

I like your defense of the table as presemantic. The table is also a flexible enough structure that it shouldn't be thought of as having rigid semantics. You can have a single-column table, etc.. It's pretty much the only game in town with regard to nonvisual data access other than a full REPL or query language.

Forge on while you have energy and we can think about turning it into other kinds of mojo later.

Writing a nonvisual intro to data science for Pandas (for which I am using the REPL only) and working with a client who is pretty annoyed to find that JupyterLite isn't very accessible so this work feels pretty central right now. Probably going to bug the JupyterLite people about notebook implementation stuff so let me know if you have any insight into that.

[tonyfast]

I like your defense of the table as presemantic. The table is also a flexible enough structure that it shouldn't be thought of as having rigid semantics. You can have a single-column table, etc.. It's pretty much the only game in town with regard to nonvisual data access other than a full REPL or query language.

these are great points i haven't thought of for nonvisual users. so, i've got some shit in the implementation that isn't conforming with standards. i thought i could use thead and tfoot as features for notebook controls and statistics; it is in the code as hidden elements now. the thead provides widgets to toggle visibility of the cell parts while the tfoot accumulations cell count, line count, output count. turns out everything goes to shit when i put role=presentation because only data tables can have thead/tfoot while layout tables should not. this is a small nit i want to sort because the automatic checkers yelling doesn't make me happy.

Writing a nonvisual intro to data science for Pandas (for which I am using the REPL only) and working with a client who is pretty annoyed to find that JupyterLite isn't very accessible so this work feels pretty central right now.

jupyter is a damn accessibility trashfire. folks are making earnest efforts against mounds of sociotechnical complexity and debt. there is a lot of focus on lab, but i think we should restrict accessibility to the single notebook implementation, not lab.

i wouldn't go buggin the lite folks too hard cause their real thesis is compiling jupyter to web assembly. they are downstream of all the accessibility failures of jupyterlab.

the work we are driving in notebooks for all is informing improvements to jupyterlab, but that accessible future isn't going to come soon. the reference patterns we've been developing have been influencing the semantics of lab. our focus here has value to jupyter products. our reference implementations are critical to that experience y'all desire.

another direction for this work could extend accessible notebook experiences to pandas using web assembly python. we could make a jupyter-less interface from the bones of these templates with pyodide or pyscript.

[tonyfast]

a snapshot of the automated testing results at the moment.

https://validator.w3.org/

the alt text image failures are the author's problem. the table row is open to fix in the validator https://github.com/validator/validator/issues/1125

axe

the serious error is keyboard access to overflowing elements. in firefox, focus is given to overflowing objects, but in chrome it needs to be hard-coded.

ibm equal access checker

accessibility insights

i'm thinkin this deserves a beer! :beer:

[tonyfast]

One error is placing focus on scrollable regions. This is a feature in Firefox, but not chrome. An update shows newer versions of chrome will focus overflowing regions. https://adrianroselli.com/2022/06/keyboard-only-scrolling-areas.html#Update04

[tonyfast]

i really like having all the cell indexes exposed as links. it turn out to be a really natural reference and gives tab navigation to every cell.

[tonyfast]

i'm proud of this one. it worked better than all the other starting points. this one is something to build on rather than throw allow.

i'm happy about how the notebooks are starting to sound. @smythp thanks for your opinion here. i'm gonna merge before things go awry.

[smythp]

Woo!