E-mail List Archives

Search E-mail List Archives for

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

From: Alastair Campbell
Date: Fri, Dec 13 2013 2:54AM
Subject: Using has-poppup to affect touch UIs
No previous message | Next message →

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

From: Steve Faulkner
Date: Fri, Dec 13 2013 6:00AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

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

From: Alastair Campbell
Date: Fri, Dec 13 2013 8:22AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

Thanks Steve,

Expanding the meaning seems like a good idea if it doesn't impact other
things, I assume it's too late to rename it hasmenu?!

Given the name, it would not surprise me at all if other people don't
realise it was intended to apply to menus, anyone scanning the list trying
to achieve something will probably just pick haspopup. There's a similar
problem for dialog, where I see that used for content pop-overs (and then
NVDA won't read the content).

If it helps on the PF list, VoiceOver also announces "pop-up", but not
always menu:
role=link, haspopup: "Menu pop-up link [text name]"
role=button, haspopup: "pop-up button [text name]"

That's a bit odd, as I would have picked button for a menu pop-up, and link
for something that takes you elsewhere (including pop-over content boxes).

I guess there should also be a bug added for NVDA if it changes, as that
announces "menu" in all your cases.

Cheers,

-Alastair

From: Bryan Garaventa
Date: Fri, Dec 13 2013 9:35AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

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 ADDRESS REMOVED = >
To: < = EMAIL ADDRESS 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 ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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
>> >> >> >>
> > >

From: Patrick H. Lauke
Date: Fri, Dec 13 2013 9:47AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

On 13/12/2013 16:35, Bryan Garaventa 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.

What about buttons that trigger a dialog/pop-up? How would you signal
that activating them will have that effect?

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

From: Steve Faulkner
Date: Fri, Dec 13 2013 9:48AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED = >
> To: < = EMAIL ADDRESS 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 ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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
> >> > >> > >> > >>
> > > > > > >
> > > >

From: Bryan Garaventa
Date: Fri, Dec 13 2013 9:53AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

Since screen readers are hardwired to announce 'submenu' and 'menu' for the
triggering elements that contain the attribute, I'd recommend offscreen text
for cross platform support of this type of feedback for the time being.

----- Original Message -----
From: "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Friday, December 13, 2013 8:47 AM
Subject: Re: [WebAIM] Using has-poppup to affect touch UIs


> On 13/12/2013 16:35, Bryan Garaventa 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.
>
> What about buttons that trigger a dialog/pop-up? How would you signal
> that activating them will have that effect?
>
> P
> --
> 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
> > > > >

From: Bryan Garaventa
Date: Fri, Dec 13 2013 9:55AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

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 ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> To: < = EMAIL ADDRESS 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 ADDRESS REMOVED = >
>> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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
>> >> >> >> >> >> >> >>
>> > >> > >> > >>
>> >> >> >>
> > >

From: Steve Faulkner
Date: Fri, Dec 13 2013 9:56AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

>
> Since screen readers are hardwired to announce 'submenu' and 'menu' for the
> triggering elements that contain the attribute,


this is not always the case, as mentioned JAWS announces "has pop up" on
links with a aria-haspopup attribute

--

Regards

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


On 13 December 2013 16:53, Bryan Garaventa < = EMAIL ADDRESS REMOVED = >wrote:

> Since screen readers are hardwired to announce 'submenu' and 'menu' for the
> triggering elements that contain the attribute, I'd recommend offscreen
> text
> for cross platform support of this type of feedback for the time being.
>
> ----- Original Message -----
> From: "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
> To: < = EMAIL ADDRESS REMOVED = >
> Sent: Friday, December 13, 2013 8:47 AM
> Subject: Re: [WebAIM] Using has-poppup to affect touch UIs
>
>
> > On 13/12/2013 16:35, Bryan Garaventa 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.
> >
> > What about buttons that trigger a dialog/pop-up? How would you signal
> > that activating them will have that effect?
> >
> > P
> > --
> > 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
> > > > > > > > > >
>
> > > >

From: Steve Faulkner
Date: Fri, Dec 13 2013 10:02AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

>
> 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 ADDRESS 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 ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
> >> To: < = EMAIL ADDRESS 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 ADDRESS REMOVED = >
> >> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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
> >> >> > >> >> > >> >> > >> >>
> >> > > >> > > >> > > >>
> >> > >> > >> > >>
> > > > > > >
> > > >

From: Patrick H. Lauke
Date: Fri, Dec 13 2013 10:07AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

On 13/12/2013 09:54, Alastair Campbell 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.

Not had a chance to test yet, but I wonder what happens in IE11/Win8.x
on touchscreen when a link/button that activates some form of
popup/dialog on click - yet still has aria-haspopup - rather than on
hover, is pressed...


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

From: Alastair Campbell
Date: Fri, Dec 13 2013 10:28AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

Steve & Bryan: I think the naming of it didn't help, at first glance
"haspopup" does seem to be quite widely applicable. Most people don't
*read* specs any more than other online text, it is more of a skimming &
try things out exercise!

I wouldn't consider a tooltop-style thing a pop-up (although some might),
but lightbox and dialog style things would seem to be.

Patrick: I had a feeling you'd think of something like that, it does seem
like there could be some logic errors there, but I couldn't think what
without testing. I'm lack and windows touch-screen.

Have a good weekend everyone,

-Alastair

From: Bryan Garaventa
Date: Fri, Dec 13 2013 10:46AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

That's true, but try adding role=button and you will se 'menu' :)

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


>
> Since screen readers are hardwired to announce 'submenu' and 'menu' for
> the
> triggering elements that contain the attribute,


this is not always the case, as mentioned JAWS announces "has pop up" on
links with a aria-haspopup attribute

--

Regards

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


On 13 December 2013 16:53, Bryan Garaventa
< = EMAIL ADDRESS REMOVED = >wrote:

> Since screen readers are hardwired to announce 'submenu' and 'menu' for
> the
> triggering elements that contain the attribute, I'd recommend offscreen
> text
> for cross platform support of this type of feedback for the time being.
>
> ----- Original Message -----
> From: "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
> To: < = EMAIL ADDRESS REMOVED = >
> Sent: Friday, December 13, 2013 8:47 AM
> Subject: Re: [WebAIM] Using has-poppup to affect touch UIs
>
>
> > On 13/12/2013 16:35, Bryan Garaventa 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.
> >
> > What about buttons that trigger a dialog/pop-up? How would you signal
> > that activating them will have that effect?
> >
> > P
> > --
> > 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
> > > > > > > > > >
>
> > > >

From: Bryan Garaventa
Date: Fri, Dec 13 2013 10:54AM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

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 ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> >> To: < = EMAIL ADDRESS 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 ADDRESS REMOVED = >
>> >> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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
>> >> >> >> >> >> >> >> >> >> >> >>
>> >> > >> >> > >> >> > >> >>
>> >> >> >> >> >> >> >>
>> > >> > >> > >>
>> >> >> >>
> > >

From: Steve Faulkner
Date: Fri, Dec 13 2013 1:18PM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

>
> 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 ADDRESS 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 ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
> >> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
> >> >> To: < = EMAIL ADDRESS 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 ADDRESS REMOVED = >
> >> >> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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
> >> >> >> > >> >> >> > >> >> >> > >> >> >>
> >> >> > > >> >> > > >> >> > > >> >>
> >> >> > >> >> > >> >> > >> >>
> >> > > >> > > >> > > >>
> >> > >> > >> > >>
> > > > > > >
> > > >

From: Bryan Garaventa
Date: Fri, Dec 13 2013 4:11PM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

"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 ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> >> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> >> >> To: < = EMAIL ADDRESS 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 ADDRESS REMOVED = >
>> >> >> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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
>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
>> >> >> > >> >> >> > >> >> >> > >> >> >>
>> >> >> >> >> >> >> >> >> >> >> >>
>> >> > >> >> > >> >> > >> >>
>> >> >> >> >> >> >> >>
>> > >> > >> > >>
>> >> >> >>
> > >

From: Patrick H. Lauke
Date: Fri, Dec 13 2013 5:52PM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

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

From: Patrick H. Lauke
Date: Fri, Dec 13 2013 5:56PM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

Small correction:

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

Of course I meant something that most likely reacts on click/activation,
but *may* also have associated hover behavior.

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

From: Steve Faulkner
Date: Fri, Dec 13 2013 6:03PM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

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

From: Patrick H. Lauke
Date: Fri, Dec 13 2013 6:31PM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

On 14/12/2013 01:03, Steve Faulkner wrote:
> 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

Sure, I saw that, but you yourself mentioned that under certain
conditions (regular link with aria-haspopup attribute), SRs will
actually announce "has popup" rather than "menu"...so it's not as clear
cut as saying that aria-haspopup will always simply result in the same
state/announcement being voiced, no? There must already be some kind of
differentiator (I should probably fire up aViewer and inspect that
actual values being exposed) and some logic built into the SR to
announce one or the other under certain conditions...

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

From: Steve Faulkner
Date: Fri, Dec 13 2013 7:11PM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | Next message →

sure, its the role/state combo

--

Regards

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


On 14 December 2013 01:31, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:

> On 14/12/2013 01:03, Steve Faulkner wrote:
> > 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
>
> Sure, I saw that, but you yourself mentioned that under certain
> conditions (regular link with aria-haspopup attribute), SRs will
> actually announce "has popup" rather than "menu"...so it's not as clear
> cut as saying that aria-haspopup will always simply result in the same
> state/announcement being voiced, no? There must already be some kind of
> differentiator (I should probably fire up aViewer and inspect that
> actual values being exposed) and some logic built into the SR to
> announce one or the other under certain conditions...
>
> P
> --
> 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
> > > > >

From: Bryan Garaventa
Date: Fri, Dec 13 2013 7:11PM
Subject: Re: Using has-poppup to affect touch UIs
← Previous message | No next message

I understand your point, and if developers only used aria-haspopup on menus,
then this functionality wouldn't actually be a problem.

If you read the MS article closely though, it describes a menu as an
example, but doesn't say anywhere that aria-haspopup should only be used on
menus.

So, it's a pretty safe bet that quite a few enterprising developers out
there are going to see that as meaning it can be used on all hover triggered
elements, because it doesn't explicitly say anywhere that it cannot.

----- Original Message -----
From: "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Friday, December 13, 2013 4:56 PM
Subject: Re: [WebAIM] Using has-poppup to affect touch UIs


> Small correction:
>
>> 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,
>
> Of course I meant something that most likely reacts on click/activation,
> but *may* also have associated hover behavior.
>
> P
> --
> 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
> > > > >