Closed jongund closed 2 years ago
Why are we restricting it at all, isn't its purpose to allow semantics to be removed regardless? This seems as absurd as saying oh, you can not use aria-hidden
on <img>
but you can use it on other elements.
@jongund i think you raise a good point. Being before my time here, I can assume as to why this rule was created. Likely due to the pretty straight forward meaning of nav vs the ambiguous nature of aside to developers and how its use in html vs its aria landmark usage can seem contradictory, as I know you are already aware. I.e., aside is more ripe to unwanted semantics than nav, regardless of misuse. That said, there is no reason this couldn’t use another review and update in the next version of the spec, as I tend to agree consistency here is important.
@dylanb there are definitely instances of where declaring role presentation/none would not be appropriate (as would declaring aria-hidden on certain elements, for that matter). For instance using it on a focusable element. And while I’m sure you know, this would then result in UAs having to error correct for author misuse. This of course, while not applicable for this particular issue that Jon raised, is not absurd to have restrictions if considering such situations.
@dylanb there are definitely instances of where declaring role presentation/none would not be appropriate
I think the disconnect here is that @jongund is talking about using ARIA to make bad code better and @scottaohara is looking at this from the perspective of "good coding practices".
It is definitely better not to put role of none
or presentation
on a <nav>
but if this is change is feasible (for example low effort) and it makes the accessibility better while refactoring the app to eliminate the use of the <nav>
is not feasible (for example a very large amount of work), then the spec should not "disallow" that. It is a very valid use, even if it is not ideal.
That’s not entirely accurate @dylanb. I understood the reasoning behind why Jon would file this issue. My comments about why there would be restrictions were per your comment “ Why are we restricting it at all…” as allowing role=none on any element would not always result in bad code becoming better.
Again, I think this is probably a good change to make for this element, and likely a few others that would make for better consistency here.
I suggest that should not be better than should if we are going to change from must not. The spec should encourage best practice wherever practical
That’s not entirely accurate @dylanb. I understood the reasoning behind why Jon would file this issue. My comments about why there would be restrictions were per your comment “ Why are we restricting it at all…” as allowing role=none on any element would not always result in bad code becoming better.
I am sure that there are cases where every element has been used incorrectly and where it would be improved by the addition of a role or none
Untrue for interactive elements.
I think the none
and presentation
role values should be allowed on the main
and nav
elements, this provides a path to "fix" poor markup, especially when nav
element is nested with other nav
elements. This will also make them consistent with the other elements that can create landmarks (e.g. aside
, footer
, form
, header
).
Untrue for interactive elements.
you underestimate the bad code that gets produced
@dylanb I would kindly ask you to not assume what I do and don't know/understand. I am quite aware of how much poor code is written.
My point was that allowing / specifying role=none
to interactive elements would not be helpful. I don't think we should be debating this, as it is spec'd to purposefully be ignored in such situations.
settle down Mr. @scottaohara that last comment was intended to be a lighthearted dig at state of the World Wide Web
I am curious to the reasoning of allowing
none
andpresentation
roles on theaside
element, but not allowing them on thenav
element. There is a lot of abuse of thenav
element and this restriction takes away one technique to remediate those pages. It also appears to me to be a little inconsistent when another similar element,aside
is allowed to have rolenone
orpresentation
.I think
nav
should be allowed the rolesnone
orpresentation
, especially when you have nestednav
elements.