WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Superfish-like drop-down menus?

for

From: Mallory
Date: Jun 18, 2017 5:50AM

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