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

Implicit role=presentation except for Required Owned Elements #1034

Closed
JAWS-test opened this issue Aug 19, 2019 · 2 comments
Closed

Implicit role=presentation except for Required Owned Elements #1034

JAWS-test opened this issue Aug 19, 2019 · 2 comments
Assignees

Comments

@JAWS-test
Copy link
Contributor

I suspect that there are some elements whose child elements are implicitly output without role and status, except for the "Required Owned Elements". which means they have "Children Presentational: true" except for the "Required Owned Elements". An example would be treeitem, which may only contain treeitem or group, but certainly no links, buttons or checkboxes. Unfortunately this is often found in practice (e.g. treeitem with child element checkbox instead of aria-checked), because in my opinion the specification does not regulate this exactly. Maybe I overlooked such a regulation. But if not, this should be added to the specification.

@mcking65
Copy link
Contributor

mcking65 commented Aug 22, 2019

@JAWS-test commented:

I suspect that there are some elements whose child elements are implicitly output without role and status, except for the "Required Owned Elements". which means they have "Children Presentational: true" except for the "Required Owned Elements".

I am not sure what you mean by "output". If you are talking about screen reader output, this is a consequence of the fact that names are flat strings that do not have embedded semantic information.

An example would be treeitem, which may only contain treeitem or group, but certainly no links, buttons or checkboxes.

This is the question being asked by #1033 (Clarify "required owned element").

Unfortunately this is often found in practice (e.g. treeitem with child element checkbox instead of aria-checked), because in my opinion the specification does not regulate this exactly. Maybe I overlooked such a regulation. But if not, this should be added to the specification.

The spec does communicate that non-composite widgets cannot have focusable, interactive descendants. However, there are others asking for additional clarification of this rule. See #1028 (Each ARIA role entry characteristics table should have a "can have focusable descendants" entry).

I am pretty sure this issue duplicates #1033 and #1028. So, I am closing as a duplicate. If I am misinterpreting, please let me know and we can re-open it.

@JAWS-test
Copy link
Contributor Author

JAWS-test commented Aug 22, 2019

@mcking65

The spec does communicate that non-composite widgets cannot have focusable, interactive descendants.

Where can I find it?

I am pretty sure this issue duplicates #1033 and #1028

#1033 and #1028 don't cover the same topic (I had read them before creating my ticket), but they are relatively similar (for example, I'm not only interested in interactive elements, but also in the question of whether elements other than the required ones can be included at all, e.g. a heading). In this respect the closing is ok.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants