- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Thu, 2 Sep 2004 19:37:01 -0500
- To: <jim@jimthatcher.com>, "'w3c-wai-gl'" <w3c-wai-gl@w3.org>
- Message-Id: <E1C324f-0001fH-00@rhv.nwtbb.com>
Hmmmm
When talking to people who were blind – they said that a skip nav link
for 4 items wasn’t worth it. it was easier to skip over them when they found
them. That is why the larger number was used.
I suggest we talk to a bunch of screen reader users and find out when it is
useful and when it is more work than the skipping.
I don't personally have an opinion one way or the other.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
_____
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Jim Thatcher
Sent: Tuesday, August 31, 2004 8:13 PM
To: 'w3c-wai-gl'
Subject: RE: [2.4] Summary of issues for guideline 2.4
I agree that in [211. Skip navigation] and also [323. Skip Navigation
Success Criteria for 2.4 [8] the general wording is better, allowing
headings markup, for example, as an alternative to a skip link to navigate.
Although it is difficult to understand when the guidance is “with more than
8 or more links.” I think 8 is far too large a number, let alone “more than
8 or more”. There are two advantages to the “skip navigation” idea – one is
to assist the user to get over the repetitious links and the other is to get
to the main content. The second advantage has nothing to do with the number
of links; the first does. If the wording stays as it is then I strongly urge
a smaller number like 3 or 4 rather than 8. Eight links covers many if not
most major navigation lists; I would like to see a number that would require
most web developers to address this navigation issue and suggest that “more
than 4 or more” is the much better – actually “4 or more.”
[808. Benefits rewording proposal [44]] Andi Snow-Weaver suggests that
headings navigation requires AT. Not so. Now Opera allows headings
navigation and I think that is an important development – for accessibility.
What an absolutely incredible job, Yvette!
Jim
Accessibility Consulting: http://jimthatcher.com/
512-306-0931
-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Yvette P. Hoitink
Sent: Monday, August 30, 2004 4:18 PM
To: 'w3c-wai-gl'
Subject: [2.4] Summary of issues for guideline 2.4
Summary of guideline 2.4
Introduction
This document is meant to review guideline 2.4 and discuss the open issues
with this guideline. The current and proposed wordings are based on the July
30, 2004 working draft [1]. Unless otherwise stated, the current wording is
used.
The current wording for 2.4 is: Facilitate the ability of users to orient
themselves and move within the content.
My personal opinions are marked with my initials (YPH).
Outstanding issues
Issues in Bugzilla
The issues in Bugzilla can be found in the status report "Guideline 2.4
(navigation-mechanisms) Issues" [2].
211. Skip navigation - technique or success criteria? [3]
Ben Caldwell wonders if providing a skip link should be an HTML technique or
a success criteria.
YPH: I think this refers to an older phrasing. Since then, we have
generalized the skip link requirement into a broader success criterion at
level 2: " Large blocks of material that are repeated on multiple pages,
such as navigation menus with more than 8 or more links, can be bypassed by
people who use screen readers or who navigate via keyboard or keyboard
interface. " Skip link is an example of such a bypass mechanism. A skip link
technique is included in the HTML techniques document [4] so I think we can
close this issue.
245. ambiguity of "long document" and "major section" [5]
Ben Caldwell asks: " What is a major section and what is a long document?
Can valid long documents be devoid of paragraphs? "
YPH: I think this refers to an old formulation. In the meanwhile, the
success criteria have been reformulated to be more specific, for example: "
In documents greater than 50,000 words or sites larger than 50 perceived
pages, at least one of the following is provided. " I propose to verify with
Ben that this answers his question and then close the issue.
319. Add another best practice checkpoint for 2.4 [6]
Ben Caldwell proposed in July of 2003 to add a best practice "Where
possible, logical tab order has been created." This has been incorporated in
the July 2003 draft but the issue was reopened upon discussion in the August
28, 2003 telecon [7] People felt that 'logical' wasn't testable, that we
needed something broader then 'tab order', etc. Wendy took an action item to
suggest new wording. This is still on the action items list.
YPH: I propose to remind Wendy about her action item ;-)
323. Skip Navigation Success Criteria for 2.4 [8]
Gregg Vanderheiden suggested to add another success criteria about skipping
links: " Users are able to skip over navigational bars or other blocks of
links that are greater than 7 when reading with a synthesizer or navigating
using
keyboard. "
This had been incorporated in the July 2003 review draft but has since then
been replaced by " Large blocks of material that are repeated on multiple
pages, such as navigation menus with more than 8 or more links, can be
bypassed by people who use screen readers or who navigate via keyboard or
keyboard interface. ".
YPH: I think the current phrasing includes Greggs point, so I propose to
check with Gregg if he agrees with that and then close this issue.
327. Making 1.5 item #1, level 2 more objective [9]
Gregg Vanderheiden commented: Checkpoints have to be objective. The
checkpoint 1 which is currently under
best practice gets close, but then changes into an (e.g. black and white,
small display, model, audio playback). If these are just examples, then it
is unclear to the user what else the individual would need to do. Suggest
that this is a good one for a "Level 2" checkpoint, but to do so, we would
need to make it definite.
The checkpoint 1 he refers to is "the structural emphases are chosen to be
distinct on different major visual display types (e.g. black and white,
small display, mono audio playback). "
YPH: Gregg's comment is an ongoing effort to make checkpoints objectively
testable. The particular success criteria he chooses as an example has been
eliminated since his comment was made. I propose to recognize the ongoing
general problem of testability but to close this item because it is no
longer valid.
370. structure of large documents [10]
Sailesh Panchang commented: " I believe that the minimum limit of 50000 word
per doc of 50 page site is not needed. Headings for text sections or groups
of links etc reveal structure and organization of content. Absence of these
struuctural markups make it inefficient to navigate a page with even less
than 10k words. So wherever a hierarchy can be used to reasonably structure
the page content, this checkpoint is applicable. The author should use
judgment to do so. I am a screen reader user and on numerous sites sensed
the need for structural markup. "
At this moment, the 50,000 word or 50 page limit is still in place. For
these cases, we require that at least one of the following is required:
* hierarchical structure
* table of contents
* alternate display order or alternate site navigation mechanisms
YPH: I think Sailesh has a point there. For HTML, I think hierarchical
structure becomes necessary for much smaller documents than the document
size for which you need tables of contents or alternate display orders. I
don't know if the same is true for other types of web content. I don't think
removing the size requirements is a good solutions because leaving it up to
the author makes it untestable. Perhaps we can explain in 'who benefits' or
the examples that this will benefit people in smaller documents as well.
Sailesh also asked: ii. While there is mention of headings and titles for
text sections, I note the absence of links that can be grouped and given
headings. Like product links, links for services offered, links for
different contacts etc. Are markup for headings used to group links outside
the scope of this checkpoint? "
YPH: We already have a SC "Each page or other resource that can be accessed
separately and that supports a title has a title that identifies the subject
or purpose of the resource. " It seems to me that this should be more
generalized to include not only 'pages' but sections or groups of links as
well. A page title will then become just one example of a more generic
success criterion.
415. Checkpoint text for navigation-mechanisms difficult to interpret [11]
Kynn Bartlett says about checkpoint 2.4 "phrasing: Again, a very ugly
sentence diagram." The phrasing at that time (the 24 June 2003 WD) was
"Structure and/or alternate navigation mechanisms have been added to
facilitate orientation and movement in content." The formulation has since
been reworked and is now easier to understand.
YPH: I propose to close this issue since the sentence Kynn objects to is no
longer in place.
416. Fitting "web application" into the page v. site divide [12]
Kynn Bartlett comments about an editorial note in the June 2003 WD about
navigating within content vs navigating within a site. applying "content" to
both pages and sites. He comments that the concept of Web application
further weakens the page/site divide.
YPH: This comment was about an ednote that is no longer present. The current
formulation of guideline 2.4 does not speak about navigating within a site
versus navigating within a document so I propose to close this issue.
434. Why aren't navigation mechanims a core checkpoint? [13]
Christian Buehler thinks navigation mechanisms should be at level 1. In
response, SIDAR feels that all documents should have structure, even if it's
so simple as a document consisting of paragraphs.
YPH: This is a fundamental problem that needs further investigation. At the
moment, 2.4 seems to be about adding extra mechanisms, and not about the
basic mechanisms that usually exist in web content (such as headings,
paragraphs, etc). I don't think additional navigation items need to be at
level 1, but basic mechanisms that also help in navigating (such as
paragraphs) should be. This overlaps with guideline 1.3 about the separation
of presentation and structure (see below).
441. proposed revisions to required section [14]
Cynthia, Kerstin and Wendy propose to delete success criteria 1 and 2 of
level 2. They argue that the structure is already available because of 1.3,
and propose to add a success criteria instead that says "a user is able to
move through the content in an order that follows the visual layout or
follows the order the page is read. " This does (to them) feel more like a
technique than a success criteria though.
YPH: This is one more example of the grey area between guideline 1.3 and
2.4. I think we first need to get the distinction clear, see below. I do
think that requiring hierarchical structure or a table of contents or an
alternative navigation order is asking more than 1.3 requires, which makes
it a valid success criteria for 2.4.
448. add definition for "visual appearance" [15]
Cynthia, Kerstin and Wendy remark that we need definitions for "visual
appearance" and "auditory characteristic."
YPH: This referred to an old formulation " the structural elements present
have a different visual appearance or auditory characteristic from each
other and from body text. " that is no longer present. I propose to close
this issue.
449. add definition for "auditory characteristic" [16]
See 448.
450. example 2 needs clarification [17]
Cynthia, Kerstin and Wendy remark that the example about data tables is
about labels, but the checkpoint is about presentation of structure. Gregg
Lowney wants to add that headers should be visually distinct from content
cells.
YPH: These are remarks for the obsolete 1.5: " Structure has been made
perceivable to more people through presentation(s), positioning, and labels.
" The example has been moved to 2.4 where it fits perfectly with the level 3
requirement " Diagrams are constructed so that they have structure that
users can access ". Since it now fits with the success criteria I propose to
close this issue.
453. move additional notes to techniques [18]
Sherman Meeds remarks that the list of considerations in the June 2003 draft
( for example: "for visual presentations, use font variations, styles, size
and white space to emphasize structure. ") should go to techniques instead
of the guidelines document.
YPH: This list has since been removed from the guidelines document and the
items in the list are now discussed in techniques (mostly in the CSS
techniques document). I propose to close this issue.
468. navigation-mechanism should be required [19]
Tina Holmboe thinks that 2.4 should be required. In our new terms, that
means it should have level 1 requirements.
YPH: This really is a duplicate issue for 434, "Why aren't navigation
mechanims a core checkpoint?". See 434.
483. sites without alternative navigation should not be allowed to state
conformance [20]
Konny Eriksson talks about the problems with Javascript-only popups that do
not provide a link in the HREF and feels that sites without alternative
navigation should not be allowed to state conformance to WAI.
YPH: I do not think providing an HREF as well as a Javascript link is what
we had in mind when we talk about alternate site navigation mechanisms. I
think this issue should be considered in the whole Javascript discussion
we're having.
488. does 1.5 require association of table headers and data cells? [21]
Gregg Gay wants to know why we don't require the association of table
headers and data cells as a core (level 1) requirement for data tables.
YPH:
Since we want the WCAG to be technology-independent, we can't explicitely
require to associate table headers and data cells for data tables because
that's HTML-specific. Instead, we now have " Diagrams are constructed so
that they have <http://www.w3.org/TR/WCAG20/#structuredef> structure that
users can access ". In HTML, one mechanism to do this is associate table
headers with data cells, as explained in the techniques document. This SC is
at level 3 at the moment.
I agree with Gregg Gay that level 3 might be too low for something as
important to the access of information as the association of table headers
and data cells. I think we should discuss this further.
491. comments and questions on navigation mechanisms [22]
Gregg Gay thinks the 50,000 words threshold is too high because documents a
lot smaller need navigation mechanisms as well. The WCAG document has less
than 15,000 words right now and is a good example of a document in which you
need the additional navigation mechanisms that are provided (TOC, headings).
Gregg Gay suggests that the table of contents be a feature for page that
include more than 5 subsections and 5000 words, and be optional as per the
ACCLIP useTableOfContents preference. A screen reader user can benefit from
having TOC turned off, while an LD user can benefit from having them turned
on.
YPH: This is a result of the underlying problem 'large documents' (see
below). I think optional TOC's can be a great tool and should be delegated
to the techniques documents.
Gregg Gay also asks: "what are "dynamic fisheye views"? Is it a TOC? "
YPH: This is an example of a site navigation mechanism in the definitions
section. I agree with Gregg that this isn't a clear example and should be
re-written.
510. bicycle example was confusing [23]
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: 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.
564. Not clear what "nav mechanism" checkpoint trying to address [24]
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. I propose to explain this to the US Access
Board and close this item.
589. checkpoint is too vague and not a WCAG issue [25]
Aries Arditi remarks that our requirement that " structural elements present
have a different visual appearance or auditory characteristic from each
other and from body text. " is not a WCAG issue.
YPH: We agreed that rendering is a user agent issue and not a WCAG issue and
removed this SC, making this issue obsolete. I propose to close the issue.
632. Proposed wording for Guideline 2.4 [26]
A proposal was made to change the wording of guideline 2.4 to " Make it easy
for users to browse the resource, to know their place in it, and to find
information they need. " Wendy objected that "browse the resource" would not
apply to all web content.
YPH: Since this issue was posted, the guideline text has been rewritten,
making this issue obsolete. I propose to close the issue.
633. Proposed wording for Guideline 2.4, [level 2] SC 1 [27]
Follow-up on issue 441. Cynthia, Kerstin and Wendy altered the text slightly
to make it more understandable by writing out the different options.
YPH: I think the proposal is easier to understand and should be adopted. I
propose to put this on the agenda for a telephone conference.
634. Proposed wording for Guideline 2.4, [level 2] SC 2 [28]
Proposal by Cynthia, Kerstin and Wendy to make it sound more like a success
criteria for the author than the visitor.
YPH: This wording has been adopted in the current WD. I propose to close
this issue.
635. Proposed wording for [level 3, item 1] Guideline 2.4 [29]
Cynthia, Kerstin and Wendy proposed a new formulation for the strategies for
facilitating orientation and movement.
YPH: This formulation has been adopted in a slightly altered form (one of
the strategies became a stand-alone success criteria). Since the
reformulation has been processed, I propose to close this issue.
636. Proposed level 3, item 2 for 2.4 [30]
Reformulation about logical reading order.
YPH: A slightly altered version of this reformulation has been adopted in
the current WD. Since the reformulation has been processed, I propose to
close this issue.
637. Proposed level 3, item 3 for 2.4 [31]
Reformulation about diagrams, making it easier to understand. John Slatin
asks if this should be moved to the 'perceivable' principle instead of
'operable'.
YPH: The reformulation has been adopted, so we can close that part. Johns
question might be answered by expanding example 4, the data table. This
currently reads: "Groups of rows or columns are labeled with headers. "
Perhaps we can expand this example to show how this helps blind users to
access the information because at the moment the example doesn't explain its
accessibility benefits. If we do this, I think we can close this issue.
638. Proposed level 3, item 4 for 2.4 [32]
Reformulation about logical tab order, making it easier to understand.
YPH: Since then, the formulation has been simplified even more. I propose to
close this issue.
675. importance of user control [33]
Greg Lowney writes about the importance of user control. This refers to the
previous SC about presenting different structures in visually different
ways. He thinks it's more important that a UAAG-compliant UA exists for all
the different types of content. He wonders if we say that anywhere.
YPH: This has since been included in guideline 4.2 as SC 1 of level 1. I
propose to close this part of the issue.
Greg Lowney also wants to make " users can control the presentation of
structural elements or the emphasis on the structure can be varied through
alternate presentation formats " to a requirement (equivalent to our current
level 1) and add "if supported by the technology".
YPH: This SC has since been deleted, if I remember correctly because we
think this is a user agent issue. See underlying issues.
676. 1.5 example 1 [34]
Greg Lowney objects to the suggestion to make _subtle_ differences between
the appearance of titles and section headings.
YPH: 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 helps 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.
679. add something about pausing before voice headers to 1.5, ex 3 [35]
Greg Lowney suggests to mention that it can be useful to add a pause before
voicing headers.
YPH: I think this would make the example more complex than necessary. It
would be a useful technique though, for example in the CSS techniques
document. I propose to hand this issue over to the Techniques Task Force. I
do question the validity of the example in question. It was moved to 2.4
when integrating 1.5 and 2.4 but we currently no longer have a success
criteria where this is an example for. It used to be an example of how to
make structure perceivable in presentation but we deleted those success
criteria so we should either delete this example or add a success criteria
about making structural elements perceivable.
690. change "added" to "included" in guideline text [36]
Greg Lowney proposes an alternative for 'added' in the phrasing of the
guideline text.
YPH: Since Greg posted his comment, the guideline text has been re-written
and doesn't include 'added' or 'included' anymore. This makes his remark
obsolete so I propose to close the issue.
691. what is meant by "move through the content" [37]
This question is about what is meant by moving through the content, since
that is an inherent capability of user agents. Greg Lowney doesn't
understand the need for this guideline.
YPH: This question refers to a very early version of the guideline, when the
guideline text was less clear and the success criteria weren't as clear yet.
I propose to check back with Greg Lowney whether he feels the current
wording addresses his issue and if so, close it.
692. structural markup and display on different devices [38]
This comment is about problems with providing structure in markup or a data
model.
YPH: This requirement has been deleted making this remark obsolete. I
propose to close this issue.
751. Guideline summary (to do) guideline navigation-mechanisms (2.4) [39]
Wendy: We need a thorough issue summary for this guideline.
YPH: Your wish is my command ;-)
760. define "structural elements" in level 2 criteria [40]
We need a definition of "structural elements" for this guideline.
YPH: We no longer use the term 'structural elements' so no longer need a
definition. I propose to close this issue.
761. Added comment from list: Visual layout is used to group related
components so that behavior is predictable. [41]
Kerstins feels we should look into "visual layout is used to group related
components so that behavior is predictable."
Need to look into this.
YPH: We deleted all the requirements to make structure perceivable, see
underlying issues. I propose to close this issue.
806. Need to think through this guideline with Web applications in mind [42]
Andy Snow-Weaver comments that the level 2 SC don't seem to cover web
applications.
YPH: This is a good point which is still valid for the current wording. I
think we should further discuss this.
Carol Smith asks what we mean by 'perceived pages', if this means pages in
the navigation structure or pages that are linked from other pages in the
site.
YPH: We definitely need a definition for 'perceived pages'. I propose to
create an action item for this.
807. Non-hierarchical relationships covered under
content-structure-separation [43]
Andi Snow-Weaver proposes to delete the requirement about non-hierarchical
relationships since that's already covered in 1.3.
YPH: It does seem that this is covered in a level 1 success criteria for 1.3
so it can be deleted. However, it's still present in the current WD. I
propose to discuss this further and take a decision to delete this item or
not.
808. Benefits rewording proposal [44]
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: 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 [45]
Michael Cooper proposed to move the linear reading order SC to level 1.
There was no consensus to do this in a telecon. There are still issues about
the phrasing of 'logical reading order', which are covered in issue 884.
YPH: Since there was no consensus and the one part that's still open is
covered by another issue, I think we can close this issue.
859. frames included in 2.4, level 3, item 4? [46]
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: 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 [47]. 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.
883. This guideline is about "usability", not "accessibility" [48]
Andi Snow-Weaver comments that this guideline seems to be more about
usability then accessibility. This question is covered in issue 564, see
there.
884. Logical tab order is subjective [49]
The US access board thinks "Logical tab order" is subjective.
YPH: There seems to be an ongoing discussion about this so I propose leave
this issue open until we solve this problem.
945. Please clarify need to "look different" [50]
James Craig is worried about the need for different structural elements to
'look different' from each other because that's a designer's choice.
YPH: This SC has been deleted since so this issue is obsolute and can be
closed.
946. Needs examples to understand success criteria for 2.4 [51]
James Craig wants examples for different level 3 succes criteria.
YPH: There is no example at the moment about providing information to
indicate at least one logical sequence in which to read the document. 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.
947. Is logical tab order testable? [52]
James Craig is worried that 'logical' tab order isn't testable.
YPH: This is a duplicate of 884. I propose to mark this issue as a duplicate
and close it.
948. User agent should determine voice style in Example 5 [53]
James Craig feels that the example about a more formal voice for headers is
something that should be left to the user agents and suggests using "a
discernibly different style" instead.
YPH: I think we shouldn't treat auditory design any different from graphical
design. We think providing different looks for headings is a great idea, so
why not do the same for sound? With CSS3, auditory design will hopefully get
a lot more attention. It's just an example, I see no harm in using a formal
voice in that. We do need to make clear that formal voice is just one
possibility, and not _the_ WCAG recommendation. I propose to alter this
example and then close this issue.
Perhaps we can rewrite it in a similar way as example 1 does for the visual
differences:
* Example 5: an audio presentation.
An audio rendering of a document, generated according to a style sheet, uses
a different voice to read titles and headers so the listener can easily
identify the words as a title and not part of the running text. This
difference might be in pitch, volume or in tone, for example by using a
louder, more formal voice.
955. TOCs should include information about presentation modes [54]
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: 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.
994. Grammatical fix to example 1 [55]
RIND suggested to change " accepted use of labelling the structure " to
"accepted way of labelling the structure"
YPH: I agree this is clearer and propose we adopt this change and then close
this issue.
1008. Assertion rather than requirement [56]
Ian Jacobs thinks the 'there is a statement asserting' success criteria
should be eliminated because they do not help authors when making the
content more accessible and are already covered by a conformance statement
YPH: This issue applies to other guidelines as well. Personally, I agree
with Ian and think the requirements to include statements are very
artificial. This is a fundamental issue because it's closely linked to
accessibility. I propose we discuss this further, perhaps even at a
face-to-face.
1016. When to determine if a site map is needed [57]
Andy Budd remarks that the need for a site map depends on the amount of
crosslinks between pages. If you can access every page from every other
page, you do not need a site map.
YPH: This is one more variant of the problem that the threshold for 'large
documents' is very arbitrary and it really depends on the content whether
you need additional navigation mechanisms or not. We need to discuss the
underlying issue before we can decide what to do about this issue.
Underlying issues
'Large documents'
Several issues come down to the same thing: the arbitrary threshold we have
for 'large content'. There are plenty of examples for content that do not
meet this threshold (for example the WCAG 2 document with less than 15,000
words) which still really need additional navigation mechanisms to make them
operable.
Perhaps we should phrase it in such a way that it is clear that it's just an
arbitrary threshold and for smaller content, we encourage the authors to use
their own judgement. If we cannot find a way to formulate this in a testable
manner in the SC text, we could do this in the examples or in a 'who
benefits'.
Make structure perceivable
A lot of the now obsolete issues were about making structure perceivable. If
I'm correct we deleted these because the presentation of the structure is a
UA issue. I propose to discuss this in a telecon to see if that's indeed
what we mean to do and if so, close all the issues about perceivable
structure.
Usability versus accessibility
Several people have pointed out that 2.4 isn't about accessibility but about
usability. Navigation in content is disproportionately harder for people
with certain types of disabilities, so providing means to facilitate
navigation is an accessibility issue. Since several knowledgeable people
have pointed this out, we have to do a better job at explaining this in the
guidelines document, perhaps in the 'who benefits' section.
Dependencies between guidelines
Guideline 1.3 - Ensure that information, functionality, and structure are
separable from presentation.
Guideline 1.3 level 1 SC 1 says that structures and relationships within the
content can be derived programmatically . This overlaps with guideline 2.4's
requirements to construct diagram so that users can access the structure,
and to reveal hierarchical and non-hierarchical relationships.
YPH: People wonder if guideline 1.3 already requires an author to make sure
the structure and relationships of the content can be derived at level 1,
what do we need the level 2 and 3 success criteria in 2.4 for to require to
add such structure and relationships to the document?
To me it sounds like guideline 1.3 is saying "if the document has structure
or relationships, make these available" and guideline 2.4 says to make sure
the document has structure and relationships. That's a very subtle
difference and one I think we need to work on making that more clear.
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, August 2004
Contact: y.p.hoitink@heritas.nl
Notes
[1]. http://www.w3.org/TR/2004/WD-WCAG20-20040730/
[2].
http://trace.wisc.edu/bugzilla_wcag/issuereports/navigation-mechanisms_issue
s.php
[3]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=211
[4].
http://www.w3.org/TR/2004/WD-WCAG20-HTML-TECHS-20040730/#linkgroups_skip
[5]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=245
[6]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=319
[7]. http://www.w3.org/2003/08/28-wai-wcag-irc.html
[8]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=323
[9]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=327
[10]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=370
[11]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=415
[12]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=416
[13]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=434
[14]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=441
[15]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=448
[16]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=449
[17]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=450
[18]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=453
[19]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=468
[20]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=483
[21]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=488
[22]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=491
[23]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=510
[24]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=564
[25]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=589
[26]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=632
[27]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=633
[28]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=634
[29]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=635
[30]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=636
[31]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=637
[32]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=638
[33]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=675
[34]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=676
[35]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=679
[36]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=690
[37]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=691
[38]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=692
[39]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=751
[40]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=760
[41]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=761
[42]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=806
[43]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=807
[44]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=808
[45]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=829
[46]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=859
[47]. http://www.w3.org/TR/2004/WD-WCAG20-HTML-TECHS-20040730/#title
[48]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=883
[49]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=884
[50]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=945
[51]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=946
[52]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=947
[53]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=948
[54]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=955
[55]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=994
[56]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1008
[57]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1016
Received on Friday, 3 September 2004 00:38:02 UTC