E-mail List Archives
Thread: Accessible accordion menus
Number of posts in this thread: 15 (In chronological order)
From: Ritz, Courtney L. (GSFC-7500)
Date: Thu, Mar 05 2009 2:30PM
Subject: Accessible accordion menus
No previous message | Next message →
Hi all,
Can anyone point me to some examples of accessible accordion-style
menus? I hope I'm terming them correctly. I'm referring to menus where
there's a link or button that, when activated, expands into more links
or buttons on the current page.
A developer of one of our sites here has used some Javascript to create
one that is not accessible, and though I'm a JAWS user and knowledgeable
in Section 508 and accessibility, I am not skilled in coding much more
than basic HTML.
Unfortunately, I cannot provide a link to the current version of the
menu being used, because it is behind a firewall, which is why I'm
hoping to direct the developer to some examples of accordion menus that
are accessible.
Any help would be greatly appreciated. Thanks.
Courtney
From: John Foliot
Date: Thu, Mar 05 2009 2:55PM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
Ritz, Courtney L. wrote
>
>
> Can anyone point me to some examples of accessible accordion-style
> menus?
NO - LOL
Please read this recent thread:
http://webaim.org/discussion/mail_thread.php?thread=3782
And in particular, my diatribe here:
http://webaim.org/discussion/mail_message.php?id=12588
Then, if you still must, Google "son of suckerfish" or (here Al, I'll save
you the trouble) see the PVII solution: http://www.projectseven.com/
JF
From: Seth Kane
Date: Thu, Mar 05 2009 3:00PM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
Oh boy, here we go again.
Seth Kane Sr. Presentation Layer Developer
From: Al Sparber
Date: Thu, Mar 05 2009 4:20PM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
From: "John Foliot" < = EMAIL ADDRESS REMOVED = >
> Ritz, Courtney L. wrote
>>
>>
>> Can anyone point me to some examples of accessible accordion-style
>> menus?
>
> NO - LOL
>
> Please read this recent thread:
> http://webaim.org/discussion/mail_thread.php?thread=3782
>
> And in particular, my diatribe here:
> http://webaim.org/discussion/mail_message.php?id=12588
>
> Then, if you still must, Google "son of suckerfish" or (here Al, I'll save
> you the trouble) see the PVII solution: http://www.projectseven.com/
Huh? What did I do now :-)
Seriously, whichever menu the gent chooses to use, it would make sense to do
it this way:
http://www.projectseven.com/products/menusystems/pmm2/ug-examples/accessible/
I know some folks have done some interesting things with arrow key support,
but as a Jaws 10 user I can now attest to the fact that completely hiding
the menus from blind surfer is the better solution. It can be done with any
scripted menu, but it cannot be done with Son of Suckerfish.
--
Al Sparber - PVII
http://www.projectseven.com
The Finest Dreamweaver Menus | Galleries | Widgets
http://www.projectseven.com/go/pop
The Ultimate DW Menu System
From: Despain, Dallas
Date: Thu, Mar 05 2009 6:00PM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
Watch out! :)
Dallas Despain | RightNow Technologies | Developer | 406-556-3454 | Salt Lake City, UT
From: Ritz, Courtney L. (GSFC-7500)
Date: Fri, Mar 06 2009 11:50AM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
Hi again,
Thanks for the examples, and I'm sorry to have stirred up something here. (grin)
I think the reason the developer went with this accordion menu was because the customer (my organization) wanted a less cluttered page. So the extra info wouldn't be displayed until one of the main menu items was selected. But I would think that there are so many other simpler ways of achieving this. I'd almost rather see a separate HTML page for each section than a huge script-heavy page that expands all its menus on that same page.. That's just my opinion as a user, but I may well be behind the times on that.
T
Hanks.
Courtney
From: John Foliot
Date: Fri, Mar 06 2009 12:15PM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
Ritz, Courtney L. wrote:
>
> Thanks for the examples, and I'm sorry to have stirred up something
here.
> (grin)
Nah, it's all good. 'Twas a 'full exchange' a week or three ago, but it's
all good. To Al and Seth - peace! (Seth, I am swamped today, but will
respond to your question more fully when I have a chance - but I will
respond)
>
> I think the reason the developer went with this accordion menu was
because
> the customer (my organization) wanted a less cluttered page. So the
extra
> info wouldn't be displayed until one of the main menu items was
selected.
> But I would think that there are so many other simpler ways of achieving
> this. I'd almost rather see a separate HTML page for each section than
a
> huge script-heavy page that expands all its menus on that same page..
That's
> just my opinion as a user, but I may well be behind the times on that.
The big takeaway is that developers (and their task masters) need to
*really* think about what they are doing. Your idea is certainly along
the lines of how I would counsel a client or manager, but I also
understand that there are competing voices around any table. For me, the
key point you have identified is that the menu would be used to mitigate
visual clutter, to which I ask, "...and the audio clutter?..."
JF
From: Al Sparber
Date: Sun, Mar 08 2009 12:10AM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
From: "John Foliot" < = EMAIL ADDRESS REMOVED = >
> Nah, it's all good. 'Twas a 'full exchange' a week or three ago, but it's
> all good. To Al and Seth - peace!
And to you, too :-)
>> I think the reason the developer went with this accordion menu was
> because
>> the customer (my organization) wanted a less cluttered page. So the
> extra
>> info wouldn't be displayed until one of the main menu items was
> selected.
>> But I would think that there are so many other simpler ways of achieving
>> this. I'd almost rather see a separate HTML page for each section than
> a
>> huge script-heavy page that expands all its menus on that same page..
> That's
>> just my opinion as a user, but I may well be behind the times on that.
If that's so, the industry needs more people like you. You are not behind
the times, you are simply reacting in a logical manner to what you
rightfully perceive as visual glitter at the expense of accessibility. We do
things slowly and methodically and after my tirade on this list 2 years ago,
we did some homework. Here's what we discovered:
Most javascript authors either don't know what they are talking about or, if
they do, wind up deploying Rube Goldberg-esque solutions to simple problems.
Scripting keyboard support for a drop-down/flyout menu, for instance, that
is almost like native OS keyboard support is totally useless as users must
learn how it works before they can use it. The only solution at the present,
that makes any sense at all, is to kill the sub-menus and link the root
links to landing pages. Done correctly and efficiently it is not extra work
for the developer, but rather an incentive to structure a site in a friendly
manner so that it pulls users - all users - through.
ARIA is a ridiculous solution for client-side widgets (like accordions, tab
panels, scrollers, etc, that simply hide/show/animate content). ARIA can be
a good solution for Ajax that updates page content - but if it's not done in
the scope of a total accessibility schema, it is half-arsed at best and
worthless at worst - That is, if JavaScript-disabled users are not
considered it would be as if a Windows-based Web developer decided to block
content for all Mac users. The numbers could easily be that high.
When it comes to accessibility, the fault lies with the authors of assistive
software and with Web developers who go pedal-to-the-metal with open source
script libraries like JQuery, Prototype, and YUI without really considering
a realistic accessibility plan.
The infamous Target lawsuit was very nice, but to really bring about change,
lawsuits should be filed against Freedom Scientific, Yahoo, Google, and any
other large entity that has the juice to make the changes that really count.
I'm not an experienced Jaws user, but I'm probably no worse at it than a
fellow who has recently lost his vision and is trying like hell to get back
into the world. I'm a sports fan. I can't follow the things I'm accustomed
to following on ESPN or YahooSports. Much of it (almost all of it in the
case of ESPN) is inaccessible.
Fredom Scientific could easily cause a revolution in accessibility by simply
reading the content in pages from top-to-bottom with either total disregard
for style sheets or, better still, by supporting CSS media types.
The whole thing disgusts me. If I hear Suckerfish or UDM or Spry one more
time I could go postal :-)
In any event, we spent 1 hour this evening making a widget that we have in
development totally accessible for:
1. Jaws 10
2. Keyboard surfers
3. Javascript-disabled surfers
Here is the test page.
http://www.projectseven.com/accessibility-tests/accordions/index_all.htm
Now, I have no idea if this is going to work in Jaws 5, 6, 7, 8, or 9 - but
it should and if it doesn't, Scientific American should be ashamed of
themselves and should provide free updates to its customers.
As a blindfolded Jaws user, what I like to hear is a page automatically read
from top to bottom, without my having to stop and press enter or stop and
press my arrow keys. It's not that difficult to do and it has nothing to do
with ARIA or Rube Goldberg scripting.
Sorry for the rant, but perhaps this will be helpful to someone.
--
Al Sparber - PVII
http://www.projectseven.com
From: Al Sparber
Date: Sun, Mar 08 2009 12:25AM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
From: "Al Sparber" < = EMAIL ADDRESS REMOVED = >
> it should and if it doesn't, Scientific American
I meant, of course, Freedom Scientific.
From: Angela French
Date: Mon, Mar 09 2009 10:00AM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
It just so happens that I'm working on one myself that would be nice if a JAWS user could test it. I would ge grateful if you would. Here is the complete html test file.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Test Expanding menus</title>
<script type="text/javascript">
function expandItem(item) {
document.getElementById(item).style.display = document.getElementById(item).style.display == ' || document.getElementById(item).style.display == 'none' ? 'block' : 'none';
if (document.getElementById(item).style.display == 'block') {
/*this is an attempt to assure accessibility - to make the screen reader take focus on the news item
when a news title has been clicked. */
document.getElementById(item).focus();
}
}
</script>
<style type="text/css">
div.submenu {
display:none;
}
</style>
</head>
<body>
<ul id="navlist">
<li class="noimage" id="active"><a href="#" id="current">Home</a></li>
<li class="noimage" >
<img src="../images/b_About.jpg" alt="About WELA"/>
<a href="About" onclick="expandItem('About');return false;">
<img src="../images/downarrow.jpg" alt="expand submenu 1" /></a>
<div id="About" class="submenu">
<ul>
<li><a href="#">sub link #1</a></li>
<li><a href="#">sub link #2</a></li>
<li><a href="#">sub link #3</a></li>
</ul>
</div>
</li>
<li class="noimage">
<img src="../images/b_Apply.jpg" alt="About WELA"/>
<a href="Apply" onclick="expandItem('Apply');return false;">
<img src="../images/downarrow.jpg" alt="expand submenu 2" /></a>
<div id="Apply" class="submenu">stuff in submenu 2</div>
</li>
<li class="noimage"><a href="#">WELA Graduates</a></li>
<li class="noimage"><a href="#">For Current Members</a></li>
</ul>
</body>
</html>
From: Seth Kane
Date: Mon, Mar 09 2009 10:25AM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
I can tell you right now it won't work because display: none omits
everything from jaws.
http://juicystudio.com/article/screen-readers-display-none.php
Try using off page positioning instead if you continue to go this route.
Seth Kane Sr. Presentation Layer Developer
From: Patrick H. Lauke
Date: Mon, Mar 09 2009 10:45AM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
On Mon, Mar 9, 2009 at 4:24 PM, Seth Kane < = EMAIL ADDRESS REMOVED = > wrote:
> I can tell you right now it won't work because display: none omits
> everything from jaws.
> http://juicystudio.com/article/screen-readers-display-none.php
>
> Try using off page positioning instead if you continue to go this route.
Seth,
not specifically looked at Angela's code, but just as a general rule
there are situations where display:none is indeed exactly what you
want to use, rather than off-page techniques. Otherwise, even for a
sighted keyboard user, you end up with having to tab through all links
in the hidden panel/submenu/accordion fold/etc. Provided that there's
an activation link that is clear and then reverts the display:none to
display:block (as I can spy in Angela's code), that's exactly the
right way to do it.
IMHO of course,
P
--
Patrick H. Lauke
From: Al Sparber
Date: Mon, Mar 09 2009 11:20AM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
From: "Angela French" < = EMAIL ADDRESS REMOVED = >
> It just so happens that I'm working on one myself that would be nice if a
> JAWS user could test it. I would ge grateful if you would. Here is the
> complete html test file.
Hi Angela,
In a completely default installation of Jaws 10, after "clicking" your image
links, Jaws stops working. Silence. In order to access the sub-menu items I
must then press my down arrow key to "hunt" for the list inside. It is,
however, accessible in that manner.
Our quest was a bit different in that we wanted our visually hidden
accordion content accessible to a brand new Jaws user. That is, we wanted
Jaws to begin reading the page and to read our hidden content contiguously,
without interruption.
Seth's proposal does not work well for a menu but does work for an
accordion - which this thread does not quite have correctly defined. My
original test page is an accordion. Accordions can contain menus but more
often contain mixed content. Your page has drop-down menus.
Menus are a completely different animal in terms of accessibility and
drop-down menus, in my opinion, should be seen and not heard - especially
within the scope of Seth's past posts.
Your menu, however, since it is relatively small in scope could be better
deployed thusly:
Have your triggers be headings.
Use background images over real text.
Position the menu lists off-screen.
Assign your onclicks assigned programmatically instead of being on the tags
Place a skip-nav link above the first heading.
Perfect now :-)
--
Al Sparber - PVII
http://www.projectseven.com
From: John Foliot
Date: Mon, Mar 09 2009 11:40AM
Subject: Re: Accessible accordion menus
← Previous message | Next message →
Al Sparber wrote:
>
> Your menu, however, since it is relatively small in scope could be
better
> deployed thusly:
>
> Have your triggers be headings.
> Use background images over real text.
> Position the menu lists off-screen.
> Assign your onclicks assigned programmatically instead of being on the
tags
> Place a skip-nav link above the first heading.
>
> Perfect now :-)
>
...*AND* keep the number of links low. Re: Seth's off-screen suggestion,
be sure to read Jared's post:
http://webaim.org/blog/hiding-content-for-screen-readers/
From: ben morrison
Date: Tue, Mar 10 2009 4:20AM
Subject: Re: Accessible accordion menus
← Previous message | No next message
On Mon, Mar 9, 2009 at 4:40 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >wrote:
> On Mon, Mar 9, 2009 at 4:24 PM, Seth Kane < = EMAIL ADDRESS REMOVED = > wrote:
> > I can tell you right now it won't work because display: none omits
> > everything from jaws.
> > http://juicystudio.com/article/screen-readers-display-none.php
> >
> > Try using off page positioning instead if you continue to go this route.
>
> Seth,
>
> not specifically looked at Angela's code, but just as a general rule
> there are situations where display:none is indeed exactly what you
> want to use, rather than off-page techniques. Otherwise, even for a
> sighted keyboard user, you end up with having to tab through all links
> in the hidden panel/submenu/accordion fold/etc. Provided that there's
> an activation link that is clear and then reverts the display:none to
> display:block (as I can spy in Angela's code), that's exactly the
> right way to do it.
>
> IMHO of course,
>
I also use display:none, but to assist with non -js users I use some very
simple JS to add a class of 'jsenabled'
that way we can target display:none like so
.jsenabled .accordion li.closed { display:none;}
Ben
--
Ben Morrison