W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > May 2007

Your comments on WCAG 2.0 Last Call Draft of April 2006

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Thu, 17 May 2007 16:44:12 -0700
Message-ID: <824e742c0705171644i732ea9bcpffcdf106eb21bb2d@mail.gmail.com>
To: "Steven Faulkner" <steven.faulkner@nils.org.au>
Cc: public-comments-WCAG20@w3.org

Dear Steven Faulkner ,

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/20060509033718.7EC0666364@dolph.w3.org
(Issue ID: LC-510)

Part of Item: Intent
Comment Type: TE
Comment (Including rationale for any proposed change):

The term "programmatically associated" is used but not defined.

Proposed Change:

Provide a definition of "programmatically associated" within Appendix
A: Glossary.

----------------------------
Response from Working Group:
----------------------------

We have reworded SC 2.4.4 to clarify its intent and to remove the term
"programmatically associated". It now reads:
2.4.4 The purpose of each link can be determined from the link text
and its programmatically determined link context.

where "Programmatically determined link context" is defined as:
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#pdlinkcontextdef

programmatically determined link context
  1. Additional information that can be programmatically determined
from relationships with a link; and
  2. can be extracted, combined with the link text, and presented to
users in different modalities.

    Example 1: Screen readers provide commands to read the current
sentence when focus is on a link.
    Example 2: Examples of information that can be extracted, combined
with link text, and presented to users in different modalities include
text that is in the same sentence, paragraph, list, or table cell as
the link or in a table header cell that is associated with the table
cell that contains the link.

----------------------------------------------------------
Comment 2:

Source: http://www.w3.org/mid/20060509035254.31FFEBDA8@w3c4.w3.org
(Issue ID: LC-511)

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

The success criterion refers to "Text or diagrams". From the definiton
of "text" in Appendix A:Glossary, it appears that images of text are
not included. This can result in web authors using images of text
(with a foreground/background luminosity ratio of less than 5:1) to
circumvent this Success criterion.

Proposed Change:

Include an explicit reference to the inclusion of images of text in
terms of this success criterion.

----------------------------
Response from Working Group:
----------------------------

The Working Group agrees with this issue and has revised SC 1.4.3
(formerly 1.4.1) and 1.4.5 (formerly 1.4.3) as follows:

SC 1.4.3  Text (and images of text) have a contrast ratio of at least
5:1, except if the text is pure decoration. Larger-scale text or
images of text can have a contrast ratio of 3:1.

SC 1.4.5   Text (and images of text) have a contrast ratio of at least
7:1, except if the text is pure decoration. Larger-scale text or
images of text can have a contrast ratio of 5:1.

We also added an advisory technique "Using unicode text and style
sheets instead of images of text"

----------------------------------------------------------
Comment 3:

Source: http://www.w3.org/mid/20060519060019.5E8A2BDA8@w3c4.w3.org
(Issue ID: LC-557)

Part of Item: Applicability
Comment Type: TE
Comment (including rationale for proposed change):

2.4.4 Each link is programmatically associated with text from which
its purpose can be determined. (Level 2)
"The intent of this success criterion is to help users understand the
purpose of each link in the content"
The intent of the criterion is not met by the use of technique H33.
Critisisms of Technique H33
"User agents will display a tool tip when the mouse hovers above an
anchor element containing a title attribute."
1.	Current User agents do not provide access to title attribute
content via the keyboard [1]
a.	Will result in content not being accessible by non-mouse users who
do not use screen reading software.
b.	Contradicts the intent of Guideline 2.1 Make all functionality
operable via a keyboard interface.
c.	Contradicts the intent of Guideline 4.2 Ensure that content is
accessible or provide an accessible alternative, because the technique
does not include advice that an accessible alternative version of the
content within the title attribute be provided.

