GL 1.3 Issues Summary

Here's the summary of the 15 open issues for GL 1.3

795 [1]

This is my issue. But I'm not sure how to solve it. Some would argue that
being able to identify the role of every element or component on a page is
critical at Level 1. I agree that it is important at Level 2 but we seem to
get by just fine on our mailing list without this for simple lists and
paragraphs. Sure, it gets tedious to wade through as the postings get
longer and longer but this is true for all of us, not just those of us who
are blind. How can we argue that this is critical at Level 1 when we don't
do it ourselves? Here are the "structural" things that I think are critical
at Level 1:

- people argue that headings are required at Level 1 with the rationale
that screen readers provide the ability to navigate from heading to
heading. I don't think we should use screen reader implementations as our
rationale. The rationale is that if you are doing something visually that
gives users a way to get an overview of the delivery unit, users with
disabilities need a way to get that same overview.
- row and column headers in data tables because there is an implied
relationship between components on the page based on their visual placement
that must be exposed programmatically for those who can't see the page.
- form field labels because it's the only way to unambiguously determine
which form field you are operating if you can't see the visual labels.
Again, there is an implied relationship between components on the page
based on their visual placement that must be exposed programmatically.
- nested lists. Is this a visual positioning thing too that needs to be
programmatically exposed? I can "perceive" a nested list because I can
"see" that it is indented under a particular list item in the parent list.

This issue could be resolved for IBM if we moved the current Level 1 SC
(Structures wihin the content can be programmatically determined) to Level
2 and added something like the following as Level 1 SC:

1. Components that are intended to provide a means for users to visually
skim the delivery unit for an overview can be programmatically determined.
2. Any visually implied relationship between components of a delivery unit
can be programmatically determined.

796 [2]

I recommend getting rid of the second benefit about aiding navigation since
this is in the "perceivable" section. And I don't see a benefit from this
guideline for people with motor or hearing disabilities. We could rewrite
the first and third benefit into one benefit to resolve this issue.
Something like:

Separating content and structure from presentation allows Web content to be
presented differently to meet the needs and constraints of people with
visual and cognitive disabilities. For example, information can be
presented via speech or braille (text) that was originally intended to be
presented visually.

827 [3]

Recommends adding a success criterion at level 2 that says "Presentation is
implemented separately from semantic structure."

Certainly, anyone creating a "new" Web site today in HTML should be using
CSS for presentation and HTML for semantics. But not all technologies
support this capability so it is too technology-specific to be required at
Level 2. And there are many legacy Web sites that don't use CSS but can be
made "accessible" without changing their whole infrastructure to be CSS
based. I could live with this at Level 3 but not at Level 2.

938 [4], 1088 [6], and 1350 [10]

938 refers to the editorial note that the examples are too HTML-specific.
1088 talks about adding an example where required form fields are indicated
in red with an asterisk. 1350 complains that example 1 suggests it is okay
to only flag mandatory fields after a form has been submitted. I recommend
the following as slight edits to the examples:

Example 1: A form that uses color and an asterisk to indicate required
fields.

A form contains both required and optional fields. Instructions at the top
of the form explain that required fields are labeled with red text and also
with an asterisk. Both the red text and the asterisk are programmatically
associated with the appropriate form fields so that screen reader users can
determine the required fields.

Example 2: A bus schedule table where the headers for each cell can be
programmatically determined

A bus schedule consists of a table with the bus stops listed vertically in
the first column and the different buses listed horizontally across the
first row. Each cell contains the time when the bus will be at that bus
stop. The bus stop and bus cells are identifed as headers for their
corresponding row or column so that a screen reader can programmatically
determine which bus and which bus stop are associated with the time in each
cell.

Example 3: A form where the labels for the checkboxes can be
programmatically determined

In a form, the labels for each checkbox can be programmatically determined
by a screen reader.

1036 [5]

I recommend we close this issue with a note back to Harvey explaining where
the blinking/flashing issue is covered. The mapping will also clarify this
for anyone trying to make the bridge from 1.0 to 2.0.

1145 [7]

JIS requests a Level 1 success  criterion about information required to
understand and operate a Web site not relying on shape or location alone. I
don't think this can be Level 1 because it requires a visible change to a
Web page. How about proposing something like this at Level 2?

Instructions for understanding or operating a delivery unit do not depend
on users' ability to perceive visual characteristics such as shape or
visual location of components.

1309 [8] and 1339 [9]

Issues with definition of programmatically determined. I recommend
proposing a slight modification to the definition of "programmatically
determined".

programmatically determined means that the specific value can be determined
by user agents and/or assistive technology in a standard form.

We should also propose that 1339 be closed as a dup of 1309.

1441 [11]

Issue was raised when reading order was part of GL 2.4. I think this was
resolved by moving this SC to GL 1.3 so I think we can recommend closing
this issue.

1705 [12]

Says there should be a clearer association between the examples and the
guideline. This should be resolved by the guide docs. I recommend closing
this issue.

1733 [13] and 1734 [14]

I recorded these issues but they are not from IBM. They came from Canada.
They question whether or not it is sufficient for the color to be
programmatically determined because a color-blind user is probably not
using assistive technology and will need another way to perceive
information that is conveyed by color. But we cannot require this at Level
1 and abide by our criteria that all Level 1 things can be done without
affecting the design of the page. I recommend closing this issue.

1735 [15]

Again - I recorded this issue from Canada. Questions whether the checkbox
is a good form control to use in example 3. I don't see a problem with it
and recommend closing this issue.

[1] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=795
[2] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=796
[3] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=827
[4] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=938
[5] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1036
[6] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1088
[7] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1145
[8] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1309
[9] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1339
[10] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1350
[11] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1441
[12] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1705
[13] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1733
[14] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1734
[15] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1735

Andi

Received on Sunday, 9 October 2005 15:38:57 UTC