"

Additional Accessibility Guides

Web Accessibility

Accessible web content is designed to remove barriers and provide equitable access to information. Users may encounter barriers due to their visual, motor, auditory, or cognitive access means. Web design significantly impacts users’ experience; proper formatting and tool use aids all users to access web content. Properly designed web content is the most accessible and user-friendly format for (almost all types of) information.

On this page:

Where to Start

The Web Content Accessibility Guidelines (WCAG) are the standard for web accessibility. WCAG is organized by the POUR principles. Web content should be Perceivable, Operable, Understandable, and Robust.

Perceivable

Can all users (regardless of access means) perceive what is being presented?

To ensure content is perceivable, ensure the following best practices are met:

Remember, HTML is content and CSS is style. Ensure no information or function is dependent on CSS alone. Use tools (discussed below) to view webpages without styling.

Operable

Can all users navigate the page and operate any interactives using their preferred or required input method (mouse, keyboard, touch, voice, etc.)?

To ensure content is operable, ensure the following best practices are met:

  • The page is logically navigable using only a keyboard
    • Check tabindex and :focus-visible
  • The page has skip link(s) and multiple ways to navigate between pages
  • Pages have meaningful and unique titles in the <title>
  • Pages have semantic structure with regionsheadings, and lists.
  • Media does not autoplay
  • Users are able to pause animations and carousels
  • Link text is meaningful and describes the destination
    • Do not use “click here” or “read more” as link text
    • Learn more about accessible links
  • Buttons accurately describe their action
Understandable

Is the content understandable?

To ensure content is understandable, ensure the following best practices are met:

  • Consistent, predictable navigation
  • Clear link text and link purpose
  • Use links and buttons correctly
    • Buttons do something (e.g. open/close, toggle on/off, etc.) while links go somewhere (e.g. somewhere else on the page or a different page or site)
  • Clear and consistent error messages that receive focus
  • Abbreviations and acronyms are explained
  • <lang> attribute matches the language of the content
    • Individual parts of pages using additional languages can be marked with <span lang="language code">
  • Buttons and form fields are labelled and instructions provided
  • Complex information is presented in more than one format
    • Provide chart data in table format, a glossary, etc. where appropriate
  • Write at a level appropriate to the audience using plain language
    • Check spelling, grammar, usage
Robust

Is your web content robust? Can all devices use it?

To ensure content is robust, ensure the following best practices are met:

  • Content
    • Works across browsers
    • Works on mobile devices
    • Is responsive to screen size and zoom level
  • HTML is reviewed and validated
  • Viewport <meta name="viewport" content="width=device-width, initial-scale=1.0"> supports reflow on user devices

For more information consult: How to Meet WCAG (Quick Reference).

Checklists

Basic Checklist

Consider the interactive Web Accessibility Checklist to assess the accessibility of web content. This tool allows you to check off criteria as you work and expand each criteria for more information and links to further guidance.

Advanced Checklist

The A11y project provides an interactive checklist to check web accessibility.

For contextual information, consider the Province of British Columbia’s guide to creating accessible web products.

Accessibility and Design

Many web accessibility features are invisible and will not interrupt design choices:

  • Alt text is hidden in code, read only to screen readers
    • Figure captions are a common practice that provide image descriptions to all users
  • Descriptive hyperlinks are more useful for all users
    • Users can verify the URL by hovering on the link and viewing the URL in the bottom-left of the browser window
  • Heading tags <H1> <H2> etc. are code to provide structure
    • Modify CSS to change style
  • Tables: <th> <tr> <td> are coded within the table and do not change appearance
    • Tables can be styled using CSS
    • Tables are for data, not to create structure. Use columns, flex-grid, or other layout tools for alignment and spacing
  • Lists: <ul> <ol> <li> <dd> are code to organize lists, but appearance can be modified with CSS
  • Language and viewport attributes are part of your HTML document
    • You can set a different language for part of your page: <span lang=”es”>Hola. Me llamo Pablo</span>. This has no effect on styling
  • Making your page keyboard accessible changes nothing about appearance
  • Form labels are expressed in visible text regardless and made accessible with <label>
  • Closed captions, transcripts, and audio descriptions are a user choice

Tools and Further Reading

If working in WordPress, read WordPress Block Editor for information on creating accessible posts and pages.

Consider Universal Design for the Web for further tips and guidance.

The following tools are useful for checking existing content for accessibility:

WAVE by WebAIM testing tool extension.

  • Flagged errors MAY not necessarily indicate a problem, but rather something that needs to be manually checked
  • The Reference tab provides information on how to amend errors on your page
  • WAVE allows you to toggle CSS off to review the page structure in simpler terms and verify that no information is dependent on styling alone
  • The contrast tab allows you to change page elements colour in a real-time preview
  • The source viewer incorporates the errors and alerts into a code preview to aid in locating issues
  • Consult WebAIM: Web Accessibility Evaluation Guide for more information about how to use WAVE.

Edge and Chrome include Lighthouse (Chrome DevTools) for testing website accessibility. Review understanding Lighthouse error messages for more information.

Use the Firefox Accessibility Inspector to investigate code-based accessibility errors.

Use the MagentaA11y toolbox to understand how to perform manual tests.

definition

License

Icon for the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

Accessibility Handbook for Teaching and Learning Copyright © 2023 by Briana Fraser and Luke McKnight is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License, except where otherwise noted.