Quick reference accessibility guidelines for content providers

Anyone developing content (documents, videos, eLearning, etc.) for digital distribution must ensure that the content is accessible to, and can be equivalently experienced by, individuals who have disabilities.

For example:

  • Blind individuals often use screen readers, which require that content be "programmed" in certain ways so that their users can perceive, interpret and understand the content equivalent to how others experience it
    • E.g., if a document features a 4-item list, screen readers need to read that content as a 4-item list
  • Deaf or hard-of-hearing individuals depend on accurate, well-timed captions to have equivalent access to the audio information offered within videos
  • Individuals who have motor control impairments may use their keyboard or other adaptive devices, instead of a mouse, to control their computer

Basic Guidelines

These guidelines will assist you in taking the first steps toward basic accessibility and Web Content Accessibility Guidelines (WCAG) 2.1 AA compliance for most types of content, and, as is often the case with accessibility practices, they’ll even help you improve digital experiences for all users!

1. Provide meaningful descriptions of images and other graphics

Use alternative text (a.k.a., "alt text") to provide equivalent access to the important visual information offered in images and other graphics.

2. Use headings to organize content, convey relationships and provide landmarks for quick understanding and navigation

Introduce each section of content with a heading that succinctly describes the section, and assign heading levels based on how sections relate to one another.

  • Headings should help users get a quick sense of what each section covers
  • Headings also aid in navigation, providing ways for users to jump directly to the sections they introduce
  • Do not choose heading level based on preferred visual appearance; assign the heading level that's appropriate per relationships, then give the heading the desired "look"
  • Per WCAG 1.3.1 Info and Relationships (Level A), if text looks like a heading and/or serves the organizational function of a heading — i.e., it introduces a distinct section of content — it needs to be programmed as a heading

3. Avoid generic or ambiguous links like "click here" and instead use descriptive link text

Link text — i.e., text that hosts a hyperlink — should, on its own, provide users with a sense of a link's purpose and/or destination.

  • Avoid using generic or ambiguous phrases as link text — e.g., "click here," "learn more," "source," etc. — since they require users to visit the link or read additional text to know a link's destination
  • No two links in the same environment should use the exact same link text unless they direct to the exact same destination
  • Explore additional link text best practices (pdf)

4. Ensure text (and certain graphical elements) achieve sufficient color contrast to be easily perceived and read

  • "Contrast ratio" is a measure of the amount of contrast between two colors and is evaluated using a checker tool, like the WebAIM Contrast Checker
  • Large text — i.e., text that is at least 14pt/19px in size and bold, or text that is at least 18pt/24px, regardless of being bold — must achieve a contrast ratio of at least 3:1
  • Normal text — i.e., any text that does not meet the definitions of large text — must achieve a contrast ratio of at least 4.5:1
  • Graphical objects and user interface components that need to be "read" in order to be reliably used — e.g., icons, sliders, form field boundaries, etc. — must also achieve a contrast ratio of at least 3:1
  • Learn all about color contrast

5. Don't use color as the sole means of conveying information

If you're using color to convey information — green = correct; red = incorrect — make sure to incorporate another perceivable element — e.g., an icon, a text label, etc. — that conveys the same information.

  • E.g., a checkmark to also communicate "correct" and an X to also communicate "incorrect"
  • Keep in mind, not everyone perceives color the same
  • Learn more through WCAG 1.4.1 Use of Color (Level A)

6. Only use tables to share "data" — do not use tables for layout purposes — and ensure tables have the proper programming to assist in screen reader interpretation

  • "Data tables" use columns and/or rows to connect pieces of information in a consistent manner
    • "Data" doesn't have to mean numbers; what matters is that information is presented consistently, by column and/or row
    • E.g., in the Link Text Best Practices PDF, every cell in each column offers the same category of information ("Rule," "Purpose/benefit," etc. — i.e., they're consistent), and every row connects pieces of information regarding rules, in a consistent order
  • Learn more about proper table programming
  • Watch this demonstration of how table header cells aid in interpreting table data
  • In Microsoft Office 365 products, table header cells are programmed through the Header Row and First Column checkboxes in the Table Design ribbon
    • Note: these checkboxes may be checked by default when creating a new table; uncheck them as appropriate

7. Ensure assistive technologies, like screen readers, encounter content in the order that best facilitates understanding

Some content development tools allow, or require, you to establish screen reader reading order separate from the visual reading order.

  • In PowerPoint, use the Reading Order pane or the Selection Pane to establish reading order
    • The two panes are connected, so changes made in one will be reflected in the other, but they capture reading order in opposite directions: the Reading Order pane operates top-to-bottom (i.e., higher elements will be read before lower elements) while the Selection pane operates bottom-to-top (i.e., lower elements will be read before higher elements)
  • In Word:
    • Use in-line text and employ paragraph and layout settings to position text; avoid inserting text boxes
    • For images, tables and other non-text elements, try to use "In Line with Text" and be mindful of how other text wrapping settings affect reading order

8. Ensure visually impaired audiences can equivalently access visual information in videos, webinars, lectures and other settings that combine audio and visual information

  • If a video's audio does not sufficiently relay the same information presented visually through elements like text, images, diagrams, etc., a separate audio description is required, per WCAG 1.2.5 Audio Description (Level AA)
    • Audio descriptions can take the form of a separate audio track users can play along with the video or a separate version of the video that includes the audio description audio
      • YouTube, like other platforms, does not currently allow you to assign a secondary audio track, so it's recommended that you add the audio description audio within a separate version of the video, upload that separate version to YouTube as well and link to that audio description version within the original video's description
    • Audio descriptions may also take the form of an "extended audio description" which pauses the video at certain moments in order to add audio that sufficiently describes proximate visual information
    • (Extended) Audio description example from a Storyline eCourse
  • Lecturers and other presenters, get in the habit of describing your visual aids

9. Ensure videos and certain other forms of multimedia (like eCourse slides that feature audio) are captioned

Captions are required to ensure hearing impaired audiences can equivalently access audio information offered through videos and similar multimedia.

  • Captions are required regardless of where/how a video is shared: e.g., through YouTube or social media, embedded in a web page, included in an eCourse or PowerPoint deck, etc.
  • Explore additional Transcript and Caption resources

10. Provide transcripts for all audio-only media, like MP3s, podcasts, etc.

Transcripts suffice to provide access to audio information in contexts where there is not visual information being presented in sync with the audio (as occurs in video).

  • Transcripts should be provided proximate to their corresponding audio and must be fully accessible
    • E.g., if you provide a transcript in the form of a linked PDF, the PDF's link must be proximate to the audio and the PDF must be accessible
  • Transcripts do not need to be provided for videos — as captions satisfy the equivalent need for videos — but they can be

11. Avoid time limits and pre-plan for accommodation needs with timed content

  • Some users may need more time to navigate and access material, due to disability and/or use of assistive technologies
  • If time limits are essential, ensure an option for extended time limits are available
  • Learn more through WCAG 2.2.1 Timing Adjustable (Level A)

12. Communicate in a concise, logical manner

All users benefit from clear, succinct communication, but it can be especially meaningful for assistive technology users and users who have certain disabilities, as there may already be ways in which they're having to expend more time and energy to perceive, operate and understand environments that weren't designed with their needs in mind.

  • Keep text and other communication short and to the point
  • Explain or avoid idioms that may not be understood by all audiences
  • Introduce what acronyms/abbreviations mean when, or before, first using them

Additional Resources

In addition to the wealth of information and resources available through the UC Electronic Accessibility website, you can also explore: