E-mail List Archives
Thread: mouseover/hover and keyboard accessible expandable menu?
Number of posts in this thread: 52 (In chronological order)
From: Nancy Johnson
Date: Fri, Nov 06 2009 7:55AM
Subject: mouseover/hover and keyboard accessible expandable menu?
No previous message | Next message →
Does anyone on this group know of a left-hand vertical navigation menu
that will expand on mouseover or hover, however is keyboard
accessible?
CSS with either js or jquery is fine.
Thanks in Advance
From: Moore,Michael (DARS)
Date: Fri, Nov 06 2009 8:20AM
Subject: Re: mouseover/hover and keyboard accessible expandable menu?
← Previous message | Next message →
HTML Dog has some good examples http://htmldog.com/articles/suckerfish/dropdowns/example/vertical.html
Mike Moore
(512) 424-4159
From: Jason Megginson
Date: Fri, Nov 06 2009 8:40AM
Subject: Re: mouseover/hover and keyboard accessible expandable menu?
← Previous message | Next message →
HTML Dog is an excellent source for clean HTML and CSS. However, I would
improve upon their example by including an onFocus event so the sub-menus
appear when keyboard focus is present on the parent menu item and as the
focus is on the sub-menu items as a user tabs.
This provides accessibility to sighted and non-sighted keyboard users.
Jason Megginson
From: Al Sparber
Date: Fri, Nov 06 2009 9:20AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
From: "Jason Megginson" < = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, November 06, 2009 10:37 AM
Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
expandablemenu?
> HTML Dog is an excellent source for clean HTML and CSS. However, I would
> improve upon their example by including an onFocus event so the sub-menus
> appear when keyboard focus is present on the parent menu item and as the
> focus is on the sub-menu items as a user tabs.
>
> This provides accessibility to sighted and non-sighted keyboard users.
It also forces keyboard users to have to tab through all sub-menu items,
which presents usability problems tabbing to fifth root item when there are
40 sub-menu items in the way :-)
The most accessible *and* usable menus of this kind are ones in which the
sub-menus are not available to keyboard or non-sighted people, but which
instead include links on the root items to "landing" pages, from which links
in the relevant sub-menu are present in the flow of the document's visible
content areas.
--
Al Sparber - PVII
http://www.projectseven.com
Dreamweaver Menus | Galleries | Widgets
http://www.projectseven.com/go/apm
An Accessible & Elegant Accordion
From: Karl Groves
Date: Fri, Nov 06 2009 9:25AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
>
> The most accessible *and* usable menus of this kind are ones in which
> the
> sub-menus are not available to keyboard or non-sighted people, but
> which
> instead include links on the root items to "landing" pages, from which
> links
> in the relevant sub-menu are present in the flow of the document's
> visible
> content areas.
Al,
I do not agree with this statement. While I would agree that the root
menu item should be a real link to an actual destination, I hardly regard
it as accessible or usable to not provide programmatic access and visual
focus to sub-menu options.
Karl
From: Moore,Michael (DARS)
Date: Fri, Nov 06 2009 9:45AM
Subject: Re: mouseover/hover and keyboard accessible expandable menu?
← Previous message | Next message →
Sorry I thought that was included - I guess that I forgot that I had added it to the code that I had "borrowed" from the site. I would also add that more than one drop down level really decreases usability. imho
Mike Moore
(512) 424-4159
From: deblist
Date: Fri, Nov 06 2009 9:50AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
On Fri, 6 Nov 2009, Al Sparber wrote:
> The most accessible *and* usable menus of this kind are ones in which the
> sub-menus are not available to keyboard or non-sighted people, but which
> instead include links on the root items to "landing" pages, from which links
> in the relevant sub-menu are present in the flow of the document's visible
> content areas.
As a hands-free (and therefore keyboard-only) disabled user
myself, I strongly disagree with this. I very much prefer getting
the same user experience that non-keyboard-only users have, which
includes the drop-down menus. This is a fundamental principle of
universal design!
Getting shunted to landing pages for me is the accessible minimal
acceptable solution, but it is certainly not the way I like to
work.
-deborah
From: Jared Smith
Date: Fri, Nov 06 2009 9:55AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
On Fri, Nov 6, 2009 at 9:21 AM, Karl Groves
< = EMAIL ADDRESS REMOVED = > wrote:
> I do not agree with this statement. While I would agree that the root
> menu item should be a real link to an actual destination, I hardly regard
> it as accessible or usable to not provide programmatic access and visual
> focus to sub-menu options.
There are really only three approaches to such menu accessibility:
1. Force the user to listen to and navigate through all menu items.
This is not efficient. It is certainly not the same experience sighted
and mouse users have. The hierarchy of such menus is hard to convey to
someone listening to them. It's overwhelming and confusing. Hardly
accessible.
2. Program the menu to be technically keyboard/screen reader
accessible. The problem with this approach is that there is no
standard way of doing so. Do you open the menu with space or enter? Do
the arrow keys expand/collapse the menu? Up and down or left and
right? How are you to know if you can't see it? And again, hierarchy
and semantics are nearly impossible to convey with such menus. Without
standard controls, trying to make complex menus accessible is not
likely to result in a good experience. It may be technically
accessible, but effectively a usability nightmare.
3. Hide the sub-menu items from screen reader and keyboard access and
make the main menu item a standard link to a page which provides
redundant access to each of the sub-menu items. I can find no problems
with such an approach. The only drawback with such an approach is that
it is one extra step - hardly as problematic as either of the other
options, in my opinion.
The key here is getting users to the content in an efficient and
effective way. We shouldn't try to force the same menu experience on
them no more than we drag wheelchairs up the stairs in order to give
them the same experience of getting to the second floor.
Jared Smith
WebAIM
From: deblist
Date: Fri, Nov 06 2009 10:10AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
On Fri, 6 Nov 2009, Jared Smith wrote:
> 2. Program the menu to be technically keyboard/screen reader
> accessible. The problem with this approach is that there is no
> standard way of doing so. Do you open the menu with space or enter? Do
> the arrow keys expand/collapse the menu? Up and down or left and
> right? How are you to know if you can't see it? And again, hierarchy
> and semantics are nearly impossible to convey with such menus. Without
> standard controls, trying to make complex menus accessible is not
> likely to result in a good experience. It may be technically
> accessible, but effectively a usability nightmare.
it seems to me the appropriate solution to this is to propose
standard controls to the standards making bodies, not just say
"oh well, usability nightmare".
> The key here is getting users to the content in an efficient and
> effective way. We shouldn't try to force the same menu experience on
> them no more than we drag wheelchairs up the stairs in order to give
> them the same experience of getting to the second floor.
but if we want to see menu experience, we should have access to
it. For me, usable drop-down menus via keyboard provide a much
better browsing experience. I speak here not just as a web
programmer who is, like the rest of you, trying to solve these
problems, but as a disabled user with no mouse access.
Also remember that not all keyboard-only users are screenreader.
We should come up with solutions that provide a pleasurable
browsing experience both for sighted keyboard-only users and for
screenreader-using keyboard-only users. As long as we are doing
stretched metaphors here, saying "keyboard accessible drop-down
menus are a bad idea because they provide a bad screenreader
experience" is like saying "keyboard access to a non-screenreader
accessible page element is a bad idea."
-deborah
From: deblist
Date: Fri, Nov 06 2009 10:30AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
On Fri, 6 Nov 2009, Jared Smith wrote:
> The key here is getting users to the content in an efficient and
> effective way. We shouldn't try to force the same menu experience on
> them no more than we drag wheelchairs up the stairs in order to give
> them the same experience of getting to the second floor.
I have figured out why I had such a strong response to this
analogy. I understand you were just speaking for flavor, but the
fact is not only do you not drag wheelchairs up the stairs, but
you also don't shove them into elevators. You build the stairs,
and you build the elevator, and then you let the person who uses
a wheelchair DECIDE how she wants to get upstairs. If she wants
to find a way to get her wheelchair up the stairs, more power to
her. Part of our job building accessible websites is adding
things like handrails to the stairwell, and making sure all the
stairwells have corners that are wide enough. We provide the
tools, we don't force the path.
Here's another example which isn't in web programming. In my
building where I work, if I want access to automatic door openers
(which I need), I can only navigate the building through
wheelchair-accessible routes. Side doors and stairwells haven't
taken this need into account, because the idea is that if you
provide that physical access for everyone all at once, then you
have at least made one physically-accessible path through the
building. But lots of people (including me) might not need
elevators and ramps but might need that other level of physical
assistance: handrails, automatic door openers, etc. Leaving aside
the greater problem (that there is only one wheelchair-accessible
path through a very large building), it is only just barely
adequate accessibility to say "we have provided physical
accessibility as long as you go out of your way". That's not the
spirit of accessibility, that's just the minimum required to
provide it.
-deborah
From: Nancy Johnson
Date: Fri, Nov 06 2009 10:40AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
This is a very interesting perspective
"3. Hide the sub-menu items from screen reader and keyboard access and
make the main menu item a standard link to a page which provides
redundant access to each of the sub-menu items. I can find no problems
with such an approach. The only drawback with such an approach is that
it is one extra step - hardly as problematic as either of the other
options, in my opinion."
I have a brand new site, our job is to put a CMS system behind it.
We got photoshop comps and html static pages from the design
development company.
My first assignment was to make an assessment based on the html that I
received
When it came to 508, I found some jquery elements were not keyboard
accessible including the drop down elements in the global navigation,
but I thought that if the navigation in the landing pages were 100%
accessible then that is OK, which I documented.
The client now wants the left-hand to expand by hover and in the
expansion not only have a link but a description of the link.
I can only put in writing my 508 findings and the client has to decide
hence my query.
This brings up another issue. Unfortunately to most developers 508 in
an intellectual issue, and if a page passes any of the 508 validators,
then the page is accessible, but many of these validators do not check
for AJAX, jquery and other functionality that is commonly used, other
than manually checking pages, are there any validators addressing
these issues.
How to tell a client in fact that this passes the validator but is not
usable or accessible to those with major mobility and visual issues?
Nancy
On Fri, Nov 6, 2009 at 11:50 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Fri, Nov 6, 2009 at 9:21 AM, Karl Groves
> < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I do not agree with this statement. While I would agree that the root
>> menu item should be a real link to an actual destination, I hardly regard
>> it as accessible or usable to not provide programmatic access and visual
>> focus to sub-menu options.
>
> There are really only three approaches to such menu accessibility:
>
> 1. Force the user to listen to and navigate through all menu items.
> This is not efficient. It is certainly not the same experience sighted
> and mouse users have. The hierarchy of such menus is hard to convey to
> someone listening to them. It's overwhelming and confusing. Hardly
> accessible.
>
> 2. Program the menu to be technically keyboard/screen reader
> accessible. The problem with this approach is that there is no
> standard way of doing so. Do you open the menu with space or enter? Do
> the arrow keys expand/collapse the menu? Up and down or left and
> right? How are you to know if you can't see it? And again, hierarchy
> and semantics are nearly impossible to convey with such menus. Without
> standard controls, trying to make complex menus accessible is not
> likely to result in a good experience. It may be technically
> accessible, but effectively a usability nightmare.
>
> 3. Hide the sub-menu items from screen reader and keyboard access and
> make the main menu item a standard link to a page which provides
> redundant access to each of the sub-menu items. I can find no problems
> with such an approach. The only drawback with such an approach is that
> it is one extra step - hardly as problematic as either of the other
> options, in my opinion.
>
> The key here is getting users to the content in an efficient and
> effective way. We shouldn't try to force the same menu experience on
> them no more than we drag wheelchairs up the stairs in order to give
> them the same experience of getting to the second floor.
>
> Jared Smith
> WebAIM
>
From: Jared Smith
Date: Fri, Nov 06 2009 10:55AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
On Fri, Nov 6, 2009 at 10:27 AM, < = EMAIL ADDRESS REMOVED = > wrote:
> You build the stairs,
> and you build the elevator, and then you let the person who uses
> a wheelchair DECIDE how she wants to get upstairs.
Agreed, but it often does not work this way with web accessibility. A
web developer must make decisions and those decisions are usually
forced upon the site visitors. If you provide really bad alternative
text, it WILL be read by screen readers. If you try to make your
complex drop-down menu accessible, keyboard-only and screen reader
users WILL interact with your attempts at accessibility and will
likely have a frustrating experience.
I am curious though, how you typically interact with such menus using
only your keyboard. Have you found them to generally be accessible? If
so, how do they work? Any examples of good ones? Have you found a
universal convention to making them keyboard accessible? Do you think
they could be made accessible to someone that cannot see them?
Jared
From: Jason Megginson
Date: Fri, Nov 06 2009 11:00AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
>I can only put in writing my 508 findings and the client has to decide
>hence my query.
>This brings up another issue. Unfortunately to most developers 508 in
>an intellectual issue, and if a page passes any of the 508 validators,
>then the page is accessible, but many of these validators do not check
>for AJAX, jquery and other functionality that is commonly used, other
>than manually checking pages, are there any validators addressing
>these issues.
>How to tell a client in fact that this passes the validator but is not
>usable or accessible to those with major mobility and visual issues?
Hi Nancy,
There is only so much that can be tested automatically. Not all of the
Section 508 paragraphs can be tested with validators. In addition, the
functional performance criteria of Section 508 (Subpart C) should never be
overlooked and should be included in your analysis. From my experience,
many people have the misconception that accessibility is a blind issue or
a "JAWS" issue.
Manual testing and Assistive technology testing are necessary elements to
a testing methodology. If there is equivalent facilitation to inaccessible
drop-down menus, document it accordingly. I think the several examples
provided in this thread are enough to help you reach the idea of
equivalent access. My advice is to develop the most "accessible" approach
to satisfy the technical and functional requirements based on your current
design.
Jason Megginson
From: Simius Puer
Date: Fri, Nov 06 2009 11:05AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Education is the only way. The simple fact is validators can only check if
something is in place, but not check if it is accurate. A qualitative
assessment by trained professionals is required to truly meet 501 (or any
accessibility standard).
Simplest example: a validator sees an image has alt text and passes it. A
human checks the image and sees it is a cat - the alt image is "photo of a
dog". Once clients understand that the rest is easy - you just need to
break the mentality of "tickbox accessibility".
Building this into the standard specification for any job right at the start
helps a lot too.
Best of luck!
From: Al Sparber
Date: Fri, Nov 06 2009 11:15AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
From: < = EMAIL ADDRESS REMOVED = >
> On Fri, 6 Nov 2009, Al Sparber wrote:
>> The most accessible *and* usable menus of this kind are ones in which the
>> sub-menus are not available to keyboard or non-sighted people, but which
>> instead include links on the root items to "landing" pages, from which
>> links
>> in the relevant sub-menu are present in the flow of the document's
>> visible
>> content areas.
>
> As a hands-free (and therefore keyboard-only) disabled user
> myself, I strongly disagree with this. I very much prefer getting
> the same user experience that non-keyboard-only users have, which
> includes the drop-down menus. This is a fundamental principle of
> universal design!
>
> Getting shunted to landing pages for me is the accessible minimal
> acceptable solution, but it is certainly not the way I like to
> work.
Hi Deborah,
This is an issue that very few people can ever seem to agree on ;-)
Tell you what... try this test page:
http://www.projectseven.com/csslab/accessible/menu/
Imagine you are a regular visitor to this imaginary site and your objective
today is to access either of these 2 links on that page:
Objective 1: Test Page 1
Objective 2: Test Page 2
Note how many tab stops it takes for each.
Now try it on this page:
http://www.projectseven.com/csslab/accessible/menu/index2.htm
If you still disagree strongly, no problem. Everyone has a different
perspective - but we have done a very large amount of user testing on this
and our perspective is as I stated in my previous mail.
--
Al Sparber - PVII
http://www.projectseven.com
Dreamweaver Menus | Galleries | Widgets
http://www.projectseven.com/go/apm
An Accessible & Elegant Accordion
From: deblist
Date: Fri, Nov 06 2009 11:20AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
On Fri, 6 Nov 2009, Jared Smith wrote:
> Agreed, but it often does not work this way with web accessibility. A
> web developer must make decisions and those decisions are usually
> forced upon the site visitors.
That's not true, though. I interact with any given webpage in
many different ways. For example, there are a few webpages were
in order to get to certain items embedded in the menus I toggle
off CSS, because the various drop-down are badly written and the
only way I can find things is by hiding the CSS. On the other
hand, at other times I leave the CSS turned on because of the
extra usability of having the page layout look right. Sometimes I
turn off JavaScript because it makes too much on the page active
and I lose control, and other times I turn JavaScript back on
because it's the only way I have navigation. Sometimes I turn off
images because I want to know the name of the alt text so that I
can keyboard navigate to it via direct access, or because it's
the only way I can get the extra punchline on an xkcd cartoon
without mouse access. As a web navigator with disabilities, I
make these choices *all the time*.
In the same way, JAWS users can decide to browse the entire page,
to look for headings, to look for landmarks if they are there, to
report alt text or not, to report the title attribute on links or
ignore it, etc.
Users with disabilities are not helpless pawns being led by the
hand through webpages by the kind developers who worry about
accessibility. We have agency, and we use it. So more tools gives
us more opportunity to use our agency.
> I am curious though, how you typically interact with such menus using
> only your keyboard. Have you found them to generally be accessible? If
> so, how do they work? Any examples of good ones? Have you found a
> universal convention to making them keyboard accessible? Do you think
> they could be made accessible to someone that cannot see them?
I've had mixed success. My greatest success with such menus is
using Firefox + mouseless browsing. SOME (but certainly not all)
JavaScript enabled drop-down menus can be directly dropped down
via a link if you access them via mouseless browsing. I have
encountered very few menus that could be accessed directly via
the keyboard in Firefox or Opera, by which I mean tabbing to them
and then hitting enter or somesuch, although they do exist.
Right now I'm working on improving the menus of the site I'm
working on, and I keep going through multiple rounds of testing,
because not only am I testing myself with JAWS, NVDA, etc., but I
have a fairly respectably sized community of screenreader users
with a variety of different ways of working with computers who
are also testing for me. So yes, I do think they can be made
accessible to someone who cannot see them, because I've got work
in progress which is improving all the time. WAI-ARIA helps, of
course, that isn't available to everybody.
-deborah
From: deblist
Date: Fri, Nov 06 2009 11:35AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
> From: < = EMAIL ADDRESS REMOVED = >
>>
>> As a hands-free (and therefore keyboard-only) disabled user
>> myself, I strongly disagree with this.
On Fri, 6 Nov 2009, Al Sparber wrote:
> Imagine you are a regular visitor to this imaginary site and your objective
> today is to access either of these 2 links on that page:
> ...
> If you still disagree strongly, no problem. Everyone has a different
> perspective - but we have done a very large amount of user testing on this
> and our perspective is as I stated in my previous mail.
Al,
Imagine you are a web developer with a focus on accessibility.
Imagine you set up a couple of artificial test pages and run
focus groups and ask people which they find easiest to use in a
hypothetical situation. Now imagine a Real Live Disabled Person
comes to you and says "In my Real Live Web Browsing, I have a
different preference. I browse the web all the time and this is
what I've found to be the most useable."
Do you say:
1. But try my hypothetical situation and see if your experience
is the same.
2. Well, everyone's different. Our focus groups report something
different.
3. Hmm, interesting data point. Maybe we should get more
feedback from Real Live Disabled people about Real Live Web
Browsing and see if their preferences differ from the test
situation.
One of the major roadblocks in accessibility is accessibility
advocates who don't listen to people with disabilities when we
speak up about our experiences. I understand you mean well, but
I beg all accessibility-oriented folks to incorporate listening
into their process.
-deborah
From: Jared Smith
Date: Fri, Nov 06 2009 12:05PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
On Fri, Nov 6, 2009 at 11:34 AM, < = EMAIL ADDRESS REMOVED = > wrote:
> I understand you mean well, but
> I beg all accessibility-oriented folks to incorporate listening
> into their process.
An interesting recommendation, seeing as you've yet to acknowledge any
of the other recommendations made in this thread. Instead, you've
summarily dismissed them with no justification. What's best for you
may not be best for everybody else. The techniques you use for
accessibility (disabling javascript or styles or images) are well
beyond what many screen reader or keyboard-only users might employ.
Al's been on this list about 20 times longer than you - since at least
2005. He is a regular contributor and I assure you his recommendations
don't come 'off the cuff' or without thorough testing and listening.
I'm not saying your wrong. These are complex issues and there isn't
ONE answer. We're simply saying that, in general, it has been our
experience that attempts to make complex menus accessible typically
result in less accessibility than hiding them and simply making the
main menu item a link to redundant navigation. If you've found a
universally accessible method of making them accessible to all users,
please share. If not, a little listening to the recommendations of
others might expand your thinking on this issue.
Jared
From: Al Sparber
Date: Fri, Nov 06 2009 12:15PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
>> From: < = EMAIL ADDRESS REMOVED = >
> Al,
>
> Imagine you are a web developer with a focus on accessibility.
> Imagine you set up a couple of artificial test pages and run
> focus groups and ask people which they find easiest to use in a
> hypothetical situation. Now imagine a Real Live Disabled Person
> comes to you and says "In my Real Live Web Browsing, I have a
> different preference. I browse the web all the time and this is
> what I've found to be the most useable."
>
> Do you say:
>
> 1. But try my hypothetical situation and see if your experience
> is the same.
>
> 2. Well, everyone's different. Our focus groups report something
> different.
>
> 3. Hmm, interesting data point. Maybe we should get more
> feedback from Real Live Disabled people about Real Live Web
> Browsing and see if their preferences differ from the test
> situation.
>
> One of the major roadblocks in accessibility is accessibility
> advocates who don't listen to people with disabilities when we
> speak up about our experiences. I understand you mean well, but
> I beg all accessibility-oriented folks to incorporate listening
> into their process.
I'm sorry we disagree, but it happens sometimes. I also want to assure you
that I take disability very seriously and when we run tests for our scripts
we do so with people that have real disabilities. I learned a long time ago
that I cannot test in JAWS because I'm not blind, so we have blind people
that help us test. I am also not a dependable keyboard/pointing device
tester because my hands are fully functional, so we have testers that cannot
use a mouse.
Again, please keep an open mind and understand that I value your opinion and
am not trying to argue. I just have a different opinion.
From: deblist
Date: Fri, Nov 06 2009 12:20PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
On Fri, 6 Nov 2009, Jared Smith wrote:
> On Fri, Nov 6, 2009 at 11:34 AM, < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I understand you mean well, but
>> I beg all accessibility-oriented folks to incorporate listening
>> into their process.
>
> An interesting recommendation, seeing as you've yet to acknowledge any
> of the other recommendations made in this thread. Instead, you've
> summarily dismissed them with no justification. What's best for you
> may not be best for everybody else. The techniques you use for
> accessibility (disabling javascript or styles or images) are well
> beyond what many screen reader or keyboard-only users might employ.
>
> Al's been on this list about 20 times longer than you - since at least
> 2005. He is a regular contributor and I assure you his recommendations
> don't come 'off the cuff' or without thorough testing and listening.
I don't even know where to start with this. First of all, you are
telling me that Al's opinions are more valid than mine because
he's been on the list for longer. I would understand you saying
"I know Al, and I trust him, because he's been on the list for
four years." But that's not what you just said there. You
basically used Al's tenure on the list as a bludgeon to tell me
I'm wrong.
I don't understand what anything means to get knowledge the other
recommendations based on this thread. You guys are making
recommendations based on working things out logically for a
process and going through testing and focus groups. What I'm
saying is that AS AN ACTUAL DISABLED USER I have a different
experience. That is something that should make you say "hey,
interesting, tell me more," (as you did, Jared), not "yes, but
your real life experience doesn't match my laboratory focus group
so I am going to ignore it."
Of course many other screen reader or keyboard-only users aren't
not technically oriented and don't have the same experience I do.
Many other non-disabled users aren't as technically oriented as
you are and don't have the same experience you do. Does that mean
that developers of user agents shouldn't take your needs into
account as well as the needs of the non-technically oriented
users? Of course not! Accessibility is about universal design.
Universal design means that there should be a good user
experience for able-bodied advanced users, for able-bodied novice
users, for advanced users with disabilities, for novice users
with disabilities.
One of the reasons I've avoided the programming-for-
accessibility community for so long is because I found it hostile
to individuals with disabilities. The reason I joined the webaim
list when I did is because by spending some time reading the
public archive that seemed to me no longer to be true. I didn't
see what I'm seeing today: the assumption that all users with
disabilities are passive, that they are novices, that they don't
have agency in their own web use, their feedback is not as
important as laboratory understanding and following best
practices or standards.
-deborah
From: deblist
Date: Fri, Nov 06 2009 12:30PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
On Fri, 6 Nov 2009, = EMAIL ADDRESS REMOVED = wrote:
> I don't understand what anything means to get knowledge the other
> recommendations based on this thread. You guys are making
> recommendations based on working things out logically for a
> process and going through testing and focus groups. What I'm
See, this is what I get for dictating when I am upset. I get
completely incomprehensible. That sentence should read "I don't
understand what it even means to 'acknowledge the other
recommendations'".
-deborah
From: Karl Groves
Date: Fri, Nov 06 2009 12:35PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
OK, I think perhaps this conversation has run its course at the moment,
and hope people can take a quick breather before feelings get hurt. I've
been on this list since 2001. This list's longevity is owed largely to the
general friendliness of the discourse. That's not to say that it has
always been perfect (nor that I've always been perfect on the list), but I
hope we can all step back, relax, and move on without further hurt
feelings.
Thanks
Karl Groves
Director of Strategic Planning and Product Development
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8961 (o)
443.889.8763 (c)
http://www.ssbbartgroup.com
Accessibility-On-Demand
From: ckrugman
Date: Fri, Nov 06 2009 12:55PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
As a screen reader user I would prefer the choice of tabbing through
whatever number of choices exist.
Chuck
----- Original Message -----
From: "Al Sparber" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, November 06, 2009 8:17 AM
Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
expandablemenu?
> From: "Jason Megginson" < = EMAIL ADDRESS REMOVED = >
> To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
> Sent: Friday, November 06, 2009 10:37 AM
> Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
> expandablemenu?
>
>
>> HTML Dog is an excellent source for clean HTML and CSS. However, I would
>> improve upon their example by including an onFocus event so the sub-menus
>> appear when keyboard focus is present on the parent menu item and as the
>> focus is on the sub-menu items as a user tabs.
>>
>> This provides accessibility to sighted and non-sighted keyboard users.
>
> It also forces keyboard users to have to tab through all sub-menu items,
> which presents usability problems tabbing to fifth root item when there
> are
> 40 sub-menu items in the way :-)
>
> The most accessible *and* usable menus of this kind are ones in which the
> sub-menus are not available to keyboard or non-sighted people, but which
> instead include links on the root items to "landing" pages, from which
> links
> in the relevant sub-menu are present in the flow of the document's visible
> content areas.
>
> --
> Al Sparber - PVII
> http://www.projectseven.com
> Dreamweaver Menus | Galleries | Widgets
> http://www.projectseven.com/go/apm
> An Accessible & Elegant Accordion
>
>
>
>
From: Jared Smith
Date: Fri, Nov 06 2009 1:05PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
On Fri, Nov 6, 2009 at 12:32 PM, Karl Groves
< = EMAIL ADDRESS REMOVED = > wrote:
> OK, I think perhaps this conversation has run its course at the moment,
> and hope people can take a quick breather before feelings get hurt. I've
> been on this list since 2001. This list's longevity is owed largely to the
> general friendliness of the discourse. That's not to say that it has
> always been perfect (nor that I've always been perfect on the list), but I
> hope we can all step back, relax, and move on without further hurt
> feelings.
Agreed. It's often difficult to convey things through text. We're all
on the same team. This is an interesting discussion - and the
differences in opinion really are minor. I apologize for making it
personal and do hope that feelings weren't hurt. This list is a
wonderful resource, even if there is heated discussion and
disagreement at times. Let's not let that discourage participation. I
think it's awesome that we can all share thoughts and listen to each
other in an accessible medium about something we're all so passionate
about.
The menu issue would make a wonderful question for a future WebAIM
survey. I'm still hoping to see details on how to best make such menus
fully accessible - we could maybe incorporate such an example into a
survey for testing.
Jared
From: ckrugman
Date: Fri, Nov 06 2009 1:20PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
As a screen reader drop down menus are accessible with the use of the up and
down arrow keys. There is no difficulty when this format is used.
Chuck
----- Original Message -----
From: "Jared Smith" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, November 06, 2009 9:49 AM
Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
expandablemenu?
> On Fri, Nov 6, 2009 at 10:27 AM, < = EMAIL ADDRESS REMOVED = > wrote:
>
>> You build the stairs,
>> and you build the elevator, and then you let the person who uses
>> a wheelchair DECIDE how she wants to get upstairs.
>
> Agreed, but it often does not work this way with web accessibility. A
> web developer must make decisions and those decisions are usually
> forced upon the site visitors. If you provide really bad alternative
> text, it WILL be read by screen readers. If you try to make your
> complex drop-down menu accessible, keyboard-only and screen reader
> users WILL interact with your attempts at accessibility and will
> likely have a frustrating experience.
>
> I am curious though, how you typically interact with such menus using
> only your keyboard. Have you found them to generally be accessible? If
> so, how do they work? Any examples of good ones? Have you found a
> universal convention to making them keyboard accessible? Do you think
> they could be made accessible to someone that cannot see them?
>
> Jared
>
From: Jason Megginson
Date: Fri, Nov 06 2009 1:45PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Hi Chuck,
In regards to the arrow keys, there may be no difficulty with navigating
this way as long as the menu items are inline with the parent link.
The example at HTML Dog provides a good example of this (sidebar: I also
like the list structure to denote hierarchy):
http://htmldog.com/articles/suckerfish/dropdowns/example/vertical.html
The child links are inline with the parent link in the source code in this
example. Screen readers like JAWS (virtual cursor) will read the content
in the order it appears in the source code.
When developers use CSS to display the sub-menu items, the content should
appear inline with the parent link(s). I have seen where developers place
the menu items at the end of the source code and position it visually in
the correct place. A user navigating with arrow keys will not be able to
identify the content because it is virtually at the end of the page.
I often recommend sighted testers to disable styles on the page (FireFox)
and inspect where the dynamic content appears. If the content appears
disjointed, that's how users in Virtual Cursor mode (JAWS) will access the
information.
Thanks
Jason
From: ckrugman
Date: Fri, Nov 06 2009 1:55PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Yes, this can sometimes be an issue. The real issue depends on how items are
labeled and the use of text appearing in an image or in Flash format as is
done on many marketing or internet survey sites. Of course, images or Flash
format is not readable by any screen reader.
Chuck
----- Original Message -----
From: "Jason Megginson" < = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, November 06, 2009 12:44 PM
Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
expandablemenu?
> Hi Chuck,
>
> In regards to the arrow keys, there may be no difficulty with navigating
> this way as long as the menu items are inline with the parent link.
>
> The example at HTML Dog provides a good example of this (sidebar: I also
> like the list structure to denote hierarchy):
> http://htmldog.com/articles/suckerfish/dropdowns/example/vertical.html
>
> The child links are inline with the parent link in the source code in this
> example. Screen readers like JAWS (virtual cursor) will read the content
> in the order it appears in the source code.
>
> When developers use CSS to display the sub-menu items, the content should
> appear inline with the parent link(s). I have seen where developers place
> the menu items at the end of the source code and position it visually in
> the correct place. A user navigating with arrow keys will not be able to
> identify the content because it is virtually at the end of the page.
>
> I often recommend sighted testers to disable styles on the page (FireFox)
> and inspect where the dynamic content appears. If the content appears
> disjointed, that's how users in Virtual Cursor mode (JAWS) will access the
> information.
>
> Thanks
> Jason
>
>
From: Andrew Kirkpatrick
Date: Fri, Nov 06 2009 2:05PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Chuck,
That is not a correct statement. Flash content can be read by many screen readers.
Thanks,
AWK
Andrew Kirkpatrick
Senior Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
From: Moore,Michael (DARS)
Date: Fri, Nov 06 2009 2:20PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Jared wrote
"...This is an interesting discussion ..."
I have been fortunate to have been involved as an accessibility and 508 compliance SME (subject matter expert) for several major web applications projects. The most successful outcomes have included early and active participation by disabled staff who would be using the system with assistive technologies (AT). The testers, all volunteers, primarily use JAWS, ZoomText, Dragon Naturally Speaking, keyboard only access or combinations of those tools. Two of the most successful projects thus far rely on accessible drop down menus as part of the navigation. This has meant that at times over 100 links may be presented to a user on a single page, however when asked the AT users in our test groups have preferred this situation to that of multiple pages with fewer choices but more "clicks" to get where you needed to go. Navigation within these systems has been enhanced through the use of short-cut keys and headings but AT users employ many strategies that we frequently do not discuss
within accessibility forums.
A few examples:
Screen readers allow users to sort links lists in the order that the links appear or alphabetically, when sorted alphabetically the user can quickly jump to the set of links beginning with any given letter. Form controls, graphics, graphics and just about any other object that you can imagine can also be sorted similarly. To see what is available use Instert+F3 in JAWS.
JAWS find, a page level search tool, is frequently used to find particular text, links or functionality, even when a user only suspects that the content may exist somewhere on the page.
Dragon users have similar functionality available to identify and jump to particular links or controls on a page.
Finally we have found that an alternative style sheet that left justifies everything can very useful for screen magnifier users, as does including the form label in the title attribute of form fields since label elements are not properly supported by ZT. I am very well aware that this is not the "standard" use of the title attribute.
There is a saying within the disabled community, "Nothing about us without us" this certainly must include web and other forms of EIR (Electronic Information Resources) accessibility. As accessibility experts we cannot and should not get too wrapped up in "standards" and "best practices." Standards are best thought of as more guidelines than a rules (is it Pirate Friday?), thus the last word in the acronym WCAG. Having in Web accessibility since 2003, I have found that "best practices" are very transitory. Heck, I have even posted on this list about the "evils" of keyboard shortcuts, and later found myself endorsing them for particular projects.
So for my perspective on accessible drop down navigation, it's probably time for another accessibility balancing act. Will the users be interacting with the site or application daily, weekly, monthly, or once in a blue moon? How many total links are there, and what does the list look like when I sort it? Is there a way to integrate headings into sections of the fly out menus? There are probably many more questions that should be considered but it's getting late on Friday afternoon and I have probably tested everyone's patience enough with another long winded post.
Jared, this is definitely something that I would like to see some data on in the next survey. Remember the difference we saw between accessibility aware developers and users on the issue of image descriptions.
Mike Moore
From: ckrugman
Date: Fri, Nov 06 2009 2:30PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Yes, I should have said that when text is presented as an image in Flash
software or at times when it is imbedded it can't be read. I currently use
JAWS and it is sometimes readable. I have tried other solutions and have not
found them satisfactory. Let me know of other suggestions to deal with this
problem.
Chuck
----- Original Message -----
From: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, November 06, 2009 1:03 PM
Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
expandablemenu?
> Chuck,
> That is not a correct statement. Flash content can be read by many screen
> readers.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
>
> Senior Product Manager, Accessibility
>
> Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
>
>
>
From: Andrew Kirkpatrick
Date: Fri, Nov 06 2009 2:40PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
I'm not sure what you mean when you write "when text is presented as an image in Flash". If there is text in the Flash content it will be available to windows-based screen readers unless the developer explicitly hides it or embeds the Flash content using an unsupported window mode.
Yes, there are caveats that developers need know about but there's a fair bit of ground between that and saying "of course, Flash format cannot be read in any screen reader".
Here's one example of Flash being authored with accessibility in mind.
Thanks,
AWK
Andrew Kirkpatrick
Senior Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
From: Jon Brundage
Date: Fri, Nov 06 2009 2:55PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Hi Andrew,
Your post states "Here's one example of Flash being authored with
accessibility in mind."
Were you meaning to include a link or an example .fla file? Or was that a
reference to another post?
Thanks,
Jon
----- Original Message -----
From: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, November 06, 2009 4:36 PM
Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
expandablemenu?
> I'm not sure what you mean when you write "when text is presented as an
> image in Flash". If there is text in the Flash content it will be
> available to windows-based screen readers unless the developer explicitly
> hides it or embeds the Flash content using an unsupported window mode.
>
> Yes, there are caveats that developers need know about but there's a fair
> bit of ground between that and saying "of course, Flash format cannot be
> read in any screen reader".
>
> Here's one example of Flash being authored with accessibility in mind.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
>
> Senior Product Manager, Accessibility
>
> Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
>
>
>
From: Andrew Kirkpatrick
Date: Fri, Nov 06 2009 3:00PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Sorry!
http://www.adobe.com/accessibility/products/flash/tutorial/
Thanks,
AWK
Andrew Kirkpatrick
Senior Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
From: charis austin
Date: Fri, Nov 06 2009 5:55PM
Subject: Re: mouseover/hover and keyboard accessible expandable menu?
← Previous message | Next message →
From: ckrugman
Date: Fri, Nov 06 2009 7:15PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
I was primarily referring to text that is imbedded or text that is actually
a picture of text such as an image of a product package or text that is
imbedded on some internet survey sites.
Chuck
----- Original Message -----
From: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, November 06, 2009 1:36 PM
Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
expandablemenu?
> I'm not sure what you mean when you write "when text is presented as an
> image in Flash". If there is text in the Flash content it will be
> available to windows-based screen readers unless the developer explicitly
> hides it or embeds the Flash content using an unsupported window mode.
>
> Yes, there are caveats that developers need know about but there's a fair
> bit of ground between that and saying "of course, Flash format cannot be
> read in any screen reader".
>
> Here's one example of Flash being authored with accessibility in mind.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
>
> Senior Product Manager, Accessibility
>
> Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
>
>
>
From: ckrugman
Date: Fri, Nov 06 2009 7:55PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
that demonstration was completely usable with JAWS. I guess the issue is
getting other web developers to apply it. The tutorial was very impressive.
Chuck
----- Original Message -----
From: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, November 06, 2009 1:57 PM
Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
expandablemenu?
> Sorry!
> http://www.adobe.com/accessibility/products/flash/tutorial/
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
>
> Senior Product Manager, Accessibility
>
> Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
>
>
>
From: Jon Gunderson
Date: Sun, Nov 08 2009 10:05AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Here is an example using ARIA markup:
http://test.cita.illinois.edu/aria/menubar/menubar1.php
Jon
Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility
Disability Resources and Educational Services
Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61820
Voice: (217) 244-5870
WWW: http://www.cita.illinois.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/
---------------------------------------------------------------
Privacy Information
---------------------------------------------------------------
This email (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. It is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this email is not the intended recipient, or agent responsible for delivering or copying of this communication, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please reply to the sender that you have received the message in error, then delete it. Thank you.
From: Geof Collis
Date: Sun, Nov 08 2009 10:55AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Hi John
I dont know what you've done but it messes up JAWS real bad. I
checked the 2 examples and somewhere down the page JAWS goes into a
mode I've never heard before, applications mode. When it is in this
mode I cant navigate anywhere and have to close the page. I'm using JAWS 10.0
cheers
Geof
At 12:02 PM 11/8/2009, you wrote:
>Here is an example using ARIA markup:
>http://test.cita.illinois.edu/aria/menubar/menubar1.php
>
>Jon
>Jon Gunderson, Ph.D.
>Coordinator Information Technology Accessibility
>Disability Resources and Educational Services
>
>Rehabilitation Education Center
>Room 86
>1207 S. Oak Street
>Champaign, Illinois 61820
>
>Voice: (217) 244-5870
>
>WWW: http://www.cita.illinois.edu/
>WWW: https://netfiles.uiuc.edu/jongund/www/
>
>---------------------------------------------------------------
>Privacy Information
>---------------------------------------------------------------
>This email (including attachments) is covered by the Electronic
>Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and
>may be legally privileged. It is intended for the use of the
>individual or entity to which it is addressed and may contain
>information that is privileged, confidential, and exempt from
>disclosure under applicable law. If the reader of this email is not
>the intended recipient, or agent responsible for delivering or
>copying of this communication, you are hereby notified that any
>retention, dissemination, distribution, or copying of this
>communication is strictly prohibited. If you have received this
>communication in error, please reply to the sender that you have
>received the message in error, then delete it. Thank you.
>
>
From: Jon Gunderson
Date: Sun, Nov 08 2009 11:15AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Application mode you use the javascript keyboard support to navigate the menu. I will try it with Jaws 11 and 10 on Monday. My guess it will do much better with Jaws 11 which has extensively improved ARIA support.
Jon
---- Original message ----
>Date: Sun, 08 Nov 2009 12:52:02 -0500
>From: Geof Collis < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] mouseover/hover and keyboard accessible expandablemenu?
>To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>
>Hi John
>
>I dont know what you've done but it messes up JAWS real bad. I
>checked the 2 examples and somewhere down the page JAWS goes into a
>mode I've never heard before, applications mode. When it is in this
>mode I cant navigate anywhere and have to close the page. I'm using JAWS 10.0
>
>cheers
>
>Geof
>
>At 12:02 PM 11/8/2009, you wrote:
>>Here is an example using ARIA markup:
>>http://test.cita.illinois.edu/aria/menubar/menubar1.php
>>
>>Jon
>>Jon Gunderson, Ph.D.
>>Coordinator Information Technology Accessibility
>>Disability Resources and Educational Services
>>
>>Rehabilitation Education Center
>>Room 86
>>1207 S. Oak Street
>>Champaign, Illinois 61820
>>
>>Voice: (217) 244-5870
>>
>>WWW: http://www.cita.illinois.edu/
>>WWW: https://netfiles.uiuc.edu/jongund/www/
>>
>>---------------------------------------------------------------
>>Privacy Information
>>---------------------------------------------------------------
>>This email (including attachments) is covered by the Electronic
>>Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and
>>may be legally privileged. It is intended for the use of the
>>individual or entity to which it is addressed and may contain
>>information that is privileged, confidential, and exempt from
>>disclosure under applicable law. If the reader of this email is not
>>the intended recipient, or agent responsible for delivering or
>>copying of this communication, you are hereby notified that any
>>retention, dissemination, distribution, or copying of this
>>communication is strictly prohibited. If you have received this
>>communication in error, please reply to the sender that you have
>>received the message in error, then delete it. Thank you.
>>
>>
From: Geof Collis
Date: Sun, Nov 08 2009 11:35AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Hi John
What good is that? It took me 7 years just to be able to upgrae to
10.0 it will take that long again just to upgrade, am I supposed to wait?
Also, I have never heard of applications mode, I found it frustrating
and if I run into it I'll just close down the page and leave, how
many others will do the same?
cheers
Geof
At 01:14 PM 11/8/2009, you wrote:
>Application mode you use the javascript keyboard support to navigate
>the menu. I will try it with Jaws 11 and 10 on Monday. My guess it
>will do much better with Jaws 11 which has extensively improved ARIA support.
>
>Jon
>
>
>---- Original message ----
> >Date: Sun, 08 Nov 2009 12:52:02 -0500
> >From: Geof Collis < = EMAIL ADDRESS REMOVED = >
> >Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
> expandablemenu?
> >To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> >
> >Hi John
> >
> >I dont know what you've done but it messes up JAWS real bad. I
> >checked the 2 examples and somewhere down the page JAWS goes into a
> >mode I've never heard before, applications mode. When it is in this
> >mode I cant navigate anywhere and have to close the page. I'm
> using JAWS 10.0
> >
> >cheers
> >
> >Geof
> >
> >At 12:02 PM 11/8/2009, you wrote:
> >>Here is an example using ARIA markup:
> >>http://test.cita.illinois.edu/aria/menubar/menubar1.php
> >>
> >>Jon
> >>Jon Gunderson, Ph.D.
> >>Coordinator Information Technology Accessibility
> >>Disability Resources and Educational Services
> >>
> >>Rehabilitation Education Center
> >>Room 86
> >>1207 S. Oak Street
> >>Champaign, Illinois 61820
> >>
> >>Voice: (217) 244-5870
> >>
> >>WWW: http://www.cita.illinois.edu/
> >>WWW: https://netfiles.uiuc.edu/jongund/www/
> >>
> >>---------------------------------------------------------------
> >>Privacy Information
> >>---------------------------------------------------------------
> >>This email (including attachments) is covered by the Electronic
> >>Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and
> >>may be legally privileged. It is intended for the use of the
> >>individual or entity to which it is addressed and may contain
> >>information that is privileged, confidential, and exempt from
> >>disclosure under applicable law. If the reader of this email is not
> >>the intended recipient, or agent responsible for delivering or
> >>copying of this communication, you are hereby notified that any
> >>retention, dissemination, distribution, or copying of this
> >>communication is strictly prohibited. If you have received this
> >>communication in error, please reply to the sender that you have
> >>received the message in error, then delete it. Thank you.
> >>
> >>
From: Jon Gunderson
Date: Sun, Nov 08 2009 1:10PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Geof,
JAWS application mode will be come more common as HTML5 and ARIA markup is used more and more on the web.
As developers continue to create more desktop type user interface controls on web, pages will need to use ARIA or HTML5 to describe the types and features of these web widgets and screen readers will need to support the markup to make these widgets accessible.
It would be nice for people using assistive technologies if web technologies would just stay the same, so assistive technology could become more stable and web developers more familiar with accessible design. But that is not the nature of the web, technologies will continue to evolve and new accessibility solution strategies will need to be developed and implemented. I wish there was an easy answer to your dilemma of needing to upgrade JAWS.
Jon
---- Original message ----
>Date: Sun, 08 Nov 2009 13:34:44 -0500
>From: Geof Collis < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] mouseover/hover and keyboard accessible expandablemenu?
>To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>
>Hi John
>
>What good is that? It took me 7 years just to be able to upgrae to
>10.0 it will take that long again just to upgrade, am I supposed to wait?
>
>Also, I have never heard of applications mode, I found it frustrating
>and if I run into it I'll just close down the page and leave, how
>many others will do the same?
>
>cheers
>
>Geof
>
>
>At 01:14 PM 11/8/2009, you wrote:
>>Application mode you use the javascript keyboard support to navigate
>>the menu. I will try it with Jaws 11 and 10 on Monday. My guess it
>>will do much better with Jaws 11 which has extensively improved ARIA support.
>>
>>Jon
>>
>>
>>---- Original message ----
>> >Date: Sun, 08 Nov 2009 12:52:02 -0500
>> >From: Geof Collis < = EMAIL ADDRESS REMOVED = >
>> >Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
>> expandablemenu?
>> >To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> >
>> >Hi John
>> >
>> >I dont know what you've done but it messes up JAWS real bad. I
>> >checked the 2 examples and somewhere down the page JAWS goes into a
>> >mode I've never heard before, applications mode. When it is in this
>> >mode I cant navigate anywhere and have to close the page. I'm
>> using JAWS 10.0
>> >
>> >cheers
>> >
>> >Geof
>> >
>> >At 12:02 PM 11/8/2009, you wrote:
>> >>Here is an example using ARIA markup:
>> >>http://test.cita.illinois.edu/aria/menubar/menubar1.php
>> >>
>> >>Jon
>> >>Jon Gunderson, Ph.D.
>> >>Coordinator Information Technology Accessibility
>> >>Disability Resources and Educational Services
>> >>
>> >>Rehabilitation Education Center
>> >>Room 86
>> >>1207 S. Oak Street
>> >>Champaign, Illinois 61820
>> >>
>> >>Voice: (217) 244-5870
>> >>
>> >>WWW: http://www.cita.illinois.edu/
>> >>WWW: https://netfiles.uiuc.edu/jongund/www/
>> >>
>> >>---------------------------------------------------------------
>> >>Privacy Information
>> >>---------------------------------------------------------------
>> >>This email (including attachments) is covered by the Electronic
>> >>Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and
>> >>may be legally privileged. It is intended for the use of the
>> >>individual or entity to which it is addressed and may contain
>> >>information that is privileged, confidential, and exempt from
>> >>disclosure under applicable law. If the reader of this email is not
>> >>the intended recipient, or agent responsible for delivering or
>> >>copying of this communication, you are hereby notified that any
>> >>retention, dissemination, distribution, or copying of this
>> >>communication is strictly prohibited. If you have received this
>> >>communication in error, please reply to the sender that you have
>> >>received the message in error, then delete it. Thank you.
>> >>
>> >>
From: Geof Collis
Date: Sun, Nov 08 2009 1:20PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Hi John
I wish JAWS would stay relatively the same as well, I have new
features that drive me nuts an I cant turn them off, at least I cant
find out where to turn them off if it is even possible.
I think the solution to your second point is to make them degrade
gracefully. :O) I know many people who are still using lower versions
than mine and wont be upgrading any time soon.
I'm all for progress, I have started incorporating Rol Landmarks in
my sites even though not many are aware of them or can appreciate
them, so I still offer a skip link for those who need them.
cheers
Geof
At 03:09 PM 11/8/2009, you wrote:
>Geof,
>
>JAWS application mode will be come more common as HTML5 and ARIA
>markup is used more and more on the web.
>
>As developers continue to create more desktop type user interface
>controls on web, pages will need to use ARIA or HTML5 to describe
>the types and features of these web widgets and screen readers will
>need to support the markup to make these widgets accessible.
>
>It would be nice for people using assistive technologies if web
>technologies would just stay the same, so assistive technology could
>become more stable and web developers more familiar with accessible
>design. But that is not the nature of the web, technologies will
>continue to evolve and new accessibility solution strategies will
>need to be developed and implemented. I wish there was an easy
>answer to your dilemma of needing to upgrade JAWS.
>
>Jon
>
>
>
>---- Original message ----
> >Date: Sun, 08 Nov 2009 13:34:44 -0500
> >From: Geof Collis < = EMAIL ADDRESS REMOVED = >
> >Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
> expandablemenu?
> >To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> >
> >Hi John
> >
> >What good is that? It took me 7 years just to be able to upgrae to
> >10.0 it will take that long again just to upgrade, am I supposed to wait?
> >
> >Also, I have never heard of applications mode, I found it frustrating
> >and if I run into it I'll just close down the page and leave, how
> >many others will do the same?
> >
> >cheers
> >
> >Geof
> >
> >
> >At 01:14 PM 11/8/2009, you wrote:
> >>Application mode you use the javascript keyboard support to navigate
> >>the menu. I will try it with Jaws 11 and 10 on Monday. My guess it
> >>will do much better with Jaws 11 which has extensively improved
> ARIA support.
> >>
> >>Jon
> >>
> >>
> >>---- Original message ----
> >> >Date: Sun, 08 Nov 2009 12:52:02 -0500
> >> >From: Geof Collis < = EMAIL ADDRESS REMOVED = >
> >> >Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
> >> expandablemenu?
> >> >To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> >> >
> >> >Hi John
> >> >
> >> >I dont know what you've done but it messes up JAWS real bad. I
> >> >checked the 2 examples and somewhere down the page JAWS goes into a
> >> >mode I've never heard before, applications mode. When it is in this
> >> >mode I cant navigate anywhere and have to close the page. I'm
> >> using JAWS 10.0
> >> >
> >> >cheers
> >> >
> >> >Geof
> >> >
> >> >At 12:02 PM 11/8/2009, you wrote:
> >> >>Here is an example using ARIA markup:
> >> >>http://test.cita.illinois.edu/aria/menubar/menubar1.php
> >> >>
> >> >>Jon
> >> >>Jon Gunderson, Ph.D.
> >> >>Coordinator Information Technology Accessibility
> >> >>Disability Resources and Educational Services
> >> >>
> >> >>Rehabilitation Education Center
> >> >>Room 86
> >> >>1207 S. Oak Street
> >> >>Champaign, Illinois 61820
> >> >>
> >> >>Voice: (217) 244-5870
> >> >>
> >> >>WWW: http://www.cita.illinois.edu/
> >> >>WWW: https://netfiles.uiuc.edu/jongund/www/
> >> >>
> >> >>---------------------------------------------------------------
> >> >>Privacy Information
> >> >>---------------------------------------------------------------
> >> >>This email (including attachments) is covered by the Electronic
> >> >>Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and
> >> >>may be legally privileged. It is intended for the use of the
> >> >>individual or entity to which it is addressed and may contain
> >> >>information that is privileged, confidential, and exempt from
> >> >>disclosure under applicable law. If the reader of this email is not
> >> >>the intended recipient, or agent responsible for delivering or
> >> >>copying of this communication, you are hereby notified that any
> >> >>retention, dissemination, distribution, or copying of this
> >> >>communication is strictly prohibited. If you have received this
> >> >>communication in error, please reply to the sender that you have
> >> >>received the message in error, then delete it. Thank you.
> >> >>
> >> >>
From: Andrew Kirkpatrick
Date: Mon, Nov 09 2009 11:00AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Glad you liked it. Thea Eaton from a company called Doodledoo in Texas created it in conjunction with Knowbility and did a great job.
Thanks,
AWK
Andrew Kirkpatrick
Senior Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
From: Al Sparber
Date: Mon, Nov 09 2009 11:15AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
From: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >
> Glad you liked it. Thea Eaton from a company called Doodledoo in Texas
> created it in conjunction with Knowbility and did a great job.
>> http://www.adobe.com/accessibility/products/flash/tutorial/
Out of curiosity, do you you envision a future Flash release that would have
the brains to do much of this automatically? I would guess that a lot of
Flash authors would not invest the time - especially in a more complex
application.
--
Al Sparber - PVII
http://www.projectseven.com
Dreamweaver Menus | Galleries | Widgets
http://www.projectseven.com/go/apm
An Accessible & Elegant Accordion
From: Andrew Kirkpatrick
Date: Mon, Nov 09 2009 11:55AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Al,
What parts do you want to see happen automatically?
- Adding equivalents for images?
- Adding captions?
- Adding audio description?
- Creating beautiful animated characters?
The beauty of this example is that while slick and highly functional, it demonstrates the effective use of a fairly small number of techniques that apply not only to Flash but to HTML also.
There are a few items that are unique to Flash, including controlling the reading order and controlling the addition/deletion of objects from the reading order. To answer your question, I can envision making the authoring tool provide better supports to accomplish these tasks, but there will always be the need for developers to understand accessibility so they can handle it properly.
We do make products that are not so open-ended as the Flash authoring tool, that provide accessibility support but do not require (or provide means to) change the accessibility support. These are very specific applications with a narrower focus, so they can handle more accessibility by default.
If you have suggestions, I'm happy to take a look.
Thanks,
AWK
Andrew Kirkpatrick
Senior Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
From: ckrugman
Date: Mon, Nov 09 2009 2:55PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
making sure that text presented as part of a graphic or as an imbedded file
is readable with screen reading software. Audio descriptions read at a
normal spped take too much time and screen reading software can read them at
the preferred speed of the user.
Chuck
----- Original Message -----
From: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, November 09, 2009 10:51 AM
Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
expandablemenu?
> Al,
> What parts do you want to see happen automatically?
> - Adding equivalents for images?
> - Adding captions?
> - Adding audio description?
> - Creating beautiful animated characters?
>
> The beauty of this example is that while slick and highly functional, it
> demonstrates the effective use of a fairly small number of techniques that
> apply not only to Flash but to HTML also.
>
> There are a few items that are unique to Flash, including controlling the
> reading order and controlling the addition/deletion of objects from the
> reading order. To answer your question, I can envision making the
> authoring tool provide better supports to accomplish these tasks, but
> there will always be the need for developers to understand accessibility
> so they can handle it properly.
>
> We do make products that are not so open-ended as the Flash authoring
> tool, that provide accessibility support but do not require (or provide
> means to) change the accessibility support. These are very specific
> applications with a narrower focus, so they can handle more accessibility
> by default.
>
> If you have suggestions, I'm happy to take a look.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
>
> Senior Product Manager, Accessibility
>
> Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
>
>
From: Geof Collis
Date: Mon, Nov 09 2009 6:55PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
I'm wondering if Flash will ever be accessible to a screen reader,
wehn I could see I was able to create things like this
http://www.badeyes.com/flash/tower.html, it is not all functional but
I'd sure like to be able to get back into Flash again. Try the
animations section.
cheers
Geof
Editor
Accessibility News
www.accessibilitynews.ca
Accessibility News International
www.accessibilitynewsinternational.com
From: Andrew Kirkpatrick
Date: Mon, Nov 09 2009 7:35PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
There's no reason that that site couldn't be more accessible with a little effort. There are challenges around how to best represent some of the animations in that section, but the same issue needs to be dealt with for animation if provided in a complex animated gif or non-flash movie.
Thanks,
AWK
Andrew Kirkpatrick
Senior Product Manager, Accessibility
Adobe Systems
= EMAIL ADDRESS REMOVED =
From: Al Sparber
Date: Mon, Nov 09 2009 8:50PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
From: "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = >
> Al,
> What parts do you want to see happen automatically?
> - Adding equivalents for images?
> - Adding captions?
> - Adding audio description?
Probably an accessibility application that can be run prior to publishing a
SWF that would recommend/nag the author to add image equivalents and
captions.
> - Creating beautiful animated characters?
ha ha :-)
A text-to-speech app would be cool, too.
I do like the keyboard support in the tutorial.
The biggest drawback to us, as extension developers is still, however, Flash
Player support. I know Adobe's stats are optimistic, and that's
understandable, but there still is a very measurable audience that has no
Flash Player, has an old version and does not know how to upgrade, has an
old version and is not allowed to upgrade, uses a 64-bit browser, etc.
For them there is simply a blank screen.
--
Al Sparber - PVII
http://www.projectseven.com
Dreamweaver Menus | Galleries | Widgets
http://www.projectseven.com/go/apm
An Accessible & Elegant Accordion
From: ckrugman
Date: Mon, Nov 09 2009 9:45PM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Its pretty difficult to use with JAWS as the background music overlays JAWS
so it is difficult to hear and there is inadequate labeling on the screen.
Chuck
----- Original Message -----
From: "Geof Collis" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, November 09, 2009 5:53 PM
Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
expandablemenu?
> I'm wondering if Flash will ever be accessible to a screen reader,
> wehn I could see I was able to create things like this
> http://www.badeyes.com/flash/tower.html, it is not all functional but
> I'd sure like to be able to get back into Flash again. Try the
> animations section.
>
> cheers
>
> Geof
>
>
>
> Editor
> Accessibility News
> www.accessibilitynews.ca
> Accessibility News International
> www.accessibilitynewsinternational.com
>
From: Geof Collis
Date: Tue, Nov 10 2009 5:40AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | Next message →
Yeah but I created it when there wasn't much accessibility built into
Flash and I could see and web accessibility wasn't even in my
vocabulary then, it was purely visual.
cheers
Geof
At 11:43 PM 11/9/2009, you wrote:
>Its pretty difficult to use with JAWS as the background music overlays JAWS
>so it is difficult to hear and there is inadequate labeling on the screen.
>Chuck
>----- Original Message -----
>From: "Geof Collis" < = EMAIL ADDRESS REMOVED = >
>To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>Sent: Monday, November 09, 2009 5:53 PM
>Subject: Re: [WebAIM] mouseover/hover and keyboard accessible
>expandablemenu?
>
>
> > I'm wondering if Flash will ever be accessible to a screen reader,
> > wehn I could see I was able to create things like this
> > http://www.badeyes.com/flash/tower.html, it is not all functional but
> > I'd sure like to be able to get back into Flash again. Try the
> > animations section.
> >
> > cheers
> >
> > Geof
> >
> >
> >
> > Editor
> > Accessibility News
> > www.accessibilitynews.ca
> > Accessibility News International
> > www.accessibilitynewsinternational.com
> >
From: Geof Collis
Date: Tue, Nov 10 2009 5:45AM
Subject: Re: mouseover/hover and keyboard accessible expandablemenu?
← Previous message | No next message
Thing is I need eyesight to do it. :O)
I created it with Flash MX and with JAWS10.0 I actually find it
pretty accessible, probably as I remember the layout and know when to
hit enter to make things happen.
cheers
Geof
At 09:32 PM 11/9/2009, you wrote:
>There's no reason that that site couldn't be more accessible with a
>little effort. There are challenges around how to best represent
>some of the animations in that section, but the same issue needs to
>be dealt with for animation if provided in a complex animated gif or
>non-flash movie.
>
>Thanks,
>AWK
>
>Andrew Kirkpatrick
>
>Senior Product Manager, Accessibility
>
>Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
>
>
>