w3c / html-aria

ARIA in HTML
https://w3c.github.io/html-aria/
Other
181 stars 48 forks source link

Softening the language around unnecessary explicit role? #236

Closed patrickhlauke closed 4 years ago

patrickhlauke commented 4 years ago

As this comes up every now and again in discussions: currently, the advice given here in the rules https://w3c.github.io/html-aria/#rules-wd

Web developers SHOULD NOT set the ARIA role and aria-* attributes to values that match the implicit ARIA semantics defined in the table.

and later in the conformance requirement note https://w3c.github.io/html-aria/#docconformance

Setting an ARIA role and/or aria-* attribute that matches the implicit ARIA semantics is unnecessary and is NOT RECOMMENDED as these properties are already set by the browser.

SHOULD NOT / NOT RECOMMENDED may be a bit too strong here. per the RFC

SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

But if authors simply explicitly define the same role="..." that is already implicit, there are no actual implications, right? There is no nasty/potential side effect that they need to be aware of...it's just the potential for them to get it wrong (which is a danger for any technology) and the fact that it's more verbose/unnecessary, but ultimately there is no possible harm that can come of it?

The only situation where I could imagine it potentially causing a problem is if you have an element that has different roles depending on the context it's used in (e.g. header that exposes different roles depending on whether or not it's in an article etc), but even here it's more a problem of "authors could get it wrong".

Would it perhaps make sense to drop the RFC "SHOULD NOT" / "NOT RECOMMENDED", and instead soften this into an explanation/note that says, more or less, that authors are encouraged not to explicitly use role="..." to just define the same implicit role the element already has, but that it's mainly because it's unnecessary? And not because it causes actual issues? Unless there are issues that I'm currently unaware of...

patrickhlauke commented 4 years ago

/cc @stevefaulkner @scottaohara as they've heard me moan about this for a while already...

stevefaulkner commented 4 years ago

@patrickhlauke gonna discuss with @scottaohara

patrickhlauke commented 4 years ago

much obliged, mighty @stevefaulkner (tm)

patrickhlauke commented 4 years ago

note that after having a "little" chat with @scottaohara already as well, I went over to a slightly less-soft approach of still retaining NOT RECOMMENDED, which in strict standard terms means the same as SHOULD NOT, but feels (subjectively) a bit clearer. and added some extra explanation in that PR #237