E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: accessible tree menus

Number of posts in this thread: 18 (In chronological order)

From: Donna Jones
Date: Mon, Feb 23 2009 3:15PM
Subject: accessible tree menus
No previous message | Next message →

hi everyone:

i need some help figuring out the best expandable and accessible tree
menu to use. i'm a third-party consultant on this. a person at the
institution uses a screen reader. a Project VII tree menu was proposed
and he had this to say:

<quote>
That is, clicking on Degrees launches the Degrees page, which shows the
related subnavigation links. Clicking Certificates launches that page
with its own navigation. So it isn't just the menus that are changing,
but the entire page.

The only downside for me using a screen reader is that each page starts
reading from the beginning, losing the focus on a particular part of the
navigation menu. </quote>

i've read the above a number of times and still not sure that i "get
it". maybe its a problem with the "expandable" bit?? maybe tree menus
just aren't good with screen readers?

i've never done an expandable menu before. i have used the Ultimate
Dropdown Menu but not as a tree/expandable.

he (the screen reader user) recommends a couple:
http://www.456bereastreet.com/archive/200705/accessible_expanding_and_collapsing_menu/

but even on the site, Patrick says its not ready for for production.
and
http://www.onlinetools.org/tools/yadm/
looks better to me.

here's the Ultimate Dropdown Menu's site:
http://www.udm4.com/menu/demos/ and i had a more confidence in its
accessibility but, i really am not sure with the above requirements.

all the best and many thanks for any clarity you can send my way!

Donna Jones

--
Donna Jones
Portland, Maine
207 772 0266
www.westendwebs.com

From: Steve Green
Date: Mon, Feb 23 2009 3:30PM
Subject: Re: accessible tree menus
← Previous message | Next message →

In our experience of user testing, expandable menus always cause problems
for screen reader users. This is predominantly because they are only ever at
a single point on a page and don't have a good holistic view of it. It is
very difficult to build and maintain a mental model of the tree as it
changes. Furthermore, the only relevant semantic structure is a nested list,
and this is usually quite incomprehensible to a screen reader user because
there is far too much information to remember.

For instance they know where an 'expand' node is but they don't know how
much content has been revealed when the node is expanded. They only know
where the start of it is.

If it is only one level of nesting, they may well be able to cope, but we
have seen menus with more than ten levels of nesting and hundreds of nodes,
and this is quite impossible to navigate sensibly.

The worst examples are where only one node can be open at a time, so opening
a new one automatically closes the last one. Screen reader users are totally
unaware that this has happened so they cannot find menu items they found
before.

Steve

From: Donna Jones
Date: Mon, Feb 23 2009 10:15PM
Subject: Re: accessible tree menus
← Previous message | Next message →

> In our experience of user testing, expandable menus always cause problems
> for screen reader users. This is predominantly because they are only ever at
> a single point on a page and don't have a good holistic view of it. It is
> very difficult to build and maintain a mental model of the tree as it
> changes. Furthermore, the only relevant semantic structure is a nested list,
> and this is usually quite incomprehensible to a screen reader user because
> there is far too much information to remember.
>
> For instance they know where an 'expand' node is but they don't know how
> much content has been revealed when the node is expanded. They only know
> where the start of it is.
>
> If it is only one level of nesting, they may well be able to cope, but we
> have seen menus with more than ten levels of nesting and hundreds of nodes,
> and this is quite impossible to navigate sensibly.
>
> The worst examples are where only one node can be open at a time, so opening
> a new one automatically closes the last one. Screen reader users are totally
> unaware that this has happened so they cannot find menu items they found
> before.

Thanks Steve, that helps me understand the issues much more. i
appreciate it.

Donna
--
Donna Jones
Portland, Maine
207 772 0266
www.westendwebs.com

From: Donna Jones
Date: Mon, Feb 23 2009 10:20PM
Subject: Re: accessible tree menus
← Previous message | Next message →

From: Seth Kane
Date: Tue, Feb 24 2009 9:00AM
Subject: Re: accessible tree menus
← Previous message | Next message →

Donna-

What I would recommend is using a DHTML system that has all the event
handlers that allow for both mouse control and keyboard controls. I
would also make sure that the non-visible content is actually on the
page and can be read with a screen reader prior to any event handlers
firing. So what I am suggesting is using something like Suckerfish
Dropdowns that has all the content rendered on the page but off screen
for the people without disabilities and for people/screen readers the
content is always present and has no function tied directly to event
handlers and content/links.

