This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The aria-haspopup attribute has traditionally been used to indicate a submenu. commonly a button/link can open a new window, dialog, datepicker as well as a submenu. a least one AT reports differently if the aria-hapopup is on a link. JAWS announces 'has popup' not 'has submenu'. There is a use case for being able to indicate that an actionable element displays/opens something other than a submenu when activated. suggest a new attribute: aria-poptype which can be used in conjunction with aria-haspopup to provide a hint as to the type of popup. suggest defining a list of type keywords and perhaps allowing a secondary author supplied string word eg. <input type="button" aria-haspopup="true" aria-poptype="[keyword]dialog [author]datepicker"
other info: aria-popType="window | dialog | tooltip | etc" default to 'menu' when aria-poptype not declared?
I like this. It would allow authors like Facebook to indicate the type of expected popup more unambiguously. For example, right now both the account and Privacy items, as well as the Requests, Messages and Notifications items all are announced as sub menus, but the type of popup that appears is totally different in the former two and latter three cases. One of the items should be "panel", since this is, I believe, what it is that appears. Not sure if I could get used to "poptype" as the attribute name, though. Immediately made me think of the song "pop goes the world". ;-)
Where this came up: (from http://lists.w3.org/Archives/Public/wai-xtech/2014May/0032.html) <bgaraventa1979> It appears that aria-haspopup is mapped to role=button in the UIAG, but not to links, should it be mapped to menu there too? <clown> [10]http://rawgit.com/w3c/aria/master/implementation/aria-imple mentation.html#mapping_state-property_table [10] http://rawgit.com/w3c/aria/master/implementation/aria-implementation.html#mapping_state-property_table JS: It's not in the role mapping table ... It's in the states and properties table ... Which roles should I look at in roles? BG: Under button JS: (Reads from spec) ... If button has aria-haspopup true, map to role button menu BG: What should happen when aria-haspopup is applied to links JS: (Reads) <clown> Expose as STATE_SYSTEM_HASPOPUP JS: So if it's on a link, it's telling you it has a popup menu <clown> From the spec: Indicates that the [11]http://rawgit.com/w3c/aria/master/spec/aria.html#dfn-elemen t has a popup context menu or sub-level menu [11] http://rawgit.com/w3c/aria/master/spec/aria.html#dfn-element DB: How do we indicated a popup that's not a menu? JS: At the moment we don't <bgaraventa1979> tjos ca,e i[ ;ast wjere O wasled wjy cam JS: aria-haspopup was supposed to be semantic equivalent to visual triangle <bgaraventa1979> I was asked last week why can't it be applied to modal popups, popup overlays, etc. DB: Should we do things more general? Why assume it's going to be a menu <davidb> Why not get rid of aria-haspopup and have aria-haspoprole="foo" to take the guesswork away. (Since wild web and all) <davidb> or haspopuprole JD: Agrees with suggestion <davidb> e.g aria-popuprole="menu" JS: And the role value would be an aria role ... I'm going to suggest you look for the issue filed by Steve asking why this property is limited to menus. ... It's either 1.1 or 2.0, but I forgoet which. <bgaraventa1979> I'm happy to support extending this to more than menus JS: I do get the impression that it has to be "attached"; it can't be another window. DB: I'm not seeing it 1.1 issues. ... I'll just email Steve
(In reply to David Bolter from comment #3) >... > > <davidb> e.g aria-popuprole="menu" > > JS: And the role value would be an aria role > ... The value of @aria-popuprole is the role that the popup has, and is taken from the current role values as defined by the ARIA spec. However, it's likely these would be further restricted. For example, I don't see aria-popuprole="checkbox" as a good UI, at first blush. Still (thinking out loud): what about aria-popuprole="radiogroup", for a popup consisting of a set of radio buttons?
(In reply to Joseph Scheuhammer from comment #4) > However, it's likely these would be further restricted. For example, I > don't see aria-popuprole="checkbox" as a good UI, at first blush. In general I don't like to be (nor see the need to be) restrictive on the browser implementation side. I certainly agree this would be relevant to any best practices docs.
(In reply to David Bolter from comment #5) > (In reply to Joseph Scheuhammer from comment #4) > > > However, it's likely these would be further restricted. For example, I > > don't see aria-popuprole="checkbox" as a good UI, at first blush. > > In general I don't like to be (nor see the need to be) restrictive on the > browser implementation side. I certainly agree this would be relevant to any > best practices docs. Agreed.
Would there be benefit in having a desc mechanism instead of an explicit role mapping? E.G aria-popupdesc="Login" where the property simply provides a labeling mechanism that ATs can use to prepend to the popup notification. The result being something like "has Login popup". This would provide more flexibility and leave it up to the AT how to convey.
What about just extending aria-haspopup to include these tokens? Any non-false value could be truthy, similar to how we define aria-invalid. Unrecognized tokens like aria-invalid="filetype" evaluates to aria-invalid="true." aria-haspopup="true | false | undefined | menu | dialog | window | ..." FWIW, "datepicker" isn't really a control type. It's a dialog that contains other sub-level controls like buttons.
(In reply to Joseph Scheuhammer from comment #4) > Still (thinking out loud): what about aria-popuprole="radiogroup", for a > popup consisting of a set of radio buttons? I think this is also just a dialog that contains a radio group.
(In reply to Bryan Garaventa from comment #7) > Would there be benefit in having a desc mechanism instead of an explicit > role mapping? > > E.G aria-popupdesc="Login" where the property simply provides a labeling > mechanism that ATs can use to prepend to the popup notification. > > The result being something like "has Login popup". > > This would provide more flexibility and leave it up to the AT how to convey. You're breaking the first rule of localization: Don't rely on string concatenation.
>You're breaking the first rule of localization: Don't rely on string concatenation. Understood, however there is already a precedent for the nandling of descriptive text, such as a specific role + aria-describedby, which is handled in a similar manner.
Though I do see the benefit of using a token for automatic localization.
I wanted to reply in support of modifying the aria-haspopup definition to indicate that the element may open a window, dialog, pop-over, or some other type of dynamic control rather than just a menu. Some screen readers say "pop up button" or "has pop up button menu" or "pop up menu". I don't think that because some screen readers say "menu" that the attribute should be restricted to only menus. A smart screen reader could look for the -haspopup attribute to see if it is inside a menubar container or role=menuitem and then speak the "menu" string, but if it's just on a plain role=button then it could just say "pop up button" like VoiceOver does. I think it's a simple attribute to improve accessibility that can be used in a variety of ways and is an easy sell to developers. I prefer this approach to visually hidden text positioning methods. And while certainly the title attribute can be used, I think aria-haspopup is also a viable solution. Thanks for considering it!
(In reply to James Craig from comment #8) > What about just extending aria-haspopup to include these tokens? Any > non-false value could be truthy, similar to how we define aria-invalid. > Unrecognized tokens like aria-invalid="filetype" evaluates to > aria-invalid="true." > > aria-haspopup="true | false | undefined | menu | dialog | window | ..." > > FWIW, "datepicker" isn't really a control type. It's a dialog that contains > other sub-level controls like buttons. I like this idea! aria-haspopup="dialog" There could be many types possible like pop-over so not sure if they all can be defined. Fall back method sounds great.
Public comment filed: http://lists.w3.org/Archives/Public/public-pfwg-comments/2014JulSep/0000.html