All best practices

Module 2 – Page structure and semantics (best practice)

Module 2 – Page structure and semantics

Landmarks

  • Ensure all content on the page is contained within a landmark.
  • Identify landmarks on the page:
    • Use equivalent HTML5 sectioning elements (preferred)
    • Use ARIA landmark role attributes if HTML5 sectioning elements cannot be used.
  • Ensure only one instance of:
    • role="banner" or <header> (when <header> is a child of <body>). A <header> is not considered a banner when it is the child of <article>, <aside>, <main>, <nav> or <section>.
    • <footer>
    • <main>
  • Ensure these landmarks are direct children of <body>:
    • <header> (when the banner)
    • <footer>
    • <main>
  • Limit the use of <nav> to primary and secondary navigations
    • Use the aria-label attribute to differentiate multiple (different) <nav> items.
    • Use the aria-labelledby attribute to label a <nav> region that begins with a heading element
    • Provide short and descriptive labels
  • The landmark role is declared by a screen reader along with the name, if any. Do not use the landmark role (e.g., “navigation”) as part of the name; for instance, the label is “Site” not “Site Navigation” for a navigation landmark.
  • Use role="search" rather than role="form" when the form is used for search functionality.

Headings

  • Provide headings for each page
  • Use heading elements <h1> - <h6> for all headings
  • Don’t use heading elements for text that is not a heading. Instead, use CSS to change font size or styles
  • Ensure headings are concise and meaningful (they describe the topic or purpose)
  • Ensure headings follow a hierarchical sequence without skipping any levels
  • Provide one <h1> heading that describes the page content

Content structure

  • Ensure an <article> element is used in a web page for self-contained composition
  • For thematic grouping of content, ensure the <section> element is used.
  • Use the paragraph (<p>) element for paragraphs.
  • Use quotes:
    • For longer and more complex quotes, use the <blockquote> element.
    • For shorted quotes, that are usually embedded in another sentence, use the inline quote <q> element.
  • To indicate that content has strong importance or urgency, use the <strong> element.
  • For words that have a stressed emphasis compared to surrounding text, use the <em> element.
  • Expand abbreviations on first use on the page, with the abbreviation accompanying the expansion, one or the other in brackets
  • Ensure each web page defines its topic or purpose in a descriptive title, set in a <title> element in the HTML <head> element. Optionally, identify the larger collection of Web pages after the page description.
  • When phrasing instructions on where to find or how to use content, avoid descriptions that rely exclusively on being able to see or hear. Be sure to include a text label in the instruction and at the item of interest.

Language

  • Add a lang attribute to the <html> element to set the default language for the entire page.
    • For English: <html lang="en">
    • For French: <html lang="fr">
    • For other languages, choose the appropriate language code from ISO-639. Use the shortest available language code.
  • You may add a region subtag if you need to say that this is the language as spoken somewhere in a particular; e.g., lang="fr-CA" indicates French as spoken in Canada.
  • Insert a lang attribute anywhere the default language changes to a different language.
  • XHTML should use both the lang attribute and the xml:lang attribute.

Lists

  • HTML provides three list structures, each with specific semantics:
    • Use unordered lists (<ul>) when the order of the items is irrelevant. Each list item (<li>) in an unordered list is marked with a bullet.
    • Use ordered lists (<ol>) for sequential information. Each list item (<li>) is numbered by the browser.
    • Use description lists (<dl>) to group related terms (<dt>) and their descriptions (<dd>).

iFrames

  • If the iframe consists of decorative images or JavaScript, hide it from screen readers by setting the aria-hidden="true" attribute on the <iframe> element.
  • If the <iframe> contains content intended for the user:
    • Give the <iframe> element a descriptive title attribute value.
    • Ensure the <iframe> title attribute value is unique across iframes on the page.

Parsing and validity

  • Elements have complete start and end tags.
  • Elements are nested according to their specifications.
  • Elements do not contain duplicate attributes.
  • Any IDs are unique.

Module 3 – Links and navigation (best practice)

Module 3 – Links and navigation

Link purpose

  • Provide link text that identifies the purpose of the link without needing additional context.
  • If the link text is not self-descriptive, ensure the link context describes the link purpose.
  • Do not use information-empty link text such as “click here” or “Read More” etc.
  • Distinguish links with identical text but different destinations by either
    • rephrasing the link text,
    • using an ARIA label, or
    • adding visually-hidden text to the link text.

Link activation

  • Custom links need tabindex="0" to receive keyboard focus and an onkeypress event to activate by Enter key.
  • A link's visible name matches or is included in the link's accessible name.

Visual focus indicator

  • Links must have a visible focus state.
  • Avoid styles that the visibility of keyboard focus indicators
  • Use CSS to design a highly-visible focus indicator with strong contrast

Distinguishing links from text

  • Ensure links have visual indicators to enable users to quickly identify them.
  • Colour must not be the only means of differentiating a link from regular text. Accompany colour with another visual cue (e.g., underline, italics, bold) to differentiate link text from regular text

Links that open in a new window

  • In general, avoid opening links in a new window.
  • When links do open in a new window, warn users.

Blocks of navigation

  • Identify important blocks of navigation with the <nav> element or role="navigation" attribute.
  • When there are two or more navigation regions on the page, name each with aria-label or aria-labelledby to differentiate them.
  • Indicate the current location visually, using CSS, and semantically, using the aria-current="page" attribute.

Skip navigation links

  • Place the skip navigation link at the top of the page before any other focusable element (link, button, or custom control).
  • The skip link doesn't not need to be visible until it receives focus.
  • Use clear link text – e.g. “Skip to Main Content” or “Skip to Content”
  • Use a same-page link, targeting the id attribute value of the destination (usually the <main> element).
  • Assign the destination the tabindex="-1" attribute. This fixes shortcomings in some browsers that move the viewport to the destination but not the focus.
  • Do not hide the skip link using any of these CSS options:
    • Use CSS to permanently position the link off screen
    • Set display: none
    • Set visibility: invisible

Multiple ways

  • Ensure the relative order of components on the page and links within navigation blocks remains unchanged across pages.

Table of contents

  • Ensure Table of contents reflects the document's heading hierarchy
  • Ensure every topic in the Table of Contents links to the appropriate location

Focus and focus order

  • Ensure a meaningful tab order by positioning focusable content in the same sequence as the underlying code.
  • Ensure the keyboard navigation order is logical and intuitive. Typically, this means ensuring the navigation follows the visual flow of the page, left to right, top to bottom. It moves through the banner, main navigation, page navigation and controls, then footer on a typical page.
  • Avoid using tabindex values greater than 0.

Character key shortcuts

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

Turn off
A mechanism is available to turn the shortcut off.
Remap
A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt).
Active only on focus
The keyboard shortcut for a user interface component is only active when that component has focus.

Changes of context

Whenever possible, give the user control over changes of context with an explicit user action that's generally understood to cause a change of context; e.g, clicking a link or pressing a submit button.

Changes of context:

  • must never be triggered on focus.
  • must be anticipated by the user if triggered by changing the setting of a control (on input).

Consistency

Consistent navigation
From one page to the next, the relative order of components on the page and of links within navigation blocks should remain unchanged. Components or links may be removed or inserted, but the relative order should stay the same.
Consistent identification
From one page to the next, identical functional components should be consistently named. For instance, a widget named "Search" on one page is named "Search" on the other pages, not sometimes "Find". This includes the alt text of icons and other non-text items with identical functionality.

Module 4 – Tables (best practice)

Module 4 – Tables

Tables concepts

  • Mark up tables semantically to define the relationship between header cells and data cells.
  • For simple tables with one row of column headers and/or one column of row headers,
    • use the <table>, <tr>, <th>, and <td> elements for mark up.
    • use the scope attribute to associate headers with their data cells and any parent headers
  • For complex tables, use id and headers attributes for explicit associations.

Canada.ca Content Style Guide

  • Use tables to organize and present data
  • Value of each cell relates to the column and row headers
  • Entries in a column don't contain information that could be considered a subhead
  • Value of each cell aligns with the column header that appears directly above it
  • Give your table a clear title (using <caption>) that describes the information in it
  • Convert complex tables into one or more simple tables
  • Convert a table to a list if the data is simple

Irregular headers

  • In irregular tables, represent the relationship between row- and column-spanning headers and their data cells with the scope attribute:
    • When a header spans multiple columns, add the scope="colgroup" attribute to the <th> element.
    • When a header spans multiple rows, add the scope="rowgroup" attribute to the <th> element.
  • Define groups in the table with <colgroup> and <tbody> elements:
    • Define column groups with the <colgroup> element, solo columns with <col>, as first children of the table element.
    • Define row groups with the <tbody> element. The solo <thead> and <tfoot> elements define their own groups.

Multi-level headers

  • To associate multi-level headers with data cells:
    • Give each header a unique id attribute value.
    • Reference those id attribute values in the headers attribute of data cells defined by the header.
  • The id/headers technique is not currently (2021) well-supported by screen readers. Simplify the data presentation by breaking a complex table into two or more simpler tables.

Captions and summary

  • Use the <caption> element to provide a name or title for the table
  • If the caption duplicates the preceding heading, visually-hide the <caption> with the WET CSS class .wb-inv.
  • Place the <caption> element as a direct child of the <table> element
  • Provide a summary for complex tables that includes purpose, composition, trends and/or usage
  • Wherever possible, convert complex tables into simple tables or lists, so that less or no explanation is required.
  • Do no duplicate caption information in the summary.
  • Pick a method for presenting table summaries:
    • Nest the summary inside the <caption> element
    • Set the summary in a paragraph preceding or following the table. Reference the summary from the table with the aria-describedby attribute.
    • Use the <figure> element to mark up a table summary. Use aria-labelledby and aria-describedby attributes to associate the caption and summary, respectively, with the table.

Additional tips and tricks

  • Break up a complex table into simpler smaller tables, each containing data for one sub-topic of the original table.
  • Start a new <table> when the topic changes.
  • Separate each piece of data into its own cell.
  • Don’t use line breaks (<br> elements) to create table rows.
  • Align text to the left and numeric data to the right.
  • Differentiate header <th> and data <td> cells visually.
  • Style even and odd rows in a different way to improve readability.
  • Ensure table isn’t cut off (e.g., do not use overflow: hidden in CSS).
  • Avoid using tables for layout. Use CSS for layout instead.

Module 5 – Images (best practice)

Module 5 – Images

Informative images

  • Use the alt attribute on the <img> element
  • Provide meaningful text alternatives that serve the equivalent purpose to convey the intent, purpose and meaning of the image.
  • Do not include words like “image of” or “graphic of” in the alt text.
  • Keep alternative text concise and less than 150 characters.

Decorative or redundant images

  • Use "null" alt attributes (alt="") to hide decorative or redundant images from assistive technology.
  • The role=presentation attribute also hide the image role, though it’s not as widely supported as alt.
  • Implement decorative images as CSS backgrounds if possible.
  • Do not leave out the alt attribute of <img> elements.

Functional images

  • When linking an image and accompanying text, use a null (empty) alt attribute (alt="") on the image if it adds no information to the link text.
  • Always provide alt text for any image serving as a link.
  • If using an icon to indicate that links open in a new window, provide the text alternative "new window".
  • Provide alternative text for stand-alone icon images that have a function.
  • Use text alternative for images that are used in a button

Images of text

  • Avoid using images of text unless it is essential or customizable.
  • Text that is part of a logo or brand name is considered essential.
  • Use actual text styled with CSS to avoid distortion and pixelation when resized.
  • Images of text used as logos are exempt from accessibility requirements like minimum colour contrast and no images of text .
  • Use images of math expressions only when math is the exception to the website content. Provide a text alternative in the alt attribute or in a long description.
  • Use MathML with MathJax to render math expressions semantically.

Animated images

  • Ensure the animation stops after five seconds or provide users with a pause button.
  • Ensure the animation doesn’t flash more than three times per second.

Complex images

A complex image requires both a short and a long description:

  • A short description or title identifies the image and indicates the location of the long description. This is stored in the <img> element’s alt attribute and shouldn’t exceed 150 characters.
  • A long description of the image contains the essential information conveyed by the image. It can consist of nothing but text or it can require structural markup – headings, paragraphs, lists, and/or tables.

Groups of images

  • When a group of images represent a single piece of information: one image holds the message in its alt attribute, the other images use a null alt attributes (alt=""), ensuring they’re ignored by assistive technology .
  • When a group of images represent a collection: nest each image in a <figure> element with a <figcaption> child element, and nest all the figures in a single parent <figure> element. Use its <figcaption> to describe the context.

Image maps

  • Describe the context in the source <img> element’s alt attribute.
  • Describe each clickable region in the <area> element’s alt attribute.

Figure and figcaption

  • Use <figcaption> element to describe contextual information that isn’t apparent from looking at the image. This includes the who, what, when, where, and/or why of an image.
  • Do not use the exact same words for both alt text and <figcaption>. Screen readers will read the information twice.
  • Always provide an alt text for images even if they have a <figcaption>. Providing an empty or null alt attribute will prevent a screen reader from announcing that an image is present.

