Creating accessible assets: Snippets/HTML code
When adding custom HTML code or snippets to your website, accessibility should be a key consideration. Poorly structured code can create barriers for users relying on assistive technologies. This article explains how to write clean, semantic HTML that supports accessibility. Covering elements like ARIA roles, proper tag usage, and keyboard-friendly design to ensure your custom code works for all visitors.
To make sure your website, landing page, form or message meets the accessibility requirements, use the checklist available here.
Please note that we don’t offer further assistance with HTML. Make sure you’re comfortable with coding or that you have a developer to consult with.
Requirements
Iframes
- The iframe title attribute (on the parent page) must be accurate and descriptive.
- The source page of an iframe (the page embedded in the iframe) must have a valid and meaningful
<title>
.
Landmarks
- Screen readers allow users to navigate by landmarks, so landmarks are an effective way to bypass blocks of content, as required by WCAG 2.4.1.
- Landmarks may be designated with either HTML tags or their equivalent ARIA roles (e.g.
<header>
orrole="banner"
,<nav>
orrole="navigation"
,<main>
orrole="main"
,<footer>
orrole="contentinfo"
, etc.).
Language
- The primary language of the page must be accurately identified using a standard language code on the element, e.g.:
<html lang="en">
,<html lang="fr">
.
- Inline language changes MUST be identified with a valid lang attribute.
Lists
- Lists have to be constructed using the appropriate semantic markup, i.e.:
<ul>
or<ol>
with<li>
child elements,- or
<dl>
with<dt>
and<dd>
child elements.
Tables
- Table headers must be designated with
<th>
. - Data table header text must accurately describe the category of the corresponding data cells.
- Table data cells must be associated with their corresponding header cells.
- Using scope (
<th scope="col">
and<th scope="row">
) is highly recommended, although not always necessary. If all cells in the first row are marked as<th>
without scope, most modern screen readers will infer that the scope is the column below each header cell.
- Using scope (
- Table data group headers (if any) must be associated with their corresponding data cell groups (e.g., via
scope="rowgroup"
or scope="colgroup"
). - Header/data associations that cannot be designated with
<th>
and scope must be designated with the header and id attributes. - Data table headers and data associations must not be referenced across nested, merged, or separate tables.
Exceptions
Inline language changes
Exceptions are allowed for:
- proper names,
- technical terms,
- words of indeterminate language,
- and words or phrases that have become part of the vernacular of the immediately surrounding text.
Examples
![]() | DO: Title added to the iframe will explain the purpose of the content. |
![]() | DO: Correctly marked landmarks that allow users to navigate via ones. |
![]() | DO: The following code fragment illustrates code that is typical for using the /Lang entry to override the default document language by specifying a marked-content sequence within a page’s content stream. |
![]() | DO: Correctly marked list of elements. |
![]() | DON’T: In this example, nested headers are used, but the content cells are incorrectly associated via the id and headers attributes. All cells reference top level header ‘Exams’ (id="e" ) – this isn’t correct for the last three columns which should reference header ‘Projects’. Also, the referencing of the second level column headers has been accidentally swapped even though in this example this makes no difference as the contents (1, 2, Final) are repeated. |