-
Notifications
You must be signed in to change notification settings - Fork 1
cell components
notebook cells are composite objects that have multiple properties and constraints. this document highlights resting state for each of the common cell components and comments on their accessibility.
a unique perspective of nbconvert-a11y is that every every cell is treated as a cell,
and the cell type determines the visual, audible, and tactile features of the cell object.
cells as forms opens the vocabulary of semantics that we can apply to notebook components. this is one of the most novel perspectives of this work is the representations of notebook components as form elements. nearly all notebook interfaces rely on frameworks to support hyper-interactive applications. frameworks make it is very easy to ignore accessibility best practices for the sake of speed and precision. these are the anti-patterns that this work is fighting again.
as of 2024/2/1, the
forms have only been used for readonly cases. it becomes possible to imagine progressive implementations that can handle the form submission of cells to a kernel. the accessible substrate for reading matures into an interactive experiences. with minor funding, reference implementations for the interactive experience can be developed to test and design the assistive interactive experiences with features likearia-live.
another advantage of form elements is relationships can be made with other elements to ultimately capture a directed graph of notebook components. we use the for and form properties extensively because form elements cannot nest inside form elements. this deconstructed form approach is flexible for the situation that we have have forms in outputs.
further the document.forms object provides a new way to access and execute cells. previously cells were referenced relative to dom nodes and bespoke events update the UI. now it is possible to access forms directly creating a novel referencing for notebooks cells independent of their notebook container.
by default, the cell number is shown as a label for the entire cell.
the cell number is the ordinal number in the sequence of cells. users will NOT change this value manually therefore it is NOT a form element. the best semantics for a the cell number are either an anchor tag or a label.
the need for cell number begins with their role as critical landmarks in the discussion of notebook content. the original notebook representations only provided implicit visual navigation for cell number. assistive technology users should be exposed to the cell number, and when we make they number audible we'll need to provide an explicit cell number. further, the cell number helps avoid duplicate aria labels that would fail audits.
by default, the cell type component is hidden, but the cell type is visually apparent and audibly announced.
the cell type is an enumerated choice defined by the notebook format schema. jupyter notebooks have markdown, code, and raw cells.
a form component that allows users to select one option out of many is the best choice for the cell type. select are a good choice for this component.
by default, cell source visible and audible for code cells.
the cell source is a multineline string which means that the textarea element is a natural form element to choose.
markdown cells do NOT show the cell source rather they present an html rendering of the input. this input is non-interactive content that is part of the narrative.
by default, cell metadata is hidden and inaudible by default.
cell metadata is held in a dialog.
the cell metadata allows vendor to encode data about computational or rendering into the cell. there are properties like execution start and end that may be encoded.
lines of code is common qualitative form. the visual gestalt allows viewers to navigate based on the shape of the code. these features are not propagated audibly, but should be.
by default, cell outputs are shown for code cells containing more than one or more outputs and the number of outputs is always verbally announced.
the cell outputs are ripe for development and testing of assistive experiences. outputs permit ANY hypermedia. our nbconvert-a11y implementation should try to provide as much accessibility, semantics, and context as possible.
by default, cell execution counts are shown for executed code cells
TODO