RE: Navigation
by "John Foliot - Another 4:00 AM Web Thing" <foliot(at)fouram.com>
|
Date: |
Thu, 24 Jan 2002 07:26:43 -0500 |
To: |
<andrew_kirkpatrick(at)wgbh.org>, <aware-techniques(at)hwg.org>, <info(at)mtbytes.com> |
In-Reply-To: |
awk |
|
todo: View
Thread,
Original
|
|
If I may add to Andrews comments...
First..., the Right hand navigation is not visible in Netscape (at least, I
can't see it). I suspect there is an open <TABLE> tag which has not been
closed; Netscape is notorious for not displaying inproperly formed tables.
You could run your code through a validator to find the problem; both the
w3c (http://validator.w3.org/) as well as HTML Help
(http://www.htmlhelp.com/tools/validator/) have on-line validators which
will do the job nicely. You will however first have to add proper DTD's
(Document Type Declarations) to all of your docs. See the w3c site or
review the HTML Basics List (Archive) at the HWG for more information about
this.
Speaking of HTML Help, they have 3 little tools (they're free) which are
great additions to the developer's tool box. Known as Widgets, they add
"right click" functionality to the Internet Explorer web browser. The 3 I
use most often are Validate HTML, Remove Stlye Sheets, and Remove Images.
They give me a quick sense of how my pages might be interpreted by different
user conditions/environments.
My second comment addresses Right hand navigation in general. Generally,
Screen readers read tables in a linear fashion, like so:
---------------------------------------------------
| Read contents | Read contents | Read contents |
| of this cell | of this cell | of this cell |
| first, then.. | second, then.. | third, then.. |
---------------------------------------------------
| Read contents | Read contents | Read contents |
| of this cell | of this cell | of this cell |
| forth, then.. | fifth, then.. | last |
---------------------------------------------------
Therefore, using a table to place navigation on the right hand side
effectively puts it _after_ the content. Once the positioning attributes of
Cascading Style Sheets are widely supported, the secondary nav block could
be visually placed on the right but still interpreted by screen
readers/speech browsers prior to the body of the content. But since Style
Sheets are not yet universally supported, this solution is probably not
acceptable, as it is impossible to ensure that every visitor will "see" the
same layout. Based on this, I would recommend that the Right hand
navigation contain only non-essential navigation and/or that the links in
this right hand cell are repeated throughout the text in the center column,
perhaps in the context of the client message.
HTH
JF
-----Original Message-----
From: owner-aware-techniques(at)hwg.org
[mailto:owner-aware-techniques(at)hwg.org]On Behalf Of Andrew Kirkpatrick
Sent: January 23, 2002 11:33 PM
To: aware-techniques(at)hwg.org; info(at)mtbytes.com
Subject: Re: Navigation
A few comments:
1) You should include a "skip to content" or "skip navigation" link at the
top of the page, prior to the long
list of links. You could also add an accesskey attribute to the link. You
are going to need to decide
whether the navigation on the right is part of the navigation or part of the
content. I think that since the
links on the right are context-sensitive, they are content. I'm not sure
about the links to news, weather, and
maps -- those are less context-sensitive, so maybe they are part of the
global nav and should be bypass-
able. You could even use the line at the top of the page as the skip-nav
link...
2) I vote against the mouseovers if they are done at the expense of the
expanded list of links. JAWS 4.01
now deals with mouseover links to some extent, but not everyone has that
version yet.
3) I noticed that the way to determine who the department head is depends on
someone noticing that the
text is bold. I don't know how to determine this with
JAWS/WIndow-Eyes/etc., and I'm willing to bet that
even if a screen reader user does know how, they won't often try. With a
screen reader I would need to
ask if a particular piece of text is bold or not. The answer is probably
no, since there are more people who
aren't department heads, and I get to try again on some other name. Maybe
I'll find one -- what a pain. In
reality, this is probably not even necessary since I can guess that the
Police Chief is the head of the Police
department.
4) Some screen readers (including JAWS 4.01) can move from heading to
heading. If a page doesn't use
headings this won't work. It is true that most screen readers don't do
this, but more will. I am in favor of the
coding practice that minimizes presentation in the html and maximizes
structure. Headers provide structure.
5) Site map -- some people like them, some people don't. If it is going to
be useful, put it in; otherwise,
don't. A site map that is structured can still be navigable -- are you
planning on including _every_ link on
the site in the map?
6) Homepage reader is another good tool -- easy to use, relatively
inexpensive, and gives a decent
approximation. You can download a trial version of JAWS at www.hj.com (a
40-minute, then reboot for 40
more minutes trial) and likewise for window-eyes at www.gwmicro.com.
7) Lastly, I think you should take a look at the text of your links. Read
the links one by one without any
surrounding text. Do they make sense? For example, "Montpelier Buildings &
Assessor's Office" makes
sense -- I'd expect to be linking to the assessor's office. On the other
hand, "highly-educated work force"
doesn't make as much sense out of context, especially since it leads to a
page on the local economy rather
than on the work force. At least there are no "click here" links. In
general, most links seem pretty good in
this regard, but worth mentioning.
Hope this helps,
Andrew
1/23/2002 8:48:25 PM, info(at)mtbytes.com wrote:
>I have questions about how to make a website with extensive
>navigation as accessibility friendly as possible.
>
>The specific site I have in mind is for a municipality.
>Although Section 508 is not mandated for us, we want to
>make the site as accessible as possible. This is a site I
>did not design, but am now maintaining.
>
>The navigation might not be extensive compared to other
>sites, but I think you can see the concept that there are
>several main sections to the site (down the left side of the
>screen) and lots of subsections (down the right side of the
>screen) within each section.
>
>Here's an example:
>http://www.montpelier-vt.org/htm/citydepts_welcome.shtml
>
>How can we make the navigation as clear as possible and
>still serve accessibility?
>
>In talking things over with me, the person who first had
>this site designed mused about the possibility of using
>mouseovers or rollovers to see a submenu under each main
>section heading. In some ways it would make the page a
>little neater and would make the navigation more clear, but
>I think it would bring up accessibility issues.
>
>Also, how much navigation does someone want to wade through
>before finally getting to the meat of the page?
>
>Another related navigation question deals with making a site
>map page. It would give an overview of the whole site and
>where to find things, but it could be horrendous to have to
>listen to an endless page of links. It is nagging at me
>that if the site navigation is done well enough, a site map
>would be unnessary. Any thoughts on this?
>
>(I have been using pwWebSpeak to test how pages sound. I
>wonder if it is a close enough approximation of what most
>screen reader users use. I bought it several years ago.)
>
>Any helpful suggestions will be appreciated. Also, any
>links to good examples would be nice, too.
>
>Thank you.
>
>
>
>
Andrew
--
Andrew Kirkpatrick, Technical Project Coordinator
CPB/WGBH National Center for Accessible Media
125 Western Ave.
Boston, MA 02134
E-mail: andrew_kirkpatrick(at)wgbh.org
Web site: ncam.wgbh.org
HWG: hwg-basics mailing list archives,
maintained by Webmasters @ IWA