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
You can’t control something that isn’t visible. aria-controls should only be added to role=tab s that have aria-selected=true .
Completely disagree! You are controlling the visibility!
This is not a bug. We should not change the examples of tabs because the example conforms with the spec. There are very good reasons for leaving the spec as is. See my comments in issue w3c/aria#531.
This idea does not scale. Imagine applying this rule at scale and across other relationships, e.g., aria-owns, using the same rationale. This would create perf problems and all kinds of ridiculousness.
As I described in issue 531, there are other ways of addressing the concerns raised by @LJWatson.
I am removing the bug label and marking this issue invalid. If consensus forms in support of such an authoring requirement in ARIA issue 531, we'll reflag it as a bug and put in a milestone that coincides with the ARIA change.
We need to keep the authoring practices consistent with the task force consensus understanding of the ARIA specification. We should only make exceptions if there is consensus in the ARIA working group that the specification itself has a defect.
mcking65
added
invalid
Closed primarily due to error or inaccuracy of some kind
and removed
bug
Code defects; not for inaccurate prose
labels
Feb 17, 2017
I am removing the bug label and marking this issue invalid. If consensus forms in support of such an authoring requirement in ARIA issue 531, we'll reflag it as a bug and put in a milestone that coincides with the ARIA change.
You can’t control something that isn’t visible.
aria-controls
should only be added torole=tab
s that havearia-selected=true
.Related conversation on Twitter
Related issue against the ARIA spec
The text was updated successfully, but these errors were encountered: