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

Your comments on WCAG 2.0 Last Call Draft of April 2006 (4 of 6)

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Thu, 17 May 2007 16:40:21 -0700
Message-ID: <824e742c0705171640y1fe39ca9obdb2c98f7894a2a2@mail.gmail.com>
To: "Lisa Seeman" <lisa@ubaccess.com>
Cc: public-comments-WCAG20@w3.org

These responses are all to comments from the spreadsheet
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

----------------------------------------------------------

Comment 1:

Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1
(Issue ID: LC-606)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

Some widgets - such as a tree, the tab order will and should change
when a component is expanded. It make no sense to say that that is not
OK unless it is not predicable. As AT becomes used to these widgets,
instruction will not be required

Proposed Change:

Changing the setting of any form control or field does not
automatically cause a change of context (beyond moving to the next
field in tab order or behavior for a progamaticly determinable widget
type.), unless the authored unit contains instructions before the
control that describe the behavior.

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

We agree that what you cite should be allowed; it is already allowed
under the current wording. Expanding the tree is a change of content,
but not a change of context. The definition of "change of context"
includes the note: "A change of content is not always a change of
context. Small changes in content, such as an expanding outline or
dynamic menu, do not change the context."

Note that the clause "(beyond moving to the next field in tab order)"
has been removed as unnecessary.

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

Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1
(Issue ID: LC-607)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

I am concerned that level 1 SC will act against automatic help and
combined with information hiding. For example when  information is
hidden unless you  focus on the element in question, and then all the
sub information about it is given.

If you do not hide the information then the page becomes busy and you
can not see what the main points are. If the user has a two strep
process to access the information, then they may never receive it.

As with many SC, they are OK if you read the definition, but if you
just read the text it is misleading.

Proposed Change:

change the term "change of context" to "confusing change in context"
the definition can remain the same

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

The term "confusing" is subjective and would not be testable.

Because keyboard users must often move focus through other controls to
navigate to the control of interest, it is particularly important that
 just setting focus to a control does not have side effects. Although
changes of content such as your example are not changes of context,
and hence would not violate this success criterion.

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

Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1
(Issue ID: LC-608)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

I am concerned that the requirement for real time synrcrization put a
lot of extra work on authors who would like to provide short
animations or clips that help people with learning disabilities
fulfill a task. On the whole, a lot of  multi media, especially in
education,  is good for many learning disabilities, and these
requirements may act as a step backwards for learning disabilities.

Proposed Change:

Make an exception in  1.2 for any content provides extra help visual
for  tasks and information that has been described in text else wear.

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

We have added an exception to SC 1.2.1 so that captions are not needed
when the multimedia is presenting information that is already
available as text:

1.2.1 Captions: Captions are provided for prerecorded multimedia
except for multimedia alternatives to text that are clearly labeled as
such.

We have also updated the intent section for this criterion to reflect
this change.

----------------------------------------------------------
Comment 4:

Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1
(Issue ID: LC-609)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

To my mind the most important aspect if predictability is exposing to
the user agent what each thing is.  That way the interface can be
tailored to the user's access strategy. If XHTML 2 roles are known -
what is main and what is secondary navigation, then  the order becomes
less important.

Proposed Change:

add success criteria

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

This requirement is covered in SC 4.1.2 "For all user interface
components, the name and role can be programmatically determined,
values that can be set by the user can be programmatically set, and
notification of changes to these items is available to user agents,
including assistive technologies" and in SC 1.3.1 "Information and
relationships conveyed through presentation can be determined
programmatically, and notification of changes to these is available to
user agents, including assistive technologies."

While additional roles will assist with navigation, the working group
does not feel the need to add an explicit navigation-related success
criterion requiring these roles, since they are already covered by SC
1.3.1. The current success criteria do not preclude the use of
navigational roles to improve the accessibility, and some of the
techniques for these success criteria depend upon the availability of
reliable role information.


----------------------------------------------------------
Comment 5:

Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1
(Issue ID: LC-610)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

Terms in the document often seem to mean something a bit different,
until you read the definitions. As WCAG is often quoted the terms
themselves should be as close to clear language as the can be without
viewing the definitions.

Proposed Change:

change the term "programticly determined", to "supported by Assistive
technology".

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

We have struggled to make the concept of "programmatically determined"
and other terms used in the document as clear as possible.
Unfortunately, "supported by assistive technology" captures only part
of the meaning of programmatically determined. The author must also
have provided the data in a form that makes information and
relationships clear by using appropriate markup within the technology.

Note that the definition of programmatically determined has been
amended to say "including assistive technology."

----------------------------------------------------------
Comment 6:

Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1
(Issue ID: LC-612)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

Adaptive interfaces are a good thing. sometimes change is because we
know more about what the user likes

Proposed Change:

change the wording
...occur in the same relative order each time they are repeated,
unless a change is initiated by the user or may  benifit the user

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

This success criterion applies to the logical order and default
presentation of the content. This success criterion does not prohibit
choices in adaptive interfaces; enabling adaptive interfaces and
alternate presentations is a goal of WCAG2. However, the user still
needs to initiate the change in order, even if the change is initiated
by global actions such as selecting preferences in a user agent or
using a user agent with adaptive behavior. We have added this
explanation to the Intent Section of the How To Meet document.


----------------------------------------------------------
Comment 7:

Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1
(Issue ID: LC-613)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

To get to CR (candidate recommendation we believe two things are required.
1, Concrete checkpoints or list of requirements
2, Tests that completion of the minimum requirements of  success
criteria at each level will make sites  progressively usable for
people with disabilities listed in the overview.

Proposed Change:

Create a list of "what to do" checkpoint

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

We have released the Quick Reference document
(http://www.w3.org/WAI/WCAG20/quickref/) which provides a compact list
of the success criteria (the checklist items for WCAG 2.0) with the
techniques that are sufficient listed directly beneath them.  Each
technique has a test that can be used to confirm implementation.

If you mean that we need a checklist for getting to CR, there is a
list of things that must be met in W3C Process Document.

With regard to your second point, this type of testing is beyond what
can be done in CR.  This would be an interesting research project but
would require considerable funding.

----------------------------------------------------------
Comment 8:

Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1
(Issue ID: LC-614)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

Level 3 success criteria:
1. Achieve additional accessibility enhancements.
2. Can not necessarily be applied to all Web content.

I object to definition. Because many criteria are level 3 only because
they are considered too hard to do on all web content does not mean
that level 1 and two achieve minimal and enhanced accessibility.
Level 3 is also minimal accessibility

Proposed Change:

change of wording
Level 3 success criteria:

1. Achieve minimal accessibility, or, if the Success criteria can be
applied to all Web content, achieves additional accessibility
enhancements.
2. Can not necessarily be applied to all Web content.

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

We have completely rewritten this section of the guidelines (see
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ):

The word "levels" does not mean that some success criteria are more
important than others. Each success criterion in WCAG 2.0 is essential
to some users, and the levels build upon each other. However, even
content that conforms at AAA (triple-A) may not be fully accessible to
every person with a disability.

*In general, Level A success criteria achieve accessibility by
supporting assistive technology while putting the fewest possible
limits on presentation. Thus people with a wide range of disabilities
using a wide range of assistive technologies, from voice input and
eye-tracking devices to screen readers and screen magnifiers, are able
to access content in different ways. In other words, Level A success
criteria support the ability of both mainstream and specialized user
agents to adapt content to formats that meet their users' needs.

*The success criteria in Level AA provide additional support for
assistive technology. At the same time, they also support direct
access to content by the many people who use conventional user agents
without assistive technology. In general, Level AA success criteria
place more limits on visual presentation and other aspects of content
than the success criteria in Level A.

*Level AAA success criteria increase both direct access and access
through assistive technology. They place tighter limits on both
presentation and content.

----------------------------------------------------------
Comment 9:

Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1
(Issue ID: LC-615)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

The claim in http://www.w3.org/TR/WCAG20/Overview.html learning
difficulties, cognitive limitations,

However the checkpoints towards understandability  even at level 3
addresses only secondary education level  in other word usable for
mainstream people without these disabilities. The basic mechanism for
simplifications have not been included, or use of symbols or
conversion to symbols. Also left out are use for controlled languages

The result: I read a lot of complex specification. I am even writing
W3C specifications, but WXAG is the only on that I can not follow
though because of my disability. I can understand the concepts, but
the presentation requires remembering  what technique 3.1.3 was for,
and then (if I forgot what 3.2.3 stood for, going back to the original
guidelines finding it, hopefully not confusing it with 1..3.2 etc 
why because WCAG are following there own specifications, so I, as a
person with a disability, can not use their material.

to say "this document contains principles, guidelines, and success
criteria that define and explain the requirements for making Web-based
information and applications accessible" and to include learning
difficulties, cognitive limitations is an insult to anyone with
learning memory or cognitive impairments. there are many clear sets of
guidelines that do that. WCAG is not one of them.

Proposed Change:

Practical proposal  state clearly that learning difficulties,
cognitive limitations are not fully addressed beyond a very limited
way. Then work on a extended guideline, be it optional and untestable,
success criteria that does the job.

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

We have added language to the Introduction, the Conformance section,
and the Quick Reference to highlight the fact that WCAG 2 only
addresses some of the needs of people with cognitive, learning, and
language disabilities, and to call out the need for more research in
this area. WAI is exploring ways in which to support and encourage
work in this important area.

We have added some best practices for cognitive, learning, and
language disabilities as advisory techniques, and we have proposed 3
new success criteria in this area.

----------------------------------------------------------
Comment 10:

Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1
(Issue ID: LC-616)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

1. Identifying changes in natural languages USING a
technology-specific technique listed below AND Identifying text
direction of passages and phrases USING a technology-specific
technique listed below (for a technology in your baseline)

The example is an odd one because always, when changing direction, you
are changing characters and there for  it is, by definition
programticly determined

More over bILI languages change direction all the times whenever
numbers are used. Are you really expecting each number to be in it's
own span? Why not follow the standard BILI algorithms

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

Based on comments from the Internationalization Working Group, we have
determined that text direction is not an accessibility issue unless it
affects the meaningful sequence of text. SC 3.1.2 no longer requires
that the direction of text be identified.
Received on Thursday, 17 May 2007 23:40:43 UTC

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