accessible computational notebooks
accessibility addresses a broad range of technical disabilities, in fact, the extent of these design spaces are so sprawling that all our visitors lived experiences are included. when we design for all these folks we must hold with tradition by considering our work's visual appearance. and, we go further to co-develop assistive designs that augment the throughput of sense data relating what our work, our science, sounds and feels like. these axes include swatches of assistive technologies like screen readers, braille displays, keyboard navigation, mobile devices, AAC, and, looking further, a future of bespoke accessibility solutions made from open hardware and software.
the expanse our of design constraints means we need to remain as close to vetted standards are possible. most of them originating from the alphabet soup of the WAI. the first stop in our standards journey WCAG that define failure criteria for inaccessible experiences, designing for WCAG means design non-inaccessible experiences. we need to look further for truly assistive technologies for the literacy machines we refer to as a computational notebooks. beyond WCAG, we'll consider
there are further aspects like accessible mobile, audio/video, evaluation, and pronunciation. it will require several aligned groups to cover all these aspects of accessibility.
most often accessibility design falls under the purview of WCAG, we can design and use techniques that are suggested. however, the use of notebooks in scientific practices often means that we are working outside these accessibility standards. external principles like POUR-CAF extend WCAG to consider heuristics for accessible data experiences.
empathizing with lived experiences will help any accessibility or assistive technology designer. the art of lived experiences through books, essays, and videos:
the predictable structure of the notebooks pairs well with css features. we'll need to make decisions on css that are accessible.
the goal of this implementation is end user configuration, and css is a lower friction way to give visitors control of their experience. some design decisions we make will become css interfaces that to configure experiences.
ARIA practice guides are developing best practices for developing common components. APG will be a beacon for the choices we choosing the proper semantics to present a notebook to assistive technology.
html is our matter when we create accessible experiences. designing reference implementations is a subtractive process to find the minimum html, css, and javascript required to describe an interface while satisfying automated testing constraints defined by the WHATWG living html spec and web content accessibility guidelines.
the first rule of ARIA is:
If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
a ARIA first rule design creates a reference implementation that relies on semantic web tags along with ARIA properties and roles to create a unstyled accessible implementation. this may not be the production implementation, but the effort in devising an ARIA first rule design will inform more complicated and styled interfaces. these reduced implementations set expectations that are easier to test and iterate on.
ARIA first principles encourage use semantic html elements to achieve the most assistive experiences for disabled users. this requires use to think about the meaning of each components and mapping it to an html standard.
currently, there are 4 templates with different DOM structures that in turn provide different cell navigation approaches with assistive technology:
- landmark navigation
- list navigation
- table navigation
- presentation navigation
the constrained Interactive Design Language for the semantic html specification does not allow for semantics to be changed from landmark to list semantics. in other words, these templates isolate specific navigation approaches and cannot be used in the same interface.
in landmark navigation, all cells have an aria-labelledby attribute and role=region. landmarks are exposed to screen readers as ways to navigate a document. landmark semantics make sense for notebook cells because they are often referenced as landmarks (eg "the first cell", "markdown cell 3", "the last cell"). assistive technology users may prefer this approach or just be more familiar with.
our template adds landmarks for table of contents, header, and footer. together the cells and the application will create a lot of landmarks, especially in a long notebook. this goes against accessibility recommendations to reduce the number of landmarks on the page.
Don't add too many landmarks to a page. Too many landmarks can make navigation more difficult and confusing.
list navigation is an approach to reduce the number of landmarks. list navigation represents cells as an order list. specifically for jupyter notebooks, these semantics make sense because ARE ordered.
with list navigation, screen reader users can navigation by list items which provides more fine grained control that the landmark representation.
presentation navigation is the null test. it removes any screen reader affordances to define the floor for accessibility.
web content accessibility guidelines are the bare minimum for assistive literacy experiences. restricting development and design to these limited guidelines will not provide equity or even equality to assistive technology users. we must look outside of WCAG and find accessibility frameworks that do help us imagine what equitable experiences are:
- Game Accessibility Guidelines
- Chartability and POUR-CAF principles
- Command Line Programs for the Blind
computational notebooks are a data visualization; hell they are data visualizations contain data visualizations. turtles all the way down.
there are a lot of reasons to consider a notebook to be a table of cells with metadata:
- the schema strictly defines notebook cells as a columnar data structure
- a critical compromising (understandable, yet robust) failure of data visualization is not providing a table.
Description: A table must be provided that contains a human-readable version of the data the chart is based on. This may be excluded if the chart title, summary, context, or annotations are sufficient at conveying all relevant information contained in the chart.
the ARIA first rule implementation designate the potential screen reader conformations a computational notebook may have. these implementations have semantic constraints that make it impossible to create multiple screen reader experiences in the same document.
the ARIA second rule says:
Do not change native semantics, unless you really have to.
our second rule implementations uses a table to represent the data structure of the notebook document. further, ARIA semantics are modified to create multiple screen reader experience sin the same document. this approach make flagship nbconvert-a11y templates the most flexible accessible html renderings. this approach allows us to roll each of the first principle assistive experiences into a single implementation; so we can choose a screen reader navigation technique or make it configurable for users.
computational notebooks serve as a containers narrative and code, but more generally they contain collections of hypermedia and hypertext. the generous ability to include any hypermedia from any vendor means that inaccessibility is inevitable especially when we rely on inaccessible upstreams. notebooks take on all the inaccessibilities an author chooses which is why is critical that the baseline notebook interface be accessible. our accessible baseline allows to measure inaccessibility; this work produces awareness for upstream accessibility and reference implementations for the expected experiences.
- The Story in the Notebook: Exploratory Data Science using a Literate Programming Tool
- Mapping the Landscape of Literate Computing
- Exploration and Explanation in Computational Notebooks
prior design studies about notebooks neglected accessibility in their surveys. the links below are accessibility specific references.