Check out this... http://carroll.org.uk/sandbox/suckerfish/bones2.html

Seth Kane Sr. Presentation Layer Developer Office +1 (312) 696-5027
Fax +1 (312) 696-5001

From: Seth Kane
Date: Fri, Feb 27 2009 12:30PM
Subject: Re: accessible tree menus
← Previous message | Next message →

Here is a GREAT example of an Accessible Dropdown Navigation that uses
suckerfish or a version of it.

http://www.harvard.edu/

Seth Kane Sr. Presentation Layer Developer

From: John Foliot
Date: Fri, Feb 27 2009 12:50PM
Subject: Re: accessible tree menus
← Previous message | Next message →

Seth Kane wrote:
>
> Here is a GREAT example of an Accessible Dropdown Navigation that uses
> suckerfish or a version of it.
>
> http://www.harvard.edu/

*IF* you think that 36 links visually hidden but none-the-less present in
the source code represents an accessible solution, sure. (I don't)

Thing is, those links are "compacted" to avoid visual clutter, but for
non-seeing users, they still need to put up with the audio clutter.

That 'simple' home-page has 62 unique links presented to the end user.
This represents a usability barrier that involves cognitive over-load not
only for the non-sighted user, but for anyone who has difficulty
remembering or retaining long lists of data (here are 62 navigation
choices - I will read all of them out to you and then you tell me which
one you want, OK? Here goes: link 1: "featured stories", link 2: "more
news", link 3: "Harvard in the world", link 4: "main navigation", ... link
17: "Graduate School", link 18: "Law", link 19: "Medical".... link 37:
"General Info"... Link 61: "Accessibility"...)

Ya, accessible...

JF

From: Seth Kane
Date: Fri, Feb 27 2009 1:40PM
Subject: Re: accessible tree menus
← Previous message | Next message →

JF & Al-

Please understand that there is a MAJOR difference between Accessibility
and Usability. Annoying maybe but still accessible.

Web accessibility means that people with disabilities can perceive,
understand, navigate, and interact with the Web.

The thread started by someone asking if there was a way to create an
accessible drop down or DHTML menu and the fact is YES there is. Now I
will agree that most people using these overuse the amount of
information present but your statements are closed minded by stating
things like suckerfish or dropdowns in general are not accessible.

NO WHERE in any published guidelines does it say how much accessibility
is too much.

If there were only 9 Links on the page (3 Navigation Items, 3 Items Per
Drop Down) would you still say it is not accessible?

Now specifically with the Audio annoyance. Ask any Speech Reader user
if they prefer using quick functions to bounce around to Headers, Link
List, Form Controls, etc.. over just sitting there like a dead fish and
listening. Even on the WEBAim Screen Reader Study is says: 76% of users
always or often navigating by headings.
http://webaim.org/blog/screen-reader-survey-results/

There are great comments and input on this topic, however I think some
people become biased by the products they sell, ways THEY ALONE use the
web and stop really focusing on the goal. To make it as accessible to
as many possibilities. I have listed below the definitions of
accessible and simply put it is defined as "Providing Access"

........................................................................
..
Accessible http://www.merriam-webster.com/dictionary/accessibility

1: providing access

2 a: capable of being reached <accessible by rail> ; also : being
within reach <fashions at accessible prices> b: easy to communicate or
deal with <accessible people>

3: capable of being influenced : open <accessible to new ideas>

4: capable of being used or seen : available <the collection is not
currently accessible>5: capable of being understood or appreciated <the
author's most accessible stories> <an accessible film>
........................................................................
..

........................................................................
..
Usable http://www.merriam-webster.com/dictionary/Usability
1 : capable of being used
2 : convenient and practicable for use
........................................................................
..

Seth Kane Sr. Presentation Layer Developer

From: John Foliot
Date: Fri, Feb 27 2009 4:40PM
Subject: Re: accessible tree menus
← Previous message | Next message →

Seth Kane wrote:
>
> Please understand that there is a MAJOR difference between Accessibility
> and Usability. Annoying maybe but still accessible.

With all due respect Seth, I have been working in the web accessibility
space for close to a decade (and have been on the WebAIM list since Feb.
2002); I do not need to be told by you that there is a difference between
usability and accessibility.

>
> Web accessibility means that people with disabilities can perceive,
> understand, navigate, and interact with the Web.

No it means *people* can perceive, understand, navigate and interact.
Adding the term "disabled" misses the point completely - what does
'disabled' mean, exactly? That my 75 year old father's vision isn't what
it used to be - is that a disability? He doesn't think so - he's just
getting old. (FWIW, he struggles with this type of menu as well, and has
asked his son, the web accessibility guy, why sites continue to use them.
My answer? They don't fully understand the issue Dad...)

"In order to truly serve users with disabilities, accessibility must
mean more than simply providing "direct" access through assistive
technologies bundled with software, and more than providing the capability
to add such assistive technologies. It also must mean designing user
interfaces that are easier to use for users with disabilities as well as
users "without" disabilities by taking their needs into account when web
pages are designed."
http://www.otal.umd.edu/UUPractice/mobility/

>
> The thread started by someone asking if there was a way to create an
> accessible drop down or DHTML menu and the fact is YES there is. Now I
> will agree that most people using these overuse the amount of
> information present but your statements are closed minded by stating
> things like suckerfish or dropdowns in general are not accessible.

To be precise and clear, the 'techniques' being used can be made
accessible to adaptive technology. Whether or not content authors should
continue to use them remains very much open to discussion and debate. In
the example you posted (Harvard), the use of the dropdown menu causes
usability issues for many types of users, and is, in effect not very
accessible to more than just screen reader users.

This does not mean that authors should *never* use these types of menus,
but what it *DOES* mean is that there is a risk that their usage will
frustrate a certain percentage of your target audience. Further, there is
a very real risk that using these types of menus can quickly escalate
beyond annoying to out-right difficult without some clear guidance and
understanding of *ALL* the issues, not just the technical ones.
Overloading of links is one such issue... heck, if you can hide 10, might
as well hide 20, or 30, or 80... (and yes, I've seen that kind of menu too
- http://bullion.nwtmint.com/) It is cognitive overload gone wild.

>
> NO WHERE in any published guidelines does it say how much accessibility
> is too much.

Or too little. Your point?

>
> If there were only 9 Links on the page (3 Navigation Items, 3 Items Per
> Drop Down) would you still say it is not accessible?

The latest guidance, WCAG2, uses the term 'perceivable' (to attain
awareness or understanding of - Merriam-Webster), and I posit that having
in excess of 30 links collapsed inside a fly out menu affects many users
ability to perceive the totality of the navigation menu - they cannot see
the forest due to all of the trees. Would 9 be acceptable? Perhaps, but
when was the last time you saw a dropdown/fly out menu such as this with
only 9 links? [an example would be great]

>
> Now specifically with the Audio annoyance. Ask any Speech Reader user
> if they prefer using quick functions to bounce around to Headers, Link
> List, Form Controls, etc.. over just sitting there like a dead fish and
> listening. Even on the WEBAim Screen Reader Study is says: 76% of users
> always or often navigating by headings.
> http://webaim.org/blog/screen-reader-survey-results/

While WebAIM's survey results are a fantastic resource that our community
has needed for some time, you cannot simply paint all users as having one
particular way of interacting with the web. Classifying this as a
screen-reader issue simply illustrates a lack of deeper understanding of
the real issue - a major one being what I referred to previously as the
cognitive overload issue.

"Working memory is generally considered to have limited capacity. The
earliest quantification of the capacity limit associated with short-term
memory was the magical number seven introduced by Miller (1956). He
noticed that the memory span of young adults was around seven elements,
called 'chunks,' regardless of whether the elements were digits, letters,
words, or other units."
http://tinyurl.com/yvvne3

Whether or not you are prepared to admit it, first time or infrequent
visitors to the Harvard site will be assaulted by 62 link options off the
home page. Blind or not, this amount of choice ultimately results in few
concrete choices - there are simply too many to process - and this may in
fact impact on users with cognitive impairments, users whose primary
language is not English, lower-literacy users, etc.

"Unlike higher-literacy users, lower-literacy users don't scan text. As
a result, for example, they can't quickly glance at a list of navigation
options to select the one they want. They must read each word in each
option carefully. Their only other choice is to completely skip over large
amounts of information, which they often do when things become too
complicated."
"According to the U.S. Department of Education's National Assessment of
Adult Literacy, 43% of the U.S. population has low literacy. (Literacy
levels are roughly the same in other advanced countries, though slightly
higher in Scandinavia.)"
http://www.useit.com/alertbox/20050314.html
http://nces.ed.gov/Pubsearch/pubsinfo.asp?pubid=2006470

Some studies are now suggesting that too many choices is actually
detrimental to end users [http://tinyurl.com/6kbtff], and that too many
choices has a physical cost associated to it as well:

"There is a lot of physical overhead to thinking. The brain needs a lot
of energy to think, and hard thinking can actually lead to measurable
decreases in the body's energy supply. In addition, there are a number of
crucial brain chemicals that are limited resources that must be conserved
for important thinking tasks. So, we often try to think as little as
possible, unless there are great benefits to be obtained from that
thinking or very serious costs to be incurred by not thinking."
http://tinyurl.com/cepktx

Further, fly out and dropdown menus have usability issues associated to
those users with mobility impairments - often those who have
fine-motor-control issues struggle with getting the mouse in the right
location to activate the dropdown or fly out.

"I recommend against using "fly-out" menus in general... As a general
usability issue, they're often described as "slippery" by able-bodied
users, and can certainly create frustration among those with motor
impairments."
[NOTE: PDF File]
http://www.user-centereddesign.com/files/top5roadblocks.pdf

Finally, people who use screen magnifiers often find these menus hard to
use. When the screen is magnified extensively, dropdown items can
sometimes disappear off screen. In some cases, it is impossible to
navigate to the dropdown items, as moving the visible screen area
deactivates the dropdown.

>
> There are great comments and input on this topic, however I think some
> people become biased by the products they sell, ways THEY ALONE use the
> web and stop really focusing on the goal. To make it as accessible to
> as many possibilities.

Nope, I've not lost that focus - instead, I think I've actually stood back
further than you and spent some real time investigating the pros and cons
of this type of navigation, and have concluded that overall, they still
remain access barriers to a significant portion of the population.

Instead, I think *you* are trying to justify the usage of a tool that
still has some serious issues attached to it, simply because some clever
developers have come up with a 'technical' solution to exposing this type
of menu tool to adaptive technology, and that they look "cool" and make
sites "prettier" to a Presentation Layer Developer.

> I have listed below the definitions of
> accessible...
>
> 5: capable of being understood or appreciated

I think the above has addressed this definition directly.

JF

From: Steve Green
Date: Fri, Feb 27 2009 4:50PM
Subject: Re: accessible tree menus
← Previous message | Next message →

Thank you John. You have expressed my views more eloquently than I ever
could.

Steve

From: Chris Hoffman
Date: Fri, Feb 27 2009 5:20PM
Subject: Re: accessible tree menus
← Previous message | Next message →

On Fri, Feb 27, 2009 at 3:37 PM, Seth Kane < = EMAIL ADDRESS REMOVED = > wrote:

> Please understand that there is a MAJOR difference between Accessibility
> and Usability. Annoying maybe but still accessible.

I was recently pointed to an article, "Usable Accessibility: Making
Web Sites Work Well for People with Disabilities," that makes a pretty
convincing case that accessibility and usability are NOT as disparate
as most people seem to believe.
(http://www.uxmatters.com/mt/archives/2009/02/usable-accessibility-making-web-sites-work-well-for-people-with-disabilities.php)

Chris

From: Jim Thatcher
Date: Sat, Feb 28 2009 8:05AM
Subject: Re: accessible tree menus
← Previous message | Next message →

Well said John.

Has anyone mentioned the menu system at http://Bookshare.org? (I haven't
been following this thread and just "dropped in"!) I was flabbergasted when
it saw it the first time, given the intended audience. Once you know how to
use it, though, it is pretty impressive!

By the way, they do have some limited ARIA markup but not enough to make it
effective for screen readers in FF 3 and IE8.

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Chris Hoffman
Date: Sat, Feb 28 2009 9:55AM
Subject: Re: accessible tree menus
← Previous message | Next message →

On Fri, Feb 27, 2009 at 2:47 PM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:

> *IF* you think that 36 links visually hidden but none-the-less present in
> the source code represents an accessible solution, sure. (I don't)
>
> Thing is, those links are "compacted" to avoid visual clutter, but for
> non-seeing users, they still need to put up with the audio clutter.

Would having some sort of mechanism (oh, say, a _link_) that allows
users to easily skip from one menu to another without having to read
through every menu item help in this situation?

Chris

From: Jim Thatcher
Date: Sat, Feb 28 2009 10:35AM
Subject: Re: accessible tree menus
← Previous message | Next message →

Well Chris, it is hard for me to imagine a link working, but
http://Bookshare.org that I mentioned in the last post uses arrow keys for
keyboard users, just like a Windows menu system, and headings (h3)
navigation for screen reader users since, for them, arrows are "in use"
(until ARIA is well supported).

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: John Foliot
Date: Sat, Feb 28 2009 12:35PM
Subject: Re: accessible tree menus
← Previous message | Next message →

Chris Hoffman wrote:
>
> Would having some sort of mechanism (oh, say, a _link_) that allows
> users to easily skip from one menu to another without having to read
> through every menu item help in this situation?
>
Fair question. Answer = depends.

If it is a frequently visited site, then yes, inter-page navigation,
including (oh say, a link) that skips over large blocks of navigation can
certainly assist non-sighted users. This is hardly new or novel; in fact,
it's the "skipnav" link that many developers add to be Section 508
compliant (even though a close reading of that spec does not actually
mandate this, only that a means to skip past a navigation block exist: "A
method shall be provided that permits users to skip repetitive navigation
links.").

Thing is, before you skip over large blocks of anything, you need to know
*what* you are skipping over - and for non-sighted users the only way to
really know what that is, is to actually have to process it/them. In the
case of the mint site I referenced [http://bullion.nwtmint.com/], that
would be *all 80* of those links. (Other hints, such as using headings or
the summary or title attributes can also assist here, but
in-and-of-themselves are not complete solutions)

The bigger take-away here is that real accessibility is nuanced and
subtle, and that pure 'technique' alone neither ensures accessibility nor
is the only answer. Use your heads people, and remember that the goal is
users first, not technology. Think about structure, and yes usability,
not just for the mainstream user, but for all users - think hard when
making foundational choices. Try hard to avoid thinking in terms of
user-agents and adaptive technology, and instead think about how users
might interact with your web content in ways other than the way that *you*
interact - one truism that Seth did note in his initial response. Does
providing 80 links from your navigation mechanism really help users, or
confuse them by providing too many links all at once - would a drill down
navigation scheme work better? Remember too that site owners are often
hyper-aware of their content and structure, but first-time or infrequent
visitors are 'learning' your site as they go - they lack the luxury of
being involved with your site since its inception. First impressions are
key, and usability for all users is a big part of that first impression.

JF

From: Chris Hoffman
Date: Sat, Feb 28 2009 1:30PM
Subject: Re: accessible tree menus
← Previous message | Next message →

On Sat, Feb 28, 2009 at 2:33 PM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:

> Thing is, before you skip over large blocks of anything, you need to know
> *what* you are skipping over - and for non-sighted users the only way to
> really know what that is, is to actually have to process it/them. In the
> case of the mint site I referenced [http://bullion.nwtmint.com/], that
> would be *all 80* of those links. (Other hints, such as using headings or
> the summary or title attributes can also assist here, but
> in-and-of-themselves are not complete solutions)

I disagree. The limits of our cognition (not to mention the limits of
time) require that we skip over large blocks of content all the time
without knowing their exact details, whether we are sighted or not.

Let's say I go to the bookstore, looking for a book with a recipe
using sugar snap peas. I will go directly to the Cooking section, and
from there I'd likely go directly to the Vegetables section. Now,
there is a good chance that there is a novel somewhere on the other
side of the store in which the author describes in great detail a
delicious sugar snap pea casserole, and by skipping over the
Literature section and not reading through every page of every book, I
will have missed it. Frankly, that's just tough legumes for me.

That said, my book browsing technique is probably _good enough_ to
help me find some suitable pea recipes.

Now of course there are certain expectations that the bookstore will
have to meet if I am to be successful (we can call them "standards" or
"best practices"). For one, if this is my first time in the store, it
would be nice to have a map (or a friendly clerk) at the front door to
guide me to a particular section. Second, I have a reasonable
expectation that the books will be organized into their respective
categories. If both of those conditions are met, then I'm likely to
find the content I'm looking for, whether this is my first visit to
the store or I'm a regular.

> Use your heads people, and remember that the goal is
> users first, not technology. Think about structure, and yes usability,
> not just for the mainstream user, but for all users - think hard when
> making foundational choices. Try hard to avoid thinking in terms of
> user-agents and adaptive technology, and instead think about how users
> might interact with your web content in ways other than the way that *you*
> interact.

I think you'd be hard-pressed to find members on this list who are not
trying their hardest to do just that.

Best,

Chris

From: Rich Pedley
Date: Sat, Feb 28 2009 1:50PM
Subject: Re: accessible tree menus
← Previous message | Next message →

On 28/02/2009 20:25, Chris Hoffman wrote:
> On Sat, Feb 28, 2009 at 2:33 PM, John Foliot < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Thing is, before you skip over large blocks of anything, you need
>> to know *what* you are skipping over - and for non-sighted users
>> the only way to really know what that is, is to actually have to
>> process it/them. In the case of the mint site I referenced
>> [http://bullion.nwtmint.com/], that would be *all 80* of those
>> links. (Other hints, such as using headings or the summary or
>> title attributes can also assist here, but in-and-of-themselves
>> are not complete solutions)
>
> I disagree. The limits of our cognition (not to mention the limits
> of time) require that we skip over large blocks of content all the
> time without knowing their exact details, whether we are sighted or
> not.

I've snipped your example - because it is very good.

"Without knowing exact details" - so you need a clue as to what is
there. So headings can help here. But lets image for a moment there
are no headings. If you look with your eyes at a block of text, even
without consciously reading it you are able to gleam an awful lot of
information. One technique for speed reading is to read a column down
the centre of the page and let your brain pick up the sides by
peripheral vision. However a blind person, which this is possibly more
relevant to than other forms of disabilities, cannot do that. For
obvious reasons.

So although we as sighted users can skip over things without knowing
their exact details, we have in fact picked up tidbits here and there.
So there should be some form of identification as to what the large
block is - which is why we have headings.

Rich

From: John Foliot
Date: Sat, Feb 28 2009 1:55PM
Subject: Re: accessible tree menus
← Previous message | No next message

Chris Hoffman wrote:
>
> I disagree. The limits of our cognition (not to mention the limits of
> time) require that we skip over large blocks of content all the time
> without knowing their exact details, whether we are sighted or not.

There is a difference between knowing exact details and knowing any details.
Knowing too many details, especially when unsolicited, can be as frustrating
as knowing no details, and this is the point of the discussion. What are we
skipping over here:
<div>

</div>

You have 2 choices - I can tell you everything inside that div, or you can
remain completely unaware of its contents. This is the reality that some
users of Adaptive Technology are faced with, and the reality we need to
consider as we structure our content.

>
> Let's say I go to the bookstore, looking for a book with a recipe
> using sugar snap peas. I will go directly to the Cooking section, and
> from there I'd likely go directly to the Vegetables section.

There is a Borders store in the local mall near me. Without knowing the
layout of the store, please direct me to the Vegetables section in the
Cooking section. You can't, because you are unaware of the layout of the
store. Now should you arrive in person, you will have *VISUAL* sign-posts
that will guide you to the section you are looking for, and more
importantly, you could quickly scan the entire store looking for clues to
quickly direct you to the cooking section. But if you cannot see the
way-finding signs, you could likely wander the store unassisted for quite
some time before you found the vegetables section of the cooking section.

>
> Now of course there are certain expectations that the bookstore will
> have to meet if I am to be successful (we can call them "standards" or
> "best practices"). For one, if this is my first time in the store, it
> would be nice to have a map (or a friendly clerk) at the front door to
> guide me to a particular section.

A store map that outlined the contents of every row of books might be
useful, but it would take you a significant amount of time to peruse all of
the row choices, although once you found what you were looking for, you
could rapidly zero in on that row of books. This is the role of a site map.

However, if I told you simply that the non-fiction books were on the right
side of the store, and that self help books were toward the back... well
now, that's concise and useful directions that get you a lot closer to where
you really want to be, and would likely be a better model for persistent
navigation - get you in the generally vicinity quickly without having to
answer too many questions or process too many choices.

>
> I think you'd be hard-pressed to find members on this list who are not
> trying their hardest to do just that.
>

And I for one am not suggesting that. However it is useful sometimes to
remind everyone that the goal should be a people-first approach, and not a
technology for the sake of technology approach... and the oldest one of all,
on-line accessibility is not simply about screen readers - a point I tried
very hard to illustrate in my lengthy posting earlier.

JF