W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2005

GL 3.2 - Proposals for resolving 10 issues

From: Andi Snow-Weaver <andisnow@us.ibm.com>
Date: Tue, 16 Aug 2005 16:32:23 -0500
To: w3c-wai-gl@w3.org
Message-ID: <OF5236D0FA.20AC9172-ON8625705F.0075A156-8625705F.0076524C@us.ibm.com>


There are currently 18 issues open on guideline 3.2. [1] I have proposals
for resolving 10 of them.

514 [2] and 742 [3] - both have issues with example 2
Recommend removing example 2 as it is about warning users before opening a
new window. This example no longer illustrates any of the success criteria.

514 [2] and 707 [4] - both have issues with example 3. As currently worded,
the example is not complete. It describes a problem but is not a conforming
example.
The example can be reworded as a solution "Frames are included in the page
history so that the browser's Back button can be used to return to a
previous frame."
But this doesn't really illustrate any of our current success criteria.
Recommend removing example 3.

767 [5] - contains 10 items. Some are resolved and some are not. See the
issue for a description of the ones that are resolved. Proposals for
remaining unresolved items:

<Note, list item numbers correspond do the numbers in issue 767>

4.) use headers consistently
This is technology specific.
Recommend that it be included as a technique for Level 2 SC 4 Components
that have the same functionality in multiple delivery
units within a set of delivery units are labeled consistently.

5.) use templates for consistent presentation of sections or whole site
Recommend reject.
This seems like a process recommendation rather than a design or
implementation recommendation.

7.) controls that look or sound the same should be designed to act the same
Recommend reject.
We have the converse of this - same functionality should be labeled
consistently - but nothing about things that have similar
appearance performing the same function.
We discussed the scenario of a traffic light performing different function
depending on the context of the Web application. So we determined that we
do not want to require that controls that look or sound the same always
perform the same function.

8.) conventions likely to be familiar to the user should be followed
Recommend reject.
This is a good usability recommendation but there is not a unique issue
here for users with disabilities.

9.) unusual user interface features or behaviors that are likely to confuse
the first-time user should be described to the user before they are
encountered
Recommend reject.
Not testable as written - "unusual user interface features"

10.) allow the user to select different page layout templates for
presentation of pages. (e.g. 3 column, linear, adding extra orientation or
navigation elements, etc.)
Recommend reject.
This doesn't seem to be applicable to GL 3.2 which is about predictable
placement and functionality of content. This is about allowing the user to
choose from several options for viewing the content.
This seems like a good usability "feature" but out of scope for
accessibility guidelines.

<end of 767>

844 [6] - proposes to move a Level 3 success criteria to Level 2. The issue
is referring to a Level 3 success criteria that no longer exists. It was
"There are no extreme changes of context."  The rationale states that this
is equivalent to WCAG 1.0 checkpoint 10.1 which is priority 2. Since this
success criteria no longer exists in the draft, this is overcome by events.
Recommend reject. We said WCAG would require that changes of context such
as opening a new window are to be programmatically determined and it is a
UA requirement to warn the user or allow them to disable the opening of new
windows.

1338 [7] - benefits needs to be reworked - some don't match the SC anymore.
Recommend replacing the current benefits with the following:
- Ensuring that changes of context can be programmatically determined
allows user agents to provide warnings to users that they are about to
occur or support settings that allow users to disable them.
- Users expect user agents to change the context (that is, load a new page)
whenever they select a link or a submit button. They can be surprised and
confused, however, if the context changes when they are simply navigating
through the Web page or changing the setting of a form field. The surprise
and confusion is more severe for users who are blind and can't see that a
new page is loading but simply hear their screen reader suddenly start
reading an entirely new page. The surprise and confusion can also be more
severe for users with learning disabilities. Avoiding these types of
unexpected changes in context reduces such surprise and confusion.
- Ensuring that repeated components occur in the same order on each page of
a site helps users become comfortable that they will able to predict where
they can find things on each page. This helps users with learning
disabilties and also those who are blind.

1414 [8] - issue with example 1. Suggest changing example 1 to something
that illustrates how a user agent would warn the user when a new window is
being opened.
A talking Web browser provides an audio tone when it determines that a new
window is being opened.

1436 [9] - proposes that all Web sites should use the same user interface
paradigm
Recommend reject - this is a general usability issue and is out of scope
for accessibility guidelines.

1461 [10] - proposes that there be generally accepted standards for design,
font, and format that would make it easy to categorize the "type" of
content, such as news, entertainment, education, etc. on quick inspection.
Reommend reject - this is out of scope for accessibility guidelines

1529 [11] - proposes an example that recommends a "close window" link be
provided on all popups.
Recommend reject - this is good usability information but out of scope of
the current success criteria.

[1]
http://trace.wisc.edu/bugzilla_wcag/issuereports/consistent-behavior_issues.php
[2] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=514
[3] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=742
[4] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=707
[5] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=767
[6] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=844
[7] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1338
[8] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1414
[9] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1436
[10] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1461
[11] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1529

Andi
Received on Tuesday, 16 August 2005 21:32:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:39 GMT