WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Using has-poppup to affect touch UIs

for

From: Bryan Garaventa
Date: Dec 13, 2013 4:11PM

"Well i respectfully dispute that, as the related article talks about an
additional meaning that Microsoft have assigned to aria-haspopup which is
currently not defined in a standard."

I concede the point, unfortunately MS doing this and using an ARIA attribute
to do it with, is likely to muddy the waters even further regarding ARIA,
since MS is assigning functionality to an ARIA attribute that has no
supporting standard and appears not to have any consideration for underlying
screen reader functionality running on the same operating system.

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.


----- Original Message -----
From: "Steve Faulkner" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Friday, December 13, 2013 12:18 PM
Subject: Re: [WebAIM] Using has-poppup to affect touch UIs


> >
>> However, if you want something that works right now, you have to build
>> applications that work right now using what is currently available.
>
>
> sure, so its good to know that there is variability in implementation, as
> I
> pointed out in regards to JAWS and as Alastair pointed out in regards to
> VO.
>
> The topic of this message isn't regard to standards, but whether
>> aria-haspopup works right now for indicating popups that are not related
>> to
>> menus. And currently, it's not reliable for this purpose.
>
> Well i respectfully dispute that, as the related article talks about an
> additional meaning that Microsoft have assigned to aria-haspopup which is
> currently not defined in a standard.
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
>
>
> On 13 December 2013 17:54, Bryan Garaventa
> < <EMAIL REMOVED> >wrote:
>
>> Granted that's true, and will always be so.
>>
>> However, if you want something that works right now, you have to build
>> applications that work right now using what is currently available.
>>
>> The topic of this message isn't regard to standards, but whether
>> aria-haspopup works right now for indicating popups that are not related
>> to
>> menus. And currently, it's not reliable for this purpose.
>>
>> ----- Original Message -----
>> From: "Steve Faulkner" < <EMAIL REMOVED> >
>> To: "WebAIM Discussion List" < <EMAIL REMOVED> >
>> Sent: Friday, December 13, 2013 9:02 AM
>> Subject: Re: [WebAIM] Using has-poppup to affect touch UIs
>>
>>
>> > >
>> >> I understand, but the screen reader behaviors have to be taken into
>> >> account
>> >> as well when implementing real world solutions.
>> >
>> >
>> > of course, but this does not mean features cannot or do not
>> develop/change
>> > over time
>> >
>> > --
>> >
>> > Regards
>> >
>> > SteveF
>> > HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
>> >
>> >
>> > On 13 December 2013 16:55, Bryan Garaventa
>> > < <EMAIL REMOVED> >wrote:
>> >
>> >> I understand, but the screen reader behaviors have to be taken into
>> >> account
>> >> as well when implementing real world solutions.
>> >>
>> >> ----- Original Message -----
>> >> From: "Steve Faulkner" < <EMAIL REMOVED> >
>> >> To: "WebAIM Discussion List" < <EMAIL REMOVED> >
>> >> Sent: Friday, December 13, 2013 8:48 AM
>> >> Subject: Re: [WebAIM] Using has-poppup to affect touch UIs
>> >>
>> >>
>> >> > Hi Bryan,
>> >> >
>> >> > note the advice is not set in stone, and can be changed if use cases
>> >> arise
>> >> > as they appear to be.
>> >> >
>> >> > --
>> >> >
>> >> > Regards
>> >> >
>> >> > SteveF
>> >> > HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
>> >> >
>> >> >
>> >> > On 13 December 2013 16:35, Bryan Garaventa
>> >> > < <EMAIL REMOVED> >wrote:
>> >> >
>> >> >> Actually I had the same question yesterday, and got some
>> >> >> confirmation
>> >> >> about
>> >> >> this which I've pasted below. The attribute aria-haspopup should
>> >> >> only
>> >> >> be
>> >> >> used on menus.
>> >> >>
>> >> >> ----- Original Message -----
>> >> >> From: "Joseph Scheuhammer" < <EMAIL REMOVED> >
>> >> >> To: < <EMAIL REMOVED> >
>> >> >> Sent: Thursday, December 12, 2013 11:15 AM
>> >> >> Subject: Re: Using aria-haspopup to simulate hover on touch-enabled
>> >> >> devices
>> >> >> (Windows)
>> >> >>
>> >> >>
>> >> >> > On 2013-12-12 2:09 PM, Bryan Garaventa wrote:
>> >> >> >> One concern I have is that hover can be used for many things,
>> >> >> >> not
>> >> just
>> >> >> >> for menus, and if devs start implementing aria-haspopup on all
>> >> >> >> elements that show hover activity, screen readers like JAWS and
>> >> >> >> NVDA
>> >> >> >> will be announcing "Menu" and "Submenu" everywhere.
>> >> >> >
>> >> >> > Right. The spec states that aria-haspopup is for menus:
>> >> >> > " Indicates that the element has a popup context menu or
>> >> >> > sub-level
>> >> >> > menu."
>> >> >> >
>> >> >> > I goes on to say that tooltips are not considered popups;
>> >> >> > tooltips
>> >> >> > generally "pop up" on a mouse hover. That entails that
>> >> >> > aria-haspopup
>> >> >> > should not be used except to indicate that there is a menu
>> >> >> > associated
>> >> >> > with the current element.
>> >> >> >
>> >> >> > Is Microsoft applying aria-haspopup to *any* content that can be
>> >> >> > revealed on hover?
>> >> >> >
>> >> >> > --
>> >> >> > ;;;;joseph.
>> >> >> >
>> >> >> >
>> >> >> > 'A: After all, it isn't rocket science.'
>> >> >> > 'K: Right. It's merely computer science.'
>> >> >> > - J. D. Klaun -
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> ----- Original Message -----
>> >> >> From: "Steve Faulkner" < <EMAIL REMOVED> >
>> >> >> To: "WebAIM Discussion List" < <EMAIL REMOVED> >
>> >> >> Sent: Friday, December 13, 2013 5:00 AM
>> >> >> Subject: Re: [WebAIM] Using has-poppup to affect touch UIs
>> >> >>
>> >> >>
>> >> >> > Hi Alastair,
>> >> >> >
>> >> >> > interesting,
>> >> >> >
>> >> >> > However, I know Bryan has done some testing which prompted him to
>> >> >> > say:
>> >> >> > "The
>> >> >> >> attribute aria-haspopup should only be used on triggering
>> >> >> >> elements
>> >> >> >> that
>> >> >> >> open menus. Otherwise, the presence of the attribute will only
>> >> >> >> misrepresent
>> >> >> >> the popup type to screen reader users." (from
>> >> >> >> http://whatsock.com/tsg/)
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > the aria-haspopup state allows authors to set the MSAA
>> >> >> > STATE_SYSTEM_HASPOPUP "When invoked, the object displays a pop-up
>> >> >> > menu
>> >> >> > or
>> >> >> > a
>> >> >> > window." [1]
>> >> >> >
>> >> >> > While the ARIA spec does define haspop more explicitly than MSAA,
>> >> >> > and
>> >> >> > is
>> >> >> > generally treated as an indication of the presence of a menu
>> >> asscoiated
>> >> >> > with the control, it is not always treated as such. For example,
>> >> >> > using
>> >> >> > JAWS
>> >> >> > if a link has aria-haspopup it announces that the link "has pop
>> >> >> > up"
>> >> >> rather
>> >> >> > than specifically stating menu/submenu which is the behaviour
>> >> exhibited
>> >> >> > when present on controls and by other AT (not extensively
>> >> >> > tested).
>> >> >> > "Indicates that the element has a popup context menu or sub-level
>> >> >> > menu."
>> >> >> > [2]
>> >> >> >
>> >> >> > I have a page with some test cases which may be helpful [3].
>> >> >> >
>> >> >> > I would suggest that the expansion of the meaning of
>> >> >> > aria-haspopup
>> >> >> > should
>> >> >> > be specified (an issue for ARIA 1.1 [4]). I have sent an email to
>> >> >> > the
>> >> >> > PF
>> >> >> > list in this regard [5]
>> >> >> >
>> >> >> > [1]
>> >> >> >
>> http://msdn.microsoft.com/en-us/library/dd373609%28v=3dvs.85%29.aspx
>> >> >> > [2]
>> >> >> > http://www.w3.org/TR/wai-aria/states_and_properties#aria-haspopup
>> >> >> > [3] https://dl.dropboxusercontent.com/u/377471/aria-haspopup.html
>> >> >> > [4] http://www.w3.org/WAI/PF/aria-1.1/
>> >> >> > [5]
>> >> >> >
>> >> >>
>> >>
>> http://lists.w3.org/Archives/Public/public-pfwg-comments/2013OctDec/0004.html
>> >> >> >
>> >> >> > --
>> >> >> >
>> >> >> > Regards
>> >> >> >
>> >> >> > SteveF
>> >> >> > HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
>> >> >> >
>> >> >> >
>> >> >> > On 13 December 2013 09:54, Alastair Campbell < <EMAIL REMOVED> >
>> >> wrote:
>> >> >> >
>> >> >> >> I came across an interesting article from Microsoft about an
>> >> >> >> approach
>> >> >> >> they
>> >> >> >> are taking, "Using aria-haspopup to simulate hover on
>> touch-enabled
>> >> >> >> devices":
>> >> >> >>
>> >> http://msdn.microsoft.com/en-us/library/ie/jj152135%28v=vs.85%29.aspx
>> >> >> >>
>> >> >> >> At first glance has-popup appears to be a useful indicator that
>> >> >> >> touch
>> >> >> >> devices could use to trigger the hover-interaction first, and
>> >> >> >> then
>> >> >> >> a
>> >> >> >> second
>> >> >> >> tap activates the control. It would appear to work from that
>> >> >> >> point
>> >> >> >> of
>> >> >> >> view,
>> >> >> >> for things like menus which have on-hover states.
>> >> >> >>
>> >> >> >> However, I know Bryan has done some testing which prompted him
>> >> >> >> to
>> >> say:
>> >> >> >> "The
>> >> >> >> attribute aria-haspopup should only be used on triggering
>> >> >> >> elements
>> >> >> >> that
>> >> >> >> open menus. Otherwise, the presence of the attribute will only
>> >> >> >> misrepresent
>> >> >> >> the popup type to screen reader users." (from
>> >> >> >> http://whatsock.com/tsg/)
>> >> >> >>
>> >> >> >> Does anyone foresee problems with this method, in terms of
>> >> encouraging
>> >> >> >> the
>> >> >> >> use of has-popup for non-accessibility reasons?
>> >> >> >>
>> >> >> >> On the other hand, perhaps it will mean lots more sites will use
>> >> >> >> has-popup,
>> >> >> >> at least somewhat appropriately...?
>> >> >> >>
>> >> >> >> -Alastair
>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
>> >> >> > >> >> >> > >> >> >> > >> >> >>
>> >> >> >> >> >> >> >> >> >> >> >>
>> >> > >> >> > >> >> > >> >>
>> >> >> >> >> >> >> >>
>> > >> > >> > >>
>> >> >> >>
> > >