Allowed roles for nav element does not include none or presentation roles

[jongund]

I am curious to the reasoning of allowing none and presentation roles on the aside element, but not allowing them on the nav element. There is a lot of abuse of the nav 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 role none or presentation.

I think nav should be allowed the roles none or presentation, especially when you have nested nav elements.

[dylanb]

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.

[scottaohara]

@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]

@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.

[scottaohara]

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.

[stevefaulkner]

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

[dylanb]

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

[scottaohara]

Untrue for interactive elements.

[jongund]

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).

[dylanb]

Untrue for interactive elements.

you underestimate the bad code that gets produced

[scottaohara]

@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.

[dylanb]

settle down Mr. @scottaohara that last comment was intended to be a lighthearted dig at state of the World Wide Web