What are common WCAG errors in tables on websites?

Common WCAG errors in tables on websites are primarily caused by missing or incorrectly used header cells, the absence of a table caption, and an unclear structure that screen readers cannot interpret correctly. These errors affect both simple data tables and complex, multi-level structures. The following article answers the most important questions regarding accessible tables, typical WCAG violations and how to check for them.

Which elements make a table accessible?

An accessible table requires at least a caption (<caption>), clearly marked header cells (<th>) with a correct scopeattribute, and a semantically meaningful separation of the table header (<thead>), table body (<tbody>) and, where applicable, table footer (<tfoot>). Only in this way can assistive technologies read out the data in its proper context.

Specifically, the following elements are crucial:

• Caption: The table caption describes the table’s content and is the first thing screen readers read out. Without it, users with visual impairments lack crucial context.
• Header cells with scope: The scope=‘col’ or scope=‘row’ attribute specifies whether a header cell describes a column or a row. If it is missing, a screen reader cannot reliably determine which value belongs to which category.
• Semantic structure: The use of <thead>, <tbody> and <tfoot> organises the table logically and supports navigation using a keyboard and screen reader.
• No layout tables: Tables must be used exclusively for tabular data, not for the visual arrangement of page elements. Layout tables cause significant confusion for assistive technologies.
• Correct cell assignment for merged cells: If cells are merged using colspan or rowspan, the header assignments must be explicitly defined using the idand headersattributes.

These requirements are enshrined in the WCAG success criteria 1.3.1 (Information and Relationships) and 4.1.1 (Syntax Analysis) and apply to all conformance levels from Level A onwards.

Why do screen readers struggle with poorly structured tables?

Screen readers navigate tables by traversing the structure cell by cell and row by row, relying on machine-readable metadata. If header cells or scopeattributes are missing, the screen reader simply reads out raw numerical values or text without establishing the context. Users then hear, for example, ‘42’ without knowing whether it refers to a price, a quantity or a date.

The problem is exacerbated in the following situations:

• Missing header cell markup: If <td> is used for headings instead of <th>, the screen reader does not recognise a header row. Every cell is treated equally, making orientation impossible.
• Nested tables: Tables within tables are difficult for screen readers to process and often lead to navigation errors or incomprehensible output.
• Missing summary for complex tables: Without an explanatory label or a summaryattribute (in accordance with WCAG 2.0), users must explore the entire table before they can understand its purpose.
• Empty header cells: An empty <th> cell at the start of a table, which serves as a visual anchor, should be provided with aria-label=‘’ or invisible text content so that screen readers do not skip it as an empty element.

In short: a screen reader relies on correct HTML semantics. Visual design alone – such as cells in bold as visual headings – is not interpreted by assistive technologies.

What are the most common WCAG violations in data tables?

The most common WCAG violations in data tables are the absence of <th> elements, the omission of the scope attribute, a missing <caption> and the use of tables for layout purposes. These errors occur particularly frequently in practice because they remain invisible to sighted users and therefore go unnoticed during visual testing.

An overview of the most common types of errors:

• Missing or incorrectly placed header cells: Header rows are marked up as <td> instead of <th>, or <th> elements are used without the scope attribute.
• No table caption: The <caption> element is completely missing, meaning the purpose of the table is not conveyed programmatically.
• Incorrect use of colspan and rowspan: Merged cells without explicit headersreferences make the mapping unclear for screen readers.
• Layout tables without ARIA labelling: Tables used solely for visual layout lack the role=‘presentation’attribute, which instructs screen readers to ignore the table structure.
• Missing row summaries in complex structures: In tables with multiple header levels, the idand headerslinks are missing, which enable unambiguous cell mapping.
• Insufficient colour contrast in table cells: WCAG Success Criterion 1.4.3 also applies within tables, stipulating a contrast ratio of at least 4.5:1 for normal text.

Anyone carrying out an accessibility audit for websites will find that table errors are among the most frequently automatically detected issues and, at the same time, among the easiest to rectify.

How do the requirements for simple and complex tables differ?

Simple tables have a single header row and a single header column; here, it is sufficient to use <th scope="col"> and <th scope="row">. Complex tables with multiple levels of headers, merged cells or multidimensional structures additionally require explicit idand headersattributes to uniquely associate each data cell with its corresponding headers.

Requirements for simple tables

A simple table consists of a clearly defined header row and, where applicable, a header column. The requirements are straightforward:

• Mark up header cells with <th>
• Assign scope=‘col’ for column headings and scope=‘row’ for row headings
• <caption> as table labels
• <thead> and use <tbody> for structural organisation

Requirements for complex tables

Complex tables arise when cells have multiple levels of headers, such as in tables with grouped columns or nested categories. Here, scope alone is no longer sufficient:

• Each header cell is assigned a unique id attribute.
• Each data cell refers to all associated header cells via the headersattribute.
• Merged cells (colspan, rowspan) must be used in such a way that the mapping remains logical and machine-readable.
• An explanatory <caption> is particularly important, as the structure is difficult for users without a visual overview to grasp.

The WCAG generally recommend splitting complex tables into several simpler tables where possible, as this significantly improves accessibility whilst also making the code easier to maintain.

How can WCAG errors in tables be detected automatically?

WCAG errors in tables can be detected automatically by using specialised accessibility testing tools to check the HTML source code for missing <th>elements, an absent scopeattribute, missing <caption>elements and layout tables without ARIA labelling. Automated tests typically cover the technically verifiable aspects, whilst content-related issues – such as the appropriateness of a label – require manual assessment.

Automated accessibility scans analyse a page’s DOM and apply rule-based checks. For tables, this specifically involves:

• Checking whether <th>elements are present and correctly positioned
• Checking the scopeattribute for valid values (col, row, colgroup, rowgroup)
• Detecting tables without <caption> or aria-label
• Identifying layout tables that lack role=‘presentation’
• Checking for empty header cells and missing headerslinks in complex structures

It is important to understand that, according to research estimates – including a review by Bielefeld University – automated tests cover around 30 to 50 per cent of all accessibility issues. Whether a table label makes sense in terms of content, or whether the visible order of the cells corresponds to the HTML structure, can only be assessed through manual checking. A good result in an automated scan is therefore a necessary but not sufficient condition for full accessibility.

For a comprehensive website accessibility audit, it is therefore always advisable to use a combination of automated scans and targeted manual tests, such as navigating through tables using only the keyboard.

When is a table considered to be BFSG-compliant?

A table is considered compliant under the Accessibility Enhancement Act (BFSG) if it meets the requirements of WCAG 2.1 at Conformity Level AA. This means: correct semantic markup, a structure that can be programmematically accessed, and sufficient colour contrast.

Passing an automated scan alone does not guarantee legal compliance, as manual checks are also required.

The BFSG, which has applied to many products and services since June 2025, refers to the European standard EN 301 549, which in turn is based on WCAG 2.1 Level AA. For tables on websites, this specifically means that the following WCAG success criteria must be met:

• 1.3.1 Information and Relationships (Level A): Structural information – i.e. which cell belongs to which heading – must be programmably determinable.
• 1.3.2 Meaningful Order (Level A): The reading order of the cells must correspond to the logical flow of the content.
• 1.4.3 Contrast (Minimum) (Level AA): Text in table cells must meet the minimum contrast ratio.
• 4.1.1 Syntax Analysis (Level A): The HTML code must be valid so that screen readers can interpret the structure correctly.

Organisations requiring official confirmation of compliance may commission an audit in accordance with the BITV audit procedure, carried out by members of the BITV Test Consortium. However, it is still advisable to carry out your own automated testing beforehand: major errors should be rectified before a paid audit, and during the implementation of corrective measures, it must be possible to continuously verify whether changes are having the desired effect.

How decareto helps identify WCAG errors in tables

Our decareto platform supports agencies, compliance teams and data protection officers in efficiently identifying and documenting table errors and other accessibility issues. Specifically, we offer:

• Automated accessibility scans: We check websites, including subpages, for WCAG violations, such as missing header cells, an absent scopeattribute and layout tables without ARIA labelling. Scans run in minutes rather than hours.
• Prioritisation by severity: Every issue found is classified by severity (critical, severe, moderate, minor) so that development teams know what needs to be fixed first.
• Specific recommendations for action: For every table error, we provide clear instructions on how to fix it, including the CSS selector and HTML of the problematic element, as well as, where possible, a screenshot of the problem area.
• Manual testing can be integrated: As automated scans cannot detect all accessibility issues, decareto allows manually identified issues to be recorded directly in the report.
• Continuous monitoring: Hundreds of websites can be monitored continuously; automatic notifications are triggered when changes occur, ensuring that new barriers are detected immediately.
• White-label reports: External service providers can pass on reports to clients under their own logo.

Would you like to check your website for WCAG errors in tables and other accessibility issues? Try it for free now and get an initial overview of your website’s accessibility status in just a few minutes.