外掛標籤
開發者團隊
原文外掛簡介
A data table that is wider than a phone screen forces the reader to scroll sideways. Success criterion 1.4.10 Reflow of WCAG 2.2 says content must be readable at 320 pixels wide without scrolling on two axes, which is exactly what a wide table does. The same criterion is what the French RGAA 4 checks under its own numbering.
Tablefold adds one option to the table block of the WordPress editor: Stack on small screens. Below the width you pick, the table stops behaving like a table. Each row becomes a card, and each value is preceded by the name of its column, so the reader never has to remember which column they were in.
Accessibility is the point, not a side effect
Turning table elements into blocks is easy. Doing it without destroying the table for screen reader users is the part most snippets get wrong, because display: block silently removes the implicit ARIA role of every table element. This plugin writes those roles back: table, rowgroup, row, columnheader and cell. Without them the relationship between a header and its cells is gone, which fails success criterion 1.3.1 Info and Relationships.
The header row is hidden from sight, never from assistive technology. It is clipped, not set to display: none, so it stays in the accessibility tree. The visible label drawn next to each value comes from CSS generated content, which is not announced reliably by every screen reader, so it is treated as a visual convenience only. The header information is always carried by the roles and the hidden header row as well, never by the pseudo-element alone.
What it does not do
Not every table can be stacked honestly. A table with merged cells, with its headers in the first column, or with no header row at all has no one-to-one mapping between a value and a column name, and inventing one would mislabel the data. When the plugin detects any of those, it changes nothing and leaves the table scrolling horizontally. It then makes that scrolling container reachable with a keyboard and gives it an accessible name, which the block does not do on its own.
How it works
The transformation happens on the server, when the page is rendered. The plugin reads the block markup with the HTML API that ships with WordPress and writes attributes into it. Nothing is stored in the saved content, so your tables stay valid whether the plugin is active or not, and removing the plugin leaves no broken blocks behind.
No JavaScript on the front end. None at all.
No outbound network request, no tracking, no analytics.
No database option is created.
No external font, script or stylesheet is loaded.
The stylesheet loads only on pages where a table was actually transformed.
About compliance
No plugin can make a site compliant with an accessibility standard, and this one does not claim to. Accessibility depends on your content, your theme, and every other plugin you run. Responsibility for meeting any standard stays with the site owner.
What this plugin does is remove one specific and very common failure: a data table that forces the reader to scroll sideways on a narrow screen. Within that scope it is built against WCAG 2.2 level AA:
1.3.1 Info and Relationships, by restoring the ARIA roles that display: block removes
1.3.2 Meaningful Sequence, by never reordering content
1.4.1 Use of Color, by telling labels apart from values with weight, not colour
1.4.3 Contrast, by inheriting the text colour your theme already uses instead of setting its own
1.4.4 Resize Text and 1.4.10 Reflow, by removing the horizontal scroll
2.1.1 Keyboard and 2.4.7 Focus Visible, on the container of tables that keep scrolling
The same criteria are what RGAA 4 checks under its own numbering. Testing with a real screen reader is still on you; the source repository lists the expected result for each table structure.
Development
Development happens in the open at https://github.com/Fyrins/tablefold . The editor script and the stylesheet are built with @wordpress/scripts, the official tooling, and the sources live in src/ in the repository.