2.	The "tool tip" in some commonly used user agents disapears after a
short period of time (approximately 5 seconds) [1]
a.	Will result in difficulty accessing title attribute content for
those users who can use a mouse, but have fine motor skill impairment.
b.	May result in reading difficulties of title attribute content for
users with cognitive/learning impairment.
c.	Contradicts the intent of Guideline 2.2 Allow users to control time
limits on their reading or interaction.
3.	Presentation of title attribute content cannot be resized or
colours changed via the user agent or by the content author.
a.	The foreground and background colours of the "tool tip" cannot be
modified by the user via the user agent.
b.	The size of the text within a "tool tip" cannot be modifed by a
user via the user agent.
c.	Contradicts the intent of Guideline 1.3 Ensure that information and
structure can be separated from presentation
4.	The placement and location of the "tool tip" cannot be modified by users.
a.	This results in some screen magnifier users being unable to access
meaningful portions of the title attribute content, because the "tool
tip" cannot be fully displyed within the view port [2].

Assistive technology issues
Three pieces of assistive technology are cited in the "User Agent and
Assistive Technology Support Notes" [4]. Two of those cited do not
provide a practical or functionally equivalent  method for users to
access the information within the title attribute of links.
JAWS 7.0
"JAWS 7.0 will speak either the link text or the title attribute for a
link depending upon a JAWS setting. This setting can be changed
temporarily or permanently within JAWS."
Discussion
JAWS does not provide a practical or functionally equivalent method
for users to hear the content of a link's title attribute
If a user has JAWS set to read "Title text" for links they cannot
access the "screen text"  without changing the JAWS verbosity settings
(This process involves a minimum of 7 keystrokes / keystroke
combinations and in 5 out of 7 tests caused JAWS to start reading
again from the top of the page, thus losing focus on the link that had
a potential "title text".).
So in Example 2 (
Table 1) of technique H33 a JAWS user with verbosity set to "use
title" for links would hear
"link opens in new window"
, but would not hear
"Subscribe to email notifications about breaking news"
, nor would they be given any indication that this additional
information was available and could not access the information without
going through these steps:
In order for a user to change the verbosity setting for links a user must:
"press INSERT V to open the Adjust JAWS Verbosity dialog box. Select
an option with the arrow keys and then press SPACEBAR or use the
Execute button to cycle through the available settings. Press ENTER to
accept your changes and close the dialog box. " [3]
Conversely if the user had the default "screen text" settings they
would not hear the information \"link opens in new window\" nor would
they be given any indication that this additional information was
available.


Table 1 H33: Supplementing link text with the title attribute - Example 2
     Subscribe to email notifications about breaking news

Homepage Reader 3.04
"Home Page Reader 3.04 will speak the title attribute of any element
with focus when the control-shift-F1 keys are pressed simultaneously."
	This is not a documented feature of HPR 3.04. The  documentation in
reference to this states that the URL of the page will be read out (no
mention of the title attribute).
	The title attribute content is read out, but after the URL of the
current page is read.
	The user has no way to know that there is supplementary information
available unless he/she activates the key combination. It is totally
impractical to expect users to query each link to find supplementary
information.

References
1.	Display of the TITLE attribute in some common browsers -
http://www.sf.id.au/WE05/#slide7
2.	Screen Magnifier users - http://www.sf.id.au/WE05/#slide12
3.	JAWS 6 documentation - JAWS 6.20 documentation [EXE file, 1.57 MB]
4.	Technique H33 - Supplementing link text with the title attribute
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H33


Proposed Change:

Remove technique H33

----------------------------
Response from Working Group:
----------------------------

We have added the information you provided to the list of user agent
notes for this technique. The working group would like to see better
user agent support for the title attribute, but feels that this should
reamain a sufficient technique while efforts to improve user agent and
assistive technology support are made. It has been made an advisory
technique for SC 2.4.8, since the link text itself must be
sufficiently descriptive without depending upon the title attribute
content to meet that criterion.

Because title attributes should only be used for supplementary
information, we have added a sentence to the Intent section "If the
supplementary information provided through the title attribute is
something the user should know before following the link, such as a
warning, then it should be provided in the link text rather than in
the title attribute." We also included a Failure Example where the
title attribute contains non-supplementary information about the link.
Received on Thursday, 17 May 2007 23:44:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:07 UTC