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

Re: [2.4] Summary of issues for guideline 2.4

From: Wendy Chisholm <wendy@w3.org>
Date: Thu, 21 Apr 2005 15:58:01 -0400
Message-ID: <426805C9.1070505@w3.org>
To: Yvette Hoitink <y.p.hoitink@heritas.nl>
Cc: w3c-wai-gl@w3.org

Hello Yvette,

Great summary!  Responses provided in-line.  Sorry I didn't get this out 
further before the call, however I hope this will be useful feedback to 
whoever takes the action items to further develop proposals for next week.

>** Issues that can be closed **
>  
>
Agree that issues 434, 564, 859, 1169, 1395

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

>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.
>  
>
I agree that we should discuss and assuming other people will have this 
concern, we could explain this in the intro of the document. e.g., 
modify  "Purpose" to read:
<current>
This document outlines design principles for creating accessible Web 
content. When these principles are ignored, individuals with 
disabilities may not be able to access the content at all, or they may 
be able to do so only with great difficulty. When these principles are 
employed, they also make Web content accessible to a variety of 
Web-enabled devices, such as phones, handheld devices, kiosks, network 
appliances. By making content accessible to a variety of devices, that 
content will also be accessible to people in a variety of situations.
</current>
<additional-paragraph>
Employing these guidelines does not guarantee that conforming content is 
accessible. However, it greatly increases the chances that the content 
will be accessible.  To truly determine if content accessible, the 
content should be tested by a variety of people with a variety of 
disabilities.
</additional-paragraph>

To avoid too much confusion or consternation this should be tweaked, but 
feel this basic idea could be expressed at this point in the document. I 
thought we already had wording to this effect but did not find it with a 
quick skim.

Also, I wonder if the following ought to be clarified:
"Designing Accessible Web Content

These guidelines provide the basic requirements for designing accessible 
Web content. This document is not designed to provide the background 
needed to learn about accessible Web design in a thorough or effective 
manner for those interested in learning. Readers are therefore referred 
to the Education and Outreach Working Group of the Web Accessibility 
Initiative."

>** 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. 
>
>  
>
Does the clarification in General Techniques accomplish this?
http://tinyurl.com/cv9sg

>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:
>  
>
sounds good to me.

>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.
>  
>
WAC: I propose to leave them as is, because the functionality is not 
limited to assistive technologies.  Opera provides a way to jump between 
headers (s and w keys) - http://www.opera.com/features/keyboard/index.dml.

>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.
>  
>
WAC: I support moving this to Level 1. Especially since this is an 
important aspect of making Web applications accessible.

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

>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.
>  
>
WAC: A better example may be a map based on the demo we received from 
John Gardner a while back which is based on his work described in this 
paper from CSUN (2001):
<http://www.csun.edu/cod/conf/2001/proceedings/0103gardner.htm>
or from his site:
<http://www.viewplus.com/products/software/IVEO>
minutes from linz meeting where john demoed his talking browser with an 
svg map - does *not* contain a good description of what the browser read 
or how he navigated two images (map of U.S., heart):
<http://www.w3.org/WAI/GL/2002/07/f2f-minutes.html#Monday>

>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.
>  
>
WAC: I like it.

>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.
>
>  
>
WAC: Agree that this seems like content for the Guide or 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. 
>  
>
WAC: Currently, our "skip link" requirement is the level 2 criterion, 
"Blocks of repeated material, such as navigation menus and document 
headers, are marked up so that they can be bypassed by people who use 
assistive technology or who navigate via keyboard or keyboard interface."
If we agree to move the other item to level 1 -  "When content is 
arranged in a sequence that affects its meaning, that sequence can be 
determined programmatically. " then the only piece missing is the markup 
that groups the repeated material.  However, that *could* be covered by 
the existing level 1 criterion, "Structures and relationships within the 
content can be programmatically determined."  Then, the current level 2 
criterion for bypassing repeated material could become a technique.  
Or...is that stretching it too much?

>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.
>  
>
WAC: Agree with John "So I would say that we should explain to the 
reviewer that the guideline *does* include site search and close the issue."

>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.
>  
>
WAC: Related to discussion of new proposal and issue summary for 
Guideline 1.3
<http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0150.html>
Which seems to suggest that we remove it from 2.4 and clarify in the 
techniques. I'm fine with that.  Seems that the Guide would provide 
useful interpretation of the overlap.

>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.
>  
>
WAC: It seems to me that this criterion is specific to documents and 
does not apply to web apps. Either way, this is subtle and should be 
clarified either through a definition (of document) or a Note: related 
to the criterion.

>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. 
>  
>
WAC: sounds like a good approach.

>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.
>  
>
WAC: If the when is always true, are we basically saying that the 
keyboard navigation sequence makes sense?  If so, what about "A 
meaningful sequence is provided or can be determined programmatically" 
In other words, either the meaningful sequence is provided by default 
via the object model or an alternative order is programmatically 
determined. However, "meaningful" is subjective.. 

>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.
>  
>
WAC: yes, believe this is covered by above proposals re: SVG and the 
bicycle example. Also covered by the Guide.

>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.
>  
>
WAC: This seems related to 3.1. I don't think "logical" clarifies it and 
is not testable.

>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.
>  
>
WAC: This does not mean the same thing as the original wording. Original 
said, "Documents that have five or more section headings and are 
presented as a single delivery unit include a table of contents with 
links to important sections of the document. "
Therefore, to keep the same meaning with the new format, it would be 
something like, "A collection of delivery units with 5 or more section 
headings that is presented as a single perceivable unit has multiple 
navigation mechanisms." In other words, a document with 5 or more 
section headings presented as a single perceivalbe unit is not the same 
as a collection of 5 or more delivery units.  This needs more work.  
Sorry I didn't catch this when the proposals were sent.

>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.
>  
>
WAC: Again, I think we're saying that the multiple ways of finding info 
is provided in the delivery unit such that the perceivable unit provides 
this functionality.  Think it needs work.

>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.
>  
>
WAC: Sounds good. Now I need to go back and rethink comments to previous 
issue...

>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.
>  
>
WAC: agree.

>** Issues that may require additional success criteria **
>  
>
WAC: Agree with Yvette's suggestion discussion points and action items.

>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.
>  
>
WAC: Yes, let's discuss. My opinion: this is a technique and is related 
to the baseline issue (which set of techniques someone chooses to use). 
I do not think we need an additional criterion.

>** Issues that may require deleting success criteria **
>
>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.
>  
>
WAC: Could depend on our definition of "non-text content."  If 
"Structures and relationships within the content can be programmatically 
determined." we could say, "this includes non-text content within the 
content...but within reason" similar to the idea I brought up yesterday 
with respect to labeling functional non-text content and recursive 
application of these criterion.

>** 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?
>  
>
WAC: Yes, should discuss. My opinion is that 1.3 should address 
providing structure and metadata related to presentation, structure, and 
behavior and 2.4 should address providing additional  navigation 
mechanisms and in some cases semantics that can not be derived from 
structure. Would be great if we could boild it down to: 1.3 is about 
structure and 2.4 is about navigation mechanisms and semantics...but 
that's too broad since structure can provide meaning...

>** 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
>  
>
-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--
Received on Thursday, 21 April 2005 19:58:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:37 UTC