Feature Documentation – Accessibility First

Working from OneNet Functional Requirements page. This document describes the accessibility features of each component in content authoring.

A11y First Text Editor

High: Must have feature for launch of version 1.0
Medium: Nice to have, but not required for version 1.0
Low: Feature we’d like to have eventually, but is likely high development cost to lower benefit

This uses a prioritization technique, MoSCoW method

Real Time: These checks are done without any user initiation of the check. It would be tied to event listeners (in the CKEditor API) for element insert/modification, and would either correct problems automatically or give the user an immediate warning/encouragement to modify.
Manual Check: The user must initiate this check either from the checks menu or a “check everything” option, or it will be triggered on save/update.

Automatically produce valid, semantically-correct HTML 5 code.
Allow authorized users to edit HTML directly.
Use HTML Tidy (or a similar code validator) to check/correct HTML code edited by users.

Leverage vertical menu: Where it makes sense, present drop down (like) menus.
Where it is more complex, open a modal window on selecting that feature/group (and in some cases a hybrid, where links in the menu can themselves open a modal).
When prompting users about errors, visually display the elements to make it easier to see how they are are related (see OneNet)–most likely as separate visualizations (one for headings, one for lists, etc.)
Run some (TBD–likely want this to be configurable) checks on requesting publish (not on save draft/auto-save) and prompt user to verify/remediate (possible) errors.