High Level Project Goals by Robert Slater
Technical Restrictions
Whenever possible, the user should be presented only valid, accessible options in the editor (for instance, if editing text after an h3 heading, the only heading options available would be h2, h3, and h4, and not h1, h5, or h6).
Guide for Users
When inserting certain HTML elements that in common practice present accessibility problems (but don’t need to), users should be presented with a Q&A wizard-style interface that prompts them to answer questions to help determine if that element is appropriate for what they are doing, eliciting sufficient information to properly mark up that element to ensure it is accessible.
For instance, a table wizard would ask about the header relationships to <td>s. For images, it would prompt the user to determine if the image was decorative or informative, and then prompt them to provide sufficient text (along with options on how to present that text) to accurately describe the image contents.
Accessibility Evaluation
The editor should include an as-you-type accessibility check on content that ideally:
- informs the user at the beginning if the content they are opening currently has any accessibility violations/potential issues
- in some way marks up/indicates the portion of the content that has a problem/violation within the editor
- notifies the user as soon as a new potential problem/violation is created, including links out to robust descriptions of the problem and common approaches to remediate or avoid the problem
- disables the ability to publish content (but still allows saving as a draft) that has sufficient violations/warnings (this would be implementation specific to the CMS it was being deployed in, and I would think that this should be an adjustable threshold by the CMS admins)