Action Item for Guideline 4.3

Summary of Guideline 4.3

There are 13 issues in Bugzilla for Guideline 4.3. This note
summarizes the issues, proposes possible resolutions, and raises some
questions for the Working Group.

In the public draft for which we received comments, this guideline was
numbered 4.2. All references to 4.2 in the comments refer to the current
Guideline 4.3.

Current wording:

Guideline 4.3 Technologies that are relied upon by the content are
declared and widely available. [Level 2 guideline]

Editorial Note: A definition of "widely available" should be added
here to include something which is low cost and available in
many?/most? countries/languages.


Issue 423: How does checkpoint declare-technology apply to javascript? [4]
Kynn Bartlett writes: Is this checkpoint saying use JavaScript as long
as you say you're using JavaScript? Or does it mean something else?

[Loretta] Aside from the issue of whether JavaScript is widely
available, I think this is what this means. Working Group, is this
correct?


Issue 458: Keep 4.2 [8]
Sherman Meeds writes: Item 4.2 does provide a clear definition in my
understanding.  What's more, it would establish important
organizational elements that might not be done otherwise.  I would
keep it.

Issue 425: Definition of "low cost" [6]

Kynn Bartlett writes: I'm not sure I understand the "low cost"
requirement. Can you define low cost?

[Loretta] Working group, do we really mean "free"?

Issue 371: Remove "are widely available" from 4.2 [3]
Sailesh Panchang suggests: The "are widely available" part should be
dropped. That will influence the decision to adopt a particular
technology and is not under content developer's control after the
decision is made to go with a technology.  Consequently references to
"widely available" in definitions and elsewhere may be deleted.

[Loretta] The goal of this Guideline is to influence the author's
choice of technology. Sailesh, can you elaborate?

Issue 444: ambiguity with "widely" available and use of "baseline" [7]
Cynthia, Kerstin and Wendy wrote: "widely" is ambiguous (note: there
is a glossary entry for "widely available" that is not yet
defined). The benefits talk about "baseline" but the idea has
disappeared from the success criteria.

Greg Gay writes: [7a] Need a quantitative definition for "widely
available". Widely available technologies in English is not likely the
same as widely available in Farsi, for example.  "Easily available"
might be a better choice of words.

[Loretta] "Widely available" refers to the availability of a user
agent for the technology: is there a user agent to render the content?
Does the user's preferred user agent render the content? Is there a
user agent in the language of the content?

[Loretta] Does "widely available" mean that there is one or more user
agents that *could be* used by the majority of users, or does is mean
that those user agents *are* used by the majority of users? Does "the
majority of users" mean 51% or 90% ?  And how will the author know
when the technology satisfies these requirements? What if it used to
be widely available, but changing support for user agents means it is
no longer? Would a web site that previously conformed suddenly fail?

[Loretta] Without getting into all the issues that have made "until
user agents" so difficult to satisfy, it seems hard to require more
than the existence of user agents that could be used by the majority
of users. This leaves the issue of whether this is too weak to achieve
the accessibility goal.

Proposed definition:

A technology that is widely available has one or more freely available
users agents in the language of the content that are available on
the hardware/software platforms used by the majority of users.

*******************************


Level 1 Success Criteria for Guideline 4.3

No level 1 success criteria for this guideline

Editorial Note: This guideline currently includes no level 1
criteria. The implications of this are that there is no level 1
criterion that says content must transform gracefully or that it must
be backwards compatible. However, if the guidelines with level 1
criterion are designed well, level A conformance would result in
content that transforms gracefully. This guideline might be too
subjective or difficult to test and may be deleted.

Issue 573: Depending on interpretation, either delete "declare tech" or
integrate elsewhere [10]

The U.S. Access Board writes: In the editorial note that follows this
checkpoint, it is suggested that this statement may be too subjective
and should be deleted.  We agree.  However, the note could also be
interpreted as meaning that designers should avoid using user agent
specific or proprietary techniques.  If that is an accurate
interpretation, then we believe this could be a valuable guideline and
should be restated and placed under Guideline 2.

[Loretta] I believe the second issue is addressed by Guideline 4.1,
requiring technologies to be used according to specification. As
proposed, "widely available" wouldn't prohibit the use of user agent
specific techniques if the user agent were available to the majority
of users.

*******************************************

Level 2 Success Criteria for Guideline 4.3

The Web resource includes a list of the technologies (other than
standard HTML) users must have in order for its content to work as
intended. Users who do not have one or more of these technologies can
still access and use the resource, though the experience may be
degraded.

Note:

When determining your list of technological 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.

[Loretta] What do we mean by standard HTML? Is there a specific version?

Issue 463: why list "required" technologies? [9]

Tina Holmboe writes: What is the point ? Why list a set of "required"
technologies and not, instead, ensure that the content transforms
gracefully to the user's physical reality ?

[Loretta] How does "users without the technologies can still access
and use the resource" differ from "the content transforms gracefully"?
Will our techniques documents demonstrate how to transform content?

Issue 712: What constitutes sufficiently documenting required techs?
[11]

Greg Lowney writes: I think we need to do more to explain this
guideline. What constitutes sufficiently documenting the list of
required technologies? For example, when a web page contains an OBJECT
element that specifies the technology required, is that sufficient? Or
are you saying that the page would have to list those required
technologies in human-friendly text in addition to the UA-friendly
tags?  Does the list of required technologies have to be posted with
every link to the document, so that users can view the list before
downloading the document? Would you, for example, require every Web
page that links to a site's online store have some text indicating
that the store requires SSL? Does every link to a PDF document need to
identify it as such?

[Loretta] Do we need to say that the requirements are documented in a
form that is accessible? Providing the user a way to know the
requirements for the target before activating a link seems desirable.

Issue 713: Clarification of first success criteria [12]

Greg Lowney writes: It seems to me that the two sentences in this
checkpoint are really making two separate points, and so should be
broken into two separate checkpoints. Thus: Checkpoint 1, "The Web
resource includes a list of the technologies (other than standard
HTML) users must have in order for its content to work as intended",
and Checkpoint 2, "Users who do not have one or more of the
technologies used by the document can still access and use the
resource, though the experience may be degraded." This allows a
document to get credit for degrading gracefully even though it might
not list required technologies up-front.

[Loretta] I agree. We should split these into different success criteria.

****************************************

Level 3 Success Criteria for Guideline 4.3

1. A list of technologies and features, support for which is required in
order for the content to be operable, has been determined and is
documented in metadata and / or a policy statement associated with the
content.

Issue 715: documenting with metadata (wording suggestion) [15]

Greg Lowney writes: How about giving priority to using metadata (which
is then computer-usable) by saying "documented in metadata if such
metadata is supported by the file format, otherwise is documented in a
policy statement associated with the content."
[Loretta] I would support this rewording.

2. Technologies and features on the required list are available in at
least two independently-developed implementations. (It is preferable
that the technologies used for the implementations have been supported
for at least one prior version of the software)

[Loretta] I've never understood the importance of independently
developed implementations for accessibility. Perhaps for validity of
the specification of the technology, but I think we assume the
validity of the specification in Guideline 4.1. Is this an indirect
reference to requiring that the specification being publicly available
(which would be necessary for independent implementations)? If so, can
we make that an explicit success criterion or guideline?

Issue 424: Are two supporting implementations sufficient? [5]

Kynn Bartlett writes: Are two supporting implementations sufficient? I
can think of things which are supported on Mozilla and Safari, but not
in Internet Explorer. IE is used by the majority of people with or
without disabilities.  Can you claim accessibility if 95% of your
audience is unable to access?

[Loretta] Kynn asks how this success criterion (two implementations)
equates to being widely available, and he has a point.


Issue 244: Keyboard access for devices that have no AT [2]

What if something is designed so that it ONLY works on a device for
which there is no AT. Can the content be "accessible" if it meets the
guidelines but only runs on a device for which there is no AT - and
therefore cannot be accessed?  Do we cover this somewhere? This issue
was raised by GV while working on draft for checkpoint 2.1. [2a] 2/27
telecon decided this should be addressed in conjunction with baseline
discussions. [2b]

[Loretta] Should we require a user agent that satisfies UAAG? If we
did, such content would not be accessible.


*************************************************************

Benefits of Guideline 4.3 (Informative)
Benefits of determining and documenting baseline user agent requirements:

Individuals can identify (either through site documentation or
automatically through metadata) whether or not they are likely to be
able to use a site. In conjunction with a search engine or a proxy
server, this could be used to automatically filter out sites a user
can not access or to automatically filter to the top sites that would
be most usable.

Requiring sites to document technology requirements will cause them to
evaluate assumptions about user agents and will minimize the number of
sites that are inadvertently inaccessible because they are unaware of
backward compatibility issues.

Benefits of designing for backward compatibility:

Individuals who must use alternative browsing technologies and devices
will be able to access the content.

Individuals who can not afford or otherwise do not have access to
newer technologies also benefit from backward compatibility in that
they will not need to purchase upgrades or equipment as often.

[Loretta] Guideline 4.3 no longer mentions backward compatability. Do
we need to reword this section?


******************************************

Examples of Guideline 4.3 (Informative)
Example 1: an online store.

By documenting minimum user agent requirements, the store makes it
possible for people using particular technologies to determine if they
are going to have trouble using the store or its checkout mechanism
without having to go through the entire process of shopping and
checkout only to find out that they are unable to complete their
transaction at the end. They can, therefore, shop at stores they can
be successful at.

Example 2: an Intranet site.

A large company was concerned about the ability to address individuals
at many diverse sites that have different technology bases. They have,
therefore, created two versions of their content and documented the
requirements for each, making it easy for individual sites to
determine which version would work for their technologies.

Issue 714: notes on examples for 4.3 [13]

Greg Lowney writes: You might explicitly note that the first example
shows listing required technologies, and the second shows degrading
gracefully.

**********************************************************

Notes:
[1] November 17, 2003 internal draft of WCAG2,
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20031117.html
[2] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=244
[2a]http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JanMar/0281.html
[2b] http://www.w3.org/WAI/GL/2003/02/27-minutes.html
[3] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=371
[4] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=423
[5] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=424
[6] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=425
[7] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=444
[7a] 
http://lists.w3.org/Archives/Public/public-comments-wcag20/2003Sep/0000.html
[8] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=458
[9] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=463
[10] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=573
[11] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=712
[12] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=713
[13] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=714
[14] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=715

Received on Tuesday, 27 January 2004 15:14:17 UTC