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

Your comments on WCAG 2.0 Public Working Draft of May, 2007 (2 of 2)

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Sat, 3 Nov 2007 21:33:16 -0700
Message-ID: <824e742c0711032133r3c905dc1o52aaec33d5484692@mail.gmail.com>
To: "Greg Lowney" <gcl-0039@access-research.org>
Cc: public-comments-WCAG20@w3.org

Comment 13: What platforms must be supported?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2141)
----------------------------
Original Comment:
----------------------------

1.      The Conformance section does not address the question of which
platforms need to be supported. If something only runs on one platform, what
determines if it is accessible? What if the plug-in required for viewing it
does not support Linux?

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

We do not have any requirements for platforms per se, but the
description of accessibility support for a technology should note
which platforms the technology has AT support on.   This is described
in the section "Understanding Accessibility Support" in "Understanding
Conformance".

----------------------------------------------------------
Comment 14: machine-readable
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2142)
----------------------------
Original Comment:
----------------------------

2.      Conformance, Optional components of a conformance claim, uses the
term "machine-readable metadata", which occurs nowhere else in the document.
Is the intention that this metadata be in a standardized form, or merely
that it can be accessed as text without the use of optical character
recognition? Should it be added to the glossary?

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

Yes, it is the intent that it be in standard form but we are not
specifying a particular standard.  This is described in the
"Understanding Conformance" document as follows:

"The most useful way of attaching conformance claims to content would
be to do so in standard machine readable form. When this practice is
widespread, search tools or special user agents will be able to make
use of this information to find and provide content that is more
accessible or so the user agents can adjust the content. There are a
number of metadata based options under development for making claims,
and authors and tool developers are encouraged to support them.

In addition, metadata can be used to report conformance to individual
success criteria once Level A conformance has been achieved.

There are also programmatic reporting formats such as Evaluation and
Report Language (EARL) that are being developed that could provide
machine readable formats for detailed conformance information. As the
reporting formats are formalized and support for them develops the
will be documented here."

----------------------------------------------------------
Comment 15: Duplicate handle
Source: http://http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2143)
----------------------------
Original Comment:
----------------------------

3.      2.2.4 has the title "Timing:" which is also the title of 2.1.1. In
all other cases, each title is unique. I suggest changing the title of 2.2.4
to "Timing (Enhanced):"

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

Thanks for catching this duplication. We changed the handles for SC
2.2.1 and 2.2.3 so they are not identical.

----------------------------------------------------------
Comment 16: Use a variety of screen readers in Conformance Claim examples
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2144)
----------------------------
Original Comment:
----------------------------

4.      I recommend Examples of Conformance Claims in the Understanding
document include references to more than one screen reader. Currently, Jaws
is the only one named, and it is named five times.

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

Thank you for pointing this out. We have made the names of specific
products non-specific.

----------------------------------------------------------
Comment 17: moving fomer SC into conformance
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2145)
----------------------------
Original Comment:
----------------------------

5.      I believe I understand the rationale for moving several (former)
success criteria into the Conformance section, but I am worried about two
things. First, they are no longer easily referenced; can you call them
something like "CR6.1, No Keyboard Trap"? Second, it seems like they are
likely to be overlooked when someone is reading what they consider to be the
key sections, or a summary of the guidelines. I would not be surprised to
see the H1 section titled "WCAG 2.0 Guidelines" being extracted or
considered the key portion, and it used to be so, but now the H2 section
titled "Conformance Requirements" is just as important for actual content
developers, not just managers. Some specific factors that could lead the
latter to be overlooked are (a) it's only H2 instead of H1, (b) it is
surrounded by other H2 sections that look much less like lists of guidelines
and more like paragraphs of text, and (c) the sections around it are more
applicable to managers than to individual designers and authors. I don't
have a good suggestion for mitigating this problem, but perhaps the working
group can think of something.

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

We have moved the conformance requirements to the front of the section.

----------------------------------------------------------
Comment 18: autoadvance on focus
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2146)
----------------------------
Original Comment:
----------------------------

6.      3.2.2 "On Input: 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." None of the
Understanding or Techniques addresses the common situation where several
form fields are used to enter the fixed-length segments of multi-part value,
such as a serial, phone, or social security number. In those cases it is
common for the focus to automatically move to the next field when the
correct number of characters have been entered. While this is common and a
convenience to many users, it would violate this success criterion and
should be addressed specifically.

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

We think these are examples of advancing the focus when the setting of
the user interface component has been changed, e.g., characters have
been typed into the fixed-length text field. While this sort of
situation is becoming more common, we believe it is non-standard
behavior for user interface controls that can cause confusion for
users. In order to avoid violating SC 3.2.2, the user should be
advised of this behavior. It is then predicable and would not violate
this success criterion.

----------------------------------------------------------
Comment 19: better handle for bullet 1
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2147)
----------------------------
Original Comment:
----------------------------

7.      1.1.1 bullet 1, "Controls-Media", could be renamed to "Controls,
Input" to be more consistent with the other bullets (e.g. "Media, Test,
Sensory" and "Decoration, Formatting, Invisible".

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

Done. Thank you.

----------------------------------------------------------
Comment 20: make handle consistent with SC
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2148)
----------------------------
Original Comment:
----------------------------

8.      1.3.3. Minor, editorial only, but you might consider changing the
either the title ("Size, Shape, Location") or the text ("shape, size, visual
location, or orientation") so the two use the same order.

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

In response to another comment we received, we changed the handle to
'Sensory Characteristics', which eliminates the concern you raised.

----------------------------------------------------------
Comment 21: suggested new SC
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2149)
----------------------------
Original Comment:
----------------------------

10.     I consider it unfortunate that the Keyboard section does not contain
a AA or AAA criterion addressing the benefit of having a keyboard interface
that does not require reference to spatial arrangement of items on the
visual display. For example, "Non-relative: All functionality of the content
is operable through a keyboard interface without requiring timings for
individual keystrokes or reference to the spatial arrangement of content or
controls on the visual display."

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

The issue you are concerned with is covered by 2.1.3 Keyboard (No
Exception) and by 1.3.3 Sensory Characteristics.

----------------------------------------------------------
Comment 22: Change level to AA or AAA
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2150)
----------------------------
Original Comment:
----------------------------

11.     2.4.4 Link Purpose (Context): I don't consider this a Single-A
criterion, as this level of information is often not available to most
users. I think that in the vast majority of cases, it is merely implied
rather than in any way made explicit. I would be fine with it being demoted
to either Double-A or Triple-A.

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

Thank you. We have revised SC 2.4.4 to better reflect current support
of assistive technology. Over time we expect that the assistive
technology support will also improve for the other options.

While the working group encourages authors to make link text as
descriptive as possible out of context, we do not feel that this
success criterion can be satisfied for all Web pages. For Example:
- a page has book titles followed by PDF, HTML, DOC.
- Article name (long) followed by a sentence and the link "more"
- GOOGLE search where each entry has text plus the following links
[translate this page] HTML and [CACHED] and [SIMILAR PAGES]
- toolbar with menus with an arrow icon - the link says "open".
Having full links makes the page very cluttered, harder cognitively to
find things  when the same long (sometimes multi-line) text is
repeated with one word different, and is very long to listen to for
those not adept at auditory skipping (or where unique information is
back end loaded).

These issues were considered carefully for a long time, the working
group feels that having 2.4.4 at Level A and this issue addressed at
Level AAA strikes the right balance.

While user agent and assistive technology support for finding the link
context is poorer than we would like, we have checked that there is at
least one case of support for each of the types of link context we
have listed as sufficient techniques. So a user who has tabbed to a
link can ask for those pieces of context without leaving the link.

We hope that if authors satisfy SC 2.4.4 and make link context
programmatically determinable, user agent developers will find a way
to let users access the context when needed, such as when the link
list is created.

----------------------------------------------------------
Comment 23: use of title attribute
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2151)
----------------------------
Original Comment:
----------------------------

12.     2.4.4 Link Purpose (Context): Note that in addition to link text and
"programmatically determined link context" the Title attribute is often used
to provide information about the purpose of a link. This is done in the WCAG
2.0 document itself, where the title attribute of link to a definition is
prefixed with "definition: ", and many user agents provide a UI to present
this title to the user.

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

The title attribute is considered programmatically determined link
context, and its use is listed as a sufficient technique for this
success criterion. (See H33: Supplementing link text with the title
attribute)

----------------------------------------------------------
Comment 24: programmatically determinable
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2152)
----------------------------
Original Comment:
----------------------------

13.     2.4.4 and Definition of "programmatically determined link context",
I believe this would more properly be described as "programmatically
DETERMINABLE link context", as the current wording literally means link text
that is assigned programmatically.

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

A good observation. We have changed SC 2.4.4 as you suggested. It now reads:

2.4.4 Link Purpose (In Context):  The purpose of each link can be
determined from the link text alone, or from the link text together
with its programmatically determined link context, except where the
purpose of the link would be ambiguous to users in general.

----------------------------------------------------------
Comment 25: WCAG doesn't meet 2.4.8
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2153)
----------------------------
Original Comment:
----------------------------

14.     2.4.8 Link Purpose (Link Text): Note that I don't think even the
WCAG document itself meets this criterion.

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

We agree, it is not always possible for all Web pages to satisfy all
Level AAA success criteria. Content that includes links to definitions
(like in the WCAG) is a good example of why this SC is included at
level AAA.

----------------------------------------------------------
Comment 26: Only change of context prohibited on focus
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2154)
----------------------------
Original Comment:
----------------------------

15.     3.2.1 On Focus: This prevents an unexpected "change of context" when
any component receives focus, but no criterion currently restricts
components from making other persistent changes, such as changing the state
of a check box, simply because it received focus. This would be analogous to
the case of a radio button becoming selected merely because the user moved
focus to it, an error which we have seen in some desktop applications. I
would have liked to see added "....or any effect that will persist after the
component has lost focus". If this cannot be added to Single-A at this
point, could it be added as Double-A or Triple-A?

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

Whether setting focus on a radio button will change the state of that
control will depend on the user agent. In fact, the behavior you
describe is the expected behavior for radio buttons for screen readers
in some reading modes. Therefore, we feel it would be confusing to
introduce a requirement like this.

We agree, however, that such changes on focus should generally be
avoided, and we have added an advisory technique "Not causing
persistent changes of state or value when a component receives focus,
or providing an alternate means to reset any changes".

----------------------------------------------------------
Comment 27: Description of method must be encountered before content
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html
(Issue ID: 2155)
----------------------------
Original Comment:
----------------------------

16.     "Content that is not accessibility-supported contains a link to
information about how to move focus back to the accessibility-supported
content via the keyboard." This fails to address the part of the Conformance
Requirement that says "the method for doing so is described BEFORE the
content is encountered".

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

We have revised the example as follows:

A page that includes content that is not accessibility-supported
contains instructions about how to move focus back to the
accessibility-supported content via the keyboard. The instructions
precede the non accessibility-supported content.
Received on Sunday, 4 November 2007 04:33:38 UTC

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