Techniques Gateway for WCAG 2.0

W3C Working Draft XXX

This version:

XXX

Latest version:

XXX

Previous version:

XXX

Editors:

Wendy Chisholm, W3C
Jason White, University of Melbourne

Checkpoint 1.1 Provide a text equivalent for all non-text content.

all non-text content is explicitly associated with a text equivalent (images have alt-text, movies have collated text transcripts, animations have descriptions, interactive scripts have a functional equivalent such as a form, audio files have a text transcript),

Further information is technology-specific. e.g. use alt on IMG in X/HTML, etc.

the text equivalent fulfills the same function and conveys the same information as the non-text content. Note: Depending on the purpose and content of the non-text content, a short label may be appropriate, or a more thorough explanation may be required,

To write a description, refer to Excerpts from NBA Tape Recording Manual

To write a short text equivalent...

• For a spacer image...
• For a bullet...
• For a horizontal rule...
• i.e. a combination of info from AERT - Checkpoint 1.1 and WCAG 1.0 Core Techniques - Text Equivalents.
• Illustrate the examples from the checkpoint (logos, photos, submit buttons, etc.)
• "interactive scripts have a functional equivalent..." can be described in core and developed further in scripting specific techniques. However, this concept in general needs to be explored further.

where it is not possible to describe the non-text content in words or for text to provide the same function as the non-text content, a label identifying the content is provided.

Not technology specific. Put info and examples here. e.g. Mona Lisa or Beethoven's 5th. Label them as such rather than trying to describe.

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

all significant visual cues in scenes, actions and events are described. If there are not sufficient breaks in dialogue to provide an audio description for all visual cues and you are unable to freeze the action frequently to insert description, describe as much as possible or give abbreviated descriptions or descriptions later or earlier when there is time,

Not technology-specific. Put info and examples here.

all significant dialogue and sounds are captioned.

Not technology-specific. Put info and exmaples here. Refer to Audio Information and Visual Motion and Information from the Core Techniques for WCAG 1.0.

descriptions and captions are synchronized with the events they represent to within a tolerance of X. Should this criterion be deleted? Should we say instead "to within a reasonable tolerance"?

Technology specific. e.g. refer to Accessibility Features of SMIL

if the Web content is a real-time broadcast, it is possible to provide real-time commentary (as with a sporting event) and real-time captioning. If this creates an undue burden, the presentation is available after-the-fact with captions and audio descriptions.Is this correct? Can we express it better?

Requires development of both core techniques and technology-specific.

Checkpoint 1.3 Use markup or a data model to provide the logical structure of content.

the hierarchical structure of the content is unambiguously represented in the markup or data model,

The non-technology aspect of this success criterion is related to types of content. A portal site will have a different logical structure than a long document.

Since the structure must be represented in the markup, there are lots of technology-specifics to cover.

important non-hierarchical relationships, such as cross-references, or the correspondence between header and data cells in a table, are represented unambiguously in the markup or data model.

The non-technology aspect of this success criterion is related to types of content. A portal site will have a different logical structure than a long document.

Since the structure must be represented in the markup, there are lots of technology-specifics to cover.

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

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.

Technology specific. e.g. refer to the Language section in the latest HTML Techniques for WCAG 2.0 draft (eeeks. no targets! pls search for "language" until a new draft is published...apologies...).

Checkpoint 1.5 Separate content and structure from presentation.

sufficient markup or a sufficient data model is provided to ensure that a logical, linear reading order can be derived from the content,

The non-technology aspect of this success criterion is related to types of content. A portal site will have a different logical structure than a long document.

Since the structure must be represented in the markup, there are lots of technology-specifics to cover.

the markup or data model representing the structure of the content is logically separated from the presentation that is either by using separate data structures or a style sheet to control presentation.

Since the structure must be represented in the markup, there are lots of technology-specifics to cover.

Types of models rather than types of content as with 1.3? PDF vs CSS will separate structure from presentation differently.

Checkpoint 2.1 Provide multiple site navigation mechanisms.

one or more navigation mechanisms are provided that cover all or selected portions of the content comprising a Web site, Delete "all or selected portions"? Delete "one or more" and substitute "two or more" to bring success criteria into line with checkpoint?

Core techniques: provide overview. related to 1.3 and 1.5.

Tech-specifics: examples. site map, search, index, etc. Particulary related to server-side techniques.

the site navigation mechanisms are clearly distinguished from the main content to make them easy to locate.

Checkpoints 1.3 and 1.5 "enforce" consistency through structure and markup. If these are followed, then this criteria should be met as a side-effect.

If content types are developed in relation to checkpoints 1.3 and 1.5, will it reduce the need for this checkpoint?

Checkpoint 2.2 Provide consistent and predictable responses to user actions.

similar layout for user interface components is used throughout your site,

Discussion with examples will go here. Perhaps provide some technology-specific examples.

similar user interface components are labelled with similar terminology,

Discussion with examples will go here. Perhaps provide some technology-specific examples.

controls that look the same are designed to act the same,

Discussion with examples will go here. Perhaps provide some technology-specific examples.

operating system, language, or application conventions likely to be familiar to the user have been followed,

Need technology-specific exmaples with some overview info in Core Techniques.

