Build accessible WordPress tables with structural headers, simple relationships, and meaningful visible context.
Use tables only for related data. Never use them merely for page layout.
Test the published table with zoom, keyboard access, and assistive technology.
Start with the data relationship
A data table connects values through rows and columns. Those connections need programmatic structure.
Visual borders cannot express those relationships to every reader. Structural markup can.
The simplest reliable table has one clear header row and consistent columns.
Decide whether a table is necessary
Use a table when readers must compare related values across two dimensions.
Use a list when every item has only one short value.
Use headings and paragraphs when the information follows a meaningful reading sequence.
Keep the first version simple
Simple tables reduce authoring errors. They also reduce interpretation work for readers.
Avoid merged cells, nested tables, split headers, and irregular empty areas.
Split complicated comparisons into several focused tables when the meaning remains clear.
Insert the Core Table block
Insert a Table block and choose only the required rows and columns.
The WordPress Table block guide covers its current editor controls.
Enter real content early. Placeholder values often hide structural and responsive problems.
Enable the header section
Open Table settings and enable the header section for column labels.
WordPress then serialises those cells as table header elements.
Bold body cells are not structural headers. Styling alone changes no relationship.
Write concise column headers
Each header should identify the values beneath it without requiring guesswork.
Prefer “Annual cost” over “Information.” Include units when every value shares them.
Keep labels short enough for narrow screens. Do not sacrifice needed meaning.
Add useful visible context
A caption should identify the table’s topic and relevant scope.
“Plan comparison” says little. “Hosting plans billed annually” gives stronger context.
Place qualifications nearby. Readers should understand dates, sources, and important exclusions.
Understand the Core caption output
The Core block’s visual caption is saved as a figure caption.
It is visible context, but it is not HTML’s native table caption.
Inspect the rendered markup before claiming a formal caption association.
Know what native captions provide
The W3C table caption guidance recommends concise identification through a caption element.
A native caption becomes programmatically associated with its table.
Nearby prose can provide extra context. It should not invent missing structure.
Use correct header cells
The W3C tables tutorial distinguishes header cells from data cells.
Use `<th>` for headers. Use `<td>` for corresponding data values.
Do not convert every emphasised value into a header cell.
Handle row headers deliberately
Some comparisons need labels down the first column. Those labels are row headers.
The Core block does not expose a dedicated row-header control.
Use suitable semantic markup or simplify the table. Bold text remains insufficient.
Use scope for clearer relationships
`scope=”col”` connects a header with its column. `scope=”row”` identifies row relationships.
Simple tables may be understood without explicit scope. Explicit relationships remain easier to inspect.
Core provides no interface for scope attributes. Choose another workflow when necessary.
Escalate complex headers
Multilevel headers can require identifiers and explicit `headers` references.
Irregular tables may require row groups or column groups. Core lacks those controls.
Do not approximate complexity with colours and merged cells. Preserve actual relationships.
Avoid empty mystery cells
An empty cell can mean unavailable, zero, unchanged, or not applicable.
Write the intended state when that distinction matters. Define uncommon abbreviations nearby.
Use a consistent dash only when its meaning is clearly documented.
Keep cell content compact
Long paragraphs make comparisons difficult. Move detailed explanations below the table.
Use consistent grammatical patterns across equivalent cells. Readers scan patterns quickly.
Avoid placing several unrelated facts inside one cell.
Format numbers consistently
Use one decimal convention, currency format, and date format within each table.
Include units in headers when possible. Repeating units can add unnecessary noise.
Explain whether percentages represent changes, shares, or rates.
Write meaningful links
Repeated “Learn more” links become ambiguous when announced outside their cells.
Include the subject within each link name. Keep destination wording predictable.
Opening many new windows can disorient readers. Use ordinary navigation where possible.
Do not rely on colour
Red and green cells cannot carry status alone. Add visible status words.
Icons also need understandable text or accessible names. Shapes need sufficient distinction.
Ensure every status remains clear in monochrome and high-contrast modes.
Check foreground contrast
Header backgrounds, stripes, links, and muted notes create separate colour pairs.
Measure the actual public colours. Editor previews may use different styling. We wrote that up in how to measure WordPress editor performance.
Test hover, visited, focus, and selected states for interactive content.
Use stripes as decoration
Striped rows can support visual tracking. They provide no structural relationship.
Keep sufficient text contrast across both stripe colours. Test linked text separately.
Strong borders may help some readers. Avoid creating a visually overwhelming grid.
Plan responsive behaviour
A wide table cannot simply shrink forever. Text eventually becomes unreadable.
Test small viewports with real values. Include long labels and translated content.
Choose controlled scrolling, simplification, or another presentation before publication.
Make horizontal scrolling discoverable
A responsive wrapper can preserve table structure while allowing horizontal movement.
Ensure keyboard users can reach and operate any custom scroll mechanism.
Do not hide scrollbars solely for visual neatness. Hidden overflow can conceal data.
Preserve headers during responsive changes
Some styles turn rows into cards. That transformation can destroy header relationships.
Generated visual labels do not automatically become accessible names.
Inspect the accessibility tree after every responsive transformation.
Test browser zoom
Zoom can expose clipping, overlap, hidden values, and unusable scroll regions.
Check table edges, sticky columns, popovers, and any sorting controls.
Do not lock table text to tiny fixed sizes.
Understand keyboard expectations
Static cells do not need tab stops. Links and controls inside them do.
Tab through every interactive element. Confirm visible focus and logical order.
Custom grid navigation creates additional obligations. Avoid it without genuine need.
Test with a screen reader
Navigate by table, row, column, and cell using supported commands.
Confirm the expected headers are announced with representative data cells.
Listen for caption context, empty cells, abbreviations, and repeated links.
Inspect the rendered HTML
Open the anonymous public page. Inspect `table`, `thead`, `th`, and `td` elements.
Check caption output, scope attributes, wrappers, and plugin-added roles.
Source inspection cannot replace user testing. It exposes many structural failures quickly.
Audit sorting controls
Sorting needs keyboard-operable controls with clear accessible names.
Communicate current sort direction programmatically. Do not rely on arrow icons.
After sorting, preserve focus and header relationships. Announce meaningful state changes.
Audit filtering and search
Every filter needs a visible label and understandable current value.
Report updated result counts when changes occur without a page reload.
Provide a clear reset action. Retain focus near the initiating control.
Audit pagination
Pagination should identify the current page and provide meaningful link names.
Changing pages should not erase the table’s context or active filters.
Place focus predictably after dynamic updates. Avoid silent content replacement.
Audit sticky rows and columns
Sticky headers can support visual tracking through long data sets.
They can also cover focused links or obscure enlarged content.
Test every viewport edge and zoom level. Verify layering across theme headers.
Use Custom HTML carefully
A Custom HTML block can include native captions and explicit header relationships.
That approach needs reliable HTML knowledge. Later visual edits can be harder.
Document ownership and test after sanitisation, migration, and theme changes.
Evaluate table plugins by output
Feature lists cannot prove accessible markup. Build a representative table first.
Inspect headers, captions, controls, responsive wrappers, and live announcements.
Test with styles and scripts delayed. Confirm useful content remains available.
Test plugin deactivation
Deactivate the plugin on staging. Inspect what content and structure remain.
Shortcodes can expose unusable text. Custom blocks may become recovery prompts.
Keep exports or source data for important tables. Document a migration path.
Protect copy-and-paste structure
Spreadsheet pasting can flatten headers or introduce empty columns.
Review structure after every import. Compare row counts and column meanings.
Do not trust visual alignment as evidence. Inspect the saved output.
Provide source information
State the source, measurement date, and relevant assumptions near the table.
Link to underlying data when readers may need complete details.
Avoid stuffing lengthy methodology into cells. Use nearby explanatory content.
Make updates traceable
Record who maintains the table and how often values change.
Outdated data can mislead readers despite perfect accessibility markup.
Retest structure after every import, redesign, or plugin update.
Separate mobile content only carefully
Duplicating tables and cards can create repeated content for assistive technology.
Hidden duplicates must be removed consistently from reading and focus order.
One robust structure usually reduces maintenance and synchronisation failures.
Retest translated tables
Translations expand labels and can change reading direction. Both affect layout.
Translate captions, abbreviations, status words, and accessible control names.
Confirm numeric and date formats remain clear for the intended audience.
Test production delivery
Caches, optimisation tools, and responsive scripts can alter final markup.
Fetch the public page anonymously. Test the delivered structure and behaviour.
Repeat checks after major WordPress, theme, and plugin releases.
Define reading order outside the table
Introduce the table before readers encounter it. Explain the intended comparison briefly.
Place essential conclusions after the table too. Do not bury them inside cells.
A clear surrounding sequence helps readers choose detailed or summary information.
Avoid images of tables
A screenshot cannot expose real cells, headers, links, or selectable text.
Alternative text rarely replaces a substantial data set. Publish actual structured data.
Offer a downloadable source when useful. Keep the accessible web version available.
Review downloadable alternatives
A spreadsheet can support analysis. It does not excuse an inaccessible page table.
Label the file type and size. Use meaningful worksheet and column names.
Keep download data aligned with visible values. Record its latest update date.
Check text spacing
Custom spacing can increase row height and expose overflow failures.
Allow cell content to wrap naturally. Avoid fixed heights that clip text.
Test header labels after spacing changes. Sticky rows need enough clearance.
Check print output
Printed tables can lose backgrounds, scroll-only columns, and repeated header context.
Preview common paper sizes when readers may print important comparisons.
Keep source details visible. Do not rely on colour-coded statuses alone.
Handle footnotes consistently
Footnote markers need understandable links and distinct visible treatment.
Return links should restore context near the original table cell.
Avoid unexplained symbols. Numbered notes often provide a clearer sequence.
Review editorial permissions
Restrict complex markup changes to contributors who understand the structure.
Provide patterns for common simple tables. Include tested header and caption settings.
Patterns reduce variation but cannot replace content-specific review.
Add a quality checkpoint
Require a frontend table review before publication. Assign a named reviewer.
Check structure, content, contrast, responsive behaviour, and keyboard controls.
Store failures with screenshots and markup evidence. Retest every correction.
Know when tables lose
A table is weak when readers do not need cross-row comparisons.
Complex responsive behaviour can also cost more than the data deserves.
This is the honest weak case. Use simpler content when it communicates better.
Use the accessible table checklist
- Confirm the content needs a table.
- Keep relationships simple.
- Use structural header cells.
- Write concise header labels.
- Provide useful visible context.
- Inspect caption semantics.
- Clarify empty values.
- Use consistent formats.
- Avoid colour-only meaning.
- Measure every colour pair.
- Test narrow screens.
- Test browser zoom.
- Check interactive controls.
- Test header announcements.
- Inspect public HTML.
- Test plugin deactivation.
- Document maintenance ownership.
- Retest production output.
Frequently asked questions
What makes a WordPress table accessible?
Use structural headers, clear relationships, meaningful context, and tested responsive behaviour.
Does bold text create a table header?
No. Use a real table header element to express that relationship.
Does the Core Table caption use an HTML caption element?
No. Core currently saves its visual caption as a figure caption.
Should WordPress tables scroll on mobile?
Scrolling can preserve structure when its region remains discoverable and operable.
When should I avoid the Core Table block?
Use another workflow when complex headers need explicit structural relationships.
The verdict
Core handles simple column-header tables well. Complex relationships need stronger markup. Then compare the $299 lifetime suite when several Pro blocks pass your content audit.
Leave a Reply