RE: FW: Skip navigation in WCAG-2

Jamal Mazrui wrote:

> 
> I ask anyone suggesting the abandonment of skip navigation
> coding to propose a reliable solution for user agents.  My
> current view is that WCAG should, in fact, go further in this
> area by recommending a specific HTML or XHTML code that a
> user agent can look for.  This would help automate the skip
> navigation task, providing smoother, more productive web
> surfing for people with visual disabilities.

We are of the opinion that there may already be a reliable if under-used
and under supported element: the relative link (<link rel="bookmark"
title="site navigation" href="#nav" />, although a case could, perhaps
should, be made for the introduction of a standardization of
"navigation", as in <link rel="navigation"...> (See:
http://www.w3.org/TR/html4/types.html#type-links)

Further, the current draft of XHTML 2 is suggesting the use of "Access
Points"
(http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-hyperAttributes.html#a
def_hyperAttributes_access)  
We noted with interest the following:
"The invocation of access shortcuts, and the assignment of key or other
bindings to them is not further defined here. A user agent should allow
the user to access the user agent's list of recognized access points, to
add to them, and to specify bindings for them." (see our article at
http://www.wats.ca/articles/thefutureofaccesskeys/66 for more info).

This appears to also serve the needs of users such as Jamal.  Authors
can enclose their navigation in any of the standard elements (<P>,
<DIV>, <UL>, etc.) and add the access attribute to that enclosure:

<div id="navigation" access="navigation"> nav elements here </div>

> 
> At present, a skip navigation link still requires one to take several
> steps:  stop the automatic reading of the page after it
> loads, navigate to the top of the page to ensure that
> scrolling by the screen reader has not passed the skip
> navigation link, tab to that link, execute it, wait for the
> page to settle at the new point of focus, , and then begin
> reading again from there.  A standard way of coding skip
> navigation would allow a screen reader to automatically begin
> a continuous reading of the page at its main content, a
> significant boost in the quality and productivity of user experience.

Precisely.  Whether through the use of the relative link, or the
proposed access attribute, the W3C appears to be providing the "logical"
means of identifying the important navigational block, while at the same
time not specifying the  exact means of accessing it, but rather leaving
it to the user agent. Identifying the navigation block in your code,
using a STANDARD method (see above) should be a mandated requirement,
and perhaps one that should be included into WCAG 2.

Meanwhile, this thread started out with:
> 
> 
> In WCAG-1:
> 
> "13.6 Group related links, identify the group (for user
> agents), and, until user agents do so, provide a way to
> bypass the group. [Priority 3]"
> 
> In WCAG-1 it is clear that "skip navigation" is regarded as a
> user agent issue. Authors should not bother about it, or just
> a little, the day user agents can do the job.

Clear?  How? Where? Where does it say "Authors should not bother about
it"...

<snip>
> 
> "Skip navigation" should not be an author issue but should
> remain a user agent issue. Making it an author issue is a
> text book example of how not to make the web more accessible.

Say what???  Wrong, wrong, wrong.  Clearly identifying the navigational
component of any web page through the use of appropriate code *must* be
the responsibility of the page author... You want software to "detect"
the navigation block of your page how?  Hunt and peck?  Guessing?
Reading aloud (in the case of screen readers) all of the links, tabbing
back and forth between headers and/or list elements and/or anchor tags?
Gimme a break...  The author must, in every case, identify the
navigational block to users, although I agree that there should be a
better, more "standard" way of doing so; one which user agents can then
build upon.

> Accessibility should as much as possible be handled by user
> agents and as little as possible depend of the acts of
> millions of web page authors.
> 
> 

Yes, while the user agent should "handle" accessing the navigational
block, it none-the-less must be programmatically identified as such, a
role left exclusively to the author, all millions of them...

_ _ _ _ _ _ _ _ _ _
> 
> 
> In WCAG-2, Guideline 2.4, Level 2 Success criteria:
> 
> "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. [V]"
> 
> and in HTML Techniques for WCAG 2.0, 9.6 Skipping link groups, says:
> 
> "Include a link that allows users to skip over grouped links."
> 
> "If there are five or more navigation links and/or other
> content that comes before the main content of the page then
> the skip navigation technique should probably be used. If
> there are twenty links and other elements before the main
> content, one of these techniques definitely should be used.
> The link should be at or very near the top of the page; it is
> a link with a local target just before the beginning of the
> main content."
> 
> _ _ _ _ _ _ _ _ _ _
> 
> 
> Note the difference: Guidelines, WCAG-2, talk about 8 links,
> Techniques, WCAG-2, talk about 5 and 20 links.

Why are you fixating on the quantity?  The important point is that a
programmatic means of efficient site/page navigation must be provided to
the end user... One which does not rely solely on visual clues. 5, 8, 2,
100; the quantity is less of an issue (although, the greater the number,
the more significant the issue may become).


> 
> *** User agents are no longer mentioned, it has become an
> author issue only.

Correctly so.  No more if's, and's or but's...

> 
> By dropping "until user agents", in this case, WCAG-2 comes
> in line with Section 508 also regarding "skip navigation" as
> an author issue. This makes the proposal for WCAG-2 just as
> plain wrong as Section 508 has always been.

HUH?  No, WCAG2 is right in dropping as much ambiguity as possible.  The
author should use the (X)HTML code and coding techniques available to
them to ensure as much usability/accessibility as possible, and not seek
"wiggle room" on achieving the bare minimum, an all-to-familiar line of
attack today (a recent thread concerning <th> on this very list being a
case in point - "I know I should, but *must* I?...").

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca   1.866.932.4878 (North America)

Received on Thursday, 9 September 2004 22:45:14 UTC