WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Using has-poppup to affect touch UIs

for

From: Steve Faulkner
Date: Dec 13, 2013 6:03PM

>
> 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.


just to grind my axe that never gets sharpened or is constantly blunted by
misunderstanding.

the haspopup state was not an invention of ARIA (which is the case for the
majority of ARIA roles/states/prp[erties), aria just allows authors to set
it whereas previously it was the domain of software implementers. As noted
earlier in this thread, it is an MSAA state that has been available and
used in desktop software for at least 10 years. Part of the usefulness of
ARIA is that AT do not for the most part have to learn new semantics. The
observed SR behavior is almost certainly derived from how the same state is
exposed in desktop sofware

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;


On 14 December 2013 00:52, Patrick H. Lauke < <EMAIL REMOVED> > wrote:

> 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
> > > > >