Closed jcsteh closed 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?
@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.
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.
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 acaption
, for example. Authors can userole=table
to reinstate the role if necessary.
if so, then I have a PR ready
Works for me.
great. Then PR has been pushed. :)
closed by extended info about NOT RECOMMENDED / examples added in #237
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:
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.
Expand the note above to explain there are some specific cases where making implicit semantics explicit is acceptable. The note currently states:
Interestingly, "is not recommended" already seems weaker than the "Should not be used" in the table. Possible new wording:
Add a footnote in the second column for the table element explaining this use case. Possible wording: