1399580 - When aria-haspopup contains an unrecognized value, it should be exposed as false; not true

Status: NEW

(Core :: Disability Access APIs, defect, P5)

Description

[Joanmarie Diggs]

Steps to reproduce:
1. Load data:text/html,<div role="button" aria-haspopup="foo"></div>
2. Use an accessibility inspector to examine the button

Expected results: The button would not report having a popup (i.e. the same results we'd get with aria-haspopup="false").

Actual results: The button reports having a popup (e.g. in ATK, the object attribute "haspopup:foo" and STATE_HAS_POPUP are both present).

https://rawgit.com/w3c/aria/master/aria/aria.html#aria-haspopup states "User agents MUST treat any value of aria-haspopup that is not included in the list of allowed values, including an empty string, as if the value false had been provided."

The allowed values are: false, true, menu, listbox, tree, grid, dialog.

Comment 1

[alexander :surkov (:asurkov)]

Joanie, is there a thread where we could object the proposed change? This is an author error and its detection goes at performance cost for the browser.

Comment 2

[Marco Zehe (:MarcoZ)]

(In reply to Joanmarie Diggs from comment #0)
> https://rawgit.com/w3c/aria/master/aria/aria.html#aria-haspopup states "User
> agents MUST treat any value of aria-haspopup that is not included in the
> list of allowed values, including an empty string, as if the value false had
> been provided."
> 
> The allowed values are: false, true, menu, listbox, tree, grid, dialog.

I am actually not sure this restriction is very future-proof. What if, in a year or two from now, that list needs to be expanded to something else? It wouldn't be the first time the spec has been overtaken by the need to fix real-world creative cases of web apps. (same goes for aria-current in a way, btw.)

The beauty of the current solution within Firefox (and possibly Chromium as well) is that it is very future-proof, e. g. the ARIA spec can introduce new valid values, and it'll just work, the only thing that needs to be adjusted, maybe, is the supporting AT.

Comment 3

[Joanmarie Diggs]

The change is already in the ARIA 1.1 spec which is already in CR and has been for quite some time. As it states in the status section, https://www.w3.org/TR/wai-aria-1.1/#sotd: " To comment, file an issue in the W3C ARIA GitHub repository. If this is not feasible, send email to [e-mail]. Comments are requested by 16 December 2016."

Comment 4

[Frédéric Wang (:fredw)]

Charlotte is interested in working on this bug.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit BugBot documentation.