Accessibility Checklist for Content Designers

Accessible writing ensures your content is easier for everyone to read. As we build government services, we want to ensure they are accessible and welcoming to everyone who needs to use them.

Plain Language

  1. Refer to the plain language section of 18F’s Content Guide for general guidance, lists of words to avoid, and links to plain-language resources.
  2. As you’re writing, consider the tech literacy level of your target audience. Define technical terms that may be unfamiliar, and use a product or service’s full name before using its acronym or abbreviation. You may also consider adding a glossary if your content contains many potentially unfamiliar terms. Include in-line definitions for scientific, legal, or technical terms that you must use.
  3. Avoid using idiomatic language.
  4. Test the readability of your content using Hemingway App, Readable.io, or a similar tool.

Reference Materials

  1. Consider defining technical or other potentially unfamiliar terms in line; this creates a much more continuous reading experience for the user.
  2. If you find that you need to define a large number of terms within your content, consider adding a separate glossary page.
  3. Use hyperlinks or a tooltip rather than footnotes to direct users to definitions. Footnotes can create a jarring reading experience, and they may not render correctly on mobile devices.

Graphic Elements

  1. Include visual elements in line with text rather than separated from it; a graphic’s proximity to associated content helps reinforce the relationship between the visual and its written description.
  2. Make sure all graphics have descriptive captions (if necessary). Also make sure that captions share a common form and voice.
  3. Include meaningful information describing each graphic element in the alt text.
  4. Use null (empty) alt text when text describing the graphic element is already on the page (alt=””).
  5. If the graphic element is decorative and you don’t want the screen reader to announce it at all, use null (empty) alt text (alt=””).
  6. Consider presenting dense technical language in a format other than as part of a graphic. When compressed to mobile view (in other words, a harder-to-read format), graphs and charts with technical language can be tough to interpret.

Scannable Content

  1. Use short sentences, whenever possible. Varying sentence length can add interest to a piece, but whenever possible, avoid unnecessarily long sentences — these can present obstacles to people who have difficulty reading. They can also be harder to skim on mobile devices.
  2. Likewise, keep your paragraphs short and focused. Short paragraphs, like short sentences, are easier to scan on mobile devices.
  3. Use precise and descriptive headings to help readers grasp the main points of a piece without reading it in its entirety.
  4. Check the continuity between sections. Paragraphs that don’t have clear thematic links from one to the next can cause difficulties for some readers.

Images

  1. Include meaningful information describing each image in the alt text.
  2. Use null (empty) alt text when text describing the image is already on the page (alt=””).
  3. Don’t start the alt text with Image of or Photo of – the screen reader already announces that images are images.
  4. If the image is decorative and you don’t want the screen reader to announce it at all, use null (empty) alt text (alt=””).

Links

  1. Make sure the voice and tone of your link text match those of the rest of the content to create a more continuous user experience. Folks using screen readers and those reading page copy won’t be jarred from their experience if all text reflects the same voice and tone guidelines.
  2. Create link text that’s as specific as possible. For example, instead of using Click here (which may not make sense for folks using screen readers), consider instead something like Download the full report. Descriptive links provide all users more information about an action they may undertake.
  3. Include information about what a link leads to; this is especially important for folks who use mobile devices. If you’re linking to a PDF, say so.

Information Architecture

  1. Write descriptive page titles. Users who rely on assistive technologies like screen readers may not be able to use visual cues to determine a page’s purpose. Make sure your page titles concisely convey each page’s focus.
  2. Make sure users can navigate a site in multiple ways. Some strategies include providing a table of contents, providing a sitemap, linking between pages, and including sitewide search.
  3. Indicate changes in language (for example, when including a foreign word in a predominantly English text). This will help people using screen readers, people with cognitive disabilities, and folks using braille translation software to fully understand your content.
  4. Use a screen reader or simulator to make sure you can land on controls and that they’re announcing things as they should.
  5. Determine whether the HTML document has a language attribute so that screen readers will read it with the correct accent and pronunciation. For example: . (Note: If you’re not comfortable taking this step, feel free to ask another designer on your project team to help.)
  6. If forms are present, make sure the screen reader reads labels and instructions.

Video and Multimedia

  1. Make sure that captions are synchronized to appear around the same time that they would be heard in the audio.
  2. Captions do not need to be a word-for-word version of the audio, but should be a concise equivalent.
  3. Use a modern video player that supports captions.
  4. If you’ve captioned your video, provide a transcript as one of the optional output formats produced by the closed captioning process.
    • To make the transcript available, link to it from your web page, wherever you link to or display the associated video.
  5. Audio description is required when important information is visually shown on the screen that cannot be observed by a blind or vision-impaired individual.

You can also view our other digital accessibility checklists:

Reference: Accessibility.digital.gov