You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, we have a rule role attribute has valid value it initially mapped to 4.1.2 Name Role Value, but the first TF review pointed out that this can happen on things that are not UI components and thus the mapping is incorrect (w3c/wcag-act#467).
While addressing that concern, I couldn't really found a SC to map it to. Instead, the best I could find was the various ARIA specs and lists of roles: #1439. See notably the discussions with @carlosapaduarte and @WilcoFiers about the mapping issue.
The new TF review both pointed out that these mappings are sub-optimal and that without mapping to the SC the rule is not very good: w3c/wcag-act#492
I'm now a bit at a lost as to what to do with the rule…
Technical
Of course, the problem comes because a role attribute can be set on any element to any value. And the very nature of the rule prevents us from targeting "element with a widget role" or similar, because, well, the role is presumably invalid or the rule has no reason to be here…
The problem is made more difficult because the role attribute is not an ARIA specific role. role can be used for many reasons and has its own specs: https://www.w3.org/TR/role-attribute/#s_role_module_attributes Thus, we cannot simply map to the ARIA definition of role because it does not exist.
ARIA defines a list of roles, but the role attribute is not really restricted to these values. I would still stay that using a different violates ARIA specs, but this is not explicitly mentioned in ARIA specs.
Possibilities
I think the rule can be kept at the very least as a good practice.
It is fairly easy to make a rule mapping to 4.1.2 and targeting elements in sequential focus navigation (tab order); these can be assumed to be UI components, thus the mapping would hold, see #1454.
But this leaves out many other cases and I'm not fully sure what to do with them.
Not sure also what to do very concretely with the latest TF review… Should we just drop that TF submission until we have other rules that map to SCs?
The text was updated successfully, but these errors were encountered:
History
So, we have a rule
role
attribute has valid value it initially mapped to 4.1.2 Name Role Value, but the first TF review pointed out that this can happen on things that are not UI components and thus the mapping is incorrect (w3c/wcag-act#467).While addressing that concern, I couldn't really found a SC to map it to. Instead, the best I could find was the various ARIA specs and lists of roles: #1439. See notably the discussions with @carlosapaduarte and @WilcoFiers about the mapping issue.
The new TF review both pointed out that these mappings are sub-optimal and that without mapping to the SC the rule is not very good: w3c/wcag-act#492
I'm now a bit at a lost as to what to do with the rule…
Technical
Of course, the problem comes because a
role
attribute can be set on any element to any value. And the very nature of the rule prevents us from targeting "element with a widget role" or similar, because, well, the role is presumably invalid or the rule has no reason to be here…The problem is made more difficult because the
role
attribute is not an ARIA specific role.role
can be used for many reasons and has its own specs: https://www.w3.org/TR/role-attribute/#s_role_module_attributes Thus, we cannot simply map to the ARIA definition ofrole
because it does not exist.ARIA defines a list of roles, but the
role
attribute is not really restricted to these values. I would still stay that using a different violates ARIA specs, but this is not explicitly mentioned in ARIA specs.Possibilities
I think the rule can be kept at the very least as a good practice.
It is fairly easy to make a rule mapping to 4.1.2 and targeting elements in sequential focus navigation (tab order); these can be assumed to be UI components, thus the mapping would hold, see #1454.
But this leaves out many other cases and I'm not fully sure what to do with them.
Not sure also what to do very concretely with the latest TF review… Should we just drop that TF submission until we have other rules that map to SCs?
The text was updated successfully, but these errors were encountered: