- From: Andi Snow-Weaver <andisnow@us.ibm.com>
- Date: Mon, 11 Jun 2007 00:18:47 -0500
- To: "Loretta Guarino Reid" <lorettaguarino@google.com>
- Cc: public-comments-WCAG20@w3.org
Loretta,
Sorry to be late in responding. I am satisfied with the response to IBM's
comments.
Andi
"Loretta Guarino
Reid"
<lorettaguarino@g To
oogle.com> Andi Snow-Weaver/Austin/IBM@IBMUS
cc
05/17/2007 06:26 public-comments-WCAG20@w3.org
PM Subject
Your comments on WCAG 2.0 Last Call
Draft of April 2006
Dear Andi Snow-Weaver ,
Thank you for your comments on the 2006 Last Call Working Draft of the
Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2006/WD-WCAG20-20060427/). We appreciate the
interest that you have taken in these guidelines.
We apologize for the delay in getting back to you. We received many
constructive comments, and sometimes addressing one issue would cause
us to revise wording covered by an earlier issue. We therefore waited
until all comments had been addressed before responding to commenters.
This message contains the comments you submitted and the resolutions
to your comments. Each comment includes a link to the archived copy of
your original comment on
http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
also include links to the relevant changes in the updated WCAG 2.0
Public Working Draft at http://www.w3.org/TR/2007/WD-WCAG20-20070517/.
PLEASE REVIEW the decisions for the following comments and reply to
us by 7 June at public-comments-WCAG20@w3.org to say whether you are
satisfied with the decision taken. Note that this list is publicly
archived.
We also welcome your comments on the rest of the updated WCAG 2.0
Public Working Draft by 29 June 2007. We have revised the guidelines
and the accompanying documents substantially. A detailed summary of
issues, revisions, and rationales for changes is at
http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please see
http://www.w3.org/WAI/ for more information about the current review.
Thank you,
Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact
On behalf of the WCAG Working Group
----------------------------------------------------------
Comment 1:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-923)
"The document states: ""The author is responsible for ensuring that
the content is delivered in such a way that software can access it.""
""Software"" is confusing here. What type of software are you referring
to?"
Proposed Change:
Change
""The author is responsible for ensuring that the content is delivered
in such a way that software can access it.""
to
""The author is responsible for ensuring that the content is delivered
in such a way that user agents and assistive technologies can access
it.""
----------------------------
Response from Working Group:
----------------------------
We have revised this sentence to read as follows:
This means that the content is delivered in such a way that user
agents, including assistive technologies, can access the information.
----------------------------------------------------------
Comment 2:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-924)
The WCAG 1.0 priority scheme is used consistently in all WAI specs but
WCAG 2.0 is defining a new priority scheme with Levels 1, 2, and 3.
Proposed Change:
Use a consistent prioritization scheme in all WAI specs
----------------------------
Response from Working Group:
----------------------------
While consistency with other specs is desirable, each spec has
individual structure for particular reasons. The WCAG 1.0 priority
scheme claims that content becomes "more accessible" as the level of
conformances get higher. Because we know that there are success
criteria at every level that are essential to some people, we feel
that this scheme is not appropriate. To clarify our usage, we have
rewritten the description of conformance levels in WCAG 2 at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels .
----------------------------------------------------------
Comment 3:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-925)
How should we classify an interactive multimedia game that is
continuously drawing to a visual canvas? Is this pre-recorded or live
multimedia?
----------------------------
Response from Working Group:
----------------------------
We have added a note to the SC:
Note: If multimedia is completely computer generated, it is not live
and is subject to the requirements for pre-recorded multimedia in WCAG
2.0.
----------------------------------------------------------
Comment 4:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-926)
Definition of "programmatically determined" is confusing.
Proposed Change:
Proposal for definition of ""programmatically determined"":
""available through content markup (element name, attributes, or
properties) or style sheet properties in the case of markup languages
or through accessibility APIs in the case of GUI applications.
Note: User agents can extract this information from content markup and
style sheet properties and make it available to an assistive
technology through programmatic means such as through the DOM or
accessibility API. Accessibility APIs may be defined by the technology
owner or in a publicly documented alternative recognized as explicitly
supporting accessibility.
----------------------------
Response from Working Group:
----------------------------
We have not changed the definition to distinguish between markup and
non-markup languages, but we have added several examples to the
definition to highlight the use of direct access and access via
accessibility APIs.
----------------------------------------------------------
Comment 5:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-927)
The term "parsed unambiguously" is difficult to understand.
Proposed Change:
Change 4.1.1 to ""The structure of and relationships within web units
and authored components can be determined without the need for user
agents or assistive technologies to perform error correction.""
Eliminate the term ""parsed unambiguously"".
----------------------------
Response from Working Group:
----------------------------
To make this requirement easier to understand, we have reworded SC
4.1.1 to clarify that it must be possible to parse content without the
need for user agent repair. The revised SC reads as follows:
4.1.1 Content implemented using markup languages has elements with
complete start and end tags, except as allowed by their
specifications, and are nested according to their specifications.
(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 quote are not complete.
----------------------------------------------------------
Comment 6:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-928)
This does not address advertisements which can also be an issue for
people with disabilities. There should be a method to skip content
that is not relevant to the page or site content.
Proposed Change:
Change 2.4.1 to ""A mechanism is available to bypass blocks of content
that are repeated on multiple Web units or that are not relevant to
the page or site content.""
Alternative proposal: Add an advisory technique to How to meet GL 2.4
or How to meet SC 2.4.1.
----------------------------
Response from Working Group:
----------------------------
We have added an advisory technique to GL 2.4 to provide mechanisms
for navigating to different sections of the content.
----------------------------------------------------------
Comment 7:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-929)
The definition of Web unit may not work for SVG.
----------------------------
Response from Working Group:
----------------------------
We have modified the term "Web unit" to be "Web page" and have updated
the definition,
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#webpagedef .
Web page
a resource that is referenced by a URI and is not embedded in another
resource, plus any other resources that are used in the rendering or
intended to be rendered together with it
Note: Although any "other resources" would be rendered together with
the primary resource, they would not necessarily be rendered
simultaneously with each other.
Example 1: When you enter http://shopping.example.com/ in your browser
you enter a movie-like interactive shopping environment where you
visually move about a store dragging products off of the shelves
around you into a visual shopping cart in front of you. Clicking on a
product causes it to be demonstrated with a specification sheet
floating alongside.
Example 2: A Web resource including all embedded images and media.
Example 3: A Web mail program built using Asynchronous JavaScript and
XML (AJAX). The program lives entirely at http://mail.example.com, but
includes an inbox, a contacts area and a calendar. Links or buttons
are provided that cause the the inbox, contacts, or calendar to
display, but do not change the URL of the page as a whole.
Example 4: A customizable portal site, where users can choose content
to display from a set of different content modules.
----------------------------------------------------------
Comment 8:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-930)
Dynamic Web Accessibility allows for an object to have multiple
relationships (group, flowto, controlledby). This introduces a
situation where the author has more than one possible path to follow.
Simple tabbing will not be enough.
Proposed Change:
Change 2.4.6 to ""Components in a Web unit or authored component
receive focus in an order that follows relationships and sequences in
the content.""
Add an XHTML technique that demonstrates using Dynamic Web Content
Accessibility ""group"", ""flowto"" and ""controlledby"" states to How
to meet 2.4.6
----------------------------
Response from Working Group:
----------------------------
Removing the notion of sequential navigation from the success
criterion leaves it ambiguous. We have added explanation to the Intent
Section to clarify that there may be many possible orders that
satisfy the success criterion.
----------------------------------------------------------
Comment 9:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-931)
Some technologies, such as SVG, do not have a way to specify the
language of the document.
----------------------------
Response from Working Group:
----------------------------
It is our understanding that SVG 1.1 (2003) has xml:lang on many
elements including svg, title, text, tspan and textpath. SVG 1.0
(2001) has xml:lang on many elements including svg, g, title, text,
tspan, textpath and a. This success criterion could be met by adding
xml:lang to the svg element.
If any technology cannot specify the language used, it may be
necessary to embed them in a technology that does provide this
support, such as HTML. Or such technologies might not be considered
accessibility-supported until they did provide such a mechanism.
----------------------------------------------------------
Comment 10:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-932)
"Form control" is too technology specific. With DHTML, authors can
create interactive controls that are not "form controls". Also,
tabbing is too specific. Keyboard navigation is not limited to
tabbing. Arrow keys can also be used.
Proposed Change:
Change 3.2.2 to "Changing the setting of any interactive control or
field does not automatically cause a change of context (beyond moving
to the next field in the navigation sequence), unless the authored
unit contains instructions before the control that describe the
behavior."
----------------------------
Response from Working Group:
----------------------------
We have updated the wording of 3.2.2. It now reads, "Changing the
setting of any user interface component does not automatically cause a
change of context unless the user has been advised of the behavior
before using the component."
----------------------------------------------------------
Comment 11:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-933)
The title for principle 4 does not fit the requirements. Also, future
user agents may not render the old content. The principle just does
not make sense.
Proposed Change:
Change principle 4 to "Content must be interoperable with assistive
technologies."
----------------------------
Response from Working Group:
----------------------------
We have revised Principle 4 to fit the requirements more accurately.
----------------------------------------------------------
Comment 12:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-934)
"Interoperability" is a better term than "compatibility". Also see
comment on principle 4 about "future user agents".
Proposed Change:
Change 4.1 to "Support interoperability with user agents (including
assistive technologies)."
----------------------------
Response from Working Group:
----------------------------
Interoperability is actually a subset of compatibility. Compatibility
also includes lack of interference with. We intend both aspects of
compatibility to apply.
----------------------------------------------------------
Comment 13:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-935)
Repurposed widgets require the user to have state information as well.
For example, if a
is used to make a checkbox you would need to know if it were checked
or not. States, properties, and values need to be programmatically
determinable. Proposed Change: Change 4.1.2 to "For all user interface
components, the name and role can be programmatically determined,
states, properties, and values that can be set by the user can
programmatically determined and set, and notification of changes to
these items is available to user agents, including assistive
technologies."
----------------------------
Response from Working Group:
----------------------------
The success criterion has been updated as proposed. It now reads:
For all user interface components, the name and role can be
programmatically determined; states, properties, and values that can
be set by the user can be programmatically determined and
programmatically set; and notification of changes to these items is
available to user agents, including assistive technologies.
----------------------------------------------------------
Comment 14:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com.
(Issue ID: LC-936)
SVG is not likely to be compliant in its current form.
----------------------------
Response from Working Group:
----------------------------
It is the working group's opinion that this is best handled from the
SVG end and doesn't impact the WCAG document itself. From our
discussion I take it you agree but that you were just pointing this
out in an informative way and are not asking for action on the part of
the WCAG WG.
----------------------------------------------------------
Comment 15:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-937)
The Dynamic Web Accessibility Adaptable States and Properties module
includes a describedby property which provides help text to describe
the object. This maps to platform accessibility APIs as well.
Proposed Change:
Add an XHTML technique that demonstrates using Dynamic Web Content
Accessibility "describedby" property.
----------------------------
Response from Working Group:
----------------------------
We have created a technique titled, "Using Accessible Rich Internet
Application describedby property to provide a descriptive,
programmatically determined label". This is an advisory technique for
Success Criteria 1.3.1, 2.4.4 and 2.4.5. It can be moved to a
sufficient technique when Accessible Rich Internet Application
specifications reach W3C recommendation status and are well supported.
----------------------------------------------------------
Comment 16:
Source:
http://www.w3.org/mid/OF4F7657B9.76D0EA97-ON86257195.006670FC-86257195.006707E6@us.ibm.com
(Issue ID: LC-938)
Users who are filling out forms need a mechanism to indicate whether
form elements are required. This is addressed in XForms and Dynamic
Web Accessibility by indicating if a form field is required or
invalid. If the user does not know a field is required form
submissions will fail and the user must repeat the process.
Proposed Change:
Add an XHTML technique to How to meet 1.3.1 that demonstrates using
Dynamic Web Content Accessibility attribute of required=""true"".
Such a technique could also be useful in meeting GL 2.5 but there is
no success criteria to relate it to. It could be an advisory technique
under ""Understanding guideline 2.5"" or listed as a related technique
under the GL 2.5 success criteria.
----------------------------
Response from Working Group:
----------------------------
Thank you for the suggestion. We have created an advisory technique
for SC 1.3.1 on how to use the Dynamic Web Content Accessibility
'required' attribute to programmatically mark a form field as
required. This is an advisory technique until the Dynamic Web Content
Accessibility specification reaches recommendation status.
Received on Monday, 11 June 2007 05:31:18 UTC