FW: [2.4] Summary of issues for guideline 2.4

Hello,

This is Yvette's issue summary for Guideline 2.4.

Although I show it as having been sent to the list several hours ago, it hasn't appeared in the archive yet, so I'm passing it along to ensure that everyone has a chance to read it ahead of tomorrow's call.

The text of the summary is in the body of the message, and an HTML version is attached.

John

"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 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Yvette Hoitink
Sent: Wednesday, April 20, 2005 3:19 AM
To: w3c-wai-gl@w3.org
Subject: [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