Triage Squad GitHubGitHubGitHub 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/ triage: Biweekly on Thursdays 07:00 UTC
The checklist on this page is a good starting point for content creators and reviewers creating or reviewing content in the Training Team. Activities this checklist can be used for include:
Writing meeting recap notes.
Publishing posts on the make.wordpress.orgWordPress.orgThe 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 lessons, courses, or online workshop slides.
This checklist used the four main guiding principles upon which the Web Content Accessibility Guidelines (WCAG) are built as a starting point, and include some recommendations that go beyond the scope of WCAGWCAGWCAG 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/. also. For those interested, How to Meet WCAG (Quick Reference) is another good resource.
If you would like to submit feedback about the accessibilityAccessibilityAccessibility (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) of any content the Training Team produces, please submit feedback on our GitHub repository. If you have more questions about accessibility or best-practices, the WordPress Accessibility Team can also be contacted via the #accessibility Slack channel.
Information and user interface components must be presentable to all users in a way that they can perceive them. Users must be able to consume the information being presented, via whatever sense they are relying on to interact with the 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:
Images and visual elements have concise and descriptive Alt Text.
Videos have captions, and audio have transcripts.
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.
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:
All interactive elements can be reached and operated with the keyboard.
There is no flashing content at a frequency of more than 3 ‘flashes’ per second.
The purpose of links can be determined by the link text alone. (e.g. Avoid placing links on words such as “here”, “this link” or “this page”.)
Interactive elements can be used with a touch screen. (e.g. Buttons and interactive elements are large enough to easily be tapped.)
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))
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:
Relative font sizes are used where possible so that users can adjust font size themselves using browser or accessibility tools. (e.g. ‘2em’ instead of ‘40px’.)
Any custom HTMLHTMLHTML 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.
Are you a content creator or editor and need to review Learn content for accessibility? Copy and paste the markdown checklist into a GitHubGitHubGitHub 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
- [ ] Images and visual elements have concise and descriptive Alt Text.
- [ ] Videos have captions, and audio have transcripts.
- [ ] 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.
- [ ] 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 links can be determined by the link text alone.
- [ ] Interactive elements can be used with a touch screen. (e.g. Buttons and interactive elements are large enough to easily be tapped.)
## Understandable
- [ ] Avoids 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).