RE: Copywriting for Screenreaders (was Alt text for URL's)

Jamal wrote:

<blockquote>
I also find navigating by heading to be efficient -- in fact, if the
first heading begins the main content of the page, I find it to be the
quickest way of getting there with JAWS (Just one press of the H key). I
seem to get better results with the skip-navigation huristic of JAWS by
doubling the default setting from 25 to 50 characters.  This still often
does not work, however, so I appreciate a skip-navigation or
jump-to-main-content link when heading structure is lacking.  

An advantage of the JAWS "quick navigation keys" like H for the next
heading or N for the next non-linked text is that they can be pressed
during the initial continuous read of the page, and the reading will
then continue after the navigation.  This is most efficient, as it
eliminates the need for separate keystrokes to navigate and then read in
context in order to know whether the skip-mavigation attempt worked.

</blockquote>
 I agree-- being able to jump quickly to headings is a very useful way
to navigate, and I use this feature often, in addition to the headings
list (Ins+F6), which has been available in JAWS for a bit longer than
the hot keys.  (JAWS 6.0 added a new hot key, the letter "I", for
jumping from one list item to the next. It's not perfect yet, but it's
quite helpful.  The reason wI say it's "not perfect' is that (a) JAWS
doesn't inform you when you've jumped into a different list; and (b) if
the list item contains an ancor element followed by other text, JAWS
doesn't speak the text following the anchor.)

But lately I've been noticing a problem with navigating by jumping from
headin gto heading: if both the navigation bar  and the main content
area contain headings, you can get a very strange sense of document
structure.  For example, on some pages I've seen recently, the main
content area starts with a <h1>.  The navigation area starts with an
<h2> and contains a couple of <h3> elements as well.  Sounds good when I
say it this way.  But if the navigation bar appears first in the source
code, pressing "h" from the top of the page doesn't take you to the <h1>
first, as you might expect: instead you jump to an <h2>, and if you
press "h" again you go to another <h2> or maybe to an <h3>, etc. You
don't get to the <h1> at the beginning of the main content area till
you've gone through the entire navigation bar!  

So a technique that *can* be used to let users bypass repeated
navigation links has the unintended consequence of forcing the user
*through* those links instead.

I think this may be a byproduct of using pre-built templates that
contain all the navigation links, so that the content provider need only
worry about the main content section. In effect, the page contains two
parallel structures.-- one for navigation and one for main content. The
distinction between navigation and main content may be perfectly clear
visually.  But the screen reader doesn't know anything about the visual
layout, and it takes the headings in source-code order. So if the
navigation area comes first in the source document, screen readers will
encounter any headings in the navigation area before they get to any
headings in the content area. This can be pretty confusing.

Using tabindex *might* help with this, but it has its own drawbacks.
For example, the screen reder will go through all elements for which
tabindex has been set before going to any element that doesn't have a
tabindex (which will then be visited in source code order). So you may
need to put everything in the tab order just to control a few things in
the tab order.

It's clear that some of this is a user agent issue; but some of it's a
design issue.

John

I don't have a solution for this, but it's almost as though the page 


"Good design is accessible design." 
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 



-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
Behalf Of Jamal Mazrui
Sent: Thursday, February 17, 2005 8:18 am
To: Lloyd Rasmussen; w3c-wai-ig@w3.org
Subject: RE: Copywriting for Screenreaders (was Alt text for URL's)



I also find navigating by heading to be efficient -- in fact, if the
first heading begins the main content of the page, I find it to be the
quickest way of getting there with JAWS (Just one press of the H key). I
seem to get better results with the skip-navigation huristic of JAWS by
doubling the default setting from 25 to 50 characters.  This still often
does not work, however, so I appreciate a skip-navigation or
jump-to-main-content link when heading structure is lacking.  

An advantage of the JAWS "quick navigation keys" like H for the next
heading or N for the next non-linked text is that they can be pressed
during the initial continuous read of the page, and the reading will
then continue after the navigation.  This is most efficient, as it
eliminates the need for separate keystrokes to navigate and then read in
context in order to know whether the skip-mavigation attempt worked.

Regards,
Jamal

-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
Behalf Of Lloyd Rasmussen
Sent: Thursday, February 17, 2005 8:44 AM
To: w3c-wai-ig@w3.org
Subject: Re: Copywriting for Screenreaders (was Alt text for URL's)



I seldom use skipnav links anymore.  With Window-Eyes and IE6, I try to
go 
to the first heading or to the first block which has two or more lines
of 
two or more characters, then look around with the MSAA cursor.  The
default 
for this "next text" command in Window-Eyes is 1 or more lines of 1 or
more 
characters, but I found this to often pick up the text between nav
links, 
so I changed it.  I think the default for JAWS is 1 or more lines of 25
or 
30 characters, which is probably not a bad heuristic either.  It would
be 
really useful if more sites would using headings in a semantically 
meaningful way, but I'm preaching to the choir by saying it here.

I use Lynx to get a good text rendering of some kinds of web pages, but
for 
table browsing and interpretation, the IE/screen reader solutions work 
much, much better.

At 04:48 AM 2/17/2005, you wrote:

>>Ok,  I'll put it succinctly.  If site navigation is so bad that it
needs to
>>be skipped, how can it be improved so that it does not need to be
skipped.
>
>Nobody is suggesting that skip links are there to deal with *bad*
navigation.
>
>Sighted users have the ability to visually skip past site navigation
and 
>straight to the content by scanning the page. However screenreader
users 
>access the page in a linear fashion and can't do this (see caveat
below). 
>The point of skip navigation is to give screenrreader users the ability
to 
>jump directly to the content if that's what they want to do.
>
>Site navigation is usually made up of a number of links, all of which
need 
>to be tabbed past if using the keyboard to navigate. If you're got to
tab 
>past 20 link on each page before you reach the main content, this can
be 
>very tedious and a bar to accessibility.
>
>Some screenreaders can display heading lists. Assuming the users are
>familiar with this ability, it can allow them to jump to the main
content 
>in well marked up sites. Also it is possible via CSS to have the nav
come 
>last rather than first. However then people navigating via the keyboard

>will have to tab though the who content to get to the nav bar, which on

>link heavy pages, could be a nightmare (think a links page).
>
>Personally I think "skip links" are unobtrusive so I'm really not sure
>what your problem with them is. It's kind of like complaining about 
>putting a lift in a building to increase accessibility because the
stairs 
>could have been made better.
>
>
>Andy Budd
>
>http://www.message.uk.com/
>

... Creating implements of mass instruction.
Lloyd Rasmussen, Senior Staff Engineer
National Library Service f/t Blind and Physically Handicapped
Library of Congress    (202) 707-0535   <http://www.loc.gov/nls/z3986>
HOME:  <http://lras.home.sprynet.com>
The opinions expressed here are my own and do not necessarily represent 
those of NLS.

Received on Thursday, 17 February 2005 14:50:01 UTC