Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve "headers attribute specified on a cell refers to cells in the same table element" feedback #513

Open
12 tasks
kengdoj opened this issue Mar 16, 2021 · 0 comments

Comments

@kengdoj
Copy link
Collaborator

kengdoj commented Mar 16, 2021

Survey Results
Rule Id: a25f45

Trevor Bostic

  • 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!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant