Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aria-haspopup needs to spec default of false "if the attribute is not present" #1209

Open
carmacleod opened this issue Feb 29, 2020 · 1 comment
Assignees
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified
Projects
Milestone

Comments

@carmacleod
Copy link
Contributor

The definition of aria-haspopup needs to clearly state that the default value is false if no value is given.
It currently mentions empty string, but I think it needs to also say something like "if the attribute is not present":

https://w3c.github.io/aria/#aria-haspopup

The aria-haspopup property is an enumerated type. 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. To provide backward compatibility with ARIA 1.0 content, user agents MUST treat an aria-haspopup value of true as equivalent to a value of menu.

For comparison, the definitions of aria-current and aria-invalid (which are also enumerated types) say:

https://w3c.github.io/aria/#aria-current

The aria-current attribute is an enumerated type. Any value not included in the list of allowed values SHOULD be treated by assistive technologies as if the value true had been provided. If the attribute is not present or its value is an empty string or undefined, the default value of false applies and the aria-current state MUST NOT be exposed by user agents or assistive technologies.

https://w3c.github.io/aria/#aria-invalid

For future expansion, the aria-invalid attribute is an enumerated type. Any value not recognized in the list of allowed values MUST be treated by user agents as if the value true had been provided. If the attribute is not present, or its value is false, or its value is an empty string, the default value of false applies.

It might be useful to make these paragraphs more consistent with one another.

Do we need to say "an empty string or undefined" (aria-current says this, but not the other 2).

Do we need to say "MUST NOT be exposed by user agents" (like aria-current)?

The last sentence in aria-invalid doesn't say "user agents MUST"... should it? It just says:

If the attribute is not present, or its value is false, or its value is an empty string, the default value of false applies.

Does it make any sense to use the word null instead of "if the attribute is not present"?
DOM spec says:

To get an attribute by name given a qualifiedName and element element, run these steps:

  • If element is in the HTML namespace and its node document is an HTML document, then set qualifiedName to qualifiedName in ASCII lowercase.
  • Return the first attribute in element’s attribute list whose qualified name is qualifiedName, and null otherwise.
@carmacleod carmacleod added this to the ARIA 1.3 milestone Feb 29, 2020
@spectranaut spectranaut added this to Cynthia Shelly in ARIA 1.3 Jun 7, 2022
@cyns cyns added the clarification clarifying or correcting language that is either confusing, misleading or under-specified label Sep 22, 2022
@scottaohara
Copy link
Member

per the discussion about aria-haspopup from #2030, it seems maybe the differences are fine / not really worth making consistent - especially since each attribute does have varying levels of baggage that could be jostled by making such changes.

cc @jnurthen do you still think we should do this, or maybe close until someone can point out a problem these variants cause?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified
Projects
ARIA 1.3
Cynthia Shelly
Development

No branches or pull requests

3 participants