You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The note in expectation 1 seems to conflict with the description of the rule. The rule reads that the "headers attribute on a cell refers to other cells in the same table", while the note reads "headers attribute referencing elements that are non-existent or not in the table are ignored." To me this only adds confusion. Whether or not the element is ignored, if the condition stated in expectation 1 is broken the rule fails. The same goes for the note under expectation 2.
Is the note possibly an accessibility support point or assumption in disguise? For example, a header reference may not exist, but if other information is present to create the relation the user may not notice.(This may already be taken care of by the current assumptions).
From inapplicable example 4, will there be a rule on non-semantic tables?
I think the notes in the expectation should be removed.
Wilco Fiers
Would like a second opinion about this. Often if proper markup is used in a table, the headers attribute is unnecessary, even if someone does the headers attribute wrong, basic th / td markup will ensure the table is still accessible. It seems like this could cause false positives. On the other hand, I've never seen this cause problems, and we've had a rule like this for years now.
Failed example 1 and 2 are examples where the assumption applies. because proper th / td markup is used, the fallback should kick in and these tables should not cause problems.
I think the notes in the expectation should be taken out. We could instead add a few sentences to the background section explaining that unless the headers attribute references another cell in the same table, the reference will be ignored by assistive technologies.
Needs the above changes. It's fairly minor so I don't mind if this rule goes directly to CFC after this is done.
Levon Spradlin
I agree with Wilco that if the fallback on native HTML cell and header code overrides the incorrect ID, I believe this should pass.
Kathy Eng
This rule seems to be the algorithm for assigning header cells (https://html.spec.whatwg.org/multipage/tables.html#algorithm-for-assigning-header-cells). Do we need an ACT Rule for an algorithm?
A Rule that evaluates the assigned header cells would be good. Perhaps "Table cell is assigned one or more header cells", with the same assumptions from this rule (required to express the relationship between data and table header cells)
Not sure this rule is necessary.
Detlev Fischer
I would have appreciated a failed example with two separate tables (e.g. to ensure a non.scrolling header) where the headers attribute in the escond table points to th cells in the first table.
Consider adding a two tables case under "Failed" (not sure whether this still a common case though, so this is not a blocker!
The text was updated successfully, but these errors were encountered:
Survey Results
Rule Id: a25f45
Trevor Bostic
Is the note possibly an accessibility support point or assumption in disguise? For example, a header reference may not exist, but if other information is present to create the relation the user may not notice.(This may already be taken care of by the current assumptions).
Wilco Fiers
Levon Spradlin
Kathy Eng
A Rule that evaluates the assigned header cells would be good. Perhaps "Table cell is assigned one or more header cells", with the same assumptions from this rule (required to express the relationship between data and table header cells)
Detlev Fischer
The text was updated successfully, but these errors were encountered: