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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
During the analysis of the impact of not setting a baseline assumption, it was found that the following SC need further exploration:
YPH: I propose to create an action item for someone to work on this.
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.
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.
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.
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.
City University/DRC had several comments about links.
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.
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:
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".
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.
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.
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.
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?
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.
This summary was written by Yvette Hoitink, April 2005
Contact: y.p.hoitink@heritas.nl
[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_issues.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