"Upshot" summaries of first ten guidelines

  Kim Patch and I have written "upshot", or plain language summaries of the first ten guidelines that we hope can serve as models for completing the set. These can not only help readers understand the guidelines and success criteria--including people who might be loathe to read the entire document--but also help *us* make sure the success criteria actually say what we intend.

Our goals were:

    * make them *easy to read*,
    * make them as *self-explanatory* as possible, and
    * *convey the general idea of each success criterion* while leaving the legalistic details for elsewhere (e.g. the normative wording of the success criteria, applicability notes, intent paragraphs, and examples),
    * *clarify the relationships between the success criteria *for a guideline that are often difficult to figure out in the full, legalistic versions.

To achieve those goals we tried to:

    * *address the developer directly* and* use the imperative* (e.g. "Provide..." and "Let..." rather than "...is provided" and "...can..."),
    * *avoid jargon* (e.g. "W3C's Web Content Accessibility Guidelines" rather than "WCAG", "menus, buttons, dialogs, etc." rather than "user agent user interface elements"),
    * *choose words and phrases that suggest everyday speech* rather than technical documents (e.g. "make sure" instead of "ensure"),
    * *include inline examples and explanations* rather than just restating the requirements,
    * *avoid going into too much detail *(e.g. don't try to list all the conditions and exceptions, don't call out priorities except to contrast items), and
    * *break out the upshot for each success criterion* (e.g. following each sub-item summary with its corresponding SC number in parentheses).


(These aren't perfect: not all address the developer directly, and we're inconsistent about using "users" vs. "the users" and "operating system" vs. "platform", etc., but those are minor quibbles that can be cleaned up later if necessary.)

Personally, I'd like to eventually see such plain language summaries at all three levels: principles, guidelines, and success criteria; we can separately decide which levels we want to publish, and in which documents.


Based on ED-UAAG20-20100920 (http://www.w3.org/WAI/UA/2010/ED-IMPLEMENTING-UAAG20-20100920/).


    Guideline 1.1 Ensure that non-Web-based functionality is accessible.

Upshot: The browser's own menus, buttons, dialogs, etc. need to meet any accessibility standards for the operating system.


    Guideline 1.2 Ensure that Web-based functionality is accessible.

Upshot: When the browser's menus, buttons, dialogs, etc. are authored in HTML or similar standards, they need to meet W3C's Web Content Accessibility Guidelines.


    Guideline 1.3 Support accessibility features of technologies.

Upshot: Implement the accessibility features of all the technologies you're using, such as supporting the platform's multitasking capabilities and HTML's alt attribute for images, and document your implementation.


    Guideline 1.4 Render content according to specification.

Upshot: Render content according to the technology specification, including accessibility features (1.4.1), and let users choose how content types are handled, such as opening embedded images, videos, or documents in separate applications or saving them to disk (1.4.2, 1.4.3).


    Guideline 2.1 Facilitate programmatic access

Upshot: Be compatible with assistive technologies by supporting platform standards (2.1.1), including providing information about all menus, buttons, dialogs, etc. (2.1.2, 2.1.6), access to DOMs (2.1.4), and access to structural relationships and meanings, such as what text or image labels a control or serves as a heading (2.1.5). Where something can't be made accessible, provide an accessible alternative version, such as a standard window in place of a customized window (2.1.3). Make sure that that programmatic exchanges are quick and responsive (2.1.7).


    Guideline 3.1 Provide access to alternative content.

Upshot: Let users see at a glance which pieces of content have alternatives like alt text or longdesc (3.1.1) and click on an item to see its available alternatives (3.3.3); they can also choose at least one alternative like alt text to be always displayed (3.1.2), but it's recommended that they also be able to specify a cascade, like alt text if it's there, otherwise longdesc, otherwise, filename, etc.


    Guideline 3.4 Repair missing content.

Upshot: If the user chooses, provide useful alternative content when the author didn't, such as showing a filename in place of missing (3.4.1) or empty (3.4.2) alt text.


    Guideline 3.5 Provide highlighting for selection, content focus, enabled elements, visited links.

Upshot: Let users visually distinguish selected, focused, and enabled items, and recently visited links (3.5.1), with their choice of highighting options that at least include foreground and background colors, and border color and thickness (3.5.2).


    Guideline 3.6 Provide text configuration.

Upshot: Let users control text font, color, and size (3.6.1), including whether all text should be the shown the same size (3.6.2).


    Guideline 3.7 Provide volume configuration.

Upshot: Respect the user's global audio volume settings (3.7.1), but also let users adjust the volume of each audio track (3.7.2).


    Guideline 3.8 Provide synthesized speech configuration.


    Guideline 3.9 Provide style sheetsconfiguration.


    Guideline 3.10 Help user to use viewports and orient within viewports.


    Guideline 3.11 Provide an effective focus mechanism.


    Guideline 3.12 Provide alternative views.


    Guideline 3.13 Provide link information.


    Guideline 4.1 Ensure full keyboard access.


    Guideline 4.2 Provide access to event handlers.


    Guideline 4.3 Allow time-independent interaction.


    Guideline 4.4 Help users avoid flashing that could cause seizures.


    Guideline 4.5 Configure and store preference settings.


    Guideline 4.6 Provide text search.


    Guideline 4.7 Provide structured navigation.


    Guideline 4.8 Provide toolbar configuration.


    Guideline 4.9 Provide control of content that may reduce accessibility.


    Guideline 5.1 Help users avoid unnecessary messages.


    Guideline 5.2 Help users avoid and correct mistakes.


    Guideline 5.3 Document the user agent user interface including all accessibility features.


    Guideline 5.4 The user agent must behave in a predictable fashion.