Why Accessibility?

While we have a legal responsibility, it is also ethically right to make guides as accessible as possible. Moreover, increased accessibility can benefit everyone (e.g., closed captions improve comprehension, attention, and memory of a video's content).

Content Styling

  • Don't use color as a way to convey meaning or importance. Colorblind users and screen readers may not pick up on color changes.
  • Don't use different font types—use the default font.
  • Don't change the font size.
  • Don't underline text that is not a hyperlink.
  • Don't use all caps for emphasis.
  • If you must use emphasis, only use bold or italics in the rich text editor (or <strong> or <em> tags in HTML—avoid older-style bold <b> or italics <i> tags as they denote style rather than importance).
    • Be consistent in your application if you use both—establish a logic.
  • Avoid relying on non-HTML content that may not be accessible, like PDF or PowerPoint.
    • If you use non-accessible content, please create an accessible counterpart.
    • It's better to feature only the accessible counterpart created (instead of both it and the non-accessible non-HTML content).

Copying & Pasting

  • You should avoid copying & pasting content from any source into the rich text editor (especially from MS Word). Many times hidden style code will also be copied along that can break accessibility.
    • Strive to write and create content within LibGuides itself.
  • If you do copy & paste text into the rich text editor then use the Button to use for removing all formatting from selected text in the rich text editor. button as it will attempt to remove formatting from the selected (highlighted) text. This will generally solve strange formatting issues and inaccesible content that can come from copied text.

Links

  • Make sure link and database assets display their description below the link—don't hide the description behind a hover-over button as this breaks accessibility.
  • It is not recommended to have long lists of items, but if you do—then you need to break them up into logical groups so that they can be skipped between by screen readers.

Images

  • All Images must have alternate (alt) text.
    • In the rich text editor, double-click an image and add alt text
    • In HTML, begin image tags with img alt=" "
  • Alt text should be brief, yet descriptive and never redundant.
  • If the image links to somewhere else, make sure the image's alt text also describes the destination.
  • Don't begin alt text with "Image of..." since it is already understood that these are images.
  • WebAIM provides good principles for phrasing and content with alt text.

PDF, PowerPoint, Video, & Audio

  • Avoid relying on non-HTML content that may not be accessible, like PDF or PowerPoint.
    • If you use non-accessible content, please create an accessible counterpart.
    • It's better to feature only the accessible counterpart created (instead of both it and the non-accessible non-HTML content).
  • Videos must have captions and/or a transcript.
    • Automatic captions via YouTube are not an alternative to use.
  • If you embed a video, it must have the ability to display captions when embedded.
    • If it cannot, then the video should be linked to, not embedded.
  • Podcasts and other audio must have a transcript.

Tables

  • Only use tables for tabular data that fits well into rows and columns.
  • Don't use tables to format links or other information.
  • Use table headers to describe the contents of the table columns.
  • Avoid spanned rows (i.e., cells taking up two or more rows or columns) as screen readers may not properly parse them.
  • There is no need to manually change a table's width or cell padding in LibGuides.

Accessibility Checkers