Training Team Accessibility Checklist

Topics

This is a tool that can be used by anybody in the training team for creating or reviewing content so that it can be easily consumed by everybody. It is important to note that this checklist is a resource only and should be used as a starting point for those looking to make content more accessible.

Some types of content where you might want to consider using this checklist include:

  • Writing meeting recap notes
  • Publishing posts on the make.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//training blog
  • Updating the Training Team Handbook
  • Creating learning content such as tutorials, courses, lesson plans or online workshop slides

This checklist is based on the four main guiding principles upon which the Web Content AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Guidelines (WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/.) are built. While the WCAG guidelines can be overwhelming, a good next resource if you would like to learn more is the How to Meet WCAG (Quick Reference). If you have more questions about accessibility or best-practices, the WordPress project has a dedicated Accessibility Team that can be contacted via the #accessibility channel (this link will open in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. and require you to log in).

Perceivable

We want to make sure that information and user interface components are presentable to all users in a way that they can perceive. Users must be able to consume the information being presented, via whatever sense they are relying on to interact with your content. A way to think about this is to consider whether you could locate all content or interactive elements on the page if you couldn’t use a specific sense (e.g. sight, hearing or touch). If something is invisible to all of a users available senses, then it is not perceivable.

Here is a short list of ways to check for perceivability:

  • Do all images and visual elements have concise and descriptive Alt Text?
  • Does all video/audio content have captions?
  • Does your content have semantically correct headings (e.g. h1, h2) and not just bolded text?
  • Does text or graphical objects that are interactive have a good color contrast between the background and foreground?
  • Does content use a method other than just color to convey meaning?
  • Does all content have a minimum font size of 16px?

Top ↑

Operable

Users must be able to operate the interface – the interface cannot require interaction that a user cannot perform. It is not enough to make a button perceivable by a user, if they cannot interact with it! Think about different user situations. Could someone interact without having the use of a mouse, or both hands on a keyboard? Could someone interact using a touch screen? Can they watch your video without it triggering a seizure?

Here is a short list of ways to check for operability:

  • Is all content accessible using only a keyboard (no mouse)
  • There is no flashing content at a frequency of more than 3 ‘flashes’ per second
  • Can the purpose of all links be determined by the link text alone?
  • Can all interactive elements be used with a touch screen? E.g. buttons and interactive elements are large enough to easily be tapped

Top ↑

Understandable

It is important that all users, regardless of language, culture, device or technology, can understand the content on the page. A useful test is to use an automated language translator to translate your content into a different language and then back to English. Does it still make sense?

Here is a short list of ways to check if content is understandable:

  • Avoid metaphors, similes, idioms, proverbs, expressions or turns of phrase that may confuse someone from a different language or culture (e.g. ‘Break a leg’)
  • Use common words instead of fancy ones where you can
  • Split sentences if required to improve clarity
  • Use simple tenses
  • Avoid using acronyms unless they have already been explicitly defined. E.g. Subject Matter Expert (SME)

Top ↑

Robust

This principle is often the most difficult to understand and test for. A robust web page displays content as the author intends, functions as the author intends and is compatible with current and future browsers, Web-enabled devices, and assistive technologies. One way you can test for robustness is to use a tool such as the W3C Markup Validation Service.

While the robust principle is more commonly applicable to code than content, here is a short list of ways to check if content is robust:

  • Use relative font sizes where possible so that users can adjust font size themselves using browser or accessibility tools (e.g. ‘2em’ instead of ‘40px’)
  • Ensure any custom HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. has necessary open and close tags and follows best practice semantic HTML.
  • Make sure any IDs added to elements are unique.

Top ↑

Markdown Checklist

Are you a content creator or editor and need to review Learn content for accessibility? Copy and paste the markdown checklist into a GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ comment or ticket:

## Perceivable

- [ ] All images and visual elements have concise and descriptive Alt Text

- [ ] All video and audio content has captions

- [ ] Content has semantically correct headings (E.g. h1, h2) and not just bolded text

- [ ] Text or graphical objects that are interactive have a good color contrast between the background and foreground

- [ ] Content uses a method other than just color to convey meaning

- [ ] All content has a minimum font size of 16px

## Operable

- [ ] All content is accessible using only a keyboard without requiring a mouse

- [ ] There is no flashing content at a frequency of more than 3 flashes per second

- [ ] The purpose of all links can be determined by the link text alone

- [ ] All interactive elements can be used with a touch screen - E.g. buttons and interactive elements are large enough to easily be tapped

## Understandable

- [ ] Avoids use of metaphors, similes, idioms, proverbs, expressions or turns of phrase that may confuse someone from a different language or culture - E.g. ‘Break a leg’

- [ ] Uses common words instead of fancy, less-common ones where possible

- [ ] Sentences are split when required to improve clarity

- [ ] Sentences use simple tenses - E.g. 'Press the on button' instead of 'the on button should be pressed'

- [ ] Avoid using acronyms unless they have already been explicitly defined - E.g. Subject Matter Expert (SME)

## Robust

- [ ] Where possible, font sizes use relative units (e.g. 2em) instead of explicit units (e.g. 40px)

Last updated: