Skip to content

[5c01ea] ARIA state or property is permitted - Passed Example 6-7-8-10-12 improvement #2311

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

Open
shunguoy opened this issue Feb 21, 2025 · 4 comments · May be fixed by #2322
Open

[5c01ea] ARIA state or property is permitted - Passed Example 6-7-8-10-12 improvement #2311

shunguoy opened this issue Feb 21, 2025 · 4 comments · May be fixed by #2322
Assignees

Comments

@shunguoy
Copy link
Collaborator

In ARIA state or property is permitted, Passed Examples 6, 7, 8 and 10
do not fully adhere to the ARIA specifications for required and supported states and properties.

  1. The only required state and property for the combobox role is area-expanded, the aria-controls is no longer required. This applies to the examples 6, 7, and 8. The descriptions and the code for those examples need to be updated.

  2. The role='none' is invalid for a button element per ARIA in HTML. Thus, the description and code for the example need to be updated.
    ACT rules are cool!

  3. remove aria-hidden="true" from example 12 because of the explicit style="display: none;".
    On

@giacomo-petri
Copy link
Collaborator

The only required state and property for the combobox role is area-expanded, the aria-controls is no longer required. This applies to the examples 6, 7, and 8. The descriptions and the code for those examples need to be updated.

I'm fine (agree) with it.

The role='none' is invalid for a button element per ARIA in HTML. Thus, the description and code for the example need to be updated.
ACT rules are cool!

I don't believe we need to make any changes, as the applicability clearly states, "This rule checks that WAI-ARIA states or properties are allowed for the element they are specified on." We're not checking the roles. So, even though you're assigning role="none" to a focusable button, which isn't allowed, it triggers the presentational roles conflict resolution, resulting in a computed role of "button" with an aria-pressed attribute. The example works fine for me as it is.

remove aria-hidden="true" from example 12 because of the explicit style="display: none;".
On

I think we can leave it as is. From a programmatic perspective, authors might want to always remove the content programmatically using aria-hidden="true", considering that aria-checked is used to convey that information. However, through js, the author might also want to visually hide something. I don't see why this should be an issue (while there is some redundancy, I understand why authors may choose to do this, as it requires extra effort on their side to also remove/add the aria-hidden attribute every time).

@HelenBurge
Copy link
Collaborator

Discussed in the CG group and agreed to only fix the first item in the list.

@carlosapaduarte
Copy link
Member

@shunguoy are you taking on this issue? Thanks

@shunguoy
Copy link
Collaborator Author

@carlosapaduarte yes, thanks.

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

Successfully merging a pull request may close this issue.

4 participants