WCAG 2 Restructuring Proposal [DRAFT] - RELEASE 2


NOTES ON THIS DRAFT --

This draft represents a proposed redraft of the central core of WCAG 2.0.

This is NOT the WCAG guidelines but a proposal to the group for its consideration. If it looks good we can use this as a base to move forward and edit it into what we want. If not we can return to the current draft and work off of it.

The proposal attempts to address as many of the open issues and to incorporate the consensus items or decisions reached as well as to address a number of different issues uncovered in the process.

It reorganizes the checkpoints into 5 guidelines to provide a clearer organization and to address some key open issues or quandaries.

The result is

It is also interesting to note that:

while

As we have author-artisits that 'write' with media and involve themselves in all aspects, we may find that authors want to assert themselves more in all four.

The last category is items that would impact all four of the first guidelines so have not quite figured out how to handle them except to have them in separate category.

The fifth group is also less worked on than 1 through 4 because the group is still wrestling with it.


Table of Contents


Guideline 1 - Perceivable.
Ensure that all content can be presented in form(s) that can be perceived by any user - except those aspects of the content that cannot be expressed in words.

Essential to any access to Web content is the ability of the user to be able to perceive the content.

Checkpoint 1.1 Provide a text equivalent for all aspects of non-text content that can be expressed in words.

Success Criteria

You will have successfully provided a text equivalent for all aspects of non-text content that can be expressed in words if:

  1. Non-text content that can be expressed in words has a text-equivalent explicitly associated with it that fulfills the same function as the non-text content (i.e. to present information and/or to label an action).
  2. Non-text content that can not be expressed in words has a descriptive label provided as it's text-equivalent

Definitions (informative)

A text equivalent

Non-text content includes but is not limited to images, text in raster images, image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ASCII art, scripts that present content, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.

Benefits (informative)

Individuals who are blind, have low vision, have cognitive disabilities or have trouble reading text for any reason can have the text read aloud to them. Individuals who are deaf, are hard of hearing or who are having trouble understanding the audio information for any reason can read the text presentation or have it translated and presented as sign language. Individuals who are blind or deaf-blind can have the information presented in Braille.

Examples (informative)

Checkpoint 1.2 Provide synchronized media equivalents for time-dependent presentations.

Success criteria

You will have successfully provided synchronized media equivalents for time-dependent presentations if:

  1. an audio description of all significant visual information in scenes, actions and events is provided to the extent possible given the constraints posed by the existing audio track and constraints on freezing the image to insert additional auditory description.
  2. all significant dialogue and sounds are captioned.
  3. descriptions and captions are synchronized with the events they represent.
  4. If web content is a real-time broadcast, and synchronized media equivalents are available, they are provide

[Issue: this set does not yet require provision of media-equivalents for live broadcast. The reason is that it is not clear how to handle problems with webcams, etc. If someone points a webcam out the window, or at the coffeee pot -- do they need to hire someone to provide a running commentarey? We should discuss and decide to require or not. UNDER WHAT CIRCUMSTANCES WOULD WE REQUIRE EQUIVALENTS == AND WHEN WOULD WE NOT - AND STILL ALLOW COMPLIANCE WITH THIS CHECKPOINT]

Definitions (informative)

A time-dependent presentation is a presentation which

Media equivalents present essential audio information visually (captions) and essential video information auditorily (audio descriptions).

Benefits (informative)

People who are deaf or have a hearing loss can access the auditory information through the captions. People who are blind or have low vision as well as those with cognitive disabilities who have difficulty interpreting visually what is happening benefit from the audio descriptions of the visual information.

People without disabilities also benefit from the media equivalents. People in noisy environments or with muted sound often use captions. Captions are used by many to develop language and reading skills. Audio descriptions also provide visual information for people who are temporarily looking away from the video presentation such as when following an instructional video and looking at their hands. Captions and text descriptions can also be used to index and search media files.

Note:Time-dependant presentations that require dual, simultaneous attention with a single sense can present significant barriers to some users. Depending on the nature of the of presentation, it may be possible to avoid scenarios where, for example, a deaf user would be required to watch an action on the screen and read the captions at the same time. However, this would not be achievable for live broadcasts (ex. a football game). Where possible, provide content so that it does not require dual, simultaneous attention or so that it gives the user the ability to effectively control/pause different media signals.

Examples (informative)

Checkpoint 1.3 [1.5] Make all content and structure available independently of presentation.

Success criteria

You will have successfully made content and structure available independent of presentation if

  1. Any information that is conveyed through presentation formatting is also provided in either text or structure.
  2. Any structure in the content is exposed through markup or data model.
  3. The following can be derived programmatically (e.g. through markup or data model) from the content without interpreting presentation.
    • at least one logical, linear reading order
    • any hierarchical elements, such as headings, paragraphs and lists
    • any relationships between elements, such as cross-references and associations between labels and controls
    • any emphasis

[Issue: will people know how to determine if a logical reading order can be derived - or how to do it to test 3a]

Definitions (informative)

Content is the information or meaning and function.

Presentation is the rendering of the content and structure in a form that can be sensed by the user.

Structure includes both hierarchical structure of the content and nonhierarchical relationships such as cross-references, or the correspondence between header and data cells in a table.

Benefits (informative)

Content and presentation can be separated because the rules that control how content is displayed can be separated from the markup that denotes the structure of the content. For example, content that separates content and structure from presentation makes it possible for a user to change the presentation to meet his/her needs, by configuring his UAAG-compliant user agent.

Typically, style rules are stored separately from the content to which they apply, in resources known as style sheets. To facilitate the presentation of Web content by a range of devices (high and low-resolution displays, printers, speech devices, etc.), it is advisable to associate a variety of style sheets with your Web content.

Examples (informative)


Guideline 2 - Operable.
Ensure that the interface elements in the content are operable by any user
.

Also essential to access is the ability to be able to operate the interface elements on the page.

Checkpoint 2.1 [2.5] Provide keyboard access to all functionality of the content.

Success criteria

You will have successfully keyboard access to all functionality of the content if:

  1. all functions of the content can be operated from a standard keyboard without requiring simultaneous activation of multiple character keys.

Benefits (informative)

Individuals who are blind (and cannot use pointing devices) can have access to the functionality of the product.

Individuals with severe physical disabilities can use speech input (coupled with a keyboard emulator which injects the spoken text or commands as if they were typed on the keyboard) to enter data or control the device.

Examples (informative)

Example 1: a submit button. A submit button may be activated by clicking on it with the mouse, tabbing to it with the keyboard then pressing the Enter key, selecting it through voice input, or pressing it with a stylus.

Checkpoint 2.2 [2.4] Allow users to control any time limits on their interaction or responses unless control is not possible due to nature of real-time events or competition.

Success criteria

You will have successfully either given users control over how long they can interact with content that requires a timed response or given them as much time as possible if:

Definitions (informative)

Real-time events

Competitive activity: an activity where timing is an essential part of the design of the activity. Removal of the time element would change the performance of the participants. None time based activities might be preferred and may be required for some venues but this would require a complete redesign of the activity or test and would therefore fall under guidelines

Benefits (informative)

People with reading disabilities, cognitive disabilities, and learning disabilities often need longer than most people to read and comprehend written text. People with physical disabilities might not be able to move quickly or accurately enough to interact with moving objects.

Content that is updated often might not be processed and read in time or in the proper order by an assistive technology or voice browser.

Examples (informative)

Examples of content that requires a response within a timed interval:

Examples of application of checkpoint

Checkpoint 2.3 [2.6] Avoid causing the screen to flicker.

Success criteria

You will have successfully avoided screen flicker if:

  1. animation or other content does not visibly or purposely flicker between 3 and 49 Hz.
  2. if flicker is unavoidable - user is warned of the flicker before they go to the page , and a version of the content without flicker is provided.

Benefits (informative)

People with photosensitive epilepsy can have seizures triggered by flickering or flashing in the 3 to 49 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second as well as quick changes from dark to light (like strobe lights).

People with distractibility problems may not be able to focus on page content with flicker occurring in same visual field.

This one has always generated complaints because authors don't know how to measure the flicker rates. Can we suggest how they would know whether their flicker falls in this range?

1 - Would be great to have a tool or a website that could test for flicker rate.
2 - what is flicker. "If I cant tell its flickering -- does it pass?"
3 - what if it is caused by slow computer. How will I know?


Guideline 3 - Orientation/Navigation. Facilitate content orientation and navigation

Key to effective use of web content is the ability to keep one's orientation within a document and/or website, and the ability to efficiently move about in the site or document.

Checkpoint 3.1 [1.3A] Provide structure within content.

Success criteria

  1. Author(s) or others have reviewed content and added as much structure as they felt was possible and appropriate.
  2. The following minimum structure elements are present
    1. xxxxxx
    2. yyyyy

NOTE: Because the form and origin (including letters, art, historical documents, etc.) of content varies so greatly, specific criteria for the amount of structure to be put into content can not be standardized. Objective success criteria cannot therefore be formulated that would apply across media and documents.

Advisory recommendations are however listed below to provide guidance in adding key structural elements into the content. See also the techniques documents for the different technologies.

Advisory Recommendations to Consider (informative)

  1. Break up text into logical paragraphs.
  2. Provide hierarchical sections and titles, particularly for longer documents
  3. Provide a table of contents or other navigation map
  4. Reveal important nonhierarchical relationships, such as cross-references, or the correspondence between header and data cells in a table, so that they are represented unambiguously in the markup or data model.
  5. Provide a search function within the document if it spans multiple documents.
  6. Provide a mechanism for obtaining a copy of the document in a single file.
  7. Divide very large works into sections and or chapters with logical labels.

[Issue: Are there others that should included in list]

Note: some forms of communication such as personal letters and poetry do not lend themselves to hierarchical division or headers within a document.

Definitions (informative)

The structure of content represents changes in context. For example,

  1. A book is divided into chapters, paragraphs, lists, etc. Chapter titles help the reader anticipate the meaning of the following paragraphs. Lists clearly indicate separate, yet related ideas. An italicized phrase emphasizes an important idea. All of these divisions help the reader anticipate changes in context.
  2. A bicycle is divided into wheels and a frame. Further, a wheel is divided into a tire and a rim. In an image of the bicycle, one group of circles and lines becomes "wheel" while another group becomes "frame."

Issue: does the definition distinguish adequately between presentation (e.g., italics) and the corresponding structure (e.g., emphasis), or is the present wording likely to confuse readers?

Issue: Provide an adequate definition of "data model" to cover such phenomena as PDF logical structure, XML information sets that are not represented in markup, etc.

Benefits (informative)

When the logical structure is provided in markup or a data model,

Examples (informative)

Checkpoint 3.2 [3.2] Emphasize structure through presentation(s), positioning, and labels.

Success criteria

  1. Author(s) or others have reviewed content and emphasized structure as they felt was possible and appropriate.
  2. The following minimum structural emphases are present.
    1. xxxxxx
    2. yyyyy

NOTE: Because the form and origin (including letters, art, historical documents, etc) of content varies so greatly, specific criteria for the amount of structure to be put into content can not be standardized. Objective success criteria cannot therefore be formulated that would apply across media and documents.

Advisory recommendations are however listed below to provide guidance in emphasizing the structure of content. See also the techniques documents for the different technologies.

Advisory Recommendations to Consider (informative)

  1. For visual presentations, use font variations, styles, size and white space to emphasize structure.
  2. Use color and graphics to emphasize structure.
  3. For auditory presentations, use different voice characteristics and/sounds for major headings, sections and other structural elements.
  4. If content is targeted for a specific user group and the presentation of the structured content is not salient enough to meet the needs of your audience, use additional graphics, colors, sounds, and other aspects of presentation to emphasize the structure.

NOTE: Ensure that the structural and semantic distinctions are provided in the markup. Refer to checkpoint 2.2.

Benefits (informative)

Presentation that emphasizes structure:

Examples (informative)

Checkpoint 3.3 [2.1] Provide multiple methods to explore site contents.

Issue: We are currently discussing the scope of this checkpoint and what is required. Does providing multiple site navigation mechanisms increase accessibility or are we trying to get at something else? Refer to the benefits for the issue we are trying to tackle. How do we set limits for when to apply this checkpoint? If a site consists of only 5 pages, a site map might look exactly like the home page.

Success criteria

You will have successfully provided multiple methods for exploring site contents if:

  1. more than one method (the home "page" with links is one method) is provided for sites that are more than 2 layers (a home "page" and one layer of "pages" linked off of it).
  2. the site exploration method(s) are easy to locate.

Definitions (informative)

Site navigation mechanism - a mechanism for easily orienting and moving about within the site. Site navigation mechanisms include but are not limited to:

Benefits (informative)

Providing different navigation mechanisms can provide a better match between different peoples skill, background knowledge, visual vs. text orientation, and the type of information they are seeking at the moment.

People with cognitive disabilities may find it easier to ask for what they want than to deduce its location from categorical choices.

People with low vision or blindness may find techniques that fetch everything that relates to a topic of interest to be easier than techniques that require them to scan larger lists for the items.

NOTE: Large documents should also consider including multiple mechanisms for navigation such as a hyperlinked table of contents, internal hyperlinks, an ability to collapse by headers, etc.

Checkpoint 3.4 [3.1] Use Consistent But Not Necessarily Identical Presentation

Success criteria

  1. Author(s) or others have reviewed content and used consistent presentation where they felt it was possible and appropriate.
  2. The following minimum structural emphases are present.
    1. xxxxxx
    2. yyyyy

NOTE: Consistency can make content easier to navigate and to find controls or features on a page. Too much consistency can be disorienting and make it harder to tell where one is or where information was located.

Advisory recommendations are however listed below to provide guidance consistent presentation. See also the techniques documents for the different technologies.

Advisory Recommendations to Consider (informative)

  1. Place navigation bars in a consistent location whenever possible
  2. Similar layout for user interface components is used for sections or whole site,
  3. Similar user interface components are labeled with similar terminology,
  4. Consistent use of headers
  5. Use templates for consistent presentation for sections or whole site
  6. Pages with similar function have similar appearance and layout

Definitions (informative)

Presentation includes, but is not limited to:

Benefits (informative)

Consistency helps users predict where to find information on each page of your site. It also helps users determine the relationships between items in the content. This understanding of the structure helps users navigate, orient themselves.

Note that differences in presentation help users determine that they have succeeded in loading a new page. Having pages which are similar but clearly different helps with this and also helps users distinguish between content.

Checkpoint 3.5 [2.2] Provide consistent and predictable responses to user actions.

Success criteria

  1. Author(s) or others have reviewed content for consistent and predictable responses to user actions.
  2. Where inconsistent or unpredictable responses are essential to the function of the content (e.g. mystery games, adventure games, tests, etc.) the user is warned in advance of encountering them.
  3. The following minimum criteria are met.
    1. xxxxxx
    2. yyyyy

NOTE: Consistency can make content easier to navigate and to find controls or features on a page. Too much consistency can be disorienting and make it harder to tell where one is or where information was located.

Advisory recommendations are however listed below to provide guidance consistent presentation. See also the techniques documents for the different technologies.

Advisory Recommendations to Consider (informative)

  1. controls that look or sound the same are designed to act the same,
  2. conventions likely to be familiar to the user have been followed,
  3. unusual user interface features or behaviors that are likely to confuse the first-time user are described to the user before they encounter them.

Benefits (informative)

Providing responses to user actions is important feedback for the user. This lets them know that your site is working properly and encourages them to keep interacting. When the user receives an unexpected response, they might think something is wrong or broken. Some people might get so confused they will not be able to use your site. Common responses to user actions:

These actions should be predictable and sensible to the end user. Make interactions consistent, both throughout the site and with commonly used interaction metaphors used throughout the Web.

Examples (informative)

Some of these examples are very brief. Should they be expanded and clarified with further details?

Checkpoint 3.6 [2.3] Either give users control of mechanisms that cause extreme changes in context or warn them of pending changes.

Success criteria

You will have successfully either given users control of mechanisms that cause extreme changes in context or warn them of pending changes if:

  1. Either
    • an easy to find setting, that persists for the site visit, is provided for the user to deactivate processes or features that cause extreme changes in context
    • or extreme changes in context are identified before they occur so the user can determine if they wish to proceed or so they can be prepared for the change

    .

Definitions (informative)

Mechanisms that cause extreme changes in context include:

Issue: do these have counterparts in non-visual interfaces?

Benefits (informative)

If the user is unable to track visual cues that make extreme changes obvious, then they will not realize the context has changed. People who are blind, some people with low vision, some people with dyslexia and other people who have difficulty interpreting visual cues need guidance during extreme changes in context.

Examples (informative)

Checkpoint 3.7 [2.7A] Provide methods to minimize error and provide graceful recovery.

Issue: This is a new checkpoint that is being explored. It does not have full support of the working group. We know that spelling mistakes are a serious issue for people with writing disabilities and dyslexia. We have generalized this checkpoint to include all input errors but highlight spelling mistakes. Are there other input errors we should highlight? Are there other ideas we can list?

Success criteria

  1. Author(s) or others have reviewed content and incorporated error prevention and recovery methods they felt were possible and appropriate.
  2. The following minimum structural emphases are present.
    1. xxxxxx
    2. yyyyy

NOTE: Because some authors do not have control of the server side services or do not know how to program such services, and the user client may not support scripting or it may be turned off, it is not possible to require specific types of error checking and recovery.

Advisory recommendations are however listed below to provide guidance in graceful error recovery. See also the techniques documents for the different technologies.

Advisory Recommendations to Consider (informative)

Benefits (informative)

People with writing disabilities and people with dyslexia often have difficulty writing text in forms or other places that need text input. People with speech disabilities might not be recognized properly in voice input applications.

Examples (informative)


Guideline 4 - Comprehension. Make it as easy as possible to understand the content and controls.

We each gain knowledge in different ways. Some people read something and understand, others have to experience it, while others need only to see something. To help people understand the information you are presenting, consider the various ways that people learn. Keep in mind the variety of backgrounds and experiences people will bring to your site. Using language, illustrations, and concepts that they are likely to know, highlighting the differences and similarities between concepts, and providing explanations for unusual terms can all facilitate understanding. .


Checkpoint 4.1 [3.3] Write as clearly and simply as is appropriate for the content.

Success criteria

  1. Site owners have reviewed the materials on the site and have tried to have the content under their control written as clearly and simply as they feel is appropriate.
  2. The following minimum criteria have been met.
    1. xxxxxx
    2. yyyyy

NOTE: It is very difficult to determine what makes writing clear and simple for all topics. Some content is derived from other sources and is copyrighted so it cannot be altered. Some materials or topics cannot be communicated accurately in simple language. Also, since some people cannot understand the content no matter how simply it is written, it is not possible to make any content accessible to everyone. Specific objective criteria that could be applied across all types of content are therefore not possible.

Advisory recommendations are however listed below to provide guidance in this area. See also the techniques documents for the different technologies.

Advisory Recommendations to Consider (informative)

  1. Provide an outline or a summary for your document.
  2. Break up long paragraphs into shorter ones, with one idea per paragraph.
  3. Break up long sentences into shorter ones.
  4. Provide accurate unique page titles.
  5. Ensure that headings and link text are unique and that they make sense when read out of context.
  6. Provide definitions for any jargon or specialized terminology used in your document.
  7. Provide explanations of figurative, metaphorical, or idiomatic uses of language (for example, 'haven't seen you in a coons age' or 'the sight tore my heart out')."
  8. Language is used that your intended audience ought to be familiar with,
  9. When introducing new concepts or terms, they are defined or annotated in language that the audience should be familiar with or definitions or explanations are linked to that might be easier to understand.

Benefits (informative)

Authors should strive for clear and simple writing to aid all users, especially those with cognitive, learning, and/or reading disabilities. This should not discourage you from expressing complex or technical ideas. Using clear and simple language also benefits people whose first language differs from your own, including those people who communicate primarily in sign language.


Checkpoint 4.2 [3.4] Supplement text with non-text content.

Success criteria

  1. Text has been supplemented with non-text content to the extent deemed appropriate by the author.
  2. The following minimum criteria have been met.
    1. xxxxxx
    2. yyyyy

NOTE: Supplementing text with non-text (e.g. graphics, sound, smell, etc) is useful for all users. However there are no clear guidelines as it relates to disability. Specific objective criteria that could be applied across all types of content are therefore not possible.

Advisory recommendations are however listed below to provide guidance in this area. See also the techniques documents for the different technologies.

Advisory Recommendations to Consider (informative)

Definitions (informative)

Non-text content - includes images, text in raster images, image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ASCII art, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. Is this definition adequate?

Benefits (informative)

Sounds, graphics, videos and animations can help make concepts presented in a Web site easier to understand, especially for people with cognitive, reading, or learning disabilities or those who are unfamiliar with the language of the text of the site.

Note: "Designers need to be cautious in deciding when to use illustrations. Reading a picture is probably a learned activity that is easier for some than others. Some users skip the pictures; others read only the pictures. Designers must also recognize that visual conventions are not universal and that individuals develop their own mental schema and expectations in interpreting visual information.
For a detailed discussion of guidelines pertaining to illustrations, consult Tufte (1983) and MacDonald-Ross (1977)." Robert W. Bailey, Ph.D., Human Performance Engineering, 3rd edition.] pg 431.

Examples (informative)


Checkpoint 4.3 [3.5] Annotate complex, abbreviated, or unfamiliar information with summaries and definitions.

Success criteria

  1. Authors or site owners have reviewed the content provided annotations for information where they feel is appropriate.
  2. The following minimum criteria have been met.
    1. Acronyms and Abbreviations are defined the first time they appear in text.
    2. yyyyy

NOTE: Advisory recommendations are listed below to provide guidance in this area. See also the techniques documents for the different technologies.

Advisory Recommendations to Consider (informative)

  1. Provide a definition (with the first occurance) of phrases, words, acronyms, and abbreviations specific to a particular community.

  2. Provide a summary for relationships that may not be obvious from analyzing the structure of the table but that may be apparent in a visual rendering of the table.

Definitions (informative)

Content is considered complex if the relationships between pieces of information are not easy to figure out. If the presentation of the information is intended to highlight trends or relationships between concepts, these should be explicitly stated in the summary.

Examples of complex information:

Content might be unfamiliar if you are using terms specific to a particular community. For example, many of the terms used in this document are specific to the disability community.

Benefits (informative)

Summarizing information that is difficult to understand helps people who do not read well. Providing a summary of the visual cues that show relationships between complex information helps people who do not use visual cues or who have difficulty using visual cues. For example, people who are blind do not use any visual cues, while people with dyslexia or people with low vision might have difficulty interpreting visual cues.

Defining key terms and specialized language will help people who are not familiar with the topic. Providing the expansion of abbreviations and acronyms not only helps people who are not familiar with the abbreviation or acronym but can clarify which meaning of an abbreviation or acronym is appropriate to use. For example, the acronym "ADA" stands for both the American with Disabilities Act as well as the American Dental Association.

Checkpoint 4.4 [1.4] Identify the primary natural language of text and text equivalents and all changes in natural language.

Success criteria

You will have successfully identified the primary natural language of text and text equivalents and all changes in natural language if:

  1. changes in language are identified at the level the changes occur.
    Note: If there is never a change throughout a whole site, then identification can occur at the highest level (usually at a page or document level). If changes occur at the word or phrase level, then changes should be identified at the word or phrase level using the markup appropriate to the markup language in use.

Definitions (informative)

Natural languages are those used by humans to communicate, including spoken, written, and signed languages.

Benefits (informative)

Oftentimes, phrases from various languages are interspersed in writing. When these phrases are identified, a speech synthesizer can voice text with the appropriate accent and pronunciation. When they are not identified, the speech synthesizer will use the default accent and pronunciation dictionary which can make the phrase intelligible. Identifying changes in language will also allow a tool to ask for automatic translations of that content. When editing content, authoring tools can switch between appropriate spelling dictionaries.

Examples (informative)



Guideline 5 - Interoperability. Design content to maximize compatibility with different presentation, operation and interpretation technologies.

Checkpoint 5.1 [4.2] Use technologies according to specification.

Success criteria

You will have successfully used technologies according to specification if:

  1. for markup: the markup has passed validity tests of the language (whether it be conforming to a schema, DTD, or other tests described in the specification), structural elements and attributes are used as defined in the specification, accessibility features are used, and deprecated features are avoided. Issue: should there be a qualification or exception for backward-compatibility? If so, under what circumstances should it apply? Alternatively, if an implementor decides to use invalid markup for backward-compatibility reasons, shouldn't they be "honest" and indicate that they haven't satisfied this checkpoint?
  2. for API's: programming standards for the language are followed and accessibility API's are used when available.

Are protocols relevant to this checkpoint? If so, why, and should we require that they be used according to specification? Obviously there are interoperability advantages in doing so, but is this pertinent to accessibility?

Benefits (informative)

When languages, API's, and protocols are used according to specification, tools that use the results will be able to do so as intended and expected.

Examples (informative)

Checkpoint 5.2 [4.4] Ensure that content remains usable when technologies that modify default user agent processing or behavior are turned off or not supported.

Issue: define "default" for purposes of this checkpoint. If "default" were taken to mean "a user agent's default rendering", then this would defeat the purpose of the checkpoint, because (for many user agents) the default is to apply style sheets, invoke scripts and programmatic objects, etc.

Success criteria

You will have successfully ensured that content remains usable when technologies that modify default user agent processing or behavior are turned off or not supported if:

Examples (informative)

Benefits (informative)

In determining the extent to which older technologies should be supported, keep in mind that


Checkpoint 5.3 [4.1A] Choose technologies that support interoperability and compatibility.

Success criteria

You will have successfully chosen a technology that supports the use of these guidelines if the technology:

  1. permits equivalents to be associated with or synchronized with auditory, graphical, and multimedia content,
  2. allows the logical structure of the content to be defined independently of presentation,
  3. supports device-independence,
  4. is documented in published specifications and can be implemented by user agent and assistive technology developers,
  5. is supported by user agents and assistive technologies.

Issue: are these success criteria complete? If not, what should be added or changed? Should we provide a link to the XML guidelines?

Issue: should the checkpoint be reworked (or an additional checkpoint inserted here) to require that content be designed, as far as possible, so that it is amenable to automated accessibility testing?

Benefits (informative)

Markup languages, multimedia formats, software interface standards, etc., vary in their support of accessibility. When choosing which technologies to use, consider how easy it is to apply these guidelines.

Checkpoint 5.4 [4.3A] Ensure that user interfaces are accessible or provide an accessible alternative.

Success criteria

You will have successfully designed user interfaces compatible with assistive technology if:

  1. accessibility conventions of the markup or programming language (API's or specific markup) are used,
  2. any applications with custom interfaces conform to at least Level A of UAAG 1.0. If the application cannot be made accessible, an alternative accessible solution is provided,
  3. device-independent access to functionality is provided,
  4. the interface has been tested using a variety of assistive technologies and preferably real people with disabilities who use assistive technologies to determine that assistive technologies can access all information on the page or hidden within the page.
    Issue: it would be possible to comply with the checkpoint without carrying out tests (either with users or with assistive technologies). Conversely, it is possible to conduct tests, but still fail to meet the checkpoint (with respect to assistive technologies that were not tested, for example). Should this success criterion be deleted?

Benefits (informative)

Asking someone to access your Web site without their assistive technology is like asking someone to access a building without their wheelchair. Assistive technologies are an essential part of the lives of many people with disabilities.

FROM CYNTHIA SHELLY -- COMMENTS ON LAST ITEMS THESE WERE NOT INCORPORATED INTO THE DOC ABOVE BECAUSE WE MISSED THEM

POSTED HERE FOR DISCUSSION

I took a stab at re-writing several of the checkpoints under guideline

4. This is really rough, but you'll get the idea. The stuff between the <notes></notes> tags are explanations that would not be in the draft.

Checkpoint 4.1 [5.3 ABOVE] Choose technologies that are designed to support accessibility

<notes> This is what we say when we're explaining the checkpoint. Let's make it the checkpoint, so we don't have to explain it.</notes>

Success Criteria:

<notes> The big change here is that I'm putting a lot more weight on implemented technologies, and their interactions with other software in the real world. I've also added the concept of looking at available technologies based on the human/natural language of the content. The idea is that if I'm creating a French site, then it matters a lot more that it works with French screen readers than with Swedish ones. I'm not sure this is the right place for this, but it's another example of adding implementation and real-world concerns to the success criteria. </notes>

Checkpoint 4.2 [5.1 ABOVE] Use technologies according to specification

Success criteria

* passing the validity tests of the language would include conforming to a schema, DTD, or other tests described in the specification.

<notes>changes here are editorial. Made "use the accessibility features" explicit, and moved the parenthetical phase to a footnote.

</notes>

Checkpoint 4.4 [5.2 ABOVE] Design for backward compatibility <notes>

Again, this is what we say when we explain the checkpoint, so let's just say it</notes>

Success criteria:

Your site can be considered backward compatible if

- You have determined and documented your baseline browser requirements in metadata and/or a policy statement on your site.

- Your content is still usable when features above your baseline (for example, scripting and stylesheets) are turned off

Informative:

1) When determining your baseline browser requirements, consider that assistive hardware and software is often slow to adapt to technological advances, and the availability of assistive technology varies across natural languages. Verify that assistive technology compatible with the technologies you choose is available in the natural language(s) of your content.

<notes>

The concept of a baseline browser is made explicit.

The definition of that baseline is left up to the author. This will probably be controversial.

Here's the reasoning:

a) The working group has yet to come up with a workable solution for defining a baseline and having it not become obsolete. I'm not convinced that it is possible to do so.

b) The author has much better information than we do about the specific situation in which his content will be used.

This includes things like audience, available tech in a given language, and the state of technology at the time he's reading the guidelines (not the time we're writing them). We could perhaps provide a few sample baselines, like the no script/no stylesheets standard assumed by WCAG 1.0. Again, added the concept of technology available in the language of the content.

</notes>

2) In some situations, there are trade-offs between this checkpoint and checkpoints 4.1 and 4.2.

Older user agents may not be compliant to standards.

Newer technologies (or their accessibility features) may break older user agents. In these situations, you will need to make a judgment call as to which is more important for your audience, and adjust your baseline browser requirements accordingly.

<notes>

We will never get around this trade-off, so let's acknowledge it, and see what we can come up with to help the author make the right decision.

</notes>