W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2004

Re: FW: Skip navigation in WCAG-2

From: david poehlman <david.poehlman@handsontechnologeyes.com>
Date: Thu, 9 Sep 2004 21:00:55 -0400
Message-ID: <01ee01c496d1$a10f6b10$6401a8c0@DAVIDPC>
To: "WAI Interest Group" <w3c-wai-ig@w3.org>

It woulbe be trivial to fix some of this.  Screen readers do not have to
start at the top of the page and begin reading and not stop till you tell
them to.  They don't have to start at the top of the page and read at all.
They could just simply announce that the page is loaded and let you do the
reading.  They could announce that the page is loaded and verballize the
characteristics of the page such as how many links, headings and the like on
the page, what the page title is and if there are any forms on it or not or
whatever you want.

We don't need new code for skip nav, what we need is to standardize on
something we already have such that it can be used for marching through a
page and for aides in navigation.  We can get lists of headings, lists of
links, lists of frames lists of form elements and who knows what else so
skip nav is really not necessary.  I know that htis leaves some in the dark
but skip nav doesn't even really help them for the reasons jamal sites below
and one more.  If I am using a text user agent and I am looking over the
page, If I follow skip nav, I have to reorient my self and if I don't use
skip nav but decide I want to, I have to find my way back to it.  If on the
other hand, I can move at will among headers, jumping to the first last,
second third, first level 1, 2, 3, 4... I can go through a page in no time.
It doesn't have to be the heading element, it can be <p> for all I care, but
standardizing on something would make it a whole lot easier than putting an
over used clumsy construct on every page.

Johnnie Apple Seed

----- Original Message ----- 
From: "Tina Holmboe" <tina@greytower.net>
To: "WAI Interest Group" <w3c-wai-ig@w3.org>
Sent: Thursday, September 09, 2004 1:45 PM
Subject: Fwd: FW: Skip navigation in WCAG-2

 Forwarded by request.

------ Forwarded message ------
    From: "Jamal Mazrui" <Jamal.Mazrui@fcc.gov>
 Subject: FW: Skip navigation in WCAG-2
    Date: Thu, 9 Sep 2004 13:30:36 -0400
      To: <tina@greytower.net>

Hi Tina,
I tried to weigh in on this topic earlier today.  I did not receive a
copy of my post, so am wondering whether it made the list.  If not,
would you consider forwarding it?


-----Original Message-----
From: Jamal Mazrui
Sent: Thursday, September 09, 2004 10:09 AM
To: 'Jesper Tverskov'; w3c-wai-ig@w3.org
Subject: RE: Skip navigation in WCAG-2

As a blind, avid user of the web, I strongly support the direction of
WCAG 2 regarding skip navigation.  I wish it were possible for this
capability to be addressed solely by the user agent, the combination of
web browser and screen reader, thus relieving page authors of that
responsibility for accessibility.  Unfortunately, however, there appears
to be no screen reader technique that can reliably infer where the main
content of a page begins.  I am experienced with the various huristic
techniques available, e.g., looking for non-linked text, a heading, a
frame, a paragraph break, etc., and none has been a reliable solution.
Often, I have to try one huristic after another on an unfamiliar web
site, hoping to find a mechanism that can spare me the frustrating,
unproductive experience of wading through navigation links, trying to
focus on the distinguishing content of the page.

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.

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.


P.S.  I do not seem to receive copies of messages I post to this list.
I would like to change that setting, as a way of assuring myself that a
message I sent was actually distributed.  I suspect that most people
appreciate such assurance when they have taken the time and care to
write something publicly, so I suggest a change in the default list
settings.  In any case, if someone can inform me how I can change this
setting, I would appreciate it.

-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
Behalf Of Jesper Tverskov
Sent: Thursday, September 09, 2004 5:46 AM
To: w3c-wai-ig@w3.org
Subject: Skip navigation in WCAG-2

The meaning of "Skip navigation" is almost completely changed in the
proposal for WCAG-2. Basically a "until user agents" has just been
dropped but in this case it changes the meaning of the guideline.

_ _ _ _ _ _ _ _ _ _

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

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.

This is a good approach. Already today a browser like Mozilla has a
"Find as you type" feature. It can be set up to work for links only
using the first letter of link text as access key making it extremely
easy to move around for keyboard users even making HTML Accesskey

Most screen readers have or should have ways to go to next word, next
sentence, next paragraph, next heading, next list, end of list of links,
etc. It is much better for users of screen readers to become experts in
using these generic methods for moving around that can be used at most
websites than to rely on "skip navigation" implemented by millions of
web page authors never using it themselves.

"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. 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.

_ _ _ _ _ _ _ _ _ _

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

_ _ _ _ _ _ _ _ _ _

Note the difference: Guidelines, WCAG-2, talk about 8 links, Techniques,
WCAG-2, talk about 5 and 20 links.

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

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.

WCAG-1 was right about "skip navigation" being mainly a user agent

Best regards,
Jesper Tverskov

Received on Friday, 10 September 2004 01:00:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:29 UTC