[2.4] Summary of issues for guideline 2.4

==REPOST BECAUSE OF ARCHIVE PROBLEMS==

Issue summary guideline 2.4 (HTML version: see attachment)

** Introduction **

This document is meant to review guideline 2.4 and discuss the open issues
with this guideline. 

The current wording for 2.4 is: 

Provide mechanisms to help users find content, orient themselves within it,
and navigate through it. 

A previous summary of this guideline was made August 30, 2004 [1]. To
provide an overview of all the issues regarding this guideline, issues that
were discussed in the previous summary which have not been resolved since
then are discussed once more in this summary.

The current and proposed wordings are based on the November 19, 2004 working
draft [2]. Unless otherwise stated, the current wording is used. The issues
are taken from the issue report for 2.4 from WCAG Bugzilla [3].

My personal opinions are marked with my initials (YPH). 

** Issues that can be closed **

434. Why aren't navigation mechanims a core checkpoint? [4]

Since this comment was made, a level 1 SC has been added to 2.4. Also,
structure is required per guideline 1.3 level 1 SC1. I think this issue can
be closed after doublechecking with the original poster.

564. Not clear what "nav mechanism" checkpoint trying to address [6]

The U.S. Access Board writes: We have not provided feedback on this section
since it is unclear what the section is trying to address. However, from the
explanatory material, it seems that this guideline may be addressing
usability more than accessibility. 

YPH: This is the question of usability versus accessibility that pops up
more, see 'underlying issues'. The informative section of this guideline has
been enhanced since this issue was raised and several techniques for 2.4
have been developed since then. I think this issue can be closed after
checking back with the U.S. Access Board.

859. frames included in 2.4, level 3, item 4? [20]

The Aktionsbuendnis für barrierefreie Informationstechnik wants to know if
"each page or resource that can be accessed independently" refers to frames
as well. 

YPH: (Same as previous summary) This SC does apply to frames as well. This
explanation should not be in the guidelines themselves (which are
technology-independent) but is covered in the techniques document. I think
this would not have been a question if the techniques document had already
been linked. I propose to check with the ABI if they agree that this is
sufficiently covered by the HTML techniques document and if so, close this
issue.

1169. GL 2.4, L2 SC: why 8 or more links? [19]

Loretta Guarino Reid feels a reason of 8 is unclear.

YPH: The current version doesn't specify '8 or more' links anymore. I
propose to close this issue.

1394. Good structure can't be captured accurately [30]

Catherine Brys says: In the Level 3 Success Criteria for Guideline 2.4, the
guidelines are trying to pin down what 'good structure' is but I think this
is quite impossible to catch. A skilled (web) author should be able to
present information in a well-structured way. I don't think the guidelines
should try to cover this because it is impossible to do this accurately.

YPH: I think Catherine's argument is valid for the entire guidelines: you
can never completely define accessibility either, in the end it's up to the
skill of the author. Simply following guidelines isn't enough, you have to
know how to apply them. However, I think this group feels that producing
these guidelines, success criteria and techniques helps developers even if
it's not a 100% guaranteed recipe for an accessible website. I propose to
explain this to the original poster and then close this issue.

1395. GL 2.4 - all benefit, not just cognitively disabled [31]

Catherine Brys feels that the 'who benefits' section should be rewritten so
it's clear that everyone benefits from this guideline.

YPH: For many guidelines, people without disabilities benefit as well.
However, the rationale for these guidelines is the benefits for people with
disabilities. For this reason, I think we should explain the 'who benefits'
sections in terms of people with disabilities. I propose to explain this to
the original poster and then close this issue.

** Issues that might be closed after some small changes and/or discussion **

510. bicycle example was confusing [5]

The Kansas Web Accessibility Subcommittee thinks the bicycle example is
confusing at first and that it might be better to use examples from the
domain of web content because that is closer to our audience.

YPH: (same as previous summary) I think the good point about this example is
that it isn't HTML-specific. Images with structural relationships in them
are covered by the WCAG and this is a good guideline to cover that. I think
we should clarify the example to make sure it's understood that this is
referring to web content. I propose to explain this to the Kansas Web
Accessibility Subcommittee and to close this issue. 

676. 1.5 example 1 [7] 

Greg Lowney objects to the suggestion to make _subtle_ differences between
the appearance of titles and section headings.

YPH: (same as previous summary) I agree with Greg. I propose to delete the
word 'subtle' from the example and then close this issue. It would then
become:

Example 1: documentation for a product. 

Identifying chapters in the structure of a book is appropriate and accepted
use of labeling the structure. Within the chapters, headings identify
(label) changes in context and highlight ideas contained in the following
text. Differences between the appearance of the chapter title and the
section headings help the user understand the hierarchy and relationship
between the title and headings. The difference might be font size and margin
indentation when presented visually, and spoken in a different voice or
preceded by a sound when presented auditorily. 

808. Benefits rewording proposal [8]

Andi Snow-Weaver suggests that because jumping from header to header is
currently only possible in assistive technology, we combine the benefits for
physical and vision disabilities by saying " Assistive technology used by
people with physical and vision disabilities can provide users with the
ability to jump from header to header to get an overview or to more quickly
"skim" to the section they are interested in." 

YPH: (Same as previous summary) I like it when the 'who benefits' section
adresses the benefits for each type of disability separately. I agree with
Andi that we should make it clear that this will require assistive
technology in most of the cases. I propose to discuss this on the list and
then decide what to do about this example.

829. Linear reading order should be level 1 [9]

Michael Cooper proposed to move the linear reading order SC to level 1. 

YPH: There was no consensus to move the requirement to have a logical
reading order in a telecon on July, 2004. Since then, a lot of re-writing
has been done. The current phrasing is: "When content is arranged in a
sequence that affects its meaning, that sequence can be determined
programmatically". I think less people will have trouble with the current
wording being at level 1. I propose to re-vote on the level of this success
criterion and then close this issue.

946. Needs examples to understand success criteria for 2.4 [10]

James Craig wants examples for different level 3 succes criteria.

YPH: (Essentially the same as previous summary) 

I think this issue can be closed after the the existing examples are
clarified.

There is no example at the moment for "When content is arranged in a
sequence that affects its meaning, that sequence can be determined
programmatically". I propose to make an action item of this (I'm willing to
volunteer). 

Diagrams have an example: the data table. 

Reveiling non-hierarchical relationships are covered in the data table
example as well (I think the association of a header cell with a data cell
is a non-hierarchical relationship). 

James Craig also asks how a scalable image of a bicycle would be spoken by a
screen reader. If I understand it correctly, these relationships can only be
represented in SVG or similar technologies. I don't know how screen readers
interact with SVG. I propose to have someone from the SVG field find out and
answer back to James Craig, and perhaps help clarify this example.

948. User agent or content author should determine voice style in Example 5
[11]

James Craig feels that the example about a more formal voice for headers is
something that should be left to the user agents or content author and
suggests using "a discernibly different style" instead. 

YPH: I think this example was meant to show how the content author could use
auditory style sheets to make distinguish between different types of
content. I think the example should be re-written to make that clear.

Perhaps we can rewrite it in a similar way as example 1 does for the visual
differences:

Example 5: an audio presentation. 

A style sheet defines a different voice to read the headers. This difference
might be in pitch, volume or in tone, for example by using a louder, more
formal voice. This way, the listener can easily hear the difference between
a header and the main text.

I propose to vote on this new phrasing and then close this issue.

955. TOCs should include information about presentation modes [12]

RNID suggests that contents pages or navigation maps should also contain
information about presentation modes available in each area of the site that
they refer to. 

YPH: (same as previous summary) I don't think I fully understand this remark
and worry that we cannot formulate this in a way that our audience will
understand it either. This feels to me like something that is applicable to
a small number of websites only. Perhaps this can be incorporated in the
gateway techniques associated with creating TOCs or navigation maps.

I propose to discuss what to do with this item and then assign some action
items to create appropriate techniques.

1214. 2.4: 1194.22-like SC should be level 1 [21]

Loretta Guarino Reid feels that the skip-link requirement should be at level
1 to harmonize with section 508.

YPH: I propose to take a vote and decide what level this SC should be at.
Perhaps, we first need to find out how people feel about following the 508
levels in WCAG. 

1387. "find content" unclear [23]

Catherine Brys thinks the "Find content" in the description of the guideline
could be misinterpreted to mean search functionality.

YPH: I agree with Catharine. I propose someone take an action item to
re-formulate this.

1388. Don't repeat GL 1.3 SC in GL 2.4 [24] 

At the moment, the level 1 SC for 1.3 and 2.4 are the same: Structures and
relationships within the content can be programmatically determined.
Catherine Brys thinks we should delete the item at 2.4.

YPH: I propose we vote to either have it in 1.3 only, in 2.4 only or in
both.

1389. "document" not appropriate to web [25]

Catherine Brys is confused by the word 'document' and feels this doesn't
refer to web content.

YPH: I propose we either explain to Catherine Brys that online documents are
meant, reformulate the wording or include a definition for document.

1390. GL2.4, SC L2 is not sufficient [26]

Catherine Brys feels that just requiring two ways to get to content is not
sufficient. In many cases, the 'findability' of the page depends on the
quality of the metadata. 

YPH: I do not see how we can make this into a testable requirement. My
proposal is to keep the SC as it is but to include an extra example which
shows two or more ways to get to content, and to create general techniques
about how to use metadata effectively. 

1391. content sequence SC too vague [27]

Catherine Brys thinks the requirement "When content is arranged in a
sequence that affects its meaning, that sequence can be determined
programmatically." is too vague since sequence will always almost influence
meaning. 

YPH: I don't really see a problem with this, it just means that the "when"
part is almost always true, so you have to make sure the sequence can be
determined programatically almost allt he time. I propose to check if the
group feels the same way and then close this issue.

1392. what is structure for images? [28]

Catherine Brys wants to know what is meant by structure for images.

YPH: For people that are unfamiliar with SVG, this requirement would seem
very strange. I propose to expand the bike example (nr. 2) by explaining
that there are technologies which allow structural grouping of visual
objects. If we explain this to Catherine, I think we can close this issue.

1393. what does "paragraph" imply? [29]

Catherine Brys wonders if the word 'paragraph' refers to the logical
paragraphs or visual paragraphs. 

YPH: I think we just mean logical paragraphs, as you can never know how a
paragraph is rendered for a specific user. Perhaps we could add the word
'logical' to make this more clear. Also, I think the fact that we mean the
logical paragraphs will be clear from the techniques for this SC. I propose
to explain this to the original poster and then close this issue.

1503. 2.4 L2 SC1 - proposed wording [33]

New proposal for baseline-free wording: "Multiple navigation mechanisms are
available for collections of 5 or more delivery units."

YPH: I propose to vote on this new wording.

1504. 2.4 L2 SC2 - proposed wording change [34]

New proposal for baseline-free wording: Multiple ways to find specific
content within a set of delivery units are available.

YPH: I propose to vote on this new wording.

1505. 2.4 L2 SC3 - proposed wording change [35]

New proposal for baseline-free wording: Blocks of repeated material are
implemented so that they can be bypassed by people who use assistive
technology or who navigate via keyboard or keyboard interface.

YPH: I propose to vote on this new wording.

1506. 2.4 L3 SC2 - proposed wording change [36]

New proposal for baseline-free wording: When a delivery unit is navigated
sequentially, elements receive focus in an order that follows relationships
and sequences int he content 

YPH: I propose to vote on this new wording.

1508. 2.4 L3 SC 5&6 need further exploration re: baseline impact [38]

During the analysis of the impact of not setting a baseline assumption, it
was found that the following SC need further exploration:

Text is divided into paragraphs

Documents are divided into hierarchical sections and subsections that have
descriptive titles

YPH: I propose to create an action item for someone to work on this.

** Issues that may require additional success criteria **

1016. When to determine if a site map is needed [13]

Andy Budd writes that a site map should be required if you can't access
every page of the site from every other page of the site. 

YPH: The current wording does not address the need for a site map at all
anymore. John Slatin thinks it might be a good idea to require a site map
for a site of any size if and when it's true that you can't access every
page on the site directly from every page on the site. I propose to take a
vote during the telecon to include a success criterion that addresses this
and then make it an action item. The level of this new SC can be decided
when discussing the proposal. 

1130. Add clear in-page link such as "skip-to-content" near the top of the
page [14]

WWAAC propose to require a skip-to-content and skip-to-links links near the
top of the page.

YPH: As John Slatin wrote, the current re-write doesn't fully address this
point since it recognizes skiplinks as _a_ way to meet the guidelines and
not as the only way. It might be useful to require those explicit links at
level 3.

I propose to discuss adding another success criterion that requires explicit
links to the most important parts of the content. If the group feels this is
a good idea, we can make it into an action item to come up with a proposal.

1131. Consider the number, location and focus of links on a page [15]

WWAAC writes: It is suggested that the number of links on one page be
limited—a maximum number of links on a page should be agreed, but 10-12 is
recommended. Avoid the use of embedded links within text. Instead, encourage
the use of links at the end of sentences, or preferably use bullets or
numbered lists instead. In addition, distinguish between in-page links and
links to other pages. This will help to orientate the user and will make
browsing a list of links more effective and understandable.

YPH: We could create general techniques that incorporate these suggestions,
perhaps as optional techniques. However, at the moment, we do not have a
success criterion to link those techniques to. We might need a new success
criterion that requires links to be understandable (or something more
specific). This might belong under 3.1 instead.

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 Web site. [16]

WWAAC propose to 'front load' content with an easy to understand summary.
This would apply both to single pages and page collections. This would
facilitate page navigation with screen readers and make it easier for a
person skimming or browsing to get a simple overview of page content. 

