1.3.1 - Information and relationships
Make sure that information and relationships that are conveyed visually (like distinct sections within a page, or a label next to a checkbox) are also identified in code.
Summary
When content structures like tables, lists, sections and headings are communicated visually, they should also be coded in ways that assistive technologies can understand.
Requirements
- Headings are presented using the correct elements or properties in code;
- Form fields have properly associated labels;
- Form fields with format requirements or other additional information have properly associated hints.
- Tabular data is presented using the correct markup;
- Lists of items are presented using the correct markup;
- Sets of radio buttons or checkboxes have a
<fieldset>
element to group them together, and a<legend>
element to provide a label for the group.
Why?
This ensures that the structure of the content that's conveyed visually by the designs is also available to screen reader, screen magnifier and speech recognition tool users.
Here's a fun video illustrating the difference this makes for screen reader users.
Official wording in the Web Content Accessibility Guidelines
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
See the W3C's detailed explanation of this guideline with techniques and examples.
Guidance for Design
This section needs some ❤️
Contribute via Github
More guidance for design
- See section 3 'Structure and semantics' of Deque's Web Accessibility Quick Checklist for Designers
Guidance for Web
This section needs a review and more content. Contribute or report issues via Github (preferred).
Forming a correct headings structure
- Code headings with heading mark-up (
<h1> - <h6>
). - Assign headings the correct heading level:
- the main page heading is coded with
<h1>
- its subheadings are coded with
<h2>
- subheadings of any
<h2>
heading are coded with<h3>
- and so on ...
- the main page heading is coded with
- Text that does not represent a heading should not coded with heading mark-up.
- Use CSS classes rather than
<h1> - <h6>
elements to style text that don't represent headings for sections of the page.
- Use CSS classes rather than
<h1>Main heading for the page</h1>
<h2>Heading for the first top level section of the page</h2>
<h3>Heading for a sub-section, nested under the first top level section</h3>
<h4>Heading for a sub-sub-section, nested under that sub-section</h4>
<h2>Heading for the second top level section of the page</h2>
<h3>Heading for a sub-section, nested under the second top level section</h3>
Example: A heading structure for a weather website
<h1>Local Weather</h1>
<h2>Today's Forecast</h2>
<h2>Tomorrow Forecast</h2>
<h3>Tomorrow's Allergy Forecast</h3>
Failure example
<div class="heading">Local Weather</div>
<div class="subheading">Today's Forecast</div>
<div class="subheading">Tomorrow Forecast</div>
<div class="subheading2">Tomorrow's Allergy Forecast</div>
More guidance on forming a correct headings structure
- Headings tutorial by the W3C Web Accessibility Initiative
- Semantic structure article by WebAIM
Forming a data table
A cell that is a row header should be coded with
<th scope="row">
;A cell that is a column header should be coded with
<th scope="col">
;Use
<th scope="rowgroup">
and<th scope="colgroup">
if the same header applies to multiple rows or columns, but you should avoid complex tables like that as they are hard to understand for screen reader users;Cells containing data are coded with
<td>
.Avoid making complex data tables (for example tables containing several rows and/or columns of headers, irregular and multi-level headers).
- If you can't avoid making a complex data table, each data cell should be associated with all its headers via the
scope
,id
andheaders
attributes.
- If you can't avoid making a complex data table, each data cell should be associated with all its headers via the
A title should be provided for all data tables via the
<caption>
element (oraria-labelledby
with theid
of ah1-h6
element directly introducing the table).
Example of a basic table structure
<table>
<caption>
Short descriptive name for the table
</caption>
<thead>
<tr>
<th scope="col">Column Heading 1</th>
<th scope="col">Column Heading 2</th>
<th scope="col">Column Heading 3</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Row Heading 1</th>
<td>Cell value for row 2, column 2</td>
<td>Cell value for row 2, column 3</td>
</tr>
<tr>
<th scope="row">Row Heading 2</th>
<td>Cell value for row 3, column 2</td>
<td>Cell value for row 3, column 3</td>
</tr>
</tbody>
</table>
Do not use HTML tables for layout out content
- The use of layout tables (meaning HTML
table
s solely used to position items on the screen) should be avoided. Use CSS to position the content instead. - When layout tables cannot be avoided, their source code should contain the ARIA
role="presentation"
attribute, and should not include the<th>
and<caption>
elements, and theheaders
,axis
,scope
andsummary
attributes.
More guidance on forming a data table
- Tables tutorial by the W3C Web Accessibility Initiative
- Creating Accessible Tables article by WebAIM
- Intentionally Hiding Semantics with the presentation Role in the ARIA Authoring Practices Guide
Forming lists
Lists should be coded with the most appropriate HTML list element:
<ul>
for unordered lists;<ol>
for ordered lists;<dl>
for description lists.
List mark-up should be used to accurately describe the structure of lists.
- For example, do not split items of a same list into two separate
<ul>
elements.
- For example, do not split items of a same list into two separate
Content that does not represent a list should not be coded with list mark-up.
Example of an ordered list
<ol>
<li>List value 1</li>
<li>List value 2</li>
</ol>
Example of a description list
<dl>
<dt>Title 1</dt>
<dd>List value 1</dd>
<dd>List value 2</dd>
<dt>Title 2</dt>
<dd>List value 1</dd>
</dl>
More guidance on forming lists
- 'Lists' section of the Content Structure tutorial by the W3C Web Accessibility Initiative
Associating form controls with labels, and associating related form controls
- Form fields that have a visible label should be associated with their label in the HTML code (via the
id
andfor
attributes).
<label for="first-name">First Name</label> <input name="first-name" />
- Radio buttons and checkboxes are associated with their label via the
id
andfor
attributes, are grouped together with<fieldset>
and the question preceding each group is coded with<legend>
.
Common mistakes
- Using the
placeholder
attribute to provide an 'Accessible Name' for a textinput
field. (Theplaceholder
attribute is not well supported by some browsers and assistive technologies combinations, and shouldn't be used for labelling text fields).
More guidance on associating form controls with labels, and associating related form controls
- Creating Accessible Forms by WebAIM
- Labelling Controls tutorial by the W3C Web Accessibility Initiative
- Grouping Controls tutorial by the W3C Web Accessibility Initiative
Use HTML5 sectioning elements to describe document structure and outline different parts of the page
- Identify the purpose of each section of content on a page using HTML5 sectioning elements. These create 'Landmark regions' that help screen reader users navigate within a page.
Element | What it means | Implicit landmark role |
---|---|---|
<header> | A section of content that is repeated at the top of all/several pages | role="banner" if it is a direct child of <body> |
<nav> | An area containing navigation links | role="navigation" |
<search> | A component that allows users to search content on the site | role="search" |
<main> | The main content of the page (meaning not header, navigation or footer elements or complementary content) | role="main" |
<form> | A form | role="form" if it has an Accessible Name |
<section> | A section of content that you want added in the list of Landmark regions | role="region" if it has an Accessible Name |
<aside> | Content that complements the content in the main area, but would also make sense on its own | role="complementary" |
<footer> | Information about the page (such as copyright) | role="contentinfo" if it is a direct child of <body> |
Make sure that every text node on the page is a descendant of a HTML sectioning element.
- Otherwise screen reader users who navigate pages by landmarks would never find it.
If a same HMTL sectioning element and/or equivalent ARIA landmark
role
is used multiple times on a page, make sure that each instance has a unique Accessible Name.
Example
<header>
<div id="logo">...</div>
<nav aria-label="BBC">
<ul>
<li><a href="...">News</a></li>
<li><a href="...">Weather</a></li>
<li><a href="...">Sport</a></li>
<li><a href="...">Travel</a></li>
...
</ul>
</nav>
<nav aria-label="News">
<ul>
<li><a href="...">Home</a></li>
<li><a href="...">UK</a></li>
<li><a href="...">World</a></li>
<li><a href="...">Business</a></li>
...
</ul>
</nav>
</header>
<main>
<h1>Pisa rankings: Why Estonian pupils shine in global tests</h1>
...
</main>
<aside>...</aside>
<footer>
<p>BBC 2016</p>
<ul>
...
</ul>
</footer>
Failure example
<!-- Do not do this -->
<div id="header">
<div id="logo">...</div>
<div id="nav" aria-label="BBC">
<ul>
<li><a href="...">News</a></li>
<li><a href="...">Weather</a></li>
<li><a href="...">Sport</a></li>
<li><a href="...">Travel</a></li>
...
</ul>
</div>
<div id="nav2" aria-label="News">
<ul>
<li><a href="...">Home</a></li>
<li><a href="...">UK</a></li>
<li><a href="...">World</a></li>
<li><a href="...">Business</a></li>
...
</ul>
</div>
</div>
<div id="content">
<h1>Pisa rankings: Why Estonian pupils shine in global tests</h1>
...
</div>
<div id="related_content">...</div>
<div id="footer">
<p>BBC 2016</p>
<ul>
...
</ul>
</div>
More guidance on identifying the page's landmark areas
- HTML Sectioning Elements article by the W3C Web Accessibility Initiative
- Page Regions tutorial by the W3C Web Accessibility Initiative
- Labelling regions tutorial by the W3C Web Accessibility Initiative