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

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

----------------------------------------------------------
Comment 1:

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

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

Comment (including rationale for proposed change):

Interfaces become inoperable when one of the following brake:

1. Each element or widget is marked with full and corrected semantics
that fully describes it's behavior  Note this is more then information
and  structure can be separated from presentation .This includes
creating enabled  javascripted widgets that the Assistive Technology
does not know what it is, what states are supported and how it maps to
the operating system API. If non exists (like a tree item that can
expand to a sub tree when you click on it) Then you may need to add a
technology, such as xforms, XHTML 2 Roles

2. The relationships between elements and groups are known. Again,
this is more then I see supported by navigation Success criteria. What
form element controls what AJAX operated section  is a good example of
a relationship

3. States, properties, and relationships are valid for each elements
behavior and are accessible via the DOM. For example if clicking on a
tree item makes it expand  or collapses, then it's state (such as
expanded) needs to be accessible via the  Document Object module Via
an attribute that can be understood by assistive technology..

4. There is an element having the correct input focus. This is
different to just being keyboard navigatable

Proposed Change:

Add success criteria at level 1 along the lines of:

1, The supported behavior of each element and widget can be
programaticaly determined.

2, The relationships between elements and groups of elements can be
programaticaly determined.

3, States, properties, and relationships are valid for each elements
behavior can be programaticaly determined.

4, There is consistently an element having the correct input focus.

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

The working group believes that your concerns for additional level A
success criteria have already been met with existing criteria. Success
criterion 4.1.2 covers the supported behavior of each element and the
states, properties and relationships of elements and requires that
they be programmatically determinable.   The relationships between
elements are covered by success criterion 1.3.1. Both of these are
level A success criterion.  For example, the pressed state of buttons
is not currently exposed by user agents to assistive technology.  In
addition, the lack of states and relationships does not block
accessibility today and the current success criteria do not block
future technology which provides additional role, state, and
relationship information.

We also do not believe that there should be a requirement for always
maintaining an element with input focus. For the bulk of content the
current focus mechanism is sufficient and allows page scrolling with
arrows and change of focus into the user agent address bar with no
interaction from the Web content author.

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

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

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

Comment (including rationale for proposed change):

Web units have titles, what is the advantage if the titles are not descriptive?

Proposed Change:

change to Web units have descriptive titles

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

We have changed SC 2.4.3 to "Web pages have descriptive titles" and
have also reflected this change in success criterion 2.4.5 and the
support documents for both success criteria.

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

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

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

Comment (including rationale for proposed change):

surely this only helps if titles are unique  -any objection to unique
should not apply at level 3

Proposed Change:

change to Web units have descriptive and unique titles

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

We have changed SC 2.4.3 to "Web pages have descriptive titles" and
have also reflected this change in success criterion 2.4.5 and the
support documents for both success criteria.

The success criterion does not require that titles be unique because
the working group is concerned that requiring uniqueness will lead to
titles that are not as descriptive and usable. It may be very
difficult to create titles that are descriptive, unique, and
reasonably short. For example, a Web page that generates titles
dynamically based on its content might need to include part of the
dynamic content in the title to ensure that it was unique.  We are
also concerned that authors may make titles unique mechanically, such
as by including a unique number in the title that is unrelated to the
content. For these reasons, although we encourage unique titles in the
techniques for this success criterion, we are not including uniqueness
in the success criterion itself.

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

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

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

Comment (including rationale for any proposed change):

sections of content need titles to be able to navigate through a page.
This is particularly true of many AJAX sites that  have multiple
regions. The regions of a page can change at different  rates due to
either user actions or asyncrones updates. The user may need to toggle
between form controls to results, and updates.

Even in simpler content  knowing that a table has a navigation
function is hugely usefully even when accessibility is not completely
broken.

Proposed Change:

Add level one success criteria
Blocks of content that become updated should be uniquely titled or
it's role can  be programaticaly determined

When multiple blocks of content in a web unit have the same role they
should be uniquely titles

Blocks of content that perform a common task should be titles or its
role can  be programaticaly determined

success criteria 2.4.1 is no longer needed

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

The WCAG WG did not create a success criterion specific to live
regions. However SC 4.1.2 was modified to require the general case
that roles, states, properties, and values be programmatically
determined.

In addition, the ability to navigate easily to such regions is an
important point and related to other needs as well. Therefore, we
created a new Level AAA success criterion in GL 2.4 "2.4.9 Section
Headings: Where content is organized into sections, the sections are
indicated with headings."

 Various ways of conforming to this success criterion would exist,
including the suggestion to provide headers for live regions as well
as any other meaningful section of content.   The technique on 'live
regions' is advisory at this time because the technology has not been
released yet.

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

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

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

Comment (including rationale for any proposed change):

2.4.6 When a Web unit or authored component is navigated sequentially,
components receive focus in an order that follows relationships and
sequences in the content. [How to meet 2.4.6]

this should be level 1 as it often completely brakes the user interface

Proposed Change:

move SC 2.4.6 to level 1

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

Because assistive technology cannot provide access to rerendered
content if this success criterion is not satisfied, it has been moved
to level A.

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

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

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

Comment (including rationale for any proposed change):

In the roles specification we now have a range widget, which means you
can state, in a programaticaly determined way what the max and min
values are.

That means that AT can give users the message any way they want -
including text, if they want. Surly this is better then requiring text

we also have in the adaptable states and properties module a required
attribute, (for situation B in the "how to understand this checkpoint)

Note this is all part of the WAI, and screen readers are working to
support it today...

Proposed Change:

change 2.5.1 to:  If an input error is detected, the nature of the
error  can be programaticaly determined or  identified and described
to the user in text.

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

This success criterion does not prevent the use of programmatic
information which can be used by AT or the user agent to identify and
provide error information. There must be some mechanism to provide the
error information to the user with all technologies in use today and
the requirement for text guarantees that.  Even when provided by the
AT or user agent rather than the content author, the information can
still be conveyed in some form of text to meet this requirement.
Thus, we don't see the requirement for text as being too restrictive.

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

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

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

Comment (including rationale for any proposed change):

2.5.2 If an input error is detected and suggestions for correction are
known and can be provided without jeopardizing the security or purpose
of the content, the suggestions are provided to the user.

With things like role attribute you can assign a functional role to an
element, and other important information such as allowable range. That
means that the assistive technology can themselves perform validation.
Makes it all a user agent thing...

Proposed Change:

2.5.2 If an input error is detected and suggestions for correction are
known and can be provided without jeopardizing the security or purpose
of the content, the suggestions are provided to the user or can be
progmaticly determined

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

The current success criterion does not prevent use of Dynamic Web
Content Accessibility, XForms or other technologies to provide
information that will allow user agents and assistive technologies to
provide suggestions for error correction.   We do not feel we need to
specifically add "programmatically determined" to the success
criterion, but such technology-specific techniques could be added as
sufficient as user-agent support for them improves. If role and
validation information is programmatically provided in the markup for
a technology and testing demonstrates that suggestions for error
correction are provided to the user via the user agent or assistive
technology, this success criterion has been satisfied. The
technology-specific techniques should be provided for such
technologies. We have provided some advisory techniques for the use of
WAI-ARIA and will promote them and will promote them as they qualify
as accessibility supported in some environments.

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

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

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

Comment (including rationale for any proposed change):

With things like role attribute you can assign a functional role to an
element, and other important information such as allowable range. That
means that the assistive technology can themselves perform validation.
We should also work on identifying critical tasks.

Hence one of the list should be (for future proofing) the role of all
information and it's critical nature can be progmaticly determined

Proposed Change:

1. Actions are reversible.
2. Actions are checked for input errors before going on to the next
step in the process.
3. The user is able to review and confirm or correct information
before submitting it.
4. The role of each control  and it's critical nature can be
progmaticly determined.

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

This success criterion is addressing the problem of users making
irreversible mistakes in the otherwise valid values provided or
actions taken. Indicating that a control is critical is not sufficient
to satisfy this success criterion. The user must still be given the
opportunity to avoid unrecoverable errors.

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

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

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

Comment (including rationale for any proposed change):

With things like role attribute and concept mapping with RDF you can
assign a functional role to an element, That means that the assistive
technology can themselves provide the correct help that is tailored to
the user. the user experience is better because the help is tailored
to their scenario

Proposed Change:

2.5.4 Context-sensitive help is available for text input or the role
of each control can be progmaticly determined

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

The current success criterion does not prevent use of Accessible Rich
Internet Application Specifications or other technologies to add
information that will allow user agents or assistive technologies to
provide context-sensitive help. We do not feel we need to specifically
add "programmatically determined" to the success criterion in order to
support this additional data, but we have added a placeholder for such
technology-specific techniques. If additional information is
programmatically provided in the markup and testing demonstrates that
context sensitive help is provided to the user via the user agent or
assistive technology, this success criterion has been satisfied.  The
technology-specific techniques should be provided for such
technologies.  We have provided some advisory techniques for the use
of WAI-ARIA and will promote them as they qualify as accessibility
supported in some environments.

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

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

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

Comment (including rationale for any proposed change):

Most of this (at least at the higher levels) helps blind folks access
error information. That is good. Clearly what is missing hear is a
game plan for helping people with a learning disability , who have
trouble filling in forms.

Forms are real nightmears for a lot of us. In fact I often do not
deposit checks and perform other tasks because of the barrier that
form filling presents.

Things that make it  harder include short labels that do not explain
what they are, coping numbers, Non expandable, small fonts. Too much
information on one  page. Information not being well grouped such as
user information, payment information. Then with the short labels I
get confused what is what. Server time outs. Asking a lot of
information to make forms simpler to process but make form filling
much harder and more complex.

For example  on this form on line it is much simpler (but PF preferred
this table .. oh well) .... the options could be in a combo box as
filled out meaningfully text...

Proposed Change:

Perform user testing with different groups of people with learning
disabilities and cognitive limitations - including age related.

Identify what technques help

Add them

----------------------------
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.

Received on Thursday, 17 May 2007 23:40:48 UTC