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-owns on roles with children presentational #2129

Open
JAWS-test opened this issue Feb 23, 2024 · 4 comments
Open

aria-owns on roles with children presentational #2129

JAWS-test opened this issue Feb 23, 2024 · 4 comments
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified editorial a change to an example, note, spelling, grammar, or is related to publishing or the repo

Comments

@JAWS-test
Copy link
Contributor

Describe your concern

#1812:

Authors MUST NOT specify aria-owns on an element which has Presentational Children

This means that aria-owns is no longer a global attribute. However, it is still a global attribute in the ARIA specification: https://w3c.github.io/aria/#aria-owns

In addition, aria-owns is still specified as a permitted attribute for all roles where it is no longer permitted: https://w3c.github.io/aria/#img, https://w3c.github.io/aria/#button and so on

Link to the version of the specification or documentation you were looking at at.

ARIA 1.3

Link to documentation: https://w3c.github.io/aria

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)?
Yes

@JAWS-test
Copy link
Contributor Author

JAWS-test commented Feb 23, 2024

Apart from the fact that I don't understand the new rule at all. In HTML there are elements that cannot have child elements such as img and br. There are also elements that can have child elements (like button), but whose child elements have no role because of Children Presentational.

However, the child elements of a button help to define the name. Instead of <button><span>Name</span></button> I could use: <button aria-owns=button></button><span id=button>Name</span> and there is no good reason to ban it now. This also works correctly in the browsers.

Of course, aria-owns makes no sense on the HTML element input type=checkbox, because the input element cannot have any child elements. But on an element with the ARIA role checkbox, aria-owns would make sense to use, because child elements are also allowed here and result in the name of the checkboxes.

The new rule would only make sense if aria-owns is not intended for child elements in the DOM, but for child elements that appear in the Accessibility API. If this is the case, however, aria-owns should not be used to refer to elements that have role=none. However, this use is not currently ruled out. Furthermore, in my opinion, there is no sensible reason to restrict aria-owns to child elements that appear in the API.

@pkra pkra added editorial a change to an example, note, spelling, grammar, or is related to publishing or the repo clarification clarifying or correcting language that is either confusing, misleading or under-specified labels Feb 23, 2024
@pkra
Copy link
Member

pkra commented Feb 23, 2024

The discussion in #1760 reflects on the fact it's an author error and user agents will continue to try to correct it.

@pkra
Copy link
Member

pkra commented Feb 23, 2024

#2124 seems somewhat related.

@JAWS-test
Copy link
Contributor Author

@pkra If I understand https://docs.google.com/document/d/1jhztcbvUWS4_QGtKmWMxVBLnMkl5ZAAqRCVTcLfdl4o/edit correctly, this was about something completely different: HTML elements that are not allowed to have child elements. For these, aria-owns is wrong, as I already wrote above. But that has nothing to do with children presentational

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 editorial a change to an example, note, spelling, grammar, or is related to publishing or the repo
Projects
None yet
Development

No branches or pull requests

2 participants