unusual user interface features or behaviors that are likely to confuse the first-time user are documented.

Discussion with examples will go here. Perhaps provide some technology-specific examples.

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

a method is provided for the user to deactivate processes or features that cause extreme changes in context. The method: is easily identified on the primary page of a multi-document site, once selected, applies to further interactions on the site.

The success criteria for checkpoint 2.3 are an either/or. Therefore, they will likely be handled a bit differently than the rest of the success criteria, right?

Provide core exmaple and technology specifics. e.g.

• script examples
• in HTML: if a has target="new" then you must...

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.

The success criteria for checkpoint 2.3 are an either/or. Therefore, they will likely be handled a bit differently than the rest of the success criteria, right?

Provide core exmaple and technology specifics. e.g.

• script examples
• in HTML: if a has target="new" then you must...

Checkpoint 2.4 Either give users control over how long they can interact with content that requires a timed response or give them as much time as possible.

the user is allowed to deactivate automatic updating or

technology-specifics: form or client-side scripting

the user is warned before time expires and allowed to extend the time available to them or

technology-specifics: server-side

the user is allowed to set how often the content is updated (in seconds) or

technology-specifics: server-side/form

the user is given as much time as possible.

show previous examples w/out time limit?

Checkpoint 2.5 Use device-independent event handlers.

generic event handlers are used instead of event handlers that require a specific input device,

Technology specifics needed.

more than one device-specific event handler is used if generic event handlers are not available.

Technology specifics needed.

Checkpoint 2.6 Avoid causing the screen to flicker.

content does not flicker between 4 and 49 Hz.

Technology-specific research needed.

Checkpoint 2.7 Handle input errors, such as misspellings.

checks for misspelled words are applied and correct spellings are suggested when text entry is required,

Technology-specific examples.

where possible, the user is allowed to select from a list of options rather than generate text.

Technology-specific examples.

Checkpoint 3.1 Use consistent presentation.

items with similar function have a similar presentation.

Reliance on 1.3 and 1.5. Primary checks in core. Examples in tech-specifics.

Checkpoint 3.2 Emphasize structure through presentation, positioning, and labels.

a unique style is created for each structural element Note: styles include differences in size, appearance, position and may be subtly distinct.

technology-specific examples are needed.

where appropriate, differences in structure are labeled,

technology-specific examples are needed.

where possible, these differences are highlighted in styles for a variety of output media including large screen, small screen, speech, braille, tty, etc.

Specifically address the different media types? Within tech-specifics address media types?

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

the audience is anticipated to have a wider range of educational levels and background knowledge than expected, This criterion seems meaningless and also condescending, in assuming that the content developer's initial judgments regarding the background of the intended audience are faulty. What should we say instead? What factors is it legitimate to take into account in defining the "intended audience" of a text?

Not technology-specific.

Need to help people understand the circumstances for when to employ these.

Look at the work by Lisa, Graham, and Charles and the November F2F.

language is used that your intended audience ought to be familiar with,

Not technology-specific.

Need to help people understand the circumstances for when to employ these.

Look at the work by Lisa, Graham, and Charles and the November F2F.

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.

This is the same as checkpoint 3.5. Perhaps instead of having a separate checkpoint leave this success criteria? Either way, it requries technology-specific examples and info.

Checkpoint 3.4 Supplement text with non-text content.

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

a definition or link to a definition is provided for phrases, words, acronyms, and abbreviations specific to a particular community. Should this criterion be restricted to the first occurrence of an acronym or abbreviation, as in WCAG 1.0?

Technology-specific examples.

Information about deciding when to provide in core techniques.

a summary is provided for relationships among cells for tables with nested headings, relationships among cells that span multiple columns or rows, or other 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. A summary may also describe how the table fits into the context of the current document.

Technology-specific examples.

Information about deciding when to provide in core techniques.

Checkpoint 4.1 Choose technologies that support the use of these guidelines.

permits equivalents to be associated with or synchronized with auditory, graphical, and multimedia content,

In core techniques - info about how to choose.

Reference XAG - this be the "technology-specific" piece?

allows the logical structure of the content to be defined independently of presentation,

In core techniques - info about how to choose.

Reference XAG - this be the "technology-specific" piece?

supports device-independence,

In core techniques - info about how to choose.

Reference XAG - this be the "technology-specific" piece?

is documented in published specifications and can be implemented by user agent and assistive technology developers,

In core techniques - info about how to choose.

Reference XAG - this be the "technology-specific" piece?

is supported by user agents and assistive technologies.

In core techniques - info about how to choose.

Reference XAG - this be the "technology-specific" piece?

Checkpoint 4.2 Use technologies according to specification.

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?

Technology-specific examples, refer to specifications.

for api's: programming standards for the language are followed and accessibility api's are used when available.

Technology-specific examples, refer to specifications.

Checkpoint 4.3 Design user interfaces compatible with assistive technology.

accessibility conventions of the markup or programming language (API's or specific markup) are used,

Technology-specifics. e.g. Accessibility features of SMIL, SVG.

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,

Some explantation in Core, then "tech-specifics" is UAAG and UAAG techs.

device-independent access to functionality is provided,

Device indie event handlers. Redundant with that?

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?

Provide info in Core Techniques.

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