According to the WCAG, the contrast ratio between text and the text’s background should be at least 4.5 to 1. If your font is at least 24 px or 19 px bold, the minimum drops to 3 to 1 (though, worth noting that this is a little fuzzy because numbered sizes aren’t always reflective of the visual size type). Be especially careful of text over images.

Source: Salesforce UX

There should be another indicator (such as icons to accompany color coding, or an underline on linked text) so that people who cannot easily distinguish colors will be able to understand and use your content.

Source: UCLA

When you strip out the color information from two hues and compare the values, there may not be much difference. Pairing different values creates contrast.

Source: UCLA

You should not rely solely on images, shape, size, visual location, orientation, or sound to indicate important instructions for operating or understanding content (ex. “See the image above”). Instead, use a combination of positioning, color, and labeling to identify content.

Source: W3C

Your designs should never actively hide focus states. When people use the keyboard to navigate, your product should include highly visible focus states.

Source: W3C

Labels should never completely go away when the focus is inside of an input. Users should always have clear instructions on what they should be inputting. Put error messages in text that explain the error and how to fix the error. Never rely solely on color to indicate errors.

Source: W3C

Users with low vision often make use of a talking browser to “read” the web. These specialized browsers convert text to speech so that a user can hear the words on a site. When a talking browser lands on an image, it looks for alt text that it can read aloud; if it finds none, it will often just say “image,” leaving the user in the dark as to what the image is and how it matters to the story.

Describe all of the elements that explain what’s happening in the image, rather than just setting the alt text to be something like, “photograph"

If you have to use an image of text, be sure to describe the design if relevant, as well as all of the words in the image. (Ex: Whiteboard drawing of the quote “This is a quote”)

Source: WebAim: The Basics of Good Alt Text

It can be difficult to make certain components (like an SVG map) into accessible experiences. In those cases, consider creating an additional screen reader-friendly experience, or at the very least, describe the experience to users.

Be consistent across functions, placement, and labeling. Components with the same functionality should work and be identified consistently. Use section headings to organize content. Be clear in writing; avoid jargon and idioms

Source: Viget

HTML elements communicate to the browser what kind of content they contain and how the browser should render or treat that content. The accessibility tree is built off of assumptions about the elements and their structure. This is the browser feature which powers screen readers. Choosing the correct element for the current context is a simple way to create a good foundation for your experiences.

Source: WebAIM

Browsers support tabbing through link, form, button elements. This is an easy way to move around the page, but it’s very easy to accidentally hinder this functionality: by relying on CSS to move elements around instead of actually reordering the HTML; hiding elements from tab flow, either by faking buttons (with JavaScript) in lieu of using button elements or disabling tab via tabindex=”-1”; and hiding form elements (on a tabbed interface) but not removing them from the tab flow (so that hidden form elements can be focused).

Source: WebAIM

People who use assistive devices may not want to peruse your content linearly, instead preferring to use an outline view (generated from markup) to find the relevant content for their current needs. These landmarks, like main and form and navigation help define specific areas that a user might want to seek out and can save them a lot of time.

Source: A List Apart

Users with low vision often make use of a talking browser to “read” the web. These specialized browsers convert text to speech so that a user can hear the words on a site. When a talking browser lands on an image, it looks for alt text that it can read aloud; if it finds none, it will often just say “image,” leaving the user in the dark as to what the image is and how it matters to the story.

Describe all of the elements that explain what’s happening in the image, rather than just setting the alt text to be something like, “photograph"

If you have to use an image of text, be sure to describe the design if relevant, as well as all of the words in the image. (Ex: Whiteboard drawing of the quote “This is a quote”)

Source: WebAim: The Basics of Good Alt Text

Your designs should never actively hide focus states. When people use the keyboard to navigate, your product should include highly visible focus states.

Source: W3C

Labels should never completely go away when the focus is inside of an input. Users should always have clear instructions on what they should be inputting. Put error messages in text that explain the error and how to fix the error. Never rely solely on color to indicate errors.

Source: W3C

ARIA stands for Accessible Rich Internet Applications. It is an optional but helpful spec to define ways to markup HTML that has dynamic experiences (typically controlled by JavaScript).

The goal when using them is to communicate to the browser and assistive technology how content is going to change or what the purpose of the content is. Dynamic error messages can be called out to screenreaders, buttons can be linked to the content they affect and many other helpful states can be expressed on a code level.

Source: W3C Guide to Using Aria

For keyboard users, it can be helpful to give them a way to skip past top level navigation to get to the main content. This is typically a button at the top of the page (it can only be visible if active), that, when clicked, shifts the current focus from the button to the top of the main content of the page. This saves the user from having to tab through many many elements of navigation.

Source: WebAIM

Assistive technology is able to find all links on a page and present them in various forms, but these links are rather useless if it’s a long list of links that are just the text “click here.” A better way is to have the link describe where the user will go if they click it, giving them an idea of what’s on the other side of clicking.

Source: Smashing Magazine

Assistive technology relies on HTML to find the content to present to users. It’s possible to create pseudo-elements with CSS, however, there is currently no way to provide alternative text if there are images or icons here.

Source: Simply Accessible

SVGs are often used as icons on interactive elements in sites. When this is the case, the SVG should have a title or embedded text (that is visually hidden but available to assistive tech) to ensure that the information of the icon is available programmatically.

Source: Sitepoint

Decorative elements, such as dividing lines, pull-quotes, or non-informative icons, can be hidden from screen readers to ensure that a user only receives relevant information as they peruse the page. This is done by adding aria-hidden=”true”  to the element.

Source: W3C

It can be difficult to make certain components (like an SVG map) into accessible experiences. In those cases, consider creating an additional screen reader-friendly experience, or at the very least, describe the experience to users.

The outline property indicates when an element or selected or has focus. This is helpful to users who don't have the ability to use a mouse or are visually impaired.

Source: WebAIM

The HTML lang attribute is used to identify the language of text content on the web. This information helps search engines return language specific results, and it is also used by screen readers that switch language profiles to provide the correct accent and pronunciation. e.g. <html lang="en">

Source: Paciello Group

We have guidelines for design, engineering, and QA testing. Read through the requirements, and be aware of the checks and standards that QA will be looking out for in your products.

Accessibility is not a checklist item that only needs to be considered in some projects, or at the end of a process. These practices should be woven into every step of a project and role in a team. Make sure you are accounting for that while planning projects and sprints.

We all like to hear our work recognized. In addition to celebrating beautiful designs, elegant code, fast turnarounds, stellar experiences—draw attention to and praise the work done by your team to make content more accessible. Talk up high contrast, a smart keyboard navigation system, or clear copy and hierarchy.

Accessibility should be at the forefront of your mind when considering which projects to take on and how to shape the products. Whatever you create should support accessibility efforts, and not hinder them. For instance, if your team creates a publishing tool that allows users to upload images, and the tool does not allow for alternate text descriptions, you have made it impossible for your users to produce accessible images for non-sighted people.

Explain to your team and stakeholders why accessibility is important and should be a priority in every piece of work your team takes on. It makes our products—and our teams—better.

This tool is not perfect, however, will provide a good basis for accessibility errors.

Remember to look out for: Accessing navigation and drop down menus, users should be able to tab through an entire page and not get trapped in any elements, this is a common issue for modals, focus states on selectable elements -- links, buttons, etc.

Apple’s built in Voice Over works well for this, and includes a built in tutorial on how to use it.

Headers should exist, clickable elements should be clearly indicated, and the user should be able to navigate through. If you are viewing content with poor lighting or from a few feet away, text should be readable. If you could foresee users having trouble seeing or comprehending content, that’s a sound indicator that something is off.

Non-sighted users often make use of a talking browser to “read” the web. These specialized browsers convert text to speech so that a user can hear the words on a site. When a talking browser lands on an image, it looks for alt text that it can read aloud; if it finds none, it will often just say “image,” leaving the user in the dark as to what the image is and how it matters to the story.

Describe all of the elements that explain what’s happening in the image, rather than just setting the alt text to be something like, “photograph”

If you have to use an image of text, be sure to describe the design if relevant, as well as all of the words in the image. (Ex: Whiteboard drawing of the quote “This is a quote”)

Source: WebAim: The Basics of Good Alt Text

For instance, SVGs are often used as icons on interactive elements in sites. When this is the case, the SVG should have a title or embedded text (that is visually hidden but available to assistive tech) to ensure that the information of the icon is available programmatically.

Sometimes you don’t have time or resources to make certain components into accessible experiences. In those cases, consider creating an additional screen reader-friendly experience, or at the very least, describe the experience to users in alt text.

Be clear in copy

Avoid jargon and idioms

Use section headings to organize content.

Source: Interactive WCAG 2.0

Assistive technology is able to find all links on a page and present them in various forms, but these links are rather useless if it’s a long list of links that are just the text “click here.” A better way is to have the link describe where the user will go if they click it, giving them an idea of what’s on the other side of clicking.

Source: Why Your Links Should Never Say “Click Here”

You should not rely solely on images, shape, size, visual location, orientation, or sound to indicate important instructions for operating or understanding content (ex. “See the image above”). Instead, use a combination of positioning, color, and labeling to identify content.

There should be another indicator (such as icons to accompany color coding, or an underline on linked text) so that people who cannot easily distinguish colors will be able to understand and use your content.

Source: Sensory Characteristics