Public Records, Private Barriers: Auditing Council Data Tables for Assistive Technology

A council table is rarely just a table. It may set out which bins are collected on which day, when a school term begins, or how a budget has been divided between services. Visually, the grid suggests order. For a screen reader user, however, an ill-formed table can become a sequence of numbers and labels with no reliable relationship between them. The public record is present, but its meaning is not.

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 established a legal framework for public sector websites in the UK. WCAG 2.2 Level AA remains the practical benchmark for many teams in 2026. Yet table accessibility is often treated as a markup question rather than an editorial one. The better starting point is simpler: can a person using assistive technology understand the same relationship between headings and values that a sighted reader takes from the grid?

Begin with a table inventory

An audit should not begin with a random page. Start by inventorying the tables published across the council site. Include service pages, committee papers, school admissions information, waste collection schedules, and budget summaries. Record the URL, the service owner, the update cycle, and whether the table is native HTML or embedded in a PDF or spreadsheet.

Prioritise by consequence. A table of leisure centre opening hours matters. A table explaining eligibility for a discretionary payment matters more. The routine should focus first on tables that people rely on to make decisions, meet deadlines, or understand entitlements. Low-traffic historical tables can follow.

This inventory also exposes layout tables. If a table is being used to position content rather than to express relationships between data, it should be removed from the template. Legacy layout tables may need temporary remediation, but they should not be treated as acceptable practice.

Test the reading order, not the visual grid

Open the page with a screen reader such as NVDA, JAWS or VoiceOver. Navigate into the table and listen to how it is announced. A useful test is to move through cells and ask whether each value arrives with enough context. If the reader announces a figure without the row and column headings that give it meaning, the table has failed in practice even if it passes a superficial code check.

For simple tables, each column and row header should be marked up as a header cell and given an appropriate scope. Visual bold text is not a substitute. For more complex tables, the relationship may need explicit header associations. The audit should check the accessibility tree as well as the source code, because browser and screen reader behaviour can vary.

Captions and surrounding context

A caption or nearby heading should tell the reader what the table contains and why it exists. A caption that says only Table 1 is rarely useful. A better caption identifies the subject, the period, and the unit of measurement where relevant. For a budget table, that may mean naming the financial year and explaining whether figures are in pounds or thousands of pounds. For a bin collection table, it may mean naming the collection round and noting how bank holidays are handled.

The old summary attribute is not a reliable solution in modern HTML. Context is better placed in a visible caption or in the text immediately before the table. That text should be available to all readers, not hidden away in metadata that only some assistive technologies may announce.

Merged cells and multi-level headers

Merged cells are common in school term dates, budget breakdowns and committee papers. They can also be the point at which a table becomes difficult to follow. An audit should check whether each merged header still has a clear relationship with the cells beneath it. Screen readers may announce blank cells, repeat a heading unexpectedly, or lose the connection between a subheading and its data.

Where possible, simplify. Splitting a complex table into two or more straightforward tables can be more accessible than preserving a visual layout that only makes sense on a large screen. If merged cells must remain, test them carefully with a screen reader and ensure that header associations are explicit. Do not assume that colspan and rowspan alone will produce a predictable reading experience.

Responsive tables: stacking can help or harm

On narrow screens, teams often convert tables into stacked cards. This can be a sensible approach when it preserves the label for every value. A card that shows a field name and its value, repeated for each item, can be easier to read on a phone than a horizontally scrolling grid. The key test is whether meaning survives. If the desktop headers are simply hidden and the values are left without labels, the responsive layout has removed the context that made the table intelligible.

Horizontal scrolling can also work, provided the scrollable region is keyboard accessible and there is a visible cue that more content is available. Test at 320 CSS pixels wide and at 400% zoom. Check that the reading order remains logical and that focus is not trapped. A responsive table should not require a mouse to explore.

A short audit checklist

• The table has a meaningful caption or a closely associated heading.
• Column and row headers are marked up correctly and announced by a screen reader.
• Complex tables have explicit header associations or have been simplified.
• Merged cells have been tested for lost or misleading context.
• Layout tables have been removed or scheduled for replacement.
• Responsive card layouts repeat field labels rather than hiding them.
• Scrollable table regions are keyboard accessible and clearly signposted.
• The table remains usable at 200% zoom and at 320 CSS pixels wide.
• The content owner and review date are recorded.

Report findings in a way that leads to repair

An audit is only useful if it changes the template or the publishing guidance. Log findings by page, table type and severity. Distinguish between a one-off content error and a template defect. If the same table pattern appears across waste collection pages, fixing one page is not enough. The pattern needs to be corrected at source, and content editors need a short guide with examples of good captions, headers and responsive behaviour.

Tables on council websites carry public information that people use in daily life. They deserve the same care as forms, navigation and plain-English content. A repeatable audit routine makes that care visible, testable and easier to maintain.