E-mail List Archives

Search E-mail List Archives for

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

From: Ritz, Courtney L. (GSFC-7200)
Date: Tue, Jun 06 2017 10:00AM
Subject: Accessible Superfish-like drop-down menus?
No previous message | Next message →

Hi all,

I tried a quick search in the archives and I didn't see anything too current on this, so apologies if I've missed something.

Our developers have put some drop-down menus onto some sites in our Druple environment.
As a JAWS user in IE or Firefox, I run into an annoying situation as I Tab through the link in these menus. If I Tab forward through them, I hear each links in the submenu, and then whatever links come after that submenu. However, if I start reverse-Tabbing back through the links, I end up completely skipping the submenu links.

The first menu they tried was called a Nice Menu I think. They switched to Superfish, since it's supposed to be 508 compliant from what they read. I'm still having this problem.

So, I guess my question is, is this just standard behavior for an accessible drop-down menu that I just don't happen to like, or is this a problem that can be fixed by tweaking the menu or trying another solution?

Thanks for any suggestions you may have.

Courtney

From: Lucy Greco
Date: Tue, Jun 06 2017 10:29AM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

hello: this is normal behavior for a simple menu in Druple. what is
going on is as you tab to the menu link the menu is opening and then you
can tab thru the items of the menu. however if your going backwards the
menu is closed until you tab to it and then you keep going backwards over
the menu item itself but not the contents because the contents of the
menu are hidden until you tab to the menu itself. we have added some ARIA
to make this more understandable to a screen reader and the ability to
close the menu if you don't want to tab thru it take a look at
open.Berkeley.edu <http://open.berkeley.edu>;
for an example of how it works. you might also want to take a look at
webaccess.berkeley.edu
to see an example of a menu that does not activate until you want it to.
hint don't tab thru to quickly stay on the links long enough to here the
aria we have added to tell you what is going on. we let you know that you
can open the menu but we also let you know that once your out of the sub
menu that the menu has closed behind you.


Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces


On Tue, Jun 6, 2017 at 9:00 AM, Ritz, Courtney L. (GSFC-7200) <
= EMAIL ADDRESS REMOVED = > wrote:

> Hi all,
>
> I tried a quick search in the archives and I didn't see anything too
> current on this, so apologies if I've missed something.
>
> Our developers have put some drop-down menus onto some sites in our Druple
> environment.
> As a JAWS user in IE or Firefox, I run into an annoying situation as I Tab
> through the link in these menus. If I Tab forward through them, I hear
> each links in the submenu, and then whatever links come after that
> submenu. However, if I start reverse-Tabbing back through the links, I end
> up completely skipping the submenu links.
>
> The first menu they tried was called a Nice Menu I think. They switched
> to Superfish, since it's supposed to be 508 compliant from what they read.
> I'm still having this problem.
>
> So, I guess my question is, is this just standard behavior for an
> accessible drop-down menu that I just don't happen to like, or is this a
> problem that can be fixed by tweaking the menu or trying another solution?
>
> Thanks for any suggestions you may have.
>
> Courtney
> > > > >

From: Ritz, Courtney L. (GSFC-7200)
Date: Tue, Jun 06 2017 10:31AM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

Ah, thanks for clarifying this for me.
I'll take a look at that and have our developers do the same.

Courtney

From: Bossley, Peter A.
Date: Tue, Jun 06 2017 1:28PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

It doesn't make sense to me for a menu to auto-expand on focus, in fact an argument could be made that was a violation in and of itself. The Web Experience Toolkit has really good examples of menubar and sub-menus that work really well.
Just my take.

From: Jeremy Echols
Date: Tue, Jun 06 2017 1:35PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

W3C has an example for a supposedly screen-reader-friendly menu implementation: http://w3c.github.io/aria-practices/examples/menubar/menubar-1/menubar-1.html

I have no idea how well that would fit in Drupal. I'm going to be trying to make something like this work shortly for our own site, but it's going to be very experimental and probably very specific to our needs, as Drupal isn't something I deal with very often. And there's every chance I'll fail anyway :)

If that menubar isn't a good example, though, I'd love to know before I get started.

From: Ritz, Courtney L. (GSFC-7200)
Date: Tue, Jun 06 2017 1:40PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

Hi,

I think we're going to be stuck with Superfish for the time being, since we're in a bit of a time crunch.
But I'm going to push for us to look at other more accessible options for future use.

Courtney

From: Lucy Greco
Date: Tue, Jun 06 2017 3:21PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

that example from w3c is for a menu bar not a site menu menu bars should
only be used in apps and site menus are not menubars

Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces


On Tue, Jun 6, 2017 at 12:40 PM, Ritz, Courtney L. (GSFC-7200) <
= EMAIL ADDRESS REMOVED = > wrote:

> Hi,
>
> I think we're going to be stuck with Superfish for the time being, since
> we're in a bit of a time crunch.
> But I'm going to push for us to look at other more accessible options for
> future use.
>
> Courtney
>
>

From: L Snider
Date: Tue, Jun 06 2017 3:39PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

In the past, I used PVII navigation for drop down fly out navigation
systems:
http://projectseven.com/index.htm

I know that it was very accessible (they really put a lot of time into
making it work with screen readers and keyboards) about 5 years ago,
haven't tested it in a while.

They don't make a Drupal module (which is a pain!), but in the past I have
put it into my Drupal template.

Cheers

Lisa



On Tue, Jun 6, 2017 at 4:21 PM, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:

> that example from w3c is for a menu bar not a site menu menu bars should
> only be used in apps and site menus are not menubars
>
> Lucia Greco
> Web Accessibility Evangelist
> IST - Architecture, Platforms, and Integration
> University of California, Berkeley
> (510) 289-6008 skype: lucia1-greco
> http://webaccess.berkeley.edu
> Follow me on twitter @accessaces
>
>
> On Tue, Jun 6, 2017 at 12:40 PM, Ritz, Courtney L. (GSFC-7200) <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > Hi,
> >
> > I think we're going to be stuck with Superfish for the time being, since
> > we're in a bit of a time crunch.
> > But I'm going to push for us to look at other more accessible options for
> > future use.
> >
> > Courtney
> >
> >

From: Jeremy Echols
Date: Tue, Jun 06 2017 4:04PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

Really? Example 1 seems like almost exactly what we use our site navigation to accomplish.

As a keyboard user, I find the menu bar approach much nicer than the more typical tabbing through piles of links. One tab into the menu, one tab out, arrows to navigate within the menu.

From: Jennifer Sutton
Date: Tue, Jun 06 2017 4:10PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

I would recommend following the guidance in this tutorial on menus, from
WAI:

http://www.w3.org/WAI/tutorials/menus/


If people have issues to report, I'm sure input is welcome.


It's my sense that this information is recent and would follow what's
expected, rather than things that are as old as PVI and Suckerfish.


I sometimes find that what we screen reader consumers might think we
prefer isn't necessarily what spec.(s) say. And if we don't like what
spec.(s) say, it's our job to work to improve/modify them, or change our
mindsets as technology enables us to do so.


To be clear, I'm not saying thse tutorials are spec.s. But it's my
understanding that they've been created based on them.


Kudos to WAI EO and others involved; I think these tutorials, with
included code samples, are some of the best work out there.


Best,

Jennifer

From: L Snider
Date: Tue, Jun 06 2017 4:22PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

Hi Jeremy,

Yes, I would agree with the menu bar approach. As I said these were ones I
used to use, some people use them, others don't...just depends on what you
want to do. At the time, they were better than suckerfish menus, but I am
not sure of suckerfish today (they may be way better).

Cheers

Lisa

On Tue, Jun 6, 2017 at 5:04 PM, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:

> Really? Example 1 seems like almost exactly what we use our site
> navigation to accomplish.
>
> As a keyboard user, I find the menu bar approach much nicer than the more
> typical tabbing through piles of links. One tab into the menu, one tab
> out, arrows to navigate within the menu.
>
>

From: Robert Fentress
Date: Thu, Jun 15 2017 3:07PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

FYI: If you are considering using Approach 2 in the Flyout-Menus section
of that WAI menus tutorial
<https://www.w3.org/WAI/tutorials/menus/flyout/#use-button-as-toggle> Jennifer
referenced (which I rather like), you should be aware that it is not
semantically valid, since it includes a button within a link. An issue
<https://github.com/w3c/wai-tutorials/issues/522> has been filed on GitHub
for this, but no response yet.

I'm currently playing around with modifying it myself, in my spare time
(right). Basically, I make the button a sibling of the link and move
aria-haspopup, and aria-expanded to it. Then, I add aria-controls and
(maybe) aria-owns to the button and associate this with the submenu, which
I then have to explicitly provide an id attribute for.

It's tricky though, because JAWS wants to switch you into Application Mode
when you activate the button. That then requires the user to switch back
to the virtual cursor to navigate the menus that appear. I guess I could
then write code to handle the keyboard interaction, but that adds a whole
other layer of complexity and screws up the elegant simplicity of the
original approach. It seems to me improper that JAWS should change modes
like that, since I haven't explicitly set the role to menu or menuitem or
anything that you would think would trigger it. It's basically just
functioning as a disclosure widget, at that point.

Warning: Here comes the rant. Is it just me or does this seem
wrong? ARIA makes my brain bleed. Why is this so hard? Why isn't the
<menu> tag or something like it implemented in the browser, where all that
keyboard stuff is taken care of by the user agent. Site menus are like,
literally, on almost every other page on the web. How can we expect
developers to write accessible code when a consensus hasn't yet been
reached on the best way to handle these things? Or maybe it has and I just
haven't gotten the memo. What am I missing? Ugh.

Sorry. I just had to get that off my chest.

Best,
Rob

On Tue, Jun 6, 2017 at 6:10 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:

> I would recommend following the guidance in this tutorial on menus, from
> WAI:
>
> http://www.w3.org/WAI/tutorials/menus/
>
>
> If people have issues to report, I'm sure input is welcome.
>
>
> It's my sense that this information is recent and would follow what's
> expected, rather than things that are as old as PVI and Suckerfish.
>
>
> I sometimes find that what we screen reader consumers might think we
> prefer isn't necessarily what spec.(s) say. And if we don't like what
> spec.(s) say, it's our job to work to improve/modify them, or change our
> mindsets as technology enables us to do so.
>
>
> To be clear, I'm not saying thse tutorials are spec.s. But it's my
> understanding that they've been created based on them.
>
>
> Kudos to WAI EO and others involved; I think these tutorials, with
> included code samples, are some of the best work out there.
>
>
> Best,
>
> Jennifer
>
>
>
>
>
> > > > >



--
Rob Fentress
Senior Accessibility Solutions Designer
Assistive Technologies at Virginia Tech
Electronic Business Card (vCard)
<http://search.vt.edu/search/person.vcf?person54847>
LinkedIn Profile
<https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>

From: Matt King
Date: Thu, Jun 15 2017 10:50PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

> ARIA makes my brain bleed. Why is this so hard?

Rob, I feel and understand your pain. I see the pain all around me. It is ubiqquitous.

That is why the ARIA practices task force is working furiously to get a full-fledged, thoroughly reviewed practices guide published -- something that has never existed. The lack of an authoratative practices guide has allowed mass confusion to ferment across the entire industry over the last several years.

BTW, we welcome more members and contributors. Please contact me if you wish to help.

> Why isn't the <menu> tag or something like it implemented in the browser, where all that keyboard stuff is taken care of by the user agent.

HTML menu tag is still experimental; that is not related to ARIA.

> How can we expect developers to write accessible code when a consensus hasn't yet been reached on the best way to handle these things? Or maybe it has and I just haven't gotten the memo.

Solving that is what the ARIA Practices guide is all about. The menubar, menu button, and menu patterns are here:

http://w3c.github.io/aria-practices/#menu

Note that the above is a link to the editor's draft.

Unfortunately, the WAI flyout menu tutorial is not yet well synchronized with ARIA practices. We still have a fair amount of work to get all the resources in sync. Highest priority for me right now is finishing ARIA Practices itself. I commented in the issue you raised so we can work toward improving alignment on this particular set of patterns.

> I'm currently playing around with modifying it myself, in my spare time (right). Basically, I make the button a sibling of the link and move aria-haspopup, and aria-expanded to it.

When you add aria-haspopup=true to a button, that tells the screen reader that it is a menubutton. This is one of those rare exceptions where a property changes the role that is exposed in the accessibility API. It probably would have been more clear if we would have never let properties change the role mapping, but that is a very old ARIA 1.0 decision that is not practical to change now.

A menu button, as you might guess, opens a menu widget.

> Then, I add aria-controls and (maybe) aria-owns to the button and associate this with the submenu, which I then have to explicitly provide an id attribute for.

No, please do not use aria-owns here; that is not valid. It will cause all kinds of problems.

You do not need aria-controls in the menu pattern. We do recommend it for a disclosure (button with aria-expanded).

> I guess I could then write code to handle the keyboard interaction, but that adds a whole other layer of complexity and screws up the elegant simplicity of the original approach.

If you are going to use the menu and menuitem roles, which are required with a menubutton, you are also required to manage focus, AKA write the javascript to move focus. Menus are composite widgets, and composite widgets are expected to manage focus.

> It's basically just functioning as a disclosure widget, at that point.

In that case, I recommend following the disclosure pattern, which is basically just a button with aria-expanded and aria-controls referring to the disclosure content.
http://w3c.github.io/aria-practices/#disclosure

Note that if you want to overload a single focusable element to both open a submenu and execute a link, that widget needs to be a menuitem, not a menu button. Generally, that means using a menubar. The authoring practices task force has an open issue for developing an example that demonstrates that type of behavior. With such menuitems, enter and space activate the link target and the appropriate arrow keys (depending on orientation) open the submenu. Such overloading isn't really the most understandable design.

Hth,
Matt King

From: Robert Fentress
Date: Fri, Jun 16 2017 8:22AM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

Thanks for your response, Matt. See comments inserted below.

On Fri, Jun 16, 2017 at 12:50 AM, Matt King < = EMAIL ADDRESS REMOVED = > wrote:

> > ARIA makes my brain bleed. Why is this so hard?
>
> Rob, I feel and understand your pain. I see the pain all around me. It is
> ubiqquitous.
>

Glad to know I'm not alone.


>
> > Why isn't the <menu> tag or something like it implemented in the
> browser, where all that keyboard stuff is taken care of by the user agent.
>
> HTML menu tag is still experimental; that is not related to ARIA.
>

Yes. My point, though, is that so many of the things that ARIA addresses
are things that should just be a part of the HTML standard. We have select
boxes, radio buttons, etc., which means developers don't need to create
custom controls for these widgets, and deal with all the attendant hassles
of handling the keyboard and touch interaction models, updating states,
etc. Why can't we have the same for menus (of multiple types), trees, tab
controls, and so on? I'm sure there are good reasons, but, if a way could
be found to just fold these things into HTML, that would be a better
solution, I think, than custom coding.


>
> > How can we expect developers to write accessible code when a consensus
> hasn't yet been reached on the best way to handle these things? Or maybe
> it has and I just haven't gotten the memo.
>
> Solving that is what the ARIA Practices guide is all about. The menubar,
> menu button, and menu patterns are here:
>
> http://w3c.github.io/aria-practices/#menu
>
> Note that the above is a link to the editor's draft.
>

Yes, the Authoring Practices guide has been a life saver for some things,
and I refer to it--and refer others to it--often. However, as Lucy
mentioned, the menu pattern described there is not appropriate for site
menus, only application menus.


> Unfortunately, the WAI flyout menu tutorial is not yet well synchronized
> with ARIA practices. We still have a fair amount of work to get all the
> resources in sync. Highest priority for me right now is finishing ARIA
> Practices itself. I commented in the issue you raised so we can work toward
> improving alignment on this particular set of patterns.
>
>
Great!


> > I'm currently playing around with modifying it myself, in my spare time
> (right). Basically, I make the button a sibling of the link and move
> aria-haspopup, and aria-expanded to it.
>
> When you add aria-haspopup=true to a button, that tells the screen reader
> that it is a menubutton. This is one of those rare exceptions where a
> property changes the role that is exposed in the accessibility API. It
> probably would have been more clear if we would have never let properties
> change the role mapping, but that is a very old ARIA 1.0 decision that is
> not practical to change now.
>
> A menu button, as you might guess, opens a menu widget.
>
> > Then, I add aria-controls and (maybe) aria-owns to the button and
> associate this with the submenu, which I then have to explicitly provide an
> id attribute for.
>
> No, please do not use aria-owns here; that is not valid. It will cause all
> kinds of problems.
>
> You do not need aria-controls in the menu pattern. We do recommend it for
> a disclosure (button with aria-expanded).
>
> > I guess I could then write code to handle the keyboard interaction, but
> that adds a whole other layer of complexity and screws up the elegant
> simplicity of the original approach.
>
> If you are going to use the menu and menuitem roles, which are required
> with a menubutton, you are also required to manage focus, AKA write the
> javascript to move focus. Menus are composite widgets, and composite
> widgets are expected to manage focus.
>
> > It's basically just functioning as a disclosure widget, at that point.
>
> In that case, I recommend following the disclosure pattern, which is
> basically just a button with aria-expanded and aria-controls referring to
> the disclosure content.
> http://w3c.github.io/aria-practices/#disclosure
>
> Note that if you want to overload a single focusable element to both open
> a submenu and execute a link, that widget needs to be a menuitem, not a
> menu button.


I've seen this done before, but I think the idea of a click event on a menu
item pulling double duty as a trigger for the submenu (first click) and a
link that takes you places (second click) is really bad. I don't think it
really fits the menuitem role, either.


> Generally, that means using a menubar. The authoring practices task force
> has an open issue for developing an example that demonstrates that type of
> behavior. With such menuitems, enter and space activate the link target and
> the appropriate arrow keys (depending on orientation) open the submenu.
> Such overloading isn't really the most understandable design.
>

The issue, as I see it, boils down to the fact that the interaction
patterns users have come to expect on the web don't track with the
system-level widgets that ARIA is attempting to map to. The site
navigation fly-out menu is not a system menu, and the expander for a
submenu is not really a button menu (I don't think). That is why I tried
to use the disclosure pattern, as it seemed to be the most agnostic about
what it was doing and, I thought, wouldn't require me to manage focus or
the active descendent. I think web users expect to be able to tab between
links on a page, rather than have submenus function as composite widgets
that have to be navigated by using arrow keys. You can't meet all
expectations (thus the expander button), but this approach seemed,
intuitively (no data), to me, to meet the requirements and expectations of
the most users. These expectations being something like:

- Mouse users expect to hover over a menu link and have it expand, and
also to be able to click on that link and have it take them to the index
page for the submenu items.
- Keyboard users should be able to get to links in the menu without
having to tab through every link in the menu, though they also expect to be
able to tab between links, generally.
- Screen reader users should be able to navigate the links using as many
useful cues and affordances as possible, but without being provided cues or
affordances that are inaccurate. In other words, they should not map to
system-level widgets, but then not follow the expected behaviors of those
system-level widgets.
- And do so in a way that still works for users of touchscreen devices.

That's my thinking at the moment. I'm sure, if I read and studied more,
I'd have better insights, but that's where I'm at now after exploring this
space. I welcome feedback.

Thanks, again, Matt, for your comments, and for your efforts on the ARIA
practices task force in trying to make the web a better place for everyone.

Best,
Rob



--
Rob Fentress
Senior Accessibility Solutions Designer
Assistive Technologies at Virginia Tech
Electronic Business Card (vCard)
<http://search.vt.edu/search/person.vcf?person54847>
LinkedIn Profile
<https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>

From: Robert Fentress
Date: Fri, Jun 16 2017 8:43AM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

Following up on my previous post, see comment below

On Fri, Jun 16, 2017 at 10:22 AM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:

> The site navigation fly-out menu is not a system menu, and the expander
> for a submenu is not really a button menu (I don't think).
>
>
A reason why a button menu is not appropriate here is that these submenus
may, themselves, have submenus. Though I don't think this is best
practice, it is not unusual to see this multi-level menu pattern. Ideally,
you'd want to accommodate that use case in whatever design you chose.


--
Rob Fentress
Senior Accessibility Solutions Designer
Assistive Technologies at Virginia Tech
Electronic Business Card (vCard)
<http://search.vt.edu/search/person.vcf?person54847>
LinkedIn Profile
<https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>

From: Mallory
Date: Fri, Jun 16 2017 8:53AM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

The menu on pearson.com used to have this: website menu items that tried
to do double duty as both items you could click (as expected of menu
items) and something that opened a dropdown (they added a little button
next to the regular menu item). For sighted keyboarding through this
site on a laptop, it was *painful*. I would have rather that the
submenus appeared on focus (for all the problems that things appearing
on focus can cause) and have the link parts stay links that go places.
It was difficult to open and close submenus at will. It was difficult to
click links. It was just a pain in the ass to navigate. And I'm just
assuming this all would have been harder with a screen reader (I did go
through it with Orca once and I never made any sense of it there either;
however I can't put myself in the place of a usual-screen-reader-user).

We need a solution for web menus (aria menus are just not right for
this). We additionally need a solution for a separate issue: so far in
my work I've run into multiple *things* that, on the surface, look like
they might be aria-menu-pattern-following things: buttons that when you
click them, a sort of menu popups open underneath.

However, aria menus are extremely limited in what goes inside these
things. And the teams asking my advice are putting *whole damn forms*
inside these. Anything that can't be a menuitem, menuitemcheckbox, or
menuitemradio don't really fit into the aria menu pattern, even if a
*lot* of it, but not all of it, would make sense.

I'm wondering if the aria specs need to consciously stop completely
trying to imitate "what desktop applications do" because that world is
being left behind FAST. Similar to someone recognising a triangle on
its side *within a video context* knows that probably means "Play" but
not having any idea what a sideways triange is in any other context,
we're finding in user testing that people don't know how to use these
things, despite the idea that this is already what they're using when it
comes to desktop application controls. The website menus are a good
example of this: we've beaned into users that on the web, menus work a
certain way, which is different from how app menus work.

Robert, thanks for your rant. It's lowering my cortisone levels as we
speak :P

cheers,
Mallory

On Fri, Jun 16, 2017, at 04:43 PM, Robert Fentress wrote:
> Following up on my previous post, see comment below
>
> On Fri, Jun 16, 2017 at 10:22 AM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
>
> > The site navigation fly-out menu is not a system menu, and the expander
> > for a submenu is not really a button menu (I don't think).
> >
> >
> A reason why a button menu is not appropriate here is that these submenus
> may, themselves, have submenus. Though I don't think this is best
> practice, it is not unusual to see this multi-level menu pattern.
> Ideally,
> you'd want to accommodate that use case in whatever design you chose.
>
>
> --
> Rob Fentress
> Senior Accessibility Solutions Designer
> Assistive Technologies at Virginia Tech
> Electronic Business Card (vCard)
> <http://search.vt.edu/search/person.vcf?person54847>
> LinkedIn Profile
> <https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>
> > > >

From: Tim Harshbarger
Date: Fri, Jun 16 2017 9:00AM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

One thing that might be worth mentioning--that is easy to forget.

ARIA is really only intended to be used in situations where the technology doesn't already provide those features. Definitely, it would be great if there were a menu element that we could use for menus. That would need to be something added to the HTML 5 spec and implemented by user agents. So if we want those features, we definitely should be recommending those things to people involved with the HTML 5 specs and with user agents.

We only really use ARIA as a stop gap for situations where the technology itself (like HTML) doesn't provide that ability. Ok, maybe not always. We also use it when developers want to do things like create their own buttons--even though HTML does provide a way to create buttons. So maybe it is more accurate to say that we use ARIA when the developer wants to do something that doesn't appear to be supported by the technology (like HTML.)

Rob, I do have a question for you because I want to clarify my understanding of the problem. Is the complexity that is problematic due to trying to figure out what roles and states need to be applied and manipulated? Or is the complexity in writing the code that accomplishes that?

Thanks,
Tim

From: Robert Fentress
Date: Fri, Jun 16 2017 9:51AM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

Thanks for the question, Tim. Comment below:

On Fri, Jun 16, 2017 at 11:00 AM, Tim Harshbarger <tim.harshbarger.cqwg@
statefarm.com> wrote:
>
>
> Rob, I do have a question for you because I want to clarify my
> understanding of the problem. Is the complexity that is problematic due to
> trying to figure out what roles and states need to be applied and
> manipulated? Or is the complexity in writing the code that accomplishes
> that?


Well, there is complexity in knowing what the right semantics to apply are
(especially with the crazy, one-off composite custom widgets folks are
developing all over the place), but the real issue for me is the amount of
time it takes to test that whatever model you've chosen actually works as
you expect it would in a given assistive technology. JAWS handles things
differently than NVDA than VoiceOver on MacOS than VoiceOver on iOS, etc.,
etc. An example might be the way focus follows the cursor in NVDA, but not
in JAWS, depending on the mode. How these AT work affect how you track
ARIA states using JavaScript, and it is easy for things to get out of sync
or behave differently than you expected. I do not have a visual
impairment, so, though I've put in a lot of time getting familiar with
them, I likely don't use screen readers as folks who have to use them every
day do. So having to discern if a problem I encounter is due to my lack of
fluency with the AT or something I'm doing wrong code-wise is a real pain.
Then there is the issue of deciding how fluent different populations of
blind users are with their *own* AT and what interaction patterns I can
reasonably expect them to be familiar with.

P.S. I'm focusing on screen readers here, because they are the most
difficult to develop for, not because I think making things accessible
means just making them work for blind folks.

--
Rob Fentress
Senior Accessibility Solutions Designer
Assistive Technologies at Virginia Tech
Electronic Business Card (vCard)
<http://search.vt.edu/search/person.vcf?person54847>
LinkedIn Profile
<https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>

From: Matt King
Date: Fri, Jun 16 2017 12:46PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

> Yes, the Authoring Practices guide has been a life saver for some things, and I refer to it--and refer others to it--often.
> However, as Lucy mentioned, the menu pattern described there is not appropriate for site menus, only application menus.

The ARIA menu pattern can work very well for site menus. It can be used for any menu that follows the style of interaction described in the pattern, regardless of the purpose of the menu items. So, whether it is appropriate has nothing to do with where the menu is or where the menu items take the user. It is all about what kind of interaction model you want.

> > Note that if you want to overload a single focusable element to both
> > open a submenu and execute a link, that widget needs to be a menuitem,
> > not a menu button.
>
> I've seen this done before, but I think the idea of a
> click event on a menu item pulling double duty as a trigger for the submenu
> (first click) and a link that takes you places (second click) is really bad.
> I don't think it really fits the menuitem role, either.

Sorry, that is not what I meant, and I agree that is bad. I was talking about hovering on a menu name reveals its submenu and clicking it goes to a page. We can do that with ARIA menus. Although, I don't that is great either.

> The issue, as I see it, boils down to the fact that the interaction patterns users have come to expect on the web don't track with the system-level widgets that ARIA is attempting to map to.

I see why you might say that. But, that is assuming you have to limit use of ARIA and the system level accessibility APIs to mirroring the exact interactions you see on the desktop. ARIA isn't really that limitted. It is better to think of ARIA as a sort of non-visual CSS and the accessibility APIs are like display drivers.

The key here is understanding how those APIs are interpreting the ARIA and how different roles, states, and properties can or cannot work together and what is or is not understandable by users. Unfortunately, as you have already mentioned, the tools available to help you do that are non-existent. Of course, the ridiculous complexity of screen reader user interfaces doesn't help.

> The site navigation fly-out menu is not a system menu,

One possible implementation is like that. But, that is not the only way.

> and the expander for a submenu is not really a button menu (I don't think).

Right, it is only a menu button if it opens a menu that works like what you call a "system menu." That is, a menu that manages focus.

> That is why I tried to use the disclosure pattern,
> as it seemed to be the most agnostic about what it was doing
> and, I thought, wouldn't require me to manage focus or the active descendent.

Spot on.

> I think web users expect to be able to tab between links on a page,
> rather than have submenus function as composite widgets that have to be navigated by using arrow keys.

Sticking to 1995 web keyboard design with long tab rings is an option, but that approach treats keyboard users like second class citizens. Helping them take advantage of GUI conventions on the web is like how we moved people away from DOS command lines to GUIs. It is a paradigm shift, and we need to realize that as we design.

> - Mouse users expect to hover over a menu link and have it expand,
> and also to be able to click on that link and have it take them to the index page for the submenu items.
> - Keyboard users should be able to get to links in the menu without
> having to tab through every link in the menu,
> though they also expect to be able to tab between links, generally.

Where designs fall down here is that there are no visual conventions for helping users navigate with the keyboard. For instance, how do they know when arrow key navigation is available? This lack of affordance perceivability is an oversight in desktop visual design that persists on the web, and it is something I desparately want to help rectify. Learning to operate exclusively with the keyboard is unnecessarily difficult. Why do mouse users get different shaped pointers? Because they are first-class citizens.

> - Screen reader users should be able to navigate the links using as many
> useful cues and affordances as possible,
> but without being provided cues or affordances that are inaccurate.

Correct. one of the tricky parts of this is that the division of responsibilities between web engineers and screen reader developers remains extremely ambiguous. I am hoping we can make some progress on this front after we have solid reference implementations of web GUI in the ARIA authoring practices.

> In other words, they should not map to system-level widgets,
> but then not follow the expected behaviors of those system-level widgets.

Yes, yes, yes! Do not use ARIA in a way that deceives the user.

> - And do so in a way that still works for users of touchscreen devices.

Mobile is a large problem space of its own -- a rat whole I don't time to crawl into now.
> That's my thinking at the moment.

I am happy your are thinking so clearly and deeply about this. You have obviously invested a lot of time in understanding accessibility. Thank you! Thank you!! As someone who is blind, I am very grateful to you and everyone else on this list who is working so hard to make it possible for all people to benefit from your work.

Matt King

From: Matt King
Date: Fri, Jun 16 2017 12:48PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

ARIA menu buttons may open menus that have submenus. That is not a problem.

From: Matt King
Date: Fri, Jun 16 2017 1:14PM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | Next message →

> We need a solution for web menus
> (aria menus are just not right for this).

Mallory, we can make anything you like with ARIA; any kind of web menu you like. However, we may or may not use the menu role. Please don't confuse the ARIA role name with the street name of a component. Menu is a word with a nearly infinite number of meanings. But, in ARIA, it has a very specific set of meanings.

> so far in my work I've run into multiple *things*
> that, on the surface, look like they might be aria-menu-pattern-following things:
> buttons that when you click them, a sort of menu popups open underneath.
> However, aria menus are extremely limited in what goes inside these things.
> And the teams asking my advice are putting *whole damn forms* inside these.
> Anything that can't be a menuitem, menuitemcheckbox, or menuitemradio don't really fit into the aria menu pattern,
> even if a *lot* of it, but not all of it, would make sense.

Very often these mega menu type of experiences that include inputs, filtering, tabs, etc., can be implemented very nicely using the ARIA dialog as a container.

> I'm wondering if the aria specs need to
> consciously stop completely trying to imitate "what desktop applications do"
> because that world is being left behind FAST.

While ARIA 1.x is limited to a role-mapping construct, due to the nature of accessibility APIs at this time, that does not necessarily limit your designs to desktop-like experiences. Nearly all web designs can be fairly easily broken down into some set of ordinary ARIA components. And, creative manipulation of those components, in ways that are consistent with the intent of the spec, expands the universe to cover nearly anything. So, move design forward. I believe that ARIA is flexible enough to move with you ... for the most part. Exceptions are hard to find.

Hopefully in ARIA 2.x, we will also have some way of expressing control patterns or something like that as well.

> Similar to someone recognising a triangle on its side *within a video context* knows that probably means "Play"
> but not having any idea what a sideways triange is in any other context,
> we're finding in user testing that people don't know how to use these things,

Are you saying that if you label your play icon "Play" and give it a button role and make it work like a button that screen reader users don't know how to operate it? Or, am I misreading this?

Matt King

From: Mallory
Date: Sun, Jun 18 2017 5:50AM
Subject: Re: Accessible Superfish-like drop-down menus?
← Previous message | No next message

Hi Matt,

>Are you saying that if you label your play icon "Play" and give it a button role and make it work like a button that screen reader users don't know how to operate it? Or, am I misreading this? /unquote

Misreading; it's a (becoming common) example of how a general user's
understanding of an interface is horribly context-sensitive (which is
normal, I'm not disputing that). It's using the specific example of
sighted users not recognising a sideways triangle in general, but almost
always knowing what it means if they see it on something that looks like
a video player. One example I've seen in the wild was the dishwashing
machine at work: the company who created it didn't want multiple
translations for start and pause/stop, so they actually used a sideways
triangle and a square to label those buttons. Nobody knew what they did
at first and someone taped a little bit of paper over them with actual
words so employees could learn what they meant over the course of a
month or so. Did people learn? Yes. Was it intuitive? No. Someone dug
out the manual, something that doesn't tend to come with websites.
Same goes for website menus: people see those visually and the first
thing they try to do is tab. So for me (on desktop only, this sucks on
mobile), my best keyboard experience is tabbing from visible menu item
to visible menu item. If there's a submenu, it appears visually when I'm
focussed on a menu item. I can then switch to arrows to explore the
submenus, or not-- to prevent the 1000-Tabs-Of-Death, but again most
users would have to either get instructions or figure out themselves
that arrows are the key. Automatically moving focus to the first submenu
item (aria-menu pattern) would be an extremely frustrating no-no, since
the subs appear on focus which is a semi-passive user action-- but
having enter trigger the subs mean we've lost all the progressive
enhancement of the submenu, where the top-level menu item is no longer a
link that takes you to a sub-category page like it should (which is why
I don't care too much that it doesn't work on mobile-- the submenus are
enhancements for impatient desktop users, but not blocking a touchscreen
from also completing a task via the main top-level links).

Screen reader users are sometimes not my problem group, exactly as you
said: they often literally get more semantics read out to them, and they
have lots of navigation options. Meanwhile my sighted keyboarders don't
get any of that. They can't hear if a dropdown is supposed to be a
disclosure widget which may expect they tab into it, vs an aria-menu
where the expectation is that focus gets managed right out from under
them (often unexpectedly) and they're supposed to switch to arrows.
I've got a popup that is triggered by users clicking a button. IF there
are existing labels (words used by users to "tag" an item they are
creating) then those are menuitems and are selectable the usual way...
but after the labels and still inside the popup, there's a form, where
one can type in new text and create, inside that menu, another text
label/tag. If the form were not inside, the fact that there are little
fake checkboxes next to the label/tag items and people can check
multiple of them while the dropdown is open, that smells like an
aria-menu (with menuitemcheckboxes). But oops someone made a slight
manBearPig franken-creature and put a form inside (label, text input,
and a sort of javascript-submit button).
Absolutely zero keyboard users have any excellent ideas how to deal with
this thing. It's 100% trial and error, though luckily they don't have
many options to try. It makes the entire thing unweildy. You can argue
(correctly and I would 100% agree) that such franken-things should not
be given to users in the first place because they suck. They are bad UX.
But these are coming more and more in many applications, especially when
sticking to traditional HTML or desktop-applications can nearly double
the number of form controls or actions needed for any user to complete a
task. These things are conglomerates of other things and so have no
pre-set semantics available-- not really in aria and definitely not in
HTML.
(btw we are trying desperately to convince the visual designers to use
something else, such as a sort of autocomplete-multiple values widget
similar to many email clients' To: field... so far, to no avail,
"because Google's got one of these." Le sigh)

If the things that look like they're tabbable looked a certain way, and
the things that are to be arrowed looked another way, it would help
immensely, but we can't get all the graphic designers around the world
to do that. Herding cats, I don't think it will happen.

So my triangle example is how people recognise controls and knowing what
to do, and in a lot of these cases the problem isn't really screen
reader users, but sighted keyboard, speech rec, and of course in our
case students and others with any range of cognitive issues.

By the way, when I say "aria menu" I am specifically talking about a
menu that is triggered by a button, with a has-popup on it, focus is
moved to the first item, and users must cycle around with arrows. I'm
not confusing this with regular menus; I don't believe website menus
should be aria-menus. In fact, because changing the navigation's list of
links into buttons means we've lost our main navigation links, users
must click the button to see what's in the submenu, then shift-tab their
way back out because they're focus was thrown inside. Unhandy and
frustrating, though I'll be the first to admit I'm an extremely
easily-frustrated person and most software is a pain for me to use.

cheers,
Mallory