Additional note to our discussion on "user agent" in the Key Terms sectio

At last week's meeting, we tentatively approved the following additional
note for the discussion of "user agent" [1]. The approval was subject to
review by the mailing list. Here is the note:

In the INTENT sections of Understanding WCAG 2.0, the term 'user agent' is
often used. When applying these intent sections to documents, the WCAG2ICT
definition of 'user agent' applies as defined here for WCAG2ICT. This
definition expressly doesn't apply to the presenting of content within
software, because software presents its own content. Therefore when
applying the INTENT section of a success criterion to software, the term
"user agent" in the INTENT should be read as "software”, recognizing that
"software" also includes assistive technologies and access features in
operating systems and other platforms.

For reference and thanks to Gregg, I have included, at the end of this
note, a summary of all uses of "user agent" in the document. Please review
the above note, keeping in mind the instances where  "user agent" is used
in the document. If there are no objections raised by Friday's meeting, we
will consider this approved.

[1] http://www.w3.org/TR/2012/WD-wcag2ict-20121213/#keyterms_ua

Andi

*==================*
*HERE ARE THE PLACES  "USER AGENT" **IS USED IN WCAG2ICT *

*YOU CAN SEE THAT MANY OF THE RATIONALE'S LEAVE SOFTWARE OUT IF USER AGENT
ONLY APPLIES TO DOCUMENTS*


*----------------------*
*
*
1. Introduction

While WCAG 2.0 was designed to be technology-neutral, it assumes the
presence of a “*user agent*” such as a browser, media player, or assistive
technology as a means to access Web content. Therefore, the application of
WCAG 2.0 to documents and software in non-Web contexts required some
interpretation in order to determine how the intent of each WCAG 2.0
success criterion could be met in these different contexts of use. The bulk
of the Task Force's work therefore involved evaluating how each WCAG 2.0
success criterion would apply in the context of non-Web ICT, if it were
applied to non-Web ICT.


2. Key Terms

There are several terms used throughout WCAG 2.0 that need to be
interpreted differently when applied to non-Web ICT. These include:
“content” and “*user agent*”. Further, the term “Web page” in WCAG 2.0 is
replaced with newly defined terms “document” and “software”, and both "set
of web pages" and "multiple web pages" are replaced with the newly defined
term "set of documents".

Further information on usage of these terms follows.

*----------------------*
*
*
3. Closed Functionality

As noted in the Introduction, WCAG 2.0  assumes the presence of a “*user
agen*t” such as a browser, media player, or assistive technology as a means
to access Web content. Furthermore, many of the success criteria in WCAG
2.0 assume Web content will be accessed by ICT that has assistive
technologies connected to it, where the assistive technologies present the
Web content to the people with disabilities in accessible form. ICT
products with "closed functionality" do not allow the use of some assistive
technologies for all of their functions. In many cases such ICT products
also lack a “*user agent*” or their equivalent.  As a result, ICT following
these success criteria by themselves will not make information accessible
on ICT with closed functionality. Something else needs to be provided or be
required in order to make the information addressed in these success
criteria accessible.  It is outside the task force work
statement<http://www.w3.org/WAI/GL/WCAG2ICT-WorkStatement> to
say what the additional measures are,  but we can point out which success
criteria depend on assistive technologies - and therefore would not work by
themselves in products with closed functionality.

*----------------------*
*
*
*
*

Intent from Understanding Success Criterion 1.1.1 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/text-equiv-all#text-equiv-all-intent-head>
:

The intent of this Success Criterion is to make information conveyed by
non-text content accessible through the use of a text alternative. Text
alternatives are a primary way for making information accessible because
they can be rendered through any sensory modality (for example, visual,
auditory or tactile) to match the needs of the user. Providing text
alternatives allows the information to be rendered in a variety of ways by
a variety of *user agent*s. For example, a person who cannot see a picture
can have the text alternative read aloud using synthesized speech. A person
who cannot hear an audio file can have the text alternative displayed so
that he or she can read it. In the future, text alternatives will also
allow information to be more easily translated into sign language or into a
simpler form of the same language.

*
*
*
*
*----------------------------*
Specific Benefits of Success Criterion 1.3.1

   -

   This Success Criterion helps people with different disabilities by
   allowing *user agent*s to adapt content according to the needs of
   individual users.

*
*
*----------------------*

Intent from Understanding Success Criterion 1.3.2 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/content-structure-separation-sequence#content-structure-separation-sequence-intent-head>
:

The intent of this Success Criterion is to enable a *user agent* to provide
an alternative presentation of content while preserving the reading order
needed to understand the meaning. It is important that it be possible to
programmatically determine at least one sequence of the content that makes
sense. Content that does not meet this Success Criterion may confuse or
disorient users when assistive technology reads the content in the wrong
order, or when alternate style sheets or other formatting changes are
applied.

*----------------------*
*
*

Intent from Understanding Success Criterion 1.4.4 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/visual-audio-contrast-scale#visual-audio-contrast-scale-intent-head>
:

The intent of this Success Criterion is to ensure that visually rendered
text, including text-based controls (text characters that have been
displayed so that they can be seen [vs. text characters that are still in
data form such as ASCII]) can be scaled successfully so that it can be read
directly by people with mild visual disabilities, without requiring the use
of assistive technology such as a screen magnifier. Users may benefit from
scaling all content on the Web page, but text is most critical.

The scaling of content is primarily a *user agent* responsibility. *user
agents* that satisfy UAAG 1.0 Checkpoint
4.1<http://www.w3.org/TR/WAI-USERAGENT/guidelines.html#tech-configure-text-scale>
allow
users to configure text scale. The author's responsibility is to create Web
content that does not prevent the *user agent* from scaling the content
effectively. Authors may satisfy this Success Criterion by verifying that
content does not interfere with *user agent* support for resizing text,
including text-based controls, or by providing direct support for resizing
text or changing the layout. An example of direct support might be via
server-side script that can be used to assign different style sheets.

The author cannot rely on the *user agent* to satisfy this Success
Criterion for HTML content if users do not have access to a *user agent* with
zoom support. For example, if they work in an environment that requires
them to use IE 6 or Firefox.

If the author is using a technology whose *user agent*s do not provide zoom
support, the author is responsible to provide this type of functionality
directly or to provide content that works with the type of functionality
provided by the *user agent*. If the *user agent* doesn't provide zoom
functionality but does let the the user change the text size, the author is
responsible for ensuring that the content remains usable when the text is
resized.

*
*
*
*
*----------------------*
*
*

Intent from Understanding Success Criterion 1.4.5 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/visual-audio-contrast-text-presentation#visual-audio-contrast-text-presentation-intent-head>
:

The intent of this Success Criterion is to encourage authors, who are using
technologies which are capable of achieving their desired default visual
presentation, to enable people who require a particular visual presentation
of text to be able to adjust the text presentation as needed. This includes
people who require the text in a particular font size, foreground and
background color, font family, line spacing or alignment.

If an author can use text to achieve the same visual effect, he or she
should present the information as text rather than using an image. If for
any reason, the author cannot format the text to get the same effect, the
effect won't be reliably presented on the commonly available *user agent*s,
or using a technology to meet this criterion would interfere with meeting
other criterion such as 1.4.4, then an image of text can be used. This
includes instances where a particular presentation of text is essential to
the information being conveyed, such as type samples, logotypes, branding,
etc. Images of text may also be used in order to use a particular font that
is either not widely deployed or which the author doesn't have the right to
redistribute, or to ensure that the text would be anti-aliased on all *user
agent*.

*----------------------*
*
*

Intent from Understanding Success Criterion 2.2.1 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/time-limits-required-behaviors#time-limits-required-behaviors-intent-head>
:

*Notes regarding server time limits*

   -

   Timed server redirects can be found below under Common Failures.
   -

   Non-timed server redirects (e.g., 3xx response codes) are not applicable
   because there is no time limit: they work instantly.
   -

   This Success Criterion applies only to time limits that are set by the
   content itself. For example, if a time limit is included in order to
   address security concerns, it would be considered to have been set by the
   content because it is designed to be part of the presentation and
   interaction experience for that content. Time limits set externally to
   content, such as by the *user agent* or by factors intrinsic to the
   Internet are not under the author's control and not subject to WCAG
   conformance requirements. Time limits set by Web servers should be under
   the author's/organization's control and are covered. (Success Criteria
   2.2.3<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-no-exceptions>
   , 2.2.4<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-postponed>
    and 2.2.5<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-server-timeout>
may
   also apply.)


*----------------------*
*
*

>From Success Criterion
2.2.2<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-pause>
:

For moving, blinking<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#blinksdef>,
scrolling, or auto-updating information, all of the following are true:

   -

   *Moving, blinking, scrolling: *For any moving, blinking or scrolling
   information that (1) starts automatically, (2) lasts more than five
   seconds, and (3) is presented in parallel with other content, there is a
   mechanism for the user to
pause<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#pauseddef>,
   stop, or hide it unless the movement, blinking, or scrolling is part of an
   activity where it is
essential<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#essentialdef>;
   and
   -

   *Auto-updating: *For any auto-updating information that (1) starts
   automatically and (2) is presented in parallel with other content, there is
   a mechanism for the user to pause, stop, or hide it or to control the
   frequency of the update unless the auto-updating is part of an activity
   where it is essential.

*Note 1: *For requirements related to flickering or flashing content, refer
to *Guideline 2.3 <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#seizure>*.
*Note 2: *Since any content that does not meet this success criterion can
interfere with a user's ability to use the whole page, all content on the
Web page (whether it is used to meet other success criteria or not) must
meet this success criterion. See *Conformance Requirement 5:
Non-Interference <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#cc5>*.
*Note 3: *Content that is updated periodically by software or that is
streamed to the *user agent* is not required to preserve or present
information that is generated or received between the initiation of the
pause and resuming presentation, as this may not be technically possible,
and in many situations could be misleading to do so.
*Note 4: *An animation that occurs as part of a preload phase or similar
situation can be considered essential if interaction cannot occur during
that phase for all users and if not indicating progress could confuse users
or cause them to think that content was frozen or broken.

*----------------------*

Intent from Understanding Success Criterion 2.4.1 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/navigation-mechanisms-skip#navigation-mechanisms-skip-intent-head>
:

The intent of this Success Criterion is to allow people who navigate
sequentially through content more direct access to the primary content of
the Web page. Web pages and applications often have content that appears on
other pages or screens. Examples of repeated blocks of content include but
are not limited to navigation links, heading graphics, and advertising
frames. Small repeated sections such as individual words, phrases or single
links are not considered blocks for the purposes of this provision.

This is in contrast to a sighted user's ability to ignore the repeated
material either by focusing on the center of the screen (where main content
usually appears) or a mouse user's ability to select a link with a single
mouse click rather than encountering every link or form control that comes
before the item they want.

It is not the intent of this Success Criterion to require authors to
provide methods that are redundant to functionality provided by the *user
agent*. Most web browsers provide keyboard shortcuts to move the user focus
to the top of the page, so if a set of navigation links is provided at the
bottom of a web page providing a "skip" link may be unnecessary.

*
*
*----------------------*

Intent from Understanding Success Criterion 2.4.2 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/navigation-mechanisms-title#navigation-mechanisms-title-intent-head>
:

The intent of this Success Criterion is to help users find content and
orient themselves within it by ensuring that each Web page has a
descriptive title. Titles identify the current location without requiring
users to read or interpret page content. When titles appear in site maps or
lists of search results, users can more quickly identify the content they
need. *User agents* make the title of the page easily available to the user
for identifying the page. For instance, a *user agent* may display the page
title in the window title bar or as the name of the tab containing the page.

*
*
*----------------------*
*
*

Intent from Understanding Guideline 3.1 in Understanding WCAG
2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/meaning#meaning-intent>
:

The intent of this guideline is to allow text content to be read by users
and by assistive technology, and to ensure that information necessary for
understanding it is available.

People with disabilities experience text in many different ways. For some
the experience is visual; for some it is auditory; for some it is tactile;
for still others it is both visual and auditory. Some users experience
great difficulty in recognizing written words yet understand extremely
complex and sophisticated documents when the text is read aloud, or when
key processes and ideas are illustrated visually or interpreted as sign
language. For some users, it is difficult to infer the meaning of a word or
phrase from context, especially when the word or phrase is used in an
unusual way or has been given a specialized meaning; for these users the
ability to read and understand may depend on the availability of specific
definitions or the expanded forms of acronyms or abbreviations. *User agent*s,
including speech-enabled as well as graphical applications, may be unable
to present text correctly unless the language and direction of the text are
identified; while these may be minor problems for most users, they can be
enormous barriers for users with disabilities. In cases where meaning
cannot be determined without pronunciation information (for example,
certain Japanese Kanji characters), pronunciation information must be
available as well

*----------------------*

Intent from Understanding Success Criterion 3.1.1 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/meaning-doc-lang-id#meaning-doc-lang-id-intent-head>
:

The intent of this Success Criterion is to ensure that content developers
provide information in the Web page that *user agent*s need to present text
and other linguistic content correctly. Both assistive technologies and
conventional *user agent*s can render text more accurately when the
language of the Web page is identified. Screen readers can load the correct
pronunciation rules. Visual browsers can display characters and scripts
correctly. Media players can show captions correctly. As a result, users
with disabilities will be better able to understand the content.

*
*
*----------------------*
*
*

Intent from Understanding Success Criterion 3.1.2 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/meaning-other-lang-id#meaning-other-lang-id-intent-head>
:

The intent of this Success Criterion is to ensure that *user agent*s can
correctly present content written in multiple languages. This makes it
possible for *user* *agent*s and assistive technologies to present content
according to the presentation and pronunciation rules for that language.
This applies to graphical browsers as well as screen readers, braille
displays, and other voice browsers.

Both assistive technologies and conventional *user* *agent*s can render
text more accurately if the language of each passage of text is identified.
Screen readers can use the pronunciation rules of the language of the text.
Visual browsers can display characters and scripts in appropriate ways.
This is especially important when switching between languages that read
from left to right and languages that read from right to left, or when text
is rendered in a language that uses a different alphabet. Users with
disabilities who know all the languages used in the Web page will be better
able to understand the content when each passage is rendered appropriately.

When no other language has been specified for a phrase or passage of text,
its human language is the default human language of the Web page (see
Success Criterion 3.1.1). So the human language of all content in single
language documents can be programmatically determined.

Individual words or phrases in one language can become part of another
language. For example, "rendezvous" is a French word that has been adopted
in English, appears in English dictionaries, and is properly pronounced by
English screen readers. Hence a passage of English text may contain the
word "rendezvous" without specifying that its human language is French and
still satisfy this Success Criterion. Frequently, when the human language
of text appears to be changing for a single word, that word has become part
of the language of the surrounding text. Because this is so common in some
languages, single words should be considered part of the language of the
surrounding text unless it is clear that a change in language was intended.
If there is doubt whether a change in language is intended, consider
whether the word would be pronounced the same (except for accent or
intonation) in the language of the immediately surrounding text.

Most professions require frequent use of technical terms which may
originate from a foreign language. Such terms are usually not translated to
all languages. The universal nature of technical terms also facilitate
communication between professionals.

Some common examples of technical terms include: Homo sapiens, Alpha
Centauri, hertz, and habeas corpus.

Identifying changes in language is important for a number of reasons:

   -

   It allows braille translation software to follow changes in language,
   e.g., substitute control codes for accented characters, and insert control
   codes necessary to prevent erroneous creation of Grade 2 braille
   contractions.
   -

   Speech synthesizers that support multiple languages will be able to
   speak the text in the appropriate accent with proper pronunciation. If
   changes are not marked, the synthesizer will try its best to speak the
   words in the default language it works in. Thus, the French word for car,
   "voiture" would be pronounced "voyture" by a speech synthesizer that uses
   English as its default language.
   -

   Marking changes in language can benefit future developments in
   technology, for example users who are unable to translate between languages
   themselves will be able to use machines to translate unfamiliar languages.
   -

   Marking changes in language can also assist *user* *agent*s in providing
   definitions using a dictionary.

*----------------------*
*
*

Intent from Understanding Success Criterion 3.2.3 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/consistent-behavior-consistent-locations#consistent-behavior-consistent-locations-intent-head>
:

The intent of this Success Criterion is to encourage the use of consistent
presentation and layout for users who interact with repeated content within
a set of Web pages and need to locate specific information or functionality
more than once. Individuals with low vision who use screen magnification to
display a small portion of the screen at a time often use visual cues and
page boundaries to quickly locate repeated content. Presenting repeated
content in the same order is also important for visual users who use
spatial memory or visual cues within the design to locate repeated content.

It is important to note that the use of the phrase "same order" in this
section is not meant to imply that subnavigation menus cannot be used or
that blocks of secondary navigation or page structure cannot be used.
Instead, this Success Criterion is intended to assist users who interact
with repeated content across Web pages to be able to predict the location
of the content they are looking for and find it more quickly when they
encounter it again.

Users may initiate a change in the order by using adaptive* user agents* or
by setting preferences so that the information is presented in a way that
is most useful to them.

*----------------------*

Intent from Understanding Success Criterion 3.3.1 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/minimize-error-identified#minimize-error-identified-intent-head>
:

<SNIP>

The identification and description of an error can be combined with
programmatic information that* user agents *or assistive technologies can
use to identify an error and provide error information to the user. For
example, certain technologies can specify that the user's input must not
fall outside a specific range, or that a form field is required. Currently,
few technologies support this kind of programmatic information, but the
Success Criterion does not require, nor prevent it.

*
*
*----------------------*

Intent from Understanding Success Criterion 3.3.3 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/minimize-error-suggestions#minimize-error-suggestions-intent-head>
:

The intent of this Success Criterion is to ensure that users receive
appropriate suggestions for correction of an input error if it is
possible. The WCAG 2.0 definition of "input error" says that it is
"information provided by the user that is not accepted" by the system. Some
examples of information that is not accepted include information that is
required but omitted by the user and information that is provided by the
user but that falls outside the required data format or allowed values.

Success Criterion 3.3.1 provides for notification of errors. However,
persons with cognitive limitations may find it difficult to understand how
to correct the errors. People with visual disabilities may not be able to
figure out exactly how to correct the error. In the case of an unsuccessful
form submission, users may abandon the form because they may be unsure of
how to correct the error even though they are aware that it has occurred.

The content author may provide the description of the error, or the* user
agent *may provide the description of the error based on
technology-specific, programmatically determined information.


*----------------------*
Principle 4: Robust

Content must be robust enough that it can be interpreted reliably by a wide
variety of *user agents*, including assistive technologies.

Guideline 4.1: Compatible

>From Guideline 4.1<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#ensure-compat>
:

Maximize compatibility with current and future *user agents*, including
assistive technologies.

Intent from Understanding Guideline 4.1 in Understanding WCAG
2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/ensure-compat#ensure-compat-intent>
:

The purpose of this guideline is to support compatibility with current and
future *user agents*, *especially* assistive technologies (AT). This is
done both by 1) ensuring that authors do not do things that would break AT
(e.g., poorly formed markup) or circumvent AT (e.g., by using
unconventional markup or code) and 2) exposing information in the content
in standard ways that assistive technologies can recognize and interact
with. Since technologies change quickly, and AT developers have much
trouble keeping up with rapidly changing technologies, it is important that
content follow conventions and be compatible with APIs so that AT can more
easily work with new technologies as they evolve.

*----------------------*

Intent from Understanding Success Criterion 4.1.1 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/ensure-compat-parses#ensure-compat-parses-intent-head>
:

The intent of this Success Criterion is to ensure that *user agents*,
including assistive technologies, can accurately interpret and parse
content. If the content cannot be parsed into a data structure, then
different *user agents* may present it differently or be completely unable
to parse it. Some *user agents* use "repair techniques" to render poorly
coded content.

Since repair techniques vary among *user agents*, authors cannot assume
that content will be accurately parsed into a data structure or that it
will be rendered correctly by specialized *user agents*, including
assistive technologies, unless the content is created according to the
rules defined in the formal grammar for that technology. In markup
languages, errors in element and attribute syntax and failure to provide
properly nested start/end tags lead to errors that prevent *user agents* from
parsing the content reliably. Therefore, the Success Criterion requires
that the content can be parsed using only the rules of the formal grammar.
*Note 1: *The concept of "well formed" is close to what is required here.
However, exact parsing requirements vary amongst markup languages, and most
non XML-based languages do not explicitly define requirements for well
formedness. Therefore, it was necessary to be more explicit in the success
criterion in order to be generally applicable to markup languages. Because
the term "well formed" is only defined in XML, and (because end tags are
sometimes optional) valid HTML does not require well formed code, the term
is not used in this success criterion.
*Note 2: *With the exception of one success criterion (* Understanding
Success Criterion 1.4.4 Resize
text<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/visual-audio-contrast-scale.html>
*, which specifically mentions that the effect specified by the success
criterion must be achieved without relying on an assistive technology)
authors can meet the success criteria with content that assumes use of an
assistive technology (or access features in use agents) by the user, where
such assistive technologies (or access features in *user agents*) exist and
are available to the user.

*
*
Additional guidance when applying Success Criterion 4.1.1 to Non-Web
Documents and Software:

This applies directly as written, and as described in INTENT from
Understanding WCAG 2.0 (above) replacing “In content implemented using
markup languages” with “For non-Web documents or software that use markup
languages, in such a way that the markup is separately exposed and
available to assistive technology or to a user-selectable *user agent*”.

With these substitutions, it would read:

4.1.1 Parsing:  For non-Web documents or software that use markup
languages, in such a way that the markup is separately exposed and
available to assistive technology or to a user-selectable user agent, elements
have complete start and end tags, elements are nested according to their
specifications, elements do not contain duplicate attributes, and any IDs
are unique, except where the specifications allow these features. (Level A)

*Note: *Start and end tags that are missing a critical character in their
formation, such as a closing angle bracket or a mismatched attribute value
quotation mark are not complete.

*Note: *Markup is not always available to assistive technology or to user
selectable *user agents* such as browsers.  Software sometimes uses markup
languages internally for persistence of the software user interface, in
ways where it is never available to assistive technology (either directly
or through a document object model (DOM)), or to a *user agent* (such as a
browser). In such cases, conformance to this provision would have no impact
on accessibility as it can for Web Content where it is exposed.

Examples of markup that is separately exposed and available to assistive
technology and to *user agents* include: documents encoded in HTML, ODF,
and OOXML. In these examples, the markup can be parsed entirely in two
ways: (a) by assistive technologies which may directly open the document,
(b) by assistive technologies using DOM APIs of *user agents* for these
document formats.

Examples of markup used internally for persistence of the software user
interface that are never exposed to assistive technology include: XUL,
GladeXML, and FXML. In these examples assistive technology only interacts
with the user interface of generated software.

*Note: *See also the discussion on Closed
Functionality<http://www.w3.org/WAI/GL/wcag2ict/#closed_functionality>
in
the Introduction.
*----------------------*

>From Success Criterion
4.1.2<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#ensure-compat-rsv>
:

For all user interface
components<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#user-interface-componentdef>
(including
but not limited to: form elements, links and components generated by
scripts), the name <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#namedef>
 and role <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#roledef> can
be programmatically
determined<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#programmaticallydetermineddef>;
states, properties, and values that can be set by the user can be
programmatically
set <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#programmaticallysetdef>;
and notification of changes to these items is available to *user agents*,
including assistive
technologies<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#atdef>
.
*Note: *This success criterion is primarily for Web authors who develop or
script their own user interface components. For example, standard HTML
controls already meet this success criterion when used according to
specification.

Intent from Understanding Success Criterion 4.1.2 in Understanding
WCAG 2.0<http://www.w3.org/WAI/GL/2012/WD-UNDERSTANDING-WCAG20-20121213/ensure-compat-rsv#ensure-compat-rsv-intent-head>
:

The intent of this Success Criterion is to ensure that Assistive
Technologies (AT) can gather information about, activate(or set) and keep
up to date on the status of user interface controls in the content.

When standard controls from accessible technologies are used, this process
is straightforward. If the user interface elements are used according to
specification the conditions of this provision will be met. (See examples
of Success Criterion 4.1.2 below)

If custom controls are created, however, or interface elements are
programmed (in code or script) to have a different role and/or function
than usual, then additional measures need to be taken to ensure that the
controls provide important information to assistive technologies and allow
themselves to be controlled by assistive technologies.

A particularly important state of a user interface control is whether or
not it has focus. The focus state of a control can be programmatically
determined, and notifications about change of focus are sent to *user agents
* and assistive technology. Other examples of user interface control state
are whether or not a checkbox or radio button has been selected, or whether
or not a collapsible tree or list node is expanded or collapsed.
*Note: *Success Criterion 4.1.2 requires a programmatically determinable
name for all user interface components. Names may be visible or invisible.
Occasionally, the name must be visible, in which case it is identified as a
label. Refer to the definition of name and label in the glossary for more
information.

*----------------------*
content (Web content)
*SEE  #1 above *

>From the WCAG 2.0 definition for content (Web
content)<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#contentdef>
:

information and sensory experience to be communicated to the user by means
of a *user agent* including code or markup that defines the content's
structure <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#structuredef>,
presentation<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#presentationdef>,
and interactions

*----------------------*

contrast ratio

>From the WCAG 2.0 definition for contrast
ratio<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#contrast-ratiodef>
:

*Note 6: *WCAG conformance should be evaluated for color pairs specified in
the content that an author would expect to appear adjacent in typical
presentation. Authors need not consider unusual presentations, such as
color changes made by the *user agent,* except where caused by authors'
code.

*----------------------*
user agent

>From the WCAG 2.0 definition for user
agent<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#useragentdef>
:

any software that retrieves and presents Web content for users
*Example: *Web browsers, media players, plug-ins, and other programs —
including assistive
technologies<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#atdef> —
that help in retrieving, rendering, and interacting with Web content.

*----------------------*
*
*