E-mail List Archives
RE: Accessible popup menus
From: John Foliot - WATS.ca
Date: Jul 29, 2005 8:15AM
- Next message: Al Sparber: "Re: Accessible popup menus"
- Previous message: Thomas Jedenfelt: "Re: Accessible popup menus"
- Next message in Thread: Al Sparber: "Re: Accessible popup menus"
- Previous message in Thread: Thomas Jedenfelt: "Re: Accessible popup menus"
- View all messages in this Thread
Al Sparber wrote:
>>> My goal is not to get a seal of approval from an accessibility
>>> "guru". My goal is to defend my product, and also to have some
>>> enjoyable debates. Perhaps no one has pressed these kinds of issues
>>> before :-)
>> Al, One would have to ask what you are defending your product from.
>> You put up a test page with a menu you claimed was accessible, as
>> soon as this was challenged you put up the defence barriers and
>> attacked anyone who criticised your test page.
> I'm defending my product because an opinion issued by Thatcher was
> posted on our public newsgroup and it claimed our menu was not
> accessible. I disagree.
...and some (many?) on this list disagree with you.
"Mr." Thatcher is an established, internationally-acknowledged web
accessibility expert and author, who has research, time and experience
on his side. He has opinions and expertese based upon real world work
in this field. His contributions to the "art" of web accessibility need
no defence, and your pompus and ignorant tone paints you as a jerk -
whether you really are or not. Tone down the rhetoric and listen to
what the list members are saying.
> I'm not known in these parts, but I do have a reputation in
> certain web development circles as a voice of reason.
Sadly, your beligerent and superior tone refutes this statement. Jim
Thatcher has a reputation in certain circles as being a pioneer in this
field - something you fail to accept. And if we're gonna throw
"reputations" around, I might note (humbly) that I too have a bit of a
reputation in this field, as a regular contributor to this and others,
as co-founder of WATS.ca (an oft referrenced resource), and a big fan of
google (http://www.google.com/search?q=web+accessibility+specialist) [as
much a sign of our expertise in SEO as well as web accessibility]
> A simple look at the number of people who have to use the keyboard (I
> totally discount people who choose not to use a mouse, as they are
> primarily over-zealous about something or other) paints a clear
> course: Develop for the majority and provide alternate paths for the
> minority. If you do it in reverse that's an opinion now, is it not?
"All animals are equal but some animals are more equal than others."
George Orwell (1903 - 1950), "Animal Farm"
Thanks for your "opinion" Sparber...
I get a very real sense that you've developed something (your
"product") which you now seek to have 'validated' by real world web
accessibility proponents (why else mysteriously show up on this list and
post your example?). When the experts point out issues with your
solution you take to insult and a superior tone and chastize those that
seek to offer their thoughts and opinions. If these opinions are not
what you are seeking, why did you ask in the first place?
There are a number of issues with *your* drop-down menu system (I sent
you a screen capture off list showing the rendering issue), and as
others have pointed out, there are also issues beyond "technical" and
"technique" with all flyout type menus such as yours - the tabbing issue
is now well discussed on this list. Having a nested list with 44
different list items links is going to be an issue for many users -
flyout (compacted) menus or not. It's information overload (too many
initial choices) that can affect users with cognative impairments, and
is covered by WCAG Guideline Priority 2 - 12.3 "Divide large blocks of
information into more manageable groups where natural and appropriate".
If you think about it, using compacted (flyout) menus such as yours
acknolwedge this very point - this is why you are compacting the list in
the first place, no? Perhaps a better method is to re-think the
navigation process into better "streams", rather than seek to provide
*all* the links every time on every page - (go back, re-read that
Your "technique" appears to follow current guidelines and best practises
- so that is a positive. But to claim that it "conforms" to Section 508
and WCAG AAA guidelines or standards misses another real point that has
been brought up; "if" the CSS method is properly integrated into a
larger whole. What if somebody took your code, but used it with a fixed
font size for rendering purposes (so that it "displays" according to
some graphic designers "vision"). What then? Fail... So remember and
understand - accessibility needs to be judged both in context and as a
whole; <img src="..." alt="button"> is technically valid, but practicly
useless as the alternative text means nothing to those users that would
require that information. Consider as well: what if this codeblock
(complete with all 44 links, such as at projectseven.com) is placed at
the "top" of your source code - minus a "skip nav" link or equivelant...
Is it still "accessible"? Many (most) would argue no, and it certainly
would not pass muster under Section 508.
A quick review of your own site (http://www.projectseven.com/index.htm)
finds your navigation block at the end of your source code... Yet there
is no "quick" way for text only or speech browsers to quickly access
this code block... Instead the page must be "read" to the end before we
reach the nav block. This is an accessibility issue! (and BTW, fails
WAI AAA Status (WCAG Priority 2 - 9.5 "Provide keyboard shortcuts to
important links (including those in client-side image maps), form
controls, and groups of form controls.") - plus without the proscribed
"Skip Nav" link you fail Section 508 (