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.

Sign up for GitHub

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

Jump to bottom

Minor clarification for aria-expanded #1912

Open
scottaohara opened this issue Apr 10, 2023 · 3 comments · May be fixed by #1980
Open

Minor clarification for aria-expanded #1912

scottaohara opened this issue Apr 10, 2023 · 3 comments · May be fixed by #1980
Assignees
@adampage
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified
Milestone
2023

Comments

@scottaohara
Copy link
Member

concerning the following text:

If a grouping container that can be expanded or collapsed is not owned by the element that has the aria-expanded attribute, the author SHOULD identify the controlling relationship by referencing the container from the element that has aria-expanded with the aria-controls property.

The use of the 'owned' term seems to imply that a container element could expose an expanded/collapsed state, but this doesn't really jive with most of the roles that allow the aria-expanded state - save for treeitem which already goes over this parent child relationship in the paragraph previous to the quoted. Rather, this paragraph could be interpreted (spoiler, it has) as saying that one could do either:

<button aria-expanded=...>
   button name
   <div>
     content to expand or collapse
   </div>
</button>

or

<button aria-expanded=... aria-owns=f>
   button name
</button>
<div id=f>
   content to expand or collapse
</div>

if not using aria-controls.

It'd be nice if we could revise that paragraph a bit so as to mitigate others thinking the above examples would be acceptable.
@spectranaut spectranaut modified the milestones: ARIA 1.4, ARIA 1.3 Apr 13, 2023
@adampage
Copy link
Member

@scottaohara, do you think it’d be too prescriptive (or just wrong?) to require aria-controls for the subset of supported roles where “ownership” isn’t applicable?

Something like so?:

When aria-expanded is used on an element of any of the following roles,
authors MUST additionally include aria-controls to identify the
specific grouping element which will be expanded or collapsed:

  • button
  • checkbox
  • combobox
  • link
  • listbox
  • menuitem
  • menuitemcheckbox
  • menuitemradio
  • tab
  • switch

@scottaohara
Copy link
Member Author

i do not think it is a must, no. particularly since in many cases there is no overt user benefit to whether aria-controls has been used or not.

@adampage
Copy link
Member

Thanks, @scottaohara. Here’s a second attempt:

If a grouping container that can be expanded or collapsed is not owned by the element that has the aria-expanded attribute, the author SHOULD identify the controlling relationship by referencing the container from the element that has aria-expanded with the aria-controls property.

Authors SHOULD set aria-controls on the same interactive element as aria-expanded, thereby identifying which content container it will expand and collapse. Authors MAY omit aria-controls for specific roles where the controlling relationship is implicit, such as row and treeitem.

It’s still a bit handwavy, but feels less permissive toward the bad examples you identified. I almost re-incorporated the concept of “owning” into the second sentence (to clarify how a controlling relationship could be implicit) but decided that muddied things unnecessarily.

Anyhoo, I’ll get a PR going on this to open it up for wordsmithing.

@adampage adampage linked a pull request Jul 11, 2023 that will close this issue
Open
@pkra pkra added the clarification clarifying or correcting language that is either confusing, misleading or under-specified label Jul 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@adampage adampage

Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified
Projects
None yet
Milestone
2023
Development

Successfully merging a pull request may close this issue.

Editorial: Clarify aria-expanded guidance adampage/aria
4 participants
@pkra @spectranaut @adampage @scottaohara