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

Updated survey of open issues for 2.4

From: John M Slatin <john_slatin@austin.utexas.edu>
Date: Mon, 12 Dec 2005 09:41:24 -0600
Message-ID: <6EED8F7006A883459D4818686BCE3B3B02A995CC@MAIL01.austin.utexas.edu>
To: <w3c-wai-gl@w3.org>
Thanks very much to Diane for getting this issue summary started.

This updated issue summary addresses all open and pending issues that
had been logged as of 11 December 2005 (i.e., it includes a few comments
logged against the 23 November 2005 draft).

I've provided a simple listing of issue numbers grouped into several
categories, followed by more detailed summaries and recommendations. A
separate document in .RTF format is attached. 


Issues that can be closed without further action
1516, 1647, 1648, 1650, 1651, 1742, 1777,510, 808,946, 948, 1130, 1136,
1319, 1391, 1442, 1503, 1720
Issues that can be closed after creating techniques
1132, 955, 1131,  1709, 
Issues that can be closed after editing benefits or 
examples
1563 (unless 2.4.1 is deleted, in which case no action), 1131, 1390,
1710, 1715 (unless 2.4.1 is deleted, in which case no action), 
Issues that may be closed after editing or adding a definition
1649, 
Issues that may require changing a success criterion or its level
1646, 1708, 1741,1769, 1770,1214,  
Bookkeeping errors (issues logged against wrong GL or SC)
1653, 1654, 
Open issues
Issue 1132. Provide a progressive complexity for both site and page
content, so that people with different abilities may be able to obtain
information from the same site
Reviewer advocates a SC requiring 
That complex content be navigable in stages, allowing users to progress
from simpler through more complex presentations of content.
This issue is partially addressed by 3.1.5 requirements for text summary
or graphical illustrations for content that requires reading ability
more advanced than lower secondary education, and is also partially
addressed by the first Optional (advisory) technique for 3.1.5 ("*
Providing text for navigational and landing pages which requires reading
ability that is less advanced than the lower secondary education
level."). The sufficient general technique "* Providing a text summary
that requires reading ability less advanced than lower secondary
education level" Also discusses the idea of "stepping up" to complexity
as opposed to "dumbing down" content.

On 8 December 2005 the WG approved an optional (advisory) technique for
including a short summary of each page in metadata as well as an
additional optional (advisory) technique for making the metadata summary
human-viewable. The WG agreed that neither technique is sufficient in
itself to satisfy the success criterion.

Recommendation
1.	Transfer issue to SC 3.1.5
2.	Create an optional (advisory) general technique about making
content progressively more complex; possible titles might be "Building
toward complex content" or "Front-loading content." This technique could
be separated out from its current location in the general technique on
Providing a text summary.
When the WG approves the new technique, close the issue  with the
following comment: "The Working Group has approved an optional
(advisory) general technique on 'Building toward complex content' and an
optional (advisory) general technique for including a short summary of
each page in metadata;  an additional optional (advisory) technique for
making the metadata summary human-viewable has also been created. These
techniques are listed in 'How to Meet SC 3.1.5.' The techniques are
defined as optional (advisory) because they go beyond what is required
by SC 3.1.5, but are not sufficient in themselves to satisfy the success
criterion."
Issue 1516. 3.2 L2 SC6 - proposed revision
This refers to a proposed rewrite for what used to be a 3.2 success
criterion (the proposed rewrite came out of the Baseline Impact analysis
in spring 2005). The issue is now addressed under SC 2.4.4 and 2.4.5.
Recommendation: Close with comment: "This issue is addressed in the 23
November 2005 draft by SC 2.4.4 and 2.4.5."
Issue 1563. Definition of navigational features contains examples that
don't meet the definition
The comments in this issue note that all three examples for GL 2.4.1
actually describe perceivable structures within the content (GL 1.3.1)
rather than "navigational mechanisms" (new term that replaced
"navigational features" as of 1 December 2005).
Recommendation: Leave the issue open pending decision on issue #1646. If
the recommendation to delete 2.4.1 is accepted, close with comment:
"That success criterion has been removed from WCAG 2.0." If the group
decides to retain SC 2.4.1, then assign someone to create new examples
that illustrate the intent of the SC.
Issue 1646. 2.4 L1 SC1 This criterion is entirely redundant
Greg Lowney writes that SC 2.4.1 is redundant because it's covered by SC
1.3.1 and  SC 4.1.2 (as agreed 1 December 2005; was 4.2.3).

I'm inclined to agree-we've already accepted that SC 1.3.1 covers
perceivable structures (e.g., headings) that also support navigation,
and SC 4.1.2 would appear to cover other interface controls within the
content.

Recommendation:
1.	Accept the comment and delete SC 2.4.1.
2.	Add the content of the Intent section for 2.4.1 to the Intent
section for 4.1.2 (to record the intent to make sure that navigational
mechanisms beyond those provided by structure can be programmatically
determined.
Issue 1647. 2.4 L2 SC1 no criteria that recommend providing ways for
locating content
The reviewer argues that there are no SC requiring more than one way to
locate content within a single delivery unit (for example, a table of
contents or search function within a very long page).

The SC as written applies only to "sets of delivery units." How to Meet
SC 2.4.2 lists providing a table of contents and providing a search
function among the sufficient techniques (more than one technique must
be implemented to meet the SC). 

Earlier Working Drafts included an SC requiring a Table of Contents or
other mechanism for long documents. However, the WG was unable to reach
consensus about how to determine when a document would be "long" enough
to trigger the requirement; there was also concern that the that wording
could not generalize beyond text documents.

Recommendation: Close with the following comment:  "Earlier Working
Drafts included an SC requiring a Table of Contents or other mechanism
for long documents. However, the WG was unable to reach consensus about
how to determine when a document would be "long" enough to trigger the
requirement. There was also concern that the earlier wording could not
generalize beyond text documents."

Issue 1648. 2.4 L2 SC2 most DVDs fail this
The reviewer asks if SC 2.4.3  should include an exception for blocks of
content that are required for legal reasons, such as copyright notices
or other disclaimers (he notes that DVDs don't allow the viewer to skip
copyright warnings, etc.).

Widespread practice is to include links to various legal notices and
disclaimers  on pages as necessary (see, for example, the footer at
http://www.utexas.edu and on many corporate Web sites). Procedures for
downloading content over the Web often include a step which requires the
user to accept licensing terms, etc. But the existence of such
conventions does not mean that WCAG should make an exception.
Recommendation: Reject and close with the following comment: "Such
exceptions are a policy issue beyond the scope of WCAG 2.0."
Issue 1649. 2.4 L2 SC4 The term "programmatic reference" is used but not
defined
Reviewer notes that there is no Glossary definition for the term
"programmatic reference" as used in SC 2.4.5, and offers a suggestion as
to how the term is being used.
Recommendations:
1.	Accept the following definition for 'programmatic reference'":
"functional component, such as a link or control, which causes a change
of context when activated"
2.	Close with the following comment: "A definition of 'programmatic
reference' has been added to the WCAG 2.0 Glossary."

Issue 1650. 2.4 L2 SC4 The goal of this criterion is unclear
This issue applies to an earlier version of what is now SC 2.4.5. The
earlier wording required that the destination for any programmatic
reference to another delivery unit could be programmatically determined,
and the reviewer was concerned that this was not enough to ensure that
information about the destination would be available to the user. 
Recommendation: Close with the following comment: "Addressed by SC 2.4.5
as defined in the 23 November 2005 draft."
Issue 1651. 2.4 L3 SC2 This is pretty vague
The reviewer asks what kind of information would be required to comply
with SC 2.4.8.
Recommendation: Close with the following comment: "This issue is
addressed in 'How to Meet SC 2.4.8."
Issue 1653. 2.4 L2 SC1 you'll have to reword this
The reviewer notes that  content designed for audio-only output doesn't
normally include error messages in text.
This issue should be logged against SC 2.5.1. 
Recommendation: transfer issue to SC 2.5.1
Issue 1654. 2.4 L2 SC3 unclear in a number of areas
The reviewer suggests that the list of triggers for SC 2.5.3 is
arbitrary-e.e., why are changes to a remote databse more serious than
changes to a local database?
This issue should be logged against SC 2.5.3.
Recommendations:
1.	Consider deleting the word "remote" from SC 2.5.3
2.	Transfer this issue to SC 2.5.3
Issue 1708. "without invalidating the activity" could be used in Level 2
SC 1
This issue proposes alternative wording for SC 2.4.2. The proposed
wording seems easier to understand than our current wording.
<proposed>
More than  one way is available to locate content within a set of
delivery units except where non-sequential navigation would change the
intended outcome of an activity.
</proposed>

<current>
2.4.2 More than one way is available to locate content within a set of
delivery units
where content is not the result of, or a step in, a process or task..
</current>
Recommendation: Accept the proposed wording for 2.4.2.  Close with the
following comment: "The alternative wording you suggested has been
incorporated in SC 2.4.2."
Issue 1741. GL 2.4 L2 SC 1 - A single way of locating content might be
sufficient
The reviewer is concerned that requiring multiple ways to locate content
may be both unnecessary and counterproductive for small pages that may
contain aggregated content. For example, it "would be silly" to require
multiple ways of locating content for a page that contains only one
paragraph where each sentence is provided by a separate delivery unit.
In such a case, users would likely not perceive themselves as trying to
locate content "within a set of delivery units." That is, users would
likely encounter the paragraph as part  of a single perceivable unit,
and would not be aware that more than one delivery unit was involved.
The SC should not apply. 
Recommendation:
1.	Consider replacing "set of delivery units" with "set of
perceivable units."
a.	Close with the following comment: "This issue has been addressed
by revising SC 2.4.2 so that it applies to sets of perceivable units."
b.	Or
2.	Close with the  following comment: "SC 2.4.2 applies only to
sets of delivery units. Users would experience the content as a single
perceivable unit."
Issue 1742. GL 2.4 L2 SC 4
This issue applies to what is now SC 2.4.5. Like issue 1650, the
reviewer is concerned that information about the destination of
programmatic references to other delivery units may not be accessible if
only required to be "programmatically determined." This issue is also
addressed by the 23 November 2005 draft.
Recommendation: Close with the following comment: "This issue is
addressed by the 23 November 2005 draft, SC 2.4.5."
Issue 1769. Labels should be descriptive, too.
Reviewer suggests that SC 2.4.6 be revised to include labels as well as
titles and headings. This concern does not appear to be fully covered by
GL 1.1 or 4.1.
Recommendation: Accept proposed wording for SC 2.4.6:
<proposed>
Titles, headings, and labels are descriptive.
</proposed>
Issue 1770. Remove reference to "page" in SC 2.4.7
Reviewer notes that the reference to "page or other delivery unit" in SC
2.4.7 is redundant. The SC should refer only to "delivery unit"
Recommendation: Accept the suggestion and delete the phrase "page or
other" from SC 2.4.7. The proposed SC would read as follows:
<proposed>
2.4.7 When  a delivery unit is navigated sequentially, elements receive
focus in an order that follows relationships and sequences in the
content.
</proposed>
Issue 1777. How do SC for sets of delivery units apply to only single
delivery unit conformance claims?
The reviewer raises the general question of how SC written for multiple
delivery units apply to content that consists of only one delivery unit.
For example, he suggests new wording for SC 2.4.8 that he feels would
address the issue.
The proposed SC  reads as follows:
<proposed>
If the content consists of a set of delivery units, information about
the
user's location in this set is available in each delivery unit.
</proposed

The reviewer goes on to say that we "could then define content as
whatever is in the scope of a conformance claim."
Recommendation: Reject with the following comment: Content consisting of
a single delivery unit is covered by SC 2.4.4 and 2.4.6, which require
that delivery units have titles and that such titles are descriptive."
Pending issues
Issue 510 Bicycle example was confusing
Wendy's comment (#4 in Bugzilla) says the example was deleted from the
WIKI, so it's OBE.
Recommendation: Close with the following comment: "The example does not
appear in the 23 November 2005 draft."
Issue 808 Benefits rewording proposal
The issue is about the benefits of navigation by heading and whether (a)
to list benefits separately for users with low vision and physical
disabilities, and b) whether to say that only AT users can get these
benefits.

OBE. SC 2.4.1 concerns only navigational mechanisms beyond structures
such as headings. However, we should make sure that the benefits of
navigation by headings are identified for SC 1.3.1.

Recommendation: Close with the following comment: "Navigation by
headings is addressed under SC 1.3.1."
Issue 946. Needs examples to understand success criteria for 2.4
Reviewer requested examples for SC under GL 2.4. Examples are being
provided in the How to Meet docs.
Recommendation: Close with the following comment: "Examples are provided
in "How to Meet..." documents for 2.4 SC."
Issue 948. User agent should determine voice style in Example 5
Comment concerned wording of an example.
Recommendation: Close with the following comment: "This issue is
addressed in the 23 November 2005 drafts."
Issue 955. TOCs should include information about presentation 
Modes
This comment, dating back to 2003, suggests that tables of contents and
site maps (such as those provided to meet SC 2.4.2) should include
information about the presentation modality of the content on each page.
Recommendation:
1.	Add an optional (advisory) technique, "Including information
about presentation modes in tables of contents, site maps, etc." for SC
2.4.2
2.	Close with the following comment: "Addressed under Optional
(advisory) techniques for SC 2.4.2."
Issue 1130. Add clear in-page link such as "skip-to-content" near the
top of the page (as some Web developers already do)
Reviewer advocates explicit  "skip" links at (or as close as possible
to) the top of each page that go to "important content," including
fullsentences, etc. This goes beyond SC 2.4.3, which requires only that
it be possible to skip repeated blocks of material.
Two previous issue summaries have suggested that the WG consider adding
an Level 3 SC. However, Wendy suggests that other conformance with other
SC will give user agents enough information to accomplish this.
Recommendation: 
Close with the following comment: "as long as authors accomplish the
existing SC, user agents can provide the desired functionality."

Issue 1131. Consider the number, location and focus of links on a page
Reviewer advocates the following: (1) maximum of 10-12 links per page;
(2) placing all links at end of sentences or, preferably, in lists; (3)
distinguishing clearly between in-page and external links
Recommendation:
1.	Create optional (advisory) general techniques for GL 2.4, about
"Limiting the number of links per page" and "Grouping links into lists"
(we may already have general techniques for grouping links, and there's
also an HTML technique)
2.	Add benefits:
a.	People who use alternative augmentative communication devices or
screen readers benefit when the number of links per page is kept to a
minimum
b.	People with intellectual and learning disabilities as well as
people who use screen readers may benefit  when links are grouped into
lists
c.	

Issue 1136. reduce the number of links, identify genuine and necessary
links
This comment advocates SC addressing information architecture. 

Some of the specifics are beyond the scope of WCAG; others are addressed
in existing SC.
Recommendation:
Close with the following comment:
"SC under Guideline 3.2 address the concern for a consistent navigation
scheme.  Issues about clarifying the information hierarchy are addressed
by SC 1.3.1 and 2.4.2.  The need for informative page titles is
addressed by 2.4.4 and 2.4.6.  The Working Group feels that requiring a
link from each page to the home page is beyond the scope of WCAG."
Issue 1214. 2.4: 1194.22-like SC should be level 1
Reviewer advocates that we move SC 2.4.3 (and any other  L2 or L3 SC
that resemble US Section 508 requirements) to L1 in order to harmonize.
Recommendation:
Leave this issue open. Take into active account in any discussion of
reordering SC/changing levels.
Issue 1319. We need a SC about labelling referenced units
Calls for a requirement addressing frame titles and other programmatic
references to delivery units.
Recommendation:
Close with the following comment: "Addressed by SC 2.4.5."
Issue 1390. GL2.4, SC L2 is not sufficient
This issue concerns the findability of content itself (e.g., the quality
of metadata, etc.). Yvette argues that this qualititative concern is not
testable and recommends creating one or more examples to illustrate good
practice.

Recommendation:
Add an example to 2.4.2 illustrating how good metadata supports
search.1. 
Close with the following comment: "'How to Meet SC 2.4.2 includes an
example illustrating how metadata can be used to support findability."
Issue 1391. content sequence SC too vague
The reviewer feels that the SC about "content sequence" is vague. I
can't tell for sure whether she's referring to 2.4.7 (when content is
navigated sequentially) or 1.3.5 (When content is arranged in a sequence
that affects its meaning...". If it's 2.4.7, the issue is addressed by
the example in How to Meet 2.4.7. If it's 1.3.5, the issue is again
addressed in the examples. So the recommendation is the same either way.
Recommendation:
Close with the following comment: "This issue is addressed by examples
in Understanding WCAG 2.0."
Issue 1442. GL 3.2, Level 2, Point 6 should be this specific
I think this one is OBE. It refers to GL 3.2 L3 SC6, which no longer
exists. Wendy's comment in Bugzilla says that the concern should be
addressed by How to Meet SC 2.4.5.
Recommendation: 
Close with the following comment: "Addressed by How to Meet SC 2.4.5."
Issue 1503. 2.4 L2 SC1 - proposed wording
This issue was logged following the baseline impact analysis on
rewording SC as functional outcomes (spring 2005).
Recommendation:
Close with the following comment: "Addressed by 30 June and 23 November
2005 drafts."

Issue 1709. L2 SC 2 might also include refs to bypassing large blocks of
data
The reviewer suggests that large blocks of data such as data tables and
links to all the letters of the alphabet should be included under 2.4.3.
Recommendation:
1.	Close with the following comment: "Data tables are addressed
under SC 1.3.1. Some user agents explicitly allow users to jump over
tables. Others provide typeahead functionality that can be used for the
same purpose. 
2.	Consider a link to techniques about grouping  links under
optional (advisory) techniques for 2.4.3.
Issue 1710. benefit needs clarification
Reviewer was concerned about the wording of a benefit saying that users
with cognitive disabilities might prefer to "ask" for the content they
are interested in. The benefit has been reworded and no longer includes
the wording in question. However, the benefit still needs attention-how
SC 2.4.2 benefits different groups of users should be indicated in
multiple bullets instead of one (fairly long) paragraph.
Recommendation:
Modify the benefit (editorial) and close the issue with the following
comment: "Addressed in the Benefits section of How to Meet SC 2.4.2."
Issue 1715. examples of how to satisfy success criterion 1?
The reviewer asks for examples and techniques for SC 2.4.1. The current
examples in How to Meet SC 2.4.1 all relate to navigating by structure
(i.e., SC 1.3.1).
Recommendation:
Either (a) leave the issue open pending creating of more appropriate
examples or (b) close the issue as moot if the WG accepts the suggestion
to delete SC 2.4.1 (see issue #1646  above).
Issue 1720. "programmatically identified", may need to rephrase
Comment is concerned with an earlier draft that used the term
"programmatically identified" in GL 2.4 L2 SC1. 
Recommendation:
Close with the following comment: The term "programmatically identified"
is no longer used in WCAG 2.0.



"Good design is accessible design."

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 512-495-4524 
email jslatin@mail.utexas.edu 
Web http://www.utexas.edu/research/accessibility 



Received on Monday, 12 December 2005 15:42:15 GMT

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