Skip to content
This repository has been archived by the owner on Nov 20, 2024. It is now read-only.

Data table WCAG compliance #90

Open
steveworley opened this issue Mar 23, 2017 · 1 comment
Open

Data table WCAG compliance #90

steveworley opened this issue Mar 23, 2017 · 1 comment

Comments

@steveworley
Copy link
Collaborator

steveworley commented Mar 23, 2017

The tools that check WCAG AA compliance have been updated to better reflect the standards. This has caused an issue with the CKAN tables and they are reporting an error.

1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

Success Criteria 1.3.1 Info and Relationships (A)

Check 245: Data table with more than one row/column of headers does not use id and headers attributes to identify cells.

Repair: Add id and headers attributes to table cells so they identify the cells that relate to the headers.

There is conflicting evidence; http://accessibility.psu.edu/tableshtml/ suggests that as long as the row th have scope=row then most screen readers will be able to interpret and will read correctly.

The AChecker suggests that adding a header attribute to each td cell and an id attribute to each th cell will address this issue. Info on this issue can be found: https://achecker.ca/checker/suggestion.php?id=245.

@Podgkin
Copy link

Podgkin commented Sep 5, 2017

This old chestnut, this has been debated as long as the standard has existed. The accessibility testing I've seen agrees with PSU. As far as I can tell, this was an issue with a couple of screen readers over ten years ago. Pretty much any modern screen reader can infer headers, usually even without the scope=row. It is a trivial thing to do technically and should never have been an issue in the first place. Actually, in some testing I've seen people have their readers set to verbose, and they end up getting frustrated as the reader monotonously reads out the header for each cell.

There seems to be a parallel with browser support here. If we don't support browsers that are five years old, how much effort should we really be expending to support screen readers that are 15 years old? Particularly since adding redundant markup to tables makes the pages slightly larger and can make the experience worse for some screen readers.

Unpopular opinion perhaps, but I've always thought blind adherence to standards is inferior to testing with users the standards are built for.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants