- From: Loretta Guarino Reid <lguarino@adobe.com>
- Date: Fri, 11 Mar 2005 17:50:47 -0800
- To: w3c-wai-gl@w3.org
I am summarizing the issues related to Guideline 4.2, which are listed at
http://trace.wisc.edu/bugzilla_wcag/issuereports/technology-supports-access_issues.php
Because we will be addressing the topic of Baselines at our meeting next
week, this message just contains the summary of issues related to
Baselines. I will send a separate message with other Guideline 4.2 issues.
I have divided the issues into several sections:
- Concerns about our baseline assumptions (842, 1073, 1133, 1221, 1334,
1335, 1336)
- What about requirements beyond the baseline (463, 712, 855, 1419)
- What about alternate representations (972, 1060)
<Current Wording of guideline>
Guideline 4.2 Ensure that user interfaces are accessible or provide an
accessible alternative(s)
Level 1 Success Criteria for Guideline 4.2
1. At least one user agent supporting the content conforms to at least the
default set of conformance requirements of the User Agent Accessibility
Guidelines (UAAG) 1.0 at Level A plus the sets of requirements (a) through
(i) (below) that apply. If required plug-ins are not accessible, an
alternative solution is provided that conforms to WCAG 2.0. If inaccessible
plug-ins are available, then a method for obtaining an accessible plug-in
is provided from the content. [V]
2. Any programmatic user interface components of the content conform to at
least the default set of conformance requirements of the UAAG 1.0 at Level
A plus the sets of requirements (a) through (i) (below) that apply. If the
custom user interfaces cannot be made accessible, an alternative solution
is provided that meets WCAG 2.0 (including this provision) to the level
claimed. [V]
Requirements (a) through (i)
a. If the application renders visual text, it should conform to the
VisualText checkpoints.
b. If the application renders images, it should conform to the Image
checkpoints.
c. If the application renders animations, it should conform to the
Animation checkpoints.
d. If the application renders video, it should conform to the Video
checkpoints.
e. If the application renders audio, it should conform to the Audio
checkpoints.
f. If the application performs its own event handling, it should conform
to the Events checkpoints.
g. If the application implements a selection mechanism, it should
conform to the Selection checkpoints.
h. The application should support keyboard access per UAAG 1.0
checkpoints 1.1 and 6.7.
i. If the application implements voice or pointer input, it should
conform to the Input Modality checkpoints.
Level 2 Success Criteria for Guideline 4.2
1. Accessibility conventions of the markup or programming language (API's
or specific markup) are used. [I]
Level 3 Success Criteria for Guideline 4.2
1. The Web resource includes a list of the technologies user agents must
support in order for its content to work as intended. The list is
documented in metadata if such metadata is supported by the format,
otherwise it is documented in a policy statement associated with the
content. [V]
2. Users who do not have one or more of these technologies can still access
and use the resource, though the experience may be degraded. [V]
Note:
When selecting required technologies, 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.
3. Technologies and features on the required list are open standards or
have a public specification. [V]
<Baseline Assumption Issues>
Concerns about scripting, javascript, dynamic content.
Can we assume UAAG?
Fallback requirement should have higher priority.
************************************************************
Issue 842: 4.2.3.2 should be level 1 or 2.
(11) 4.2.3.2 [pasted below] should be level 1 or 2 instead of level 3.
Users who do not have one or more of these technologies can still access
and use
the resource, though the experience may be degraded. [V]
Note:
When selecting required technologies, 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.
***********************************************************************
Issue 1073: Baseline support / conformance / fallbacks
Robert Fentress posed a question about requirements for client-side script
[1] -
is the requirement from WCAG 1.0 to provide a text alternative for scripts [2]
still a requirement in WCAG 2.0? WCAG 1.0 Checkpoint 6.3 says "Ensure that
pages
are usable when scripts, applets, or other programmatic objects are turned off
or not supported." This means it is not enough that a page uses scripts in an
accessible manner; it only conforms to the guidelines if it is equally
accessible when scripts are not supported.
The reason for this requirement in WCAG 1.0 was that assistive technologies
tend
to need time to catch up to mainstream technologies, and at the time WCAG 1.0
was written many technologies did not support scripts. Today, most though not
all assistive technologies do support scripts. In light of that, numerous
people
have voiced concern that if this continues to be a requirement in WCAG 2.0,
many
types of Web page will not be able to conform to the guidelines even though
they
are generally accessible. This issue goes beyond client-side scripting and
applies to all forms of non-text content. But the decision to drop the
requirement is not straightforward because of the importance of universal
technology support. It is further complicated by the fact that some non-text
technologies that provide accessibility features support those features only on
one platform or in one user agent.
There has been discussion of this topic by a group of people [3], proposals
from
Jason White [4], [5], and discussion of this issue in the 16 September 2004
teleconference [6]. Numerous other decisions rest on the direction taken on
this
issue.
[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0140.html
[2] http://www.w3.org/TR/WCAG10/#tech-scripts
[3] http://www.w3.org/2004/08/30-wai-wcag-irc
[4] http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0521.html
[5] http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0518.html
[6] http://www.w3.org/2004/09/16-wai-wcag-irc
Issue 1133: Use static, rather than dynamic, content for critical
parts of the Web site
WGAG 2.0 Principle 4: Content must be robust enough to work with current
and future technologies.
Level 1 Success Criteria for Guideline 4.2: Ensure that user interfaces are
accessible or provide an accessible alternative(s).
In an ideal world, if a required plug-in, e.g. Flash, is not fully accessible,
then an alternative solution will be provided that conforms to WCAG 2.0.
However, this is not an ideal world, and many Web pages are still not
accessible
to all users. Web pages should, therefore, be designed so that dynamic elements
can, if necessary be ignored, and critical parts of the Web site are not
missed.
Related to this recommendation is that images with embedded content and/or
navigation should also be avoided. Therefore, it is essential that, for
example,
a site map is represented as a text page, that is, an image should never be
used as a navigation aid. However, more work may be needed on textual site
maps which may be lengthy to access with a screen reader.
This guidance needs to be made more explicit in Guideline 4.2, as well as in
the following technology-supports-access issues (with the final words in
italics
added by the WWAAC project):
'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 cannot access or to automatically filter
to the top sites that would be most usable or at least whose critical elements
use static, accessible content.'
Rationale
Browsers (such as that developed by the WWAAC project) can identify a Web
site as having some inaccessible elements, e.g. Flash or JavaScript.
However, the WWAAC browser evaluations have noted some conflicting
requirements in that dynamic images are often more interesting but less
accessible for some users. In an ideal world, of course, all browsers should
support Flash, and technologies are improving so that this may not be an
issue for much longer (See that Macromedia Flashplayer is now considered
'totally accessible' at www.macromedia.com/macromedia/accessibility).
However, dynamic content still creates many problems for people with
communication and cognitive impairments. Fast changing objects (e.g. news
tickers) may be distracting and confusing for people with low reading skills,
and impossible to be accessed by screen reading tools. Floating objects on
top of other text may hide screen-reader cursors beyond it. Invisible text
(text
in the same colour as its background) and hidden texts (collapsible menus)
may still be found by a screen reader or difficult to access by switch users.
Other guidance drawn from WCAG does emphasise these points. For
example, in their "See it Right" Guidelines for Accessible Web Design, the
Royal National Institute for the Blind, state: 'Do not rely on JavaScript for
essential page functions.' This advice to use static, rather than dynamic
content for critical parts of the Web makes the guidance more explicit to Web
developers, so that if they choose to use such technologies, at least the
critical elements of the Web site will be accessible to all users, who may
still
be free to enjoy other interactive and dynamic, but inessential, elements
of the
page.
It is also suggested that a standard mechanism be employed to tell the user
that there is a more accessible version of the Web site, but what that
mechanism should be still needs to be decided. (See Section 6.1 for
comments and suggestions).
DRC/City University writes:
In addition, the Guidelines should place special emphasis, in the
form of elevated prioritisation, on the following matters already
covered:
the need to ensure that pages work when scripts and
applets are not supported
http://www.drc-gb.org/publicationsandreports/2.pdf
--------------------------------------------------------------------------------
**************************************************************************
Issue 1221: lack of support for Javascript in W3C technologies
1. The plugin for JavaScript is the browser and the technology it interacts
with includes the DOM, CSS, and HTML. To our knowledge, these technologies do
not possible for the content provider to do things like JavaScript menus and
other more complex UI objects in a way that meets many of the guidelines and
Success Criteria in WCAG 2.0 and the UAAG. These guidelines shouldn't preclude
the use of JavaScript but, due to the lack of support in various W3C defined
technologies [1], they do. This appears to be an issue the W3C [versus private
vendor] needs to drive. What is the WCAG's thinking on how to deal with this
issue?
Being able to use JavaScript and also meet WCAG's guidelines are important
requirements for many content providers, especially in the web applications
space. Shouldn't the release of these guidelines be delayed until an
achievable path that enables content providers has been agreed upon and is in
the works?
Notes:
[1] http://www.w3.org/WAI/PF/Group/roadmap/
*****************************************************************************
Issue 1334: Principle 4: what is meant by "current technologies"?
What is meant here by current technologies? I hope that we are including
technologies that are still in use at least from 5 years ago.
*************************************************************
Issue 1335: scripting should require alternative representation
The answer to the question below is going to depend on what you call
"current technology". You already have my vote and my answer to the
question below will follow it.
"Are functional alternatives required for content
that contains scripting?"
*dp* yes.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2005Jan/0001.html
Soren Hansson says:
It is still very important that pages are usable when scripts, applets, or
other programmatic objects are turned off or not supported. It is also very
important to help those, who make this information, with simple solutions to
do the information accessible. If this is not possible the solution is to
provide equivalent information on an alternative accessible page. But this
solution is not a good solution since it is a special solution and not a
universal design solution.
*********************************************************************
Issue 1336: User agents: remove all "until" clauses and assume
conforming UA?
This also depends on what you establish as "current technologies". I still
see a lot of situations where my user agent cannot do something in the
until clause although admittedly, I'm using netscape 4.77 or something
besides IE in some of those situations, but around the world, there are a
lot of these. I would offer instead though that instead of saying until,
just state the criteria and provide info about it. We may never have an
until and if you remove the until, those looking for standards will feel
that the ground is less shaky.
<Requirements beyond the baseline>
Is there any benefit to listing required technologies?
How should requirements be expressed?
*********************************************************************
Issue 463: why list "required" technologies?
On 4.2: 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?
http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/0130.html
Migrating issues related to 4.3 (declare-technology) to 4.2
(technology-supports-access) based on a proposal to combine them at
http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/0142.html that
was accepted in the Feb. 12, 2004 telecon.
*******************************************************************
Issue 712: what constitutes sufficiently documenting required techs?
68. Guideline 4.3, Double-A 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. Users who do not have one or
more of these technologies can still access and use the resource, though
the experience may be degraded."
68.a. [HIGH PRIORITY] 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.
http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/0130.html
Migrating issues related to 4.3 (declare-technology) to 4.2
(technology-supports-access) based on a proposal to combine them at
http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/0142.html that
was accepted in the Feb. 12, 2004 telecon.
************************************************************
Issue 855: clarification on ".. can still access the resource"
(25) 4.2.3.2: ". can still access the resource": not clear whether it is
the same page or could be an alternative page.
********************************************************************
Issue 1419: what is a degraded but usuable experience?
Point 2: Would it be useful to explain what a degraded but still usable
experience is?
<Alternate Representations>
Do we permit these?
***************************************************************
Issue 972: Don't encourage separate sites
Guideline 4.2, Example 2... Why encourage duality? Separate but equal?
Not likely.
*********************************************************************
Issue 1060: Do we require or permit alternative accessible pages?
WCAG 1.0 Checkpoint 11.4 [1] says:
"If, after best efforts, you cannot create an accessible page, provide a
link to
an alternative page that uses W3C technologies, is accessible, has equivalent
information (or functionality), and is updated as often as the inaccessible
(original) page."
WCAG 2.0 Guideline 4.2 [2] speaks more about doing things such that there is
never a need to provide an accessible alternative page. Under WCAG 2.0, is the
recommendation of WCAG 1.0 nevertheless still valid if all else fails - or is
the stance that all else should not fail and it should never be necessary or
acceptable to provide an accessible alternative page?
Whichever direction the group goes, the guidelines or General techniques should
speak to that explicitly, since this was a WCAG 1.0 requirement. There is
also a
need to provide an HTML technique if accessible alternative pages are
permitted.
[1] http://www.w3.org/TR/WCAG10/#tech-alt-pages
[2] http://www.w3.org/WAI/GL/WCAG20/#technology-supports-access
Received on Saturday, 12 March 2005 01:50:55 UTC