accessible jupyter notebooks (for all)

this talk is about accessible computational notebooks, specifically jupyter notebooks. it will outline our efforts to understand and improve on the qualities of jupyter notebooks. we'll highlight:

• the scope of notebooks in science and software
• modern web accessibility standards, conventions, and colloquialisms
• paid assistive tech user testing
• an html5 substrate for computational literature
• challenges we overcame and what comes next

lets design an accessible house together!

---

Isabela Presedo-Floyd @isabela-pf

has a love-hate relationship with sonic the hedgehog.

Dr. Tony Fast @tonyfast

has tattoos he randomly picked from a hat, it was a nice hat.

---

big picture

• trillions of galaxies

• billions of devices

• millions of notebooks

  as of 4/11, there are >10 million ipynb files on github. nbestimate provides daily estimates of ipynb files.

medium picture

• thousands of repositories
• hundreds of disciplines
• tens of regional and programming languages

smallest picture: the notebook for all picture

notebooks for all is an interdisciplinary accessibility collaboration fusing design research, user testing, and software development to make literate computing notebooks accessible. through this cooperative effort we were able to inspire accessible solutions to a long withstanding vulnerabilities. this effort builds off of years of vigilant community organizing in Project Jupyter.

what are notebooks and cells?

• word processing documents with computation
• notebooks are collections of cells that combine code and narrative. cells can be combined in different ways to drive computational narratives in nearly all disciplines.
  • the notebook defines cells as coupled code input and output.
• arepopular provided by different vendors Jupyter, Google, Microsoft, AWS
• notebooks are catalyst for documentation, testing, books, classrooms, and blog posts.
• the ipynb format is a standard binding millions of notebooks and users.
• for me, there are a cognitive accessibility tool and assistive technology for story telling.
• the notebooks for all task: what makes an accessible computational document/notebook/essay?

inclusive design in open source

this inclusive design project melded design and open source development. in less than a year, multiple abled and disabled people cooperated to design an accessible substrate for computational notebooks.

• several rounds of compensated user testing.

designing a modular house that is up to code

• we'll use the analogy of house to describe our efforts.
• percieve the notebook document as modular house, and the cells are the rooms
• we tried retrofitting accessibility in the old house, but that proved challenging
  • we took their time and feedback to think about a more accessible home for our notebook data as a document.
• we built a house on standards. these should be invisible to the user, but critical to their safety.

housewarming: content and navigation testing

user testing helped understand what an accessible document house needs. we learned a lot about how to throw a part, even though sally could't get down the stairs to the basement to play shuffleboard.

• see the nagivation testing results

• wip - content report

  • many fixes are "the basics"
  • users search for and rely on familiarity to manage their experience
  • "annoying but normal" is the best case scenario

• what if cells were input forms? cell inputs are interactive elements, at a minimum they are copy pastable.

get the utilities connected (have a big zoom celebration shout out iota school)

• we know community is important - thanks to everyone at the previous hackathon
• accessibility work is a community project.

getting the house up to code

two axes:

1. remediating html versions of notebooks.
2. applying POUR-CAF principles to the semantic structure of the notebook

the semantic html5 specification

• the notebook is a document with metadata. it can be percieved using html a <table> wherein the rows how structured data about each cell in the notebook.
• rather than a slew of nested meaningless <div> elements we have semantically markup for notebook documents. each cell represents a complex html <form>

nbconvert --to html5 features

• semantic html tags, roles, and aria for the notebook and its cells

• efficient tab navigation including:

  • skips links
  • heading links with large hit areas
  • cell source as readonly forms that take tab focus
  • any other rich interactive content in the output

• uses Atkinson Hyperlegible which is:

  specifically to increase legibility for readers with low vision, and to improve comprehension.

• uses the github-light-colorblind pygments code theme from the accessible-pygments project based on a11y-syntax-highlighting

• screen reader landmarks, headings (markdown & outputs), forms (cell inputs), and table navigation

• operable when zoomed in

• table of contents for code and narrative navigation

lets party

our notebooks for all documentation and github repository transparently share our mutual efforts including meetings minutes, code, and other team resources. all in under a year… not bad.

demo of the nbconvert --to html5 theme

borrowed from the nbconvert_html5 notebooks for all documentation

old and new

we'll illustrate what rendered jupyter notebooks are and demonstrate some of the improved accessibility affordances.

• the default template at the beginning of the project
• the semantic html5 variant after the project

more test notebooks

demo tools that i'm not going to demo cause this ain't my box

• Chrome Dev Tools
• Accessibility Object Model
• Deque Axe
• equal access checker
• POUR-CAF heuristics

limits of the work

• we worked with a small and vision-focused sample (but also across fields and experiences)
• we tested on navigation and reading experiences, not editing experiences
• people can put (almost?) anything in notebooks
• retrofitting accessibility is hard

what did we do

• we included disabled people
• we researched patterns across computational notebooks
• we fought some tech debt and wrote some code
• we got feedback on our work and shared our findings in multiple user testing cycles
• we created open resources to understand our work and to help people reproduce it
• we figured out advice for notebooks that overlap with wcag standards