- From: Wendy Chisholm <wendy@w3.org>
- Date: Thu, 21 Apr 2005 15:58:01 -0400
- 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