Web and Software: Cognitive best practices

Proposal on supression of unneeded function

This proposal was accepted as a recommendation, not a requirement at the March 7, 2007 meeting

• Software should provide a mechanism enabling users to individualize the interface look and feel including the modification or hiding of command buttons.
  • EXAMPLE 1 A user with a cognitive disability may, when using a given application, change the interface via a “skin” to simplify the application’s look and feel.
  • EXAMPLE 2 A word processor allows users to hide menu items and tool bar buttons that they do not find useful.

Proposals from Whitney Quesenberry and Kate Walser

These proposals are for advisory guidance, not normative requirements. The language suggested here comes from two sources: a new law in Oregon and the OMB guidelines on plain language.

• Authors should follow best practices for creating content that is accessible for people with disabilities. These guidelines include:

1. Organize the content to serve the reader's needs, considering their tasks and goals.
2. Use everyday words that convey meaning clearly and directly.
3. Use the present tense and the active voice.
4. Use short, simple sentences.
5. Include useful headings.
6. Use lists and tables to simplify complex material.

Rationale: Clearly written content improves accessibility for people with several disabilities, including people with cognitive and reading disabilities, those whose primary language is American Sign Language and those reading in Braille.

• Applications should follow best practices for designing interaction paradigms that are accessible for people with disabilities including:

1. Provide a means to undo actions, such as by resetting the form to the original information
2. Provide a way to move backwards one step in a process to fix mistakes or check answers
3. Provide a way to cancel actions before submitting

Rationale: Well-designed interaction enables people to reverse and reset actions in case they have made a mistake or are unable to complete a transaction at the time. It also provides a way for people to explore an interaction without the threat of modifying their data unintentionally. This is particularly helpful for all users, especially in cases where they have triggered an action unintentionally or realize they've made a mistake after they've taken the action.

Summary of mailing list discussion

• not much support for adding these as they are not testable and open to interpretation
• suggestion to have a separate section with advisory recommendations such as these and others we have encountered
• EWG recommends including "should" provisions in line with "must" provisions - TEITAC may decide at a later date to reorganize these into a separate section.