w3c / html-aria

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

Allow role="table" on <table> elements to enforce treatment as a data table #223

Closed jcsteh closed 4 years ago

jcsteh commented 4 years ago

Document conformance requirements for use of ARIA attributes in HTML specifies that the table element has an implicit ARIA role of table and thus that role="table" should not be used on this element. Specifically, the second column is labelled "Implicit ARIA semantics - SHOULD NOT be used" and the table element specifies role=table in this second column. While this generally makes sense, Firefox and Chrome both use heuristics to guess whether an HTML table is a layout table and provide that as a hint to clients, but there are edge cases where they get it wrong, particularly on very small tables. role="table" is a useful way of overriding this to force treatment as a data table, and this trick works in both Firefox and Chrome. As currently specified, this useful trick is a conformance violation. My hope is that we can tweak the spec to allow for this.

This is difficult to do cleanly because of the "SHOULD NOT be used " wording in the label of that second column, which applies to all of the rows. Perhaps we could:

  1. Drop the "SHOULD NOT be used" wording. Alternatively, we could change it to something like "Usually should not be used", but that feels a bit fluffy.

  2. Expand the note above to explain there are some specific cases where making implicit semantics explicit is acceptable. The note currently states:

    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.

    Interestingly, "is not recommended" already seems weaker than the "Should not be used" in the table. Possible new wording:

    In most cases, setting an ARIA role and/or aria-* attribute that matches the implicit ARIA semantics is unnecessary and should not be done, as these properties are already set by the browser. However, there is one case where this may be necessary, as noted in the table below.

  3. Add a footnote in the second column for the table element explaining this use case. Possible wording:

The HTML table element is sometimes used for layout tables. Therefore, browsers use heuristics to guess whether a table is a layout table and provide that as a hint to assistive technology products. In some cases, this guess can be incorrect, particularly on small tables. role="table" can be used to override this guess and force a table to be treated as a data table.

JAWS-test commented 4 years ago

Isn't it true that the heuristic is only used if the table has no th elements for column headings? Either all tables should have th. Or the heuristic is a bug in browsers and screen readers and should be fixed by them?

stevefaulkner commented 4 years ago

@jcsteh wrote:

As currently specified, this useful trick is a conformance violation.

It is not an error it is a warning. That is why it's a should not rather than must not

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.

source: Key words for use in RFCs to Indicate Requirement Levels

We can definitely provide some further explanation/examples though.

jcsteh commented 4 years ago

Isn't it true that the heuristic is only used if the table has no th elements for column headings?

Yes, at least for firefox. (I'm not sure about Chrome or screen reader specicific implementations.)

Either all tables should have th.

There are cases where that doesn't make sense. For example, in code listings where the line number is in one column and the code is in another, there usually aren't headings. Having headings would actually be detrimental for screen reader users, since the column headings don't add value and create excessive verbosity.

It is not an error it is a warning. That is why it's a should not rather than must not

That's fair, and I should have acknowledged that definition in my comment.

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.

I'd argue that even this seems too strong for <table role="table">. If you tell an author they shouldn't do something or that it's not recommended, that's a pretty strong statement: there might be cases where it's okay, but they're super obscure, aren't relevant in the majority of cases and might cause breakage. This case isn't necessarily super rare and has no negative implications beyond potential redundancy. That said, this is probably fair for most other elements in that table; the table element is an exception to the general rule.

We can definitely provide some further explanation/examples though.

On further reflection, I think it's enough to just add a footnote for role=table (point 3 in my comment) and leave the rest of the language alone. Would that be acceptable? The "SHOULD NOT" language at least means this isn't totally contradictory.

scottaohara commented 4 years ago

similar to what we added for list elements, would this be sufficient?

Note: some user agents suppress a table's implicit ARIA semantics if a table does not contain th elements, or is not provided a name by a caption, for example. Authors can use role=table to reinstate the role if necessary.

if so, then I have a PR ready

jcsteh commented 4 years ago

Works for me.

scottaohara commented 4 years ago

great. Then PR has been pushed. :)

scottaohara commented 4 years ago

closed by extended info about NOT RECOMMENDED / examples added in #237