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:37:52 -0700
Message-ID: <824e742c0705171637j1cbb05acubf73867bc5db4cd6@mail.gmail.com>
To: "John Nissen" <jn@cloudworld.co.uk>
Cc: public-comments-WCAG20@w3.org

Dear John Nissen ,

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/20060606062005.578DCBDA9@w3c4.w3.org
(Issue ID: LC-734)

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

[See http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0151/WCAG_comment.doc
for original comments.]

I am concerned about 4.2.2, point 1, as regards both (a) ease of
comprehension (in particular in the use of "entered" when concerned
with "content") and (b) effectiveness (in case the user can be
"trapped" through other means).

In the comparison document,
http://www.w3.org/TR/WCAG20/appendixD.html,
we have:


And if all else fails (Priority 1)	WCAG 2.0 Success Criteria
11.4: 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. 	4.2.1 At least
one version of the content meets all level 1 success criteria, but
alternate version(s) that do not meet all level 1 success criteria may
be available from the same URI. (Level 1)
4.2.2 Content meets the following criteria even if the content uses a
technology that is not in the chosen baseline: (Level 1)
1.	If content can be entered using the keyboard, then the content can
be exited using the keyboard.
2.	Content conforms to success criterion 2.3.1 (general and red flash).



In the "Understanding" document,
http://www.w3.org/TR/UNDERSTANDING-WCAG20/,
we have:
How to Meet Success Criterion 4.2.2
4.2.2 Content meets the following criteria even if the content uses a
technology that is not in the chosen baseline: (Level 1)
1.	If content can be entered using the keyboard, then the content can
be exited using the keyboard.
2.	Content conforms to success criterion 2.3.1 (general and red flash).
Key Terms
content
information to be communicated to the user by means of a user agent
Note: This includes the code and markup that define the structure,
presentation, and interaction, as well as text, images, and sounds
that convey information to the end-user.
baseline
set of technologies assumed to be supported by, and enabled in, user agents
Note: For more information on baselines and their use, refer to
Technology Assumptions and the \"baseline.\"
Intent of this success criterion
The intent of this success criterion is to ensure that content which
uses technologies outside the baseline does not include components
that actively interfere with the accessibility of the remaining
content. Such components include:
	components that would trap keyboard users within inaccessible content.
	flashing components that could cause seizures due to photosensitivity
\"Keyboard trapping\" refers to a common situation in which the
keyboard focus can become stuck in inaccessible plugins, leaving a
keyboard-only user with no way to return to the accessible content.
The requirement that content that can be entered via the keyboard can
be exited via the keyboard is to prevent this \'lock up\' effect.
The requirement to satisfy Success Criterion 2.3.1 is intended to
ensure that users with photosensitivity (including users who may not
be aware of their vulnerability) do not encounter flashing content
that could cause a seuzure.
Content may be implemented in technologies that are not in the
baseline if accessible alternatives are provided using technologies
that are in the baseline, or if the content is accessible from a user
agent that supports only the technologies in the baseline. It is vital
that there be no characteristics of any of the content that actively
interfere with its accessibility. This is because user agents that
support the technology used could be present and create accessibility
problems even though the technology is not part of the baseline.



In the techniques document,
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#G21
we have:
G21: Ensuring that users are not trapped in content
Applicability
All technologies which support interactive operation.
This technique is referenced from:
	How to Meet Success Criterion 2.1.1
	How to Meet Success Criterion 4.2.2
Description
The objective of this technique is to ensure that keyboard users do
not become trapped in a subset of the content that can only be exited
using a mouse or pointing device. A common example is content rendered
by plug-ins. Plug-ins are user agents that render content inside the
user agent host window and respond to all user actions that takes
place while the plug-in has the focus. If the plug-in does not provide
a keyboard mechanism to return focus to the parent window, users who
must use the keyboard may become trapped in the plug-in content.
This problem can be avoided by using one of the following mechanisms
to provide a way for users to escape the subset of the content:
	Ensuring that the keyboard function for advancing focus within
content (commonly the tab key) exits the subset of the content after
it reaches the final navigation location.
	Providing a keyboard function to move the focus out of the subset of
the content. Be sure to document the feature in an accessible manner
within the subset.
	If the subset of the content does natively provide a \"move to
parent\" keyboard command, documenting that command before the user
enters the plug-in so they know how to get out again.
Examples
	Once a user tabs into an applet, further tabs are handled by the
applet preventing the person from tabbing out. However, the applet is
designed so that it returns keyboard focus back to the parent window
when the person finishes tabbing through the tab sequence in the
applet.



My concerns are over comprehension and effectiveness.

(a) Concern over comprehension

The use of the word "entered" in connection with "content" suggests
that the user is entering text, for example entering text into a field
of a form (such as search terms into Google).  It is clear from the
"Understanding" document that "entering" refers to entering a part of
the page (i.e. subset of the content).  Therefore I suggest changing
the point as follows:

1. If a part or subset of the content (using a technology that is not
in the chosen baseline), can be entered using the keyboard, then that
part or subset can be exited using the keyboard.

(b) Concern over effectiveness

It is not at all obvious that this is about trapping, nor that it is
effective against trapping in general.  (For example, I could envisage
being trapped by a pointing device if there were no way to exit using
the pointing device.)  So I would like to see the point made more
explicit and more general by a further change as follows:

1. If a part or subset of the content (using a technology that is not
in the chosen baseline), can be entered using some device (such as the
keyboard), then that part or subset can be exited using the same
device, such that a user cannot be trapped in that part without a
means to exit.

Furthermore, the effectiveness relies on the means of exiting being
documented in such a way that it is obvious to the user how to escape.
 So I suggest adding the word "obvious" to the above:


1. If a part or subset of the content (using a technology that is not
in the chosen baseline), can be entered using some device (such as the
keyboard), then that part or subset can be exited using the same
device, such that a user cannot be trapped in that part without an
obvious means to exit.



Proposed Change:

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

Thank you for pointing out the ambiguity in the use of the word
"entered". To clarify, we have adapted your proposal and changed
conformance requirement 6, item 1, as follows:
 "If focus can be moved to technologies that are not accessibility
supported using a keyboard interface, then focus can be moved away
from that content using only a keyboard interface, and the method for
doing so is described before the content is encountered and in a way
that meets all Level A success criteria."

Although making the means to exit obvious to the user is important to
the effectiveness of any technique, we are unable to determine any way
to test whether a technique is obvious, since it depends upon the
user's expectations. The technique "Ensuring that users are not
trapped in content" discusses the need to document the mechanism.

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

Source: http://www.w3.org/mid/16a201c680ce$efd26840$0202a8c0@Tomschoice
(Issue ID: LC-1331)

Dear Chair and members of WAI,

I would like to suggest some improvement in 4.2.2.  I have documented
my proposal, and the reasons for it, in the attached document.  I have
to admit that at first reading of 4.2.2 (point 1), I was completely
flumoxed.  But having read through a lot of explanation, I think you
could make the point a lot clearer and also more effective by some
small changes.

BTW, I notice that the deadline for comments is 31st May, and I shall
be out next week for half-term holiday!  So if there is a problem with
this submission, please let me know by return.

Yours sincerely,

John

[See attachment to
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0151
]

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

Thank you for pointing out the ambiguity in the use of the word
"entered". This success criterion has been moved to conformance. To
clarify, we have adapted your proposal and changed conformance
requirement 6, item 1, as follows:
  "If focus can be moved to technologies that are not accessibility
supported using a keyboard interface, then focus can be moved away
from that content using only a keyboard interface, and the method for
doing so is described before the content is encountered and in a way
that meets all Level A success criteria."

Although making the means to exit obvious to the user is important to
the effectiveness of any technique, we are unable to determine any way
to test whether a technique is obvious, since it depends upon the
user's expectations.
Received on Thursday, 17 May 2007 23:38:11 UTC

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