"David Dorward" <do*****@yahoo. com> wrote in message
news:be******** ***********@new s.demon.co.uk.. .
I am optimistic and believe that a hierarchical menu script
can be written to address the problems of cleanly degrading
on JavaScript disabled and unsupportive/insufficiently
dynamic browsers, accessibility
There are two big problems with h-menus in general.
(1) people with motor skill problems (although activating
onclick and onfocus can go a long way to dealing with this).
Yes, keyboard navigation is essential, though that is as much for laptop
users who have learnt all the keyboard shortcuts (so they can avoid
using the built in "pointing device") as anyone else.
(2) People using screen scrapers. Its unfortunate that most
software products for reading webpages aloud are not true
aural browsers (parsing the HTML, and applying aural CSS),
but instead are Internet Explorer screen scrapers. From what
I hear, they don't react well to pages gaining new visible
elements dynamically.
I have often wondered how an aural browser would implement the dynamic
DOM level 2 interfaces (createElement, appendChild, and so on). What
should it do if a text node was inserted? Suddenly blurt out the text,
start reading the document again from the beginning or ignore the
insertion? In the latter case it would make most sense to never
implement the interface at all as at least that could be detected by a
script.
The thing that seems to distinguish h-menus from the tree-menu
alternatives is the need to use CSS that will potentially render the
contents of the nested ULs [1] inaccessible (display:inline ; on the top
level items and position:absolu te;, visibility:hidd en;/dispaly:none; on
the sub menus). My strategy is to have an external CSS provide most of
the styling for the ULs but to use JavaScript in the HEAD of the page to
write out a STYLE section that introduces the critical CSS. Obviously in
the absence of JavaScript the ULs retain their externally specified (or
default) display characteristics so clean degradation is achieved.
The viability of the exercise hangs on the ability of the script to make
the right decision about writing out that STYLE section. If it decides
not to then it only has to disable it's own initialisation routine and
everything degrades to a usable UI. If it decides to insert the STYLE
section it must be 100% certain that the browser will fully support the
menu script and that the result will be suitably usable UI. I am
confident that detecting suitably dynamic browser support is realistic
but, as you point out, being confident that the result will be a usable
UI under all circumstances is another question. I will have to resolve
that question to my own satisfaction through experimentation , which will
either tell me how it can be done or why it cant be done (either of
which will be useful knowledge).
David's other proposal (I suspect tongue in cheek)
I have been known to go tongue in cheek, but this time I was
serious. Its difficult, impractical and time consuming - but
just about possible.
I didn't mean to imply that you did not think that it was doable. I was
hoping to suggest that its presence in the list was merely to provide a
comprehensive list of alternatives and that you were not presenting it
as a realistic course of action. Given your undisguised preference for
the elimination of frames and your describing the simultaneous aligning
of elements across a frameset as "difficult, impractical and time
consuming" I don't think that you do consider it a realistic course of
action when compared with your 3 other suggestions.
A few weeks ago I wrote a script that aligned a DIV in each frame of a
frameset (to the mouse pointer) in response to a question on the group.
It was not good enough to be more than a demonstration of the principal
but it was enough to give me a reasonable handle on the issues. I learnt
that it would be much easier to tailor such a script to a known
frameset, which is why I don't think that there will be an adequate
off-the-shelf solution available. I am confident that it can be done (to
the extent that the menu itself can) but the prospect of layering that
requirement on top of the menu script and implementing it for each page
that may pass through the frameset is daunting.
Richard.
[1] Like many others, I have concluded that nested ULs are the only
sensible mark-up to use as the basis for this type of menu, as they
offer a familiar and usable presentation of the hierarchical navigation
structure in the absence of both CSS and JavaScript.