SVG images

  • Use the <img> element and reference the SVG via the src attribute.
  • Use the <svg> element to embed the SVG directly into the HTML code.
  • Do not embed SVG using <object> or <iframe>
  • For simple, uncomplicated images with basic alt text description
    • Use <img> and src attribute
    • Add role="img" to improve accessibility support
    • Provide text alternative that conveys the same intent and meaning as the image.
    • Use the alt attribute to provide alt text (preferred)
    • Can also use aria-label or aria-labelledby to provide alt text
  • For complex images with extended alt text description
    • Use <svg> element
    • Add role="image" to improve accessibility support
    • Provide text alternative that conveys the same intent and meaning as the image.
    • Use <title> element to provide short alt text
      • <title> must be the first child of its parent element
      • <title> text will appear as tooltip when user moves mouse pointer over it
    • Use <desc> element to provide longer text description if needed, for complex images.
    • Text in a <desc> element is not visible.
    • To improve accessibility support:
      • Add appropriate, unique ID values to the <title> and <desc>
      • Use aria-labelledby to reference the ID values
  • Hide decorative SVG images by using aria-hidden="true"
  • For text in SVG:
    • Avoid text within <svg> elements or keep text to a minimum
    • Add role="img" to improve accessibility support
    • Provide text alternative that conveys the same intent and meaning as the image.
    • Use <title> element to provide short alt text
      • <title> must be the first child of its parent element
      • <title> text will appear as tooltip when user moves mouse pointer over it
    • Use <text> element to provide text in SVG
    • To ensure accessjibility support:
      • Add appropriate, unique ID values to the <title> and <text>
      • Use aria-labelledby to reference the ID values
    • Put text outside the SVG instead of inside (preferred)
  • Include a background colour behind text and other important parts of the image
  • For SVG animation:
    • Use JavaScript or CSS, not <animate>
    • Avoid SVG that flash or blink more than 3 times per second
    • Avoid SVG that auto-play to avoid distracting users
    • Allow users to play and pause SVG animations
    • Use animated SVG to serve a specific purpose, not distract
  • For interactive SVG:
    • Ensure interactive <svg> objects are keyboard accessible
    • Ensure interactive <svg> objects are touchscreen accessible
    • Ensure interactive <svg> objects convey applicable name, role and value
    • Ensure interactive <svg> objects meet all applicable WCAG 2.1 guidelines

CAPTCHA

  • Provide two different modalities of CAPTCHA (e.g., a visual task and an audio task).
  • Provide alt text saying the CAPTCHA requires completing a task and what type of task it is. When an alternate version of a CAPTCHA is available, include instructions in the alt text on how to find it.
  • Optional steps to reach edge cases:
    1. Provide more than two modalities of CAPTCHAs.
    2. Provide access to a human customer service representative who can bypass CAPTCHA.
    3. Don't require CAPTCHAs for authorized users.
  • Use Google's reCAPTCHA v3, if possible.

Additional tips and tricks for images

  • Prioritize information in text alternative. Put the most important information at the beginning.
  • Use punctuation in the text alternative to make information easier to understand.
  • Ensure there is no space character in between the quotes of null (empty) text alternative (alt="").

Module 6 – Forms (best practice)

Module 6 – Forms

Labelling controls

  • Provide labels to describe the purpose of the form control.
  • Use the <label> element to explicitly associate a form control with a label
  • Match exactly the for attribute of the label with the id attribute of the form control
  • Elements that use explicitly associated labels are:
    • <input type="text">
    • <input type="checkbox">
    • <input type="radio">
    • <input type="file"> (file-select fields)
    • <input type="password">
    • <textarea>
    • <select> (drop-down lists)
  • Do not use the <label> element for the following elements.
    • Submit and Reset buttons (<input type="submit"> or <input type="reset">)
      • Label provided by the value attribute
    • Image buttons (<input type="image">)
      • Label provided by the alt attribute
    • Hidden input fields (<input type="hidden">)
    • Buttons (button elements or <input type="button">)
      • Label provided by the element content itself (button) or the value, aria-label, or aria-labelledby attribute
  • Use ARIA labels (aria-labelledby or aria-label attributes) when it is not possible to use <label>
  • When using ARIA labels, include any visible text in the control label.
  • Use the aria-labelledby attribute to retrieve a label from the context or to concatenate a label out of one or more elements in the context.
  • Avoid using the title attribute to identify form controls. It is not widely supported by AT.
  • Keep label text short and concise.
  • Use unique label text on a page.
  • Position labels visually to the right of radio buttons and checkboxes.
  • Position labels visually directly above their form fields (preferred by WET) or to the left, aligned right (WET alternative, when there’s a need to conserve vertical space).

Grouping controls

  • Use the <fieldset> element to group related controls in a form.
  • Use the <legend> element to name the <fieldset> element
  • Make the legend as short as possible as some assistive technology declares the legend together with the label every time.
  • Make the individual labels self-explanatory as some assistive technology does not declare the <legend>. Do not repeat the legend in every label.
  • Use optgroup element for <select> elements with groups of options
  • Use ARIA role="group" and aria-labelledby attributes to group and label related form elements when you can't use native HTML <fieldset> and <legend> elements.
  • Use <label> wherever possible for universal browser and screen reader support.

Form instructions

  • Provide overall instructions that apply to the entire form and provide them before the <form> element. This ensures screen reader users encounter the information before switching to “Forms Mode.”
  • Use aria-labelledby or aria-describedby to provide instructions outside of labels.
  • Identify the type of form input field (e.g., type= "email") so that browsers and assistive technology can provide input helpers, such as custom keyboards, autofill and icon labels.
  • Indicate any required input, data formats, and other relevant information.
  • Ensure placeholder attribute text meets a minimum contrast ratio of 4.5:1.

Validating input

  • Validate user data using validation attributes on HTML5 form elements.
  • Common validation attributes include required, type, pattern, min and max attributes.
  • Validate data on client-side and server-side to ensure security.
  • Identify required form fields both visually in the label and semantically.
  • Use HTML5 input types to validate different types of data, including email, URL, number, telephone, date and range.
  • Validate patterned input using the pattern attribute to specify a regular expression for matching
  • Validate length of entries using minlength, maxlength, min and max attributes
  • Be accommodating as possible of different input formats
  • Enable your users to check and correct their input to reduce errors.
  • Require user confirmation for irreversible actions.
  • Provide undo functionality to ensure submissions are reversible.

User notifications

  • Upon form submission, notify the user of success or of any errors.
  • Ensure error messages are clear and concise and provide simple instructions for resolving the error.
  • Provide feedback in the main heading, in the title element, as a list of errors before the form, as well as in-line, programmatically associated with the form control.
  • Errors listed before the form should:
    • Reference the label of the corresponding form control.
    • Provide a concise, easy to understand description of the error.
    • Indicate how to correct mistakes, and remind users of any format requirements;
    • Include an in-page link to the corresponding form control for easy access.

Multi-step forms

  • Split the form up according to its logical groups of controls (e.g., contact information and questionnaire).
  • Validate the current step before exposing the next.
  • Label optional steps and enable users to skip them.
  • Ensure keyboard focus moves smoothly from step to step, backwards and forwards. At a new step, set the focus preferably on the next relevant form element, or relevant heading or container.
  • Avoid a time limit to fill out the form. If a limit is required, enable the user to adjust or extend it.
  • If the steps are across pages, repeat overall instructions on every page.
  • Indicate progress in the form (“Step x of y”).

Custom controls

  • Whenever possible, use native HTML form elements rather than custom controls.
  • Model the behaviour after native HTML form elements.
  • Add appropriate ARIA name, role, and values if necessary.
  • Communicate updates and state changes via ARIA live messages when they can’t be communicated through HTML or ARIA methods

Module 7 – Visual design and colours (best practice)

Module 7 – Visual design and colours

Colour

  • Ensure that information conveyed by colour differences is also available in text.
  • Include a text cue for coloured form labels.
  • Ensure that additional visual cues are available when text colour differences are used to convey information.
  • Ensure a contrast ratio of 3:1 with surrounding text and provide an additional visual cue on focus for links or controls where colour alone is used to identify them.

Contrast

  • Ensure small text (under 18 point regular font or under 14 point bold font) has a contrast ratio of at least 4.5:1 with the background.
  • Ensure large text (at least 18 point regular font or 14 point bold font) has a contrast ratio of at least 3:1 with the background.
  • Ensure active user interface components (i.e., controls), their states, and meaningful graphics have a contrast ratio of at least 3:1 with adjacent colours.
  • Implement enhanced contrast whenever possible, aiming for the stronger 7:1 contrast for small text and 4.5:1 contrast for large text.

Visual proximity of labels

  • Position labels for form fields immediately before the field, either:
    • above the field (preferred by the WET Style Guide), or
    • to the left of the field, aligned right (preferred by the WET Style Guide when there’s a need to conserve vertical space).
  • Position labels for radio buttons and checkboxes after the field.

Text spacing

Your design should be flexible enough to render without any loss of content or functionality when the user modifies the text spacing, within these constraints:

  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.

To design for text spacing override:

  • Don’t use fixed containers in your CSS styles.
  • Ensure that content reflows without overlapping or clipped text.
  • Use relative units of font size, line height, spaces between characters, words, lines and paragraphs.

CSS-generated text and icons

  • Hide decorative CSS-generated content from screen readers with the aria-hidden="true" attribute.
  • Don't use CSS-generated text.
    • Exception: Use CSS-generated text to expose mark, del, ins, and s elements to screen reader users.
  • For informative CSS-generated icons:
    • Set the icon on a <span> element, and:
      • Hide it from screen reader users with the aria-hidden attribute.
      • Add a visible label for mouse users with the title attribute.
    • Add a label for screen-reader users in a second <span> element, visually-hidden with the WET CSS class .wb-inv.

Hiding content

Content can be hidden from three groups of users:

  • From all users, by using either the CSS display:none or visibility:hidden attribute. When hiding inactive content, such as untriggered modal windows and unselected sub-menus, hide it from all users.
  • From users of assistive technology, by using the aria-hidden="true" attribute to remove the element from the Accessibility API.
  • From sighted users, by using the WET CSS class .wb-inv to visually hide the content.

Exposing hidden content on hover or focus

When exposing hidden content via pointer hover or focus, ensure the exposed content has these three properties:

Dismissable
The user can dismiss the exposed content without moving the mouse or keyboard focus, typically by pressing the Escape key.
Hoverable
The user can hover the mouse over the exposed content.
Persistent
The exposed content doesn’t disappear until mouse hover or keyboard focus leaves it.

Module 8 – Zoom and responsive design (best practice)

Module 8 – Zoom and responsive design

Zoom

Content should appear in a single column with no horizontal scrolling and no loss of information or functionality when adjusting your browser window:

  • to 320 pixels wide by 256 pixels high, or
  • to 1280 pixels wide by 1024 pixels high then zooming the content to 400%.

Implement a responsive design.

When designing content to reflow in a single column:

  • The main content fills the viewport.
  • Horizontal scrolling doesn’t happen.
  • Avoid using multiple columns. The short line length is hard to read.
  • Avoid using CSS floats. They also create short line length, unless the floated element is very small.
  • Avoid using CSS fixed widths and minimum widths. They tend to cause horizontal scrolling.

Responsive design

  • Use CSS “media queries” to determine user's screen size and serve distinct layouts to different screen widths at breakpoints.

  • Set the viewport via the <meta> element in the head:

    HTML

    									<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=2.0; user-scalable=1">
    • width=device-width instructs the page to match the device's width, allowing the page to reflow content to match different screen sizes.
    • initial-scale=1.0 sets the default zoom level of the page.
    • maximum-scale=2.0 sets a maximum of 200% zoom on pinch-to-zoom on mobile.
    • user-scalable=1 enables the user to pinch-to-zoom on mobile.
  • Test breakpoints using viewport emulators.
  • Users with low vision often zoom to trigger mobile layouts on large displays, enabling quite large text.

Responsive forms

As the viewport changes size, ensure:

  • form fields do not overflow, and
  • form fields and labels are not separated by wide areas of whitespace:
    • In the default desktop view, labels are positioned to the left of the control, flush right. (This layout is preferred when there’s a need to conserve vertical space.)
    • In the small screen view, labels are positioned directly above the control, to maximize screen area for each.

Responsive images

images can be made responsive in one of four ways:

  • Technique 1 – Style the image with CSS width: 100%
  • Technique 2 – Style the image with CSS max-width: 100%
  • Technique 3 – Serve different sizes of the image to different screen sizes using the srcset attribute
  • Technique 4 – Serve different images to different screen sizes using the <picture> element.

Responsive text

  • Text containers should resize as the viewport size changes to prevent text from overflowing the viewport.
  • Avoid static, fixed container sizes.

Responsive objects and plugins

  • Objects and plugins can resize as the viewport size changes so they do not overflow the viewport.
  • Set CSS max-width="100%" on the container.
  • Use the <img> element to embed a picture, <iframe> element to embed HTML, and <video> and <audio> elements to embed media content.

Responsive tables

  • Wide tables that overflow the viewport are not responsive. Follow these tips to help prevent overflow:
    • Use percentage instead of fixed pixels to set the width of columns and tables
    • Break large or wide tables into multiple small or narrow tables
    • Display a horizontal scroll bar if the table overflows the screen
    • Make tables more narrow by:
      • Reducing the number of columns
      • Merging columns
      • Using acronyms or abbreviations for long words
      • Inserting soft hyphen markup &shy; to break long words
    • Transform tables at small viewports to prevent horizontal scrolling.

Responsive UI components

Page UI Components reorder and resize to maintain readability.

Responsive video

Videos resize as the viewport size changes so they do not overflow the viewport. Either:

  • set the CSS max-width:100% property on the video’s container element, or
  • set the CSS width: 100% property on the <video> element.

Static sizing can break page layouts.

Orientation

  • Enable users to view your content in the orientation (portrait or landscape) they prefer.
  • Do not restrict the page orientation.

Module 9 - Audio, video, animation and motion (best practice)

Module 9 - Audio, video, animation and motion

Captions

  • Provide captions for pre-recorded and live video with audio
  • Use <track> element to specify timed text tracks for <audio> or <video> elements.
  • Captions are synchronized with the audio.
  • Captions are typed in mixed case letters.
  • Captions use no more than three lines at a time.
  • Put a new sentence on a new line.
  • Maximum number of characters per line is 32 characters.
  • Insert caption line breaks at logical points rather than in the middle of a phrase.
  • Default colors are white text on a black background.
  • Default color contrast ratio between font color and background color is a minimum of 3:1 (font size at least 18 points).
  • Default font size is at least 22pt.
  • Position captions to not obscure on-screen text, people’s faces and other important visual information.
  • Ensure a minimum of 1.5 seconds gap in between captions.
  • Remove captions from long silent intervals. Captions have a maximum duration of 6 seconds.

Transcripts

  • Basic transcripts are a text version of the speech and non-speech audio information.
  • Descriptive transcripts also include text description of the visual information.
  • Provide descriptive transcripts for pre-recorded video with audio
  • Provide descriptive transcripts or audio description for pre-recorded video-only
  • Provide basic transcript for pre-recorded audio-only
  • Provide basic transcript or captions for live audio-only
  • Interactive transcripts enable a user to click a phrase anywhere in the transcript to navigate to that exact point in the video (or audio). Interactive transcripts are built from timed text files specified in the <track> element.
  • Position the transcript or a link to it directly below or adjacent to the media player.
  • If the transcript is on another page, provide a link back to the audio or video file.
  • Provide the transcript in HTML for maximum accessibility to people and to search engines.
  • If working with a captions file, combine several lines into sensible paragraphs.

Transcribing audio to text

  • Transcription best practice is nearly identical for captions and transcripts.
  • When transcribing, the goal is accuracy:
    • Never paraphrase or omit words (and do not censor).
    • Never substitute words.
    • Never rearrange the order of speech.
    • Never correct or edit a speaker’s grammar.
    • Never provide clarifying information in the captions (you may in the transcript).
  • Transcribe all speech and non-speech sounds (laughs, groans, sighs, screams, car backfiring, footsteps approaching, distant roaring)
  • Identify the speakers. Use the full name the first time and single name otherwise. If a speaker is not identified, use Speaker + number (e.g, Speaker 1, Speaker 2) or use a role/title without a number (e.g., interviewer, Doctor)
  • Exclude non-relevant speech and non-relevant background noise.
  • Do not reveal intentionally held information before the appropriate time.
  • Include relevant information about the speech, e.g., (whispering), (mouthing).
  • Put non-speech sounds in parenthesis, italics, lowercase, and with a space before and after, e.g., ( chatter in distance )
  • Use punctuation to convey emphasis.
  • For interrupted speech, use a dash at the end of the line.
  • Use all capital letters only to indicate yelling.
  • When the speech is unintelligible or inaudible, transcribe [inaudible]
  • Indicate large silences as (silence).
  • Include background music if it’s important to understand the content:
    • Identify music with the uppercase label MUSIC (or a verb implying music), followed by a colon and the title in quotation marks followed by the artist.
  • Transcribe important lyrics with musical notes to either side, e.g.,

    ♪ A long, long time ago ♪

  • Describe music that’s not part of the action but sets the mood, e.g.,

    ♪ scary music ♪

  • Best practices unique to transcripts:
    • For descriptive transcripts, include all relevant audio information as well as description of all relevant visual information.
    • If your transcript is generated from timed text files ensure descriptions fit into gaps in the main audio, or use a player that can pause the video during the description.
    • Transcripts include onscreen text in videos. Captions do not include onscreen text.
    • Ensure transcripts identify the source of sounds, rather than just describing them.
    • In some cases, such as legal depositions, the transcript must be verbatim, including ums, ahs, and indicating pauses.
    • Headings, topics and links can make the transcript more usable.
    • Include timestamps only when useful.
    • Add a timestamp to inaudible audio.

Description of visual information

  • Provide audio description for pre-recorded video with audio.
  • Provide audio description or a descriptive transcript for video-only
  • Design new videos with integrated descriptions (script includes all relevant visual information) to avoid the need for audio description
  • Make sure the important visual elements are described appropriately and objectively to understand what the video is communicating.
  • Write description of visual information in present tense, using an active voice and a third-person narrative style.
  • Make sure to include all text, e.g., title text at the beginning, links and email addresses, speaker’s names, and text in a presentation.

Media player accessibility

The ideal media player provides built-in support for captions, audio descriptions, and transcripts.

Keyboard accessibility:

  • All controls can receive focus via the tab key.
  • Controls have a visible keyboard focus indicator.
  • The tab order of controls matches the visual order, left to right.
  • All controls are operable by keyboard.
  • Text, controls, and backgrounds have sufficient contrast between colors.

Screen reader accessibility:

  • Each control presents to screen readers its name and role, and value if one or more is set.

Flashing content

Ensure flashing content:

  • Does not flash more than 3 times per second.
  • Is not larger than 21,824 sq pixels.
  • Does not have high contrast.

Assess flashing content using a tool such as the Photosensitive Epilepsy Analysis Tool (PEAT).

Animation and motion

  • Allow users to turn off motion animations.
  • Avoid using unnecessary animations.

Pause, stop or hide

  • For any moving, blinking and scrolling information that starts automatically, lasts more than five seconds, and is presented in parallel with other content, provide the user a way to pause, stop or hide it.
  • For auto-updating information, provide a way for the user to pause, stop or hide the content. Or, provide a way for the user to control the frequency of the update.
  • A keyboard accessible “pause button” or other mechanisms can be used to pause the content.
  • Avoid unnecessary moving, blinking, scrolling or auto-updating content.

Audio control

If audio plays automatically on page load for more than 3 seconds, enable the user to:

  • pause or stop the audio, or
  • control the volume independ of the system volume.

Alternately, play sounds only on user request.

Module 10 - Input modalities (best practice)

Module 10 - Input modalities

Mouse input

  • Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the addition content is:
    • Dismissible
    • Hoverable
    • Persistent
  • Content that can be triggered via pointer hover should also be able to be triggered by keyboard focus.
  • For functionality that can be operated using a single pointer, at least one of the following is true:
    • No Down-Event
    • Abort or Undo
    • Up Reversal
    • Essential
  • Use the default behaviour of controls (e.g. onclick or mouseup event) and do not override that behaviour with an explicit down-event trigger.

Keyboard input

Focus and focus order

  • Ensure a meaningful tab order by positioning focusable content in the same sequence as the underlying code.
  • Ensure the keyboard navigation order is logical and intuitive. Typically, this means ensuring the navigation follows the visual flow of the page, left to right, top to bottom. It moves through the banner, main navigation, page navigation and controls, then footer on a typical page.
  • Avoid using tabindex values greater than 0.

Visual focus indicator

  • Avoid styles that remove or limit the visibility of keyboard focus indicators
  • Use CSS to design a highly-visible focus indicator with strong contrast
  • Links must have a visible focus state.

Keyboard functionality

  • Ensure all page content can be operated through a keyboard.
  • When possible, use native HTML links and form controls rather than custom elements.
  • Use the onclick event of anchors and buttons.
  • Pair mouse event handlers with keyboard event handlers.

Keyboard trap

  • Make sure the user can get in and out of the interactive elements by using only the keyboard.

Focus management with JavaScript-injected content

  • Whenever a pop up appears on the page as a result of the user interaction or invoking a control, ensure that the user returns to the same place where the interaction first started.

Touch/pointer input

  • All functionality should be accessible via pointer input devices, e.g., via a mouse, a finger on a touch screen, or an electronic stylus.
  • All functionalities can be operated by a single click or tap, double tap, double click, long press, or click & hold.
  • Write JavaScript event handlers that trigger on both keyboard and mouse click. A mouse-accessible interface is generally touch accessible.
  • Ensure the target size is at least 44px by 44px (Level AAA, optional)

Voice input

  • When a control has an accessible name set via an ARIA label as well as a visible label, the visible label text must be part of or match the ARIA label.

Motion actuation

  • If you provide motion actuation (functions triggered by sensor input such as shaking), ensure the functions can also be triggered by conventional user interface components.
  • Ensure users can disable motion actuation.

Module 11 - ARIA live and time limits (best practice)

Module 11 - ARIA live and time limits

ARIA live regions

  • Identify a live region with an aria-live attribute on a container element.
    • The live region must be empty on page load or when it’s first added to the DOM.
    • Use aria-live="polite" for most announcement.
    • Use aria-live="assertive" when the user needs immediate feedback.
  • Use the aria-atomic attribute to specify if the whole live region should be announced, or only the text that changed.
    • Use aria-atomic="false" to announced only the updated text.
    • Use aria-atomic="true" to announce static and updated text.
  • Only use the aria-relevant attribute if the removal of content from a live region needs to be announced.
  • Use the aria-busy="true" attribute to notify assistive technology that it should temporarily ignore changes to an element when things are loading. Once everything is in place, clear the attribute or set it to aria-busy="false".
  • Use a special type of live region role when appropriate:
    • Use role="alert" to announce important and typically time-sensitive information that requires the user’s immediate attention.
    • Use role="status" to announce advisory information to the user that is less urgent than an alert.
    • Use role="timer" to identify a numerical counter listing the time elapsed from a starting point or the time remaining until an end point.
    • Use role="marquee" to define an area as a type of live region with non-essential announcements that change frequently.
    • Use role="log" to keep track of sequential updates, such as a chat log, messaging history, game log or an error log.

Time limits

  • Any design with a time limit must offer the user the ability to either:
    • Turn off the time limit before encountering it.
    • Adjust the time limit before encountering it to a length at least ten times the default setting.
    • Extend the time limit. The user must be warned at least 20 seconds before time expires.
  • With session timeouts, present warning messages in a popup dialog with options for the user to either extend or end the session.
  • For timers with fixed deadlines, provide a countdown feature with ARIA live announcements at strategic intervals.
  • When refreshing/reloading a page, ask the user’s permission. Notify users that newer content is available and provide the options to update or continue.
Back to top