YPH: This proposal benefits orientation, navigation and understandability. I
don't know whether this would belong with 2.4 or 3.1. Wherever it should go,
I think it would be a good level 3 success criterion. I propose to discuss
this and if the group agrees, assign an action item to make a proposal for
both the text and which guideline it should belong to. 

1136. reduce the number of links, identify genuine and necessary links [17]

City University/DRC had several comments about links. 

1. reduce the number of links and ensure that genuine and necessary links
are clearly identified as such 2. avoid site fragmentation: navigation
mechanisms should be consistent (eg in appearance and behaviour), the
relative importance of different sections (across the site and within pages)
should be apparent, mark-up languages should be used to indicate the
structure of pages 3. preserve links to the Home page 4. eradicate
excessively deep site structures; and ensure that page titles are
informative. 

YPH: Comment 1 is partly covered by issue 1131. The identification of
'necessary' links is not addressed in the current wording. I think it would
be hard to make this a testable requirement. I propose to discuss this in
the group and if the group feels the same way close that part of this issue.

The requirement to preserve a link to the homepage and to avoid deep site
structures are not addressed in the current wording. They might be
candidates for new success criteria. I propose to discuss this in the group.

The other suggestions are already covered by the current wording. I propose
to explain this to the original poster and then close that part of the
issue.

1137. Higher priority for need to divide blocks on info into manageable
units [18]

City University/DRC feels the need to divide blocks of information into more
manageable units should be given a higher priority.

YPH: I think we should take a vote on where what level this requirement
should go.

But I think the real problem is that we do not address the whole scope of
the problem. After the rewrites, the need to divide blocks of information is
addressed by two SC in 2.4 at level 3: 

Text is divided into paragraphs. 

Documents are divided into hierarchical sections and subsections that have
descriptive titles

I feel we might need a more generic version of "text is divided into
paragraphs" because the problem of too much content isn't limited to text.
For example: if you show a image with the architectural design of a house,
you do not want all the details like the measures of each window on the
overview image. You would want one overview image which displays the general
layout of the house, and then additional images for each room which lists
the details for each room. If we have a more general phrasing, "text is
divided into paragraphs' and 'documents are divided into hierarchical
sections and subsections' would then become general techniques for this
success criterion. The other part of the second SC would then become a
seperate item: "Sections and subsections of content have descriptive
titles". 

1319. We need a SC about labelling referenced units [22]

Yvette Hoitink feels we need a SC about identifying units that are
referenced, like the title-attribute on the frame-element in WCAG 1.

YPH: I propose to discuss this possible additional success criterion, if
people agree this is a good idea have someone take an action item to
formulate it and then decide where it should go.

** Issues that may require deleting success criteria **

1441. GL 2.4, Level 3 - agree no need for testing sequence intention [32]

Soren Hansson agrees with the editiorial note that is has no use to testing
whether the sequence matters or not. 

YPH: If the group feels that the sequence is already covered by 1.3, we
could delete this level 3 success criterion.

1507. 2.4 L3 SC3 - proposed deletion [37]

After the impact analysis of not setting a baseline, Ben Caldwell proposes
to delete the success criterion "Images have structure that users can
access"

YPH: I propose we take a vote on this.

** Issues that need serious discussion ("elephants") **

Overlap with guideline 1.3

YPH: As can be seen from the duplicate SC at level 1, there seems to be
major overlap with guideline 1.3. 

We need to decide what 2.4 is about. Is it about adding structure so people
can navigate? Is it about additional navigation mechanisms besides that
which you get when providing structure? What do we want to go in 1.3 and
what needs to be in 2.4?

** Rationale **

Navigation in content is disproportionately harder for people with certain
types of disabilities, so providing means to facilitate navigation increases
accessibility for people with disabilities. 

** Author **

This summary was written by Yvette Hoitink, April 2005
Contact: y.p.hoitink@heritas.nl 

** Notes **

[1]. http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0512.html
[2]. http://www.w3.org/TR/2004/WD-WCAG20-20041119/
[3].
http://trace.wisc.edu/bugzilla_wcag/issuereports/navigation-mechanisms_issue
s.php
[4]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=434
[5]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=510
[6]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=564
[7]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=676
[8]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=808
[9]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=859
[10]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=946
[11]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=948
[12]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=955
[13]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1016
[14]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1130
[15]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1131
[16]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1132
[17]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1136
[18]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1137
[19]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1169
[20]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=829
[21]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1214
[22]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1319
[23]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1387
[24]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1388
[25]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1389
[26]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1390
[27]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1391
[28]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1392
[29]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1393
[30]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1394
[31]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1395
[32]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1441
[33]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1503
[34]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1504
[35]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1505
[36]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1506
[37]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1507
[38]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1508