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:42:54 -0700
Message-ID: <824e742c0705171642k79c8b8e2td26d6e6a31ad5619@mail.gmail.com>
To: "Robert C. Baker" <Robert.C.Baker@ssa.gov>
Cc: public-comments-WCAG20@w3.org

Dear Robert C. Baker ,

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/7BB274B2F849DE4981915D42210ED48F028EE0EA@s3c1ex1.ba.ad.ssa.gov
(Issue ID: LC-681)

The Social Security Administration welcomes the opportunity to comment
on the proposed WCAG 2.0 standards. In general, SSA finds that the
general content of the proposed standards addresses many shortcomings
of the previous version of the standards. In addition, the baseline
concept for establishing a testing environment provides excellent
direction for accessibility and validation testing. However, SSA has
some concerns that should be addressed before the final version is
published.

 The principles are broken down into 4 simple components 
perceivable, operable, understandable and robust, which we agree is an
excellent way to structure the standards at a high level. However, the
explanations and further breakdown tend to be confusing and navigation
through the 400 plus pages is unwieldy. As a result - it can be
difficult to determine if appropriate standards exists to guide
development activities.

 Specific techniques for meeting the guidelines are very scientific
and precise, however from a pragmatic perspective will be difficult to
implement due to focus on mathematic calculations to address
unfamiliar issues such as luminosity and audio levels.

 Success criteria in some cases are very general and in need of
further definition to support proper implementation (for example:
minimal level of accessibility is defined as the target - but the
criteria for meeting this requirement are not defined).


 The guidelines do not address the following:

 Alt text for images, links, etc. that are normally exposed by mouse
over capabilities must also be accessible by the keyboard.

 For error handling, there must be a way for users to know where
errors are in a form and be able to navigate directly to the input in
error.

 Guidelines for creating HTML documentation and Help must be stated
and Help using navigational techniques must also be documented for
accessibility.

 Informational text and instructions within web applications must
have a focal point achieved by using tab indices of zero or some
equivalent technique.

 Applets and plug-ins used with web pages or applications must be
referenced with specific guidelines for accessibility.

 Standardized keyboard navigation through frames.

 Search facility guidelines for navigation and focus.

 Mark-up of textual information for carets and other pointers.

 Avoiding conflicts between browser and web application commands.


 In addition, we recommend the W3C address the following items at a later date:

 Guidelines should provide additional guidance and examples are
needed to address user navigation to errors once they are identified.

 Guidelines should address keyboard access, however additional
guidance is needed for when to assign hotkeys, defining logical tab
order, hotkeys shown on buttons, and defining tab indices for text
focus and search functionality.  Also, guidance is needed to determine
what is an acceptable number of keystrokes to perform the equivalent
of one mouse action to provide comparable access.

 Guidelines should address e-learning considerations, such as
navigation, registration, administration, courseware, simulations,
test taking, and reporting results.

 Guidelines should address context sensitive help built into the HTML
structure.

 Guidelines should address table navigation for magnification users.

Respectfully,
Robert Baker

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

-----------------------------------------------------------------
 The principles are broken down into 4 simple components 
perceivable, operable, understandable and robust, which we agree is an
excellent way to structure the standards at a high level. However, the
explanations and further breakdown tend to be confusing and navigation
through the 400 plus pages is unwieldy. As a result - it can be
difficult to determine if appropriate standards exists to guide
development activities.

  Specific techniques for meeting the guidelines are very scientific
and precise, however from a pragmatic perspective will be difficult to
implement due to focus on mathematic calculations to address
unfamiliar issues such as luminosity and audio levels.

 Success criteria in some cases are very general and in need of
further definition to support proper implementation (for example:
minimal level of accessibility is defined as the target - but the
criteria for meeting this requirement are not defined).

We agree with this assesment and have created the QUICK REFERENCE
document (http://www.w3.org/WAI/WCAG20/quickref/).  We believe that
this will address your concern by putting the requirements and a
succinct list of techniques for meeting them all in one document.  The
sufficient techniques are very concrete and have full descriptions,
examples and tests associated with them.

With regard to the technique requiring calculation, we provide links
to free tools that will automatically carry out the calculations and
evaluate content for you.   In the past we only said things like "use
sufficent contrast" which provided no guidance and did not allow
authors to ever determine if they had met the guideline or not.
-----------------------------------------------------------------

 Alt text for images, links, etc. that are normally exposed by mouse
over capabilities must also be accessible by the keyboard.

Keyboard operations requirement and alt text are already in the
guideline at level A. Assuming content meets WCAG 2.0, it is the user
agent that determines if alt text can be exposed by keyboard only. If
a 'mouseover' event is used in scripting then SC 2.1.1 would require
that moving the focus to the item by keyboard would also trigger the
same action as mouseover. So the concern is either met (in one case)
or a user agent issue (in the other case).
-----------------------------------------------------------------
 For error handling, there must be a way for users to know where
errors are in a form and be able to navigate directly to the input in
error.

The working group considered adding this requirement as a success
criterion, and decided not to because it is too specific to apply to
all technologies and all environments. However, there are several
advisory techniques provided that will help authors who wish to design
more usable forms.
-----------------------------------------------------------------
 Guidelines for creating HTML documentation and Help must be stated
and Help using navigational techniques must also be documented for
accessibility.

We agree that Help and documentation that is available *on the web* is
web content and hence that it should conform to these Guidelines. Note
that although the same issues appear for documentation and Help files
for desktop applications, these guidelines do not address that
content. However, we feel that attempting to single out specific
examples of Web content is likely to lead people to believe that only
the listed examples are covered.
-----------------------------------------------------------------
 Informational text and instructions within web applications must
have a focal point achieved by using tab indices of zero or some
equivalent technique.

The working group believes that there are some instances where
deliberately putting focus on something (like error messages) can be
helpful, but that attempting to control the way a user interacts with
all pages, especially where it may conflict with expected behaviors
for forms or other user interface components, is problematic.
-----------------------------------------------------------------
 Applets and plug-ins used with web pages or applications must be
referenced with specific guidelines for accessibility.

Programmatic content (applets, etc.) are covered in several ways. If
they are not accessibility supported, then conformance requirement6
requires that the inaccessible content do no harm and conformance
requirement 4 requires that an accessible version also be provided.

If the technologies are accessibility supported, then SC 4.1.2
requires that the programmatic content be compatible with assistive
technologies and be accessible. In addition, all of the other success
criteria (such as keyboard operability) in the guidelines would also
need to be met by the programmatic content.

The term "plug-in" is usually used for extensions to user agents, and
is related to the definitions of "user agent" and "assistive
technology". Guidelines related to the accessibility of plug-ins
themselves can be found in the User Agent Accessibility Guidelines
(http://www.w3.org/TR/UAAG10/).
-----------------------------------------------------------------
 Standardized keyboard navigation through frames.

The success criteria in guideline 2.1 require that all content be
operable via the keyboard. How user agents provide keyboard navigation
through frames is a user agent issue.
-----------------------------------------------------------------
 Search facility guidelines for navigation and focus.

While this can be helpful for improving the experience with Windows
Narrator, more fully-featured screen readers have the ability to allow
users to interact with all kinds of text. Users of those screen
readers are used to the way they interact with structured pages, and
don't need this extra help.

In addition, there are many issues for other types of users with this
non-standard approach. For example,

1) Unexpected behavior for all users
2) Developers often attach events to paragraphs and other
non-actionable elements when they have focus, and this is not
compatible with AT.
3) This will be more difficult for sighted keyboard users, as they
will have to tab through parts of the page that are not normally
tabbable.
4) Confusing for experienced screen-reader users, because they expect
that everything tabbable in a form is an editable field
5) Optimized for forms mode, but also used on non-form pages. This is
very strange when in browse mode, because users expect to be able to
tab to find links.
-----------------------------------------------------------------
 Mark-up of textual information for carets and other pointers.

The user agent issue is, of course, outside of our guidelines and
would be in the domain of the user agent guidelines. From a content
perspective, any non-text content must have text equivalents under SC
1.1.1. Structure (lists etc.) must be programatically determinable
under SC 1.3.1. Other use of characters that convey information
required to understand and operate content should be addressed by SC
1.3.3 (formerly 1.3.5).
-----------------------------------------------------------------
 Avoiding conflicts between browser and web application commands.

We will be adding an advisory technique titled "Avoiding use of common
user-agent keyboard commands for other purposes."
-----------------------------------------------------------------
 Guidelines should provide additional guidance and examples are
needed to address user navigation to errors once they are identified.

There are advisory techniques for SC 2.5.3 that cover much of the SSA
recommendations. They include.
-Validating form submissions on the server (future link)
-Re-displaying a form with a summary of errors (future link)
-Providing error notification as the user enters information (future link)
-Assisting the user in making corrections by providing links to each
error (future link)
-Highlighting or visually emphasizing errors where they occur (future link)
-Supplementing text with non-text content when reporting errors (future link)

In addition, we are adding the following advisory techniques.
-"Placing focus in the field containing the error"
-"Avoiding use of the same words or letter combinations to begin each
item of a drop-down list"

And we have linked this SC to the following advisory technique:
"Providing client-side validation and alert"

NOTE: "(future link)" is what we call all techniques that we have
identified and are listed in our "Understanding WCAG" and our "Quick
Reference" documents but have not yet been fully written up.
-----------------------------------------------------------------
 Guidelines should address keyboard access, however additional
guidance is needed for when to assign hotkeys, defining logical tab
order, hotkeys shown on buttons, and defining tab indices for text
focus and search functionality. Also, guidance is needed to determine
what is an acceptable number of keystrokes to perform the equivalent
of one mouse action to provide comparable access.

This type of topic would be handled in an application notes. We would
love to write an Application Note "Enhancing Keyboard Access to Web
Content" that would provide guidance on assigning hotkeys, defining
logical tab order, defining hotkeys shown on buttons, and defining tab
indices for text focus and search functionality. It might also discuss
the topic of "number of keystrokes to perform the equivalent of one
mouse action" but it won't be able to define "comparable access" since
it would differ so much based on individual abilities to point or
create keystrokes. User agent support for access keys is so bad that
developers have started looking for server-side solutions that allow
users to define access keys (see
http://juicystudio.com/article/user-defined-accesskeys.php and
http://juicystudio.com/article/user-defined-access-keys-aspversion.php).
If you are aware of a good paper or application note on this we would
be most interested.
-----------------------------------------------------------------
 Guidelines should address e-learning considerations, such as
navigation, registration, administration, courseware, simulations,
test taking, and reporting results.

We belive that all of the fundamental issues raised in making these
applications accessible are included in the guidelines. The guidelines
cover form controls, text, images, multimedia and programmatic
elements (applets and the like). The EO group working with WCAG WG
will be working on application notes to look at particular
applications in the future and we expect that additional techniques in
this area will become available in the future. However, the basics
should already all be in place.
-----------------------------------------------------------------
 Guidelines should address context sensitive help built into the HTML
structure.

Thank you, we have added an advisory technique (which will be
completed at later date) titled "Using the title attribute to provide
context-sensitive help" and another titled, "Using scripts to provide
context-sensitive bubble help."
-----------------------------------------------------------------
 Guidelines should address table navigation for magnification users.

Success criterion 1.3.1 includes requirements related to the use of
table markup. The working group believes that this is a user agent
issue rather than a content issue.

If you have suggestions for techniques that would improve table
navigation for screen magnification users, please submit them so we
can include them. (Refer to the techniques submission form at
http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/).
Received on Thursday, 17 May 2007 23:43:21 UTC

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