Axe Core Guide
Table cells that use the headers attribute must only refer to cells in the same table
The headers attribute is one of the primary ways to programmatically associate data cells with their corresponding header cells in HTML tables. It works by referencing the id values of th elements. When these references point to elements outside the table — or to id values that don’t exist at all — the association breaks, and assistive technology can no longer convey the relationship between data and headers.
This primarily affects users who are blind or deafblind and rely on screen readers. When navigating a data table, screen readers announce the relevant column and row headers as users move from cell to cell. This “table navigation mode” is essential for understanding the data in context. If the headers attribute references are broken, users may hear no header announcements or incorrect ones, making it impossible to interpret the data.
This rule relates to WCAG 2.0, 2.1, and 2.2 Success Criterion 1.3.1: Info and Relationships (Level A), which requires that information, structure, and relationships conveyed visually are also available programmatically. It also applies to Section 508 requirements that row and column headers be identified for data tables and that markup be used to associate data cells with header cells in tables with two or more logical levels of headers.
How to Fix the Problem
There are three common approaches to associating headers with data cells:
Use the scope attribute (simplest approach)
For straightforward tables, adding scope="col" to column headers and scope="row" to row headers is the easiest and most reliable method. No id or headers attributes are needed.
Use id and headers attributes (for complex tables)
For tables with multiple levels of headers or irregular structures, you can assign an id to each th element and then list the relevant id values in each td‘s headers attribute. The critical rule is: every id referenced in a headers attribute must belong to a th in the same <table> element.
Use scope="colgroup" and scope="rowgroup"
For tables with headers that span multiple columns or rows, the colgroup and rowgroup values of scope can indicate which group of columns or rows a header applies to.
Examples
Incorrect: headers attribute references an id outside the table
In this example, the headers attribute on data cells references id="name", which exists on an element outside the table. This will trigger the rule violation.
<h2 id="name">Name</h2>
<table>
<tr>
<th id="time">Time</th>
</tr>
<tr>
<td headers="name time">Mary - 8:32</td>
</tr>
</table>
Incorrect: headers attribute references a non-existent id
Here, headers="runner" refers to an id that doesn’t exist anywhere in the table.
<table>
<tr>
<th id="name">Name</th>
<th id="time">1 Mile</th>
</tr>
<tr>
<td headers="runner">Mary</td>
<td headers="runner time">8:32</td>
</tr>
</table>
Correct: Using scope for a simple table
For simple tables, scope is the preferred method and avoids the pitfalls of headers entirely.
<table>
<caption>Greensprings Running Club Personal Bests</caption>
<thead>
<tr>
<th scope="col">Name</th>
<th scope="col">1 Mile</th>
<th scope="col">5 km</th>
<th scope="col">10 km</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Mary</th>
<td>8:32</td>
<td>28:04</td>
<td>1:01:16</td>
</tr>
<tr>
<th scope="row">Betsy</th>
<td>7:43</td>
<td>26:47</td>
<td>55:38</td>
</tr>
</tbody>
</table>
Correct: Using id and headers for a complex table
When a table has multiple levels of headers, the headers attribute allows you to explicitly associate each data cell with the correct set of headers. All referenced id values are on th elements within the same table.
<table>
<caption>Items Sold August 2016</caption>
<thead>
<tr>
<td colspan="2"></td>
<th id="clothes" scope="colgroup" colspan="3">Clothes</th>
<th id="accessories" scope="colgroup" colspan="2">Accessories</th>
</tr>
<tr>
<td colspan="2"></td>
<th id="trousers" scope="col">Trousers</th>
<th id="skirts" scope="col">Skirts</th>
<th id="dresses" scope="col">Dresses</th>
<th id="bracelets" scope="col">Bracelets</th>
<th id="rings" scope="col">Rings</th>
</tr>
</thead>
<tbody>
<tr>
<th id="belgium" scope="rowgroup" rowspan="3">Belgium</th>
<th id="antwerp" scope="row">Antwerp</th>
<td headers="belgium antwerp clothes trousers">56</td>
<td headers="belgium antwerp clothes skirts">22</td>
<td headers="belgium antwerp clothes dresses">43</td>
<td headers="belgium antwerp accessories bracelets">72</td>
<td headers="belgium antwerp accessories rings">23</td>
</tr>
<tr>
<th id="gent" scope="row">Gent</th>
<td headers="belgium gent clothes trousers">46</td>
<td headers="belgium gent clothes skirts">18</td>
<td headers="belgium gent clothes dresses">50</td>
<td headers="belgium gent accessories bracelets">61</td>
<td headers="belgium gent accessories rings">15</td>
</tr>
<tr>
<th id="brussels" scope="row">Brussels</th>
<td headers="belgium brussels clothes trousers">51</td>
<td headers="belgium brussels clothes skirts">27</td>
<td headers="belgium brussels clothes dresses">38</td>
<td headers="belgium brussels accessories bracelets">69</td>
<td headers="belgium brussels accessories rings">28</td>
</tr>
</tbody>
</table>
In this complex example, each data cell’s headers attribute lists the id values of every relevant header — the country group, the city, the product category, and the specific product. Every referenced id belongs to a th within the same <table>, so the associations are valid and screen readers can announce the full context for each cell.
Tips for avoiding this issue
-
Double-check
idvalues. A common cause of this violation is a typo in either theidon thethor in theheadersattribute value on thetd. -
Don’t reuse
idvalues across tables. If you copy markup from one table to another, ensureidvalues are unique within the page and thatheadersattributes reference the correct table’sthelements. -
Prefer
scopewhen possible. For simple tables with a single row of column headers and/or a single column of row headers,scopeis simpler and less error-prone thanid/headers. -
Use
idandheadersfor genuinely complex tables — those with multiple header levels, merged cells, or irregular structures wherescopealone cannot convey all relationships.
Learn more:
Last reviewed: February 14, 2026
Related Accessibility Rules
An image map consists of a single image with numerous clickable sections. Because screen readers cannot translate graphics into text, an image map, like all images, must contain alternative text for each of the distinct clickable parts, as well as for the larger image itself.
In the absence of alternative text, screen readers often announce the image’s filename. Filenames do not accurately describe images and are therefore inconvenient for screen reader users.
What this Accessibility Rule Checks
Ensures that image map area elements have alternative text.
For screen reader users, buttons must include recognizable text that specifies the destination, purpose, function, or action.
Users of screen readers are unable to determine the function of elements with the roles role="link", role="button", and role="menuitem" that lack an accessible name.
What this Accessibility Rule Checks
Verifies that each button has a distinguishable, accessible label.
Each page must have a main landmark to allow users to rapidly traverse repetitive blocks of material or interface elements (such as the header and navigation) and get the primary content.
Due to the fact that websites frequently display secondary, repetitive content on several pages (such as navigation links, heading graphics, and advertising frames), keyboard-only users benefit from faster, more direct access to a page’s principal content. This saves keystrokes and reduces physical discomfort.
It is more difficult and time-consuming for users who cannot use a mouse to navigate using the keyboard if the interface does not provide features to facilitate keyboard navigation. To activate a link in the middle of a web page, for instance, a keyboard user may have to browse through a significant number of links and buttons in the page’s header and primary navigation.
Extremely motor-impaired users may require several minutes to browse through all of these pieces, which can cause to tiredness and potential physical pain for some users. Even users with less severe limitations will require more time than users with a mouse, who can click on the desired link in less than a second.
What this Accessibility Rule Checks
Checks for the presence of at least one of the following features:
- an internal skip link
- a header
- a geographical landmark
When used in a document, the frame or iframe element’s title attribute must not be empty in order to provide context for users of screen reader software.
Users of screen readers depend on the title of a frame to describe its contents. If the HTML for a frame or iframe element lacks a title attribute, navigating within the element can be a frustrating and time-consuming experience for users of this technology.
Users of screen readers can see a list of the frames on a page and their respective titles. Providing each frame with a distinct, descriptive label facilitates easy navigation. Without titles, it’s easy to get lost trying to jump from one frame to the next. Screen readers will instead provide information like “frame,” “JavaScript,” the filename, or the URL if no title is provided. This data is unlikely to be useful in most situations.
What this Accessibility Rule Checks
Make sure the title attribute of every iframe and frame element is both distinct and not empty.
To express their purpose and meaning to screen reader users, all images must include alternative text.
Even if the image just contains text, screen readers have no way of translating it into words that are read to the user. As a result, photos must have concise, descriptive alt text so that screen reader users grasp the image’s contents and purpose.
If you can’t see, all visual information, such as photographs, is meaningless unless a digital text equivalent is provided so that screen readers may translate that text into either sound or braille. People with limited eyesight or colorblindness experience the same phenomenon to varied degrees.
Screen readers cannot translate an image into speech or braille to make it available by sound or touch if you do not provide a suitable alternative that works for their available sensory modalities, such as making an image accessible by providing a digital text description.
What this Accessibility Rule Checks
Ensures that all <image> elements have alternative text and either role="presentation" or role="none" (ARIA 1.1).
Ensures that input buttons have legible text.
Without an accessible name, screen reader users cannot determine the purpose of a input type="button".
Without a discernible and accessible name, screen reader users cannot grasp the purpose of an image. A title for a photograph may just convey advisory information about the image. When used as a control, unnamed actionable visual images such as buttons have no clear definition of the destination, purpose, function, or action for the non-text material.
What this Accessibility Rule Checks
The text on input buttons must be readable.
Makes certain that <input type="image"> elements have alternative text.
Screen reader users will not understand the function of a <input type="image"> button unless equivalent wording is provided. Even if the image merely contains text, alternative text is required because a screen reader cannot interpret images of words into output.
Simply typing text adjacent to the form element will not result in a true label. Screen readers, for example, require labels in code that can be determined automatically.
Some screen readers are configured to estimate the label based on the surrounding text, however this method is not foolproof and might cause confusion if the screen reader guesses incorrectly.
What this Accessibility Rule Checks
Ensures that each <input type="image"> has a name that can be found.
Each form element must have a label element attached with it programmatically.
Forms must have effective form labels in order to be accessible. Form elements like as checkboxes, radio buttons, input fields, etc. are frequently self-explanatory to sighted users, even if they are not programmatically labeled. Users with screen readers require descriptive form labels to identify form fields. Adding labels to all form elements removes uncertainty and makes the product more accessible.
When form elements lack labels, screen reader users are unaware of the expected data input. Screen readers cannot determine information about input items programmatically in the absence of an established label association (or redundant text functioning as a label).
Since clicking the label activates the control, people with weak motor control do not benefit from a bigger clickable area for the control.
What this Accessibility Rule Checks
Ensures that each form element has a label associated with it programmatically.
When used as links, link text and alternative text for images must be recognizable by screen readers, have no duplicate labels, and be focusable.
- Accessibility is hindered by inaccessible link components, as they are a crucial component of a website.
- Users who traverse a webpage using only the keyboard (and no mouse) can only click on links that can gain programmed emphasis. Inaccessible to these users is any link that cannot gain programmatic focus.
- Similar to sighted people, screen reader users must know where a link leads. This information is provided via inner link text, albeit it will not be utilized if a screen reader cannot access it.
-
Only the links and form components that can get programmatic focus can be activated by keyboard users, including those with visual impairments or those who cannot use a mouse. Keyboard users cannot access events activated only by other sorts of focus, such as
onmouseoverevents that depend on the mouse hover focus. By default, only links and form elements receive keyboard emphasis. Addtabindex="0"to items that are not links or form components to make them focusable.
What this Accessibility Rule Checks
Ensures that each link’s name is accessible.
Ensures that components with the label role="img" have an alternative text.
Even if an image merely contains text, screen readers are unable to convert it into words that the user can hear. As a result, alternative language for images must be brief, descriptive, and easily understandable so that screen reader users may understand the image’s contents and intended application.
Without an accessible text alternative that screen readers can translate into sound or braille, all visual information, including images, is utterly useless if you can’t see. Accessible alternative text is also necessary to variable degrees for people with low vision or color blindness problems.
If an image does not have a text alternative that is accessible, screen readers cannot translate the information in the image to voice or braille.
What this Accessibility Rule Checks
Elements with the property value role="img" must additionally have markup that specifies accessible alternative text for the image.