WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Using has-poppup to affect touch UIs

for

From: Patrick H. Lauke
Date: Dec 13, 2013 5:52PM

On 13/12/2013 23:11, Bryan Garaventa wrote:
> I wouldn't see any of this being a problem if MS had invented their own
> attribute for doing this, E.G ms-haspopup="true" or something like. It's the
> cross-purposing of an ARIA attribute that is where I see this being a
> problem, since it imparts browser specific functionality to a cross-browser
> attribute.

Of course, if MS had invented a new attribute, that would have put the
onus on developers to change their existing/legacy sites in order to
support a potential fix to certain common problems (primarily
hover-based menus) found mostly in...well...legacy sites. And we know
that this never flies (unless it's a -webkit prefixed new hotness, where
developers seem to lose all sense of reason just to get the shiny).

So MS made a leap of assumption that if some sites have at least added
ARIA to their menus, then they may take advantage of that if present and
infer that this is in fact something that most likely reacts to hover,
and so the first tap on a touchscreen should fake a hover behavior
rather than passing a click through to the element. Interestingly, this
approach is perhaps less haphazard than the heuristics-based behavior
iOS Safari and UIWebView take, where the processing of events is halted
(so no click is fired) if after the initial mouse compatibility events
like mouseover, as well as the following focus, are fired, something
changes in the visual presentation of the page (e.g. a div is flipped
from display:none to display:block or similar). [1]

It's also worth noting that the MS approach is not, from what I can
tell, touted as a suggested solution as such (the more common advice
nowadays, with touch interfaces being so prevalent, is to avoid
hover-based interactions exactly because hover on touchscreens can at
best be faked), but rather as a stopgap bridging solution, and it hopes
to hook into existing ARIA use for a slightly better experience on touch
devices. Not philosophically pure, but pragmatic. I don't - and maybe
I'm too optimistic - foresee a flood of developers now rushing to add
aria-haspopup to their legacy sites...and for any new projects, it's far
more likely they'll actually design interfaces that simply don't rely on
hover (or provide a different solution in case the user didn't get to a
control with a hover-capable input like a mouse, but rather a
touch/stylus/etc).

Getting back to the wording of the ARIA spec, though, I find it slightly
limited/limiting. And yes, the fact that some screenreaders have taken
the word of the spec literally and announce "menu" rather than "has
popup" is...unfortunate. And yes, in the here and now this will pose a
problem. But if we think that the spec itself should be loosened or
expanded in its definition, and sites use aria-haspopup for more than
the use proposed in the wording of the spec (e.g. a button that triggers
a modal dialog, using aria-haspopup to provide some form of role/state
to indicate that activating the button will in fact display, and move
focus to, a modal on the same page), AT would likely also expand what
they announce to reflect the reality of the web (but of course, at the
usual "fast" pace we're used to from some AT vendors).

All this IMHO, of course...

P


[1] figure 6-4 in
https://developer.apple.com/library/IOS/documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html#//apple_ref/doc/uid/TP40006511-SW7


--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke