Skip to content
Tony Fast edited this page Feb 21, 2024 · 3 revisions

nbconvert-a11y is a work in progress towards accessible html representation of computational notebooks, more specifically documents complying with the [jupyter notebook format]. accessibility practices for notebooks have historically been ignored. we must design these interfaces to be accessible because they are increasingly common portals for computational literacy practices in education and business. unfortunately for assistive technology users, the adoption of computational notebooks has continued undeterred without any accessibility foundations; this is an inaccessibility that cumulatively harms marginalized communities of disabled learners. now, all notebooks have inaccessibilities that limit the quality of the notebook experience for assistive technology users, their literacy gains will suffer disproportionately when they use inaccessible systems, like most interfaces, notebook interfaces, are accessibility anti-patterns and this studies of their structure and semantics will bring long needed redress to assistive technology users.

first and foremost, notebooks are literacy tools that advance both reading and writing practice. to date, a lot notebook development has focused on hyper-interactive features (eg code completion, reactive interfaces, interactive visualization), and this disproportionate interest in interactivity belies the enduring qualities of the notebook document which is critical to ensures future access. the neglected development into the reading qualities of the same document. we can see varying opinions for html notebooks in sphinx or mkdocs documentation, but, again, accessibility requires retrofitting. experienced notebook users can attest to gaining literacy through the repeated work of interactive computing, but the lack of accessibility considerations means that this experience is limited to abled users. disabled users are required to use a variety of bespoke tools, these niche tools tend to lack the 👀 to make enough bugs shallow. popular upstreams need to integrate accessible developer experiences otherwise disabled people cannot share the same cooperative benefit of open source. inaccessibility is harmful.

the nbconvert-a11y spun out of the [notebooks for all] project. these projects are successful because the design decisions begin with accessibility and include affected disabled people. the dual mission of literacy and accessibility provide non-technical constraints to answer our technical questions. this is good because technology rarely fixes technology.

this project makes accessibility a foremost priority. so much so that we view literacy acquisition through the lens of technical disability, and, as a result, demand equitable accessible developer experiences. within a discipline, not knowing or lacking language is a manufactured technical disability and filling this lack requires assistive technologies. we must learn to discover information about people, places, and things; further, we acquire language through community culture learning to ask better questions and gain more knowledge. literacy journeys begin with a need for access and, more generally, accessibility. these are the motivations for accessible HTML recommendations for computational notebooks. this is where the literacy journey will begin for most people, and it will work best when accessibility is a guiding principle.

Clone this wiki locally