Accessibility for content creators

Overview

Accessibility is everyone's job. It isn't just something that developers add in when they write code. Web content itself needs to be accessible, too.

See below for some ways you can make the web content you create accessible to more people.

Language

The words you choose can affect someone's ability to understand and use your website or application.

• Do you have any instructions that rely only on color? For example, "click the green button to continue" doesn't help someone who can't distinguish which button is green. Make sure you find other ways to identify items.
• Do any instructions rely only on sensory descriptions? Just as with color, not everyone can perceive sensory descriptors, like "the large button" or "the button on the right". Some descriptions, such as "left" and "right", may not apply if content has been rearranged to fit a smaller screen or when accessed with a screen reader. Don't rely on size, location, shape, or sound alone to identify something.
• Is important information conveyed only through color? Is any information lost if you view your content in grayscale, without color? People who can't distinguish color won't have access to that information. That doesn't mean you can't use color, only that you'll also need to use an additional method of conveying the same information. In some cases, such as graphs, it's best to use patterns in addition to color.
  • Not accessible: Past due balances are marked in red.
  • More accessible: Past due balances are marked in red and include the notation "Past due".
• Do you have any language changes in your text? For example, if your site is primarily in English, but there's a section in Spanish, you'll need to indicate that in the code so screen readers can correctly pronounce the content. Identifying language changes also helps with automated translation into another language.
• Have you used the simplest language possible? Plain language helps everyone understand your content, including people with cognitive or learning impairments and non-native speakers of the language. In particular, technical terms and jargon can be difficult to understand. If you use acronyms or abbreviations, it's usually best to include the expanded term first.

Labeling

Labels identify and describe a component's purpose. They help people understand what actions are available, and they are announced by assistive technology. A lot of things need labels, and someone has to come up with them.

• Do all links, buttons, form fields (text fields, radio buttons, checkboxes, etc.), and other interactive elements have unique, descriptive labels? If someone can click an item, it needs a name that can be shared by assistive technology. The label should match or start with the visible text, which helps people using speech recognition software. Also, you shouldn't use the same label for different items on the same page, as this can be confusing. For more, see Write link text for accessibility.
• Does each page within the website or application have a unique title? The title is the first piece of information announced by a screen reader when navigating to a new page. The title should inform people of where they are, with the most specific information first.
• What will the heading structure be? Headings are critically important because they form an outline for your page. Assistive technology users may refer to this outline to get an overview of the page. Use a hierarchical heading structure, starting with a level 1 heading. Distinct content areas should have descriptive headings.

Images

Images need alternative (alt) text, and someone has to write it. Alt text is announced by screen readers and is intended as a text alternative for people who may not see the image. Alt text will also appear as an on-screen text alternative if an image fails to load. All images should have an alt attribute. This includes logos, icons, charts and graphs, and any other images.

• Is each image, icon, or graphic meaningful or decorative? If you removed the item, would you need text to replace it? If so, provide the replacement text as your alt text: alt="description of the image". Don't duplicate caption text in the alt text. Alt text describes an image while a caption gives context for the image.

  You can indicate an image is purely decorative with null alt text. Null alt text is empty alt text, indicated by alt="" (alt equals a double quotation mark followed by another double quotation mark, with no space between). Assistive technology will ignore images with null alt text. If you aren't sure if an image is decorative or meaningful, provide alt text.

  For more, including tips for writing good alt text, see Alternative text for images.

• Is there visible text in close proximity to the image that describes it but is not the image caption? For example, on a profile page, the person's name might be located next to their image. In this case, alt text would be redundant since the alt text would duplicate the person's name.

  You can indicate that alt text is not needed using null alt text. If you're not sure whether alt text is needed or not, provide it.

  Note:

  If your image has a caption, you must provide alt text that describes the image while the caption provides context. Null alt text will hide the image from assistive technology, leaving a caption with no context.
• Do any of the images include images of text? If so, assistive technologies don't have access to that text. You should include the image text in the alt text, although it's generally better to not use images of text.

Audio and video

Time-based media such as audio and video need alternatives to make them accessible to more people. Some decisions made during planning and recording can improve the accessibility of the media and make it easier to implement the alternatives.

• Are you involved in planning the media? If visual content can be described as part of the audio, making a small change to the script could reduce the need for additional description of the visual content. When that isn't possible, consider including pauses in the audio for the audio descriptions of visual content.
• Are you involved in recording the media? Record the best sound quality possible. Consider the balance of foreground noise to background noise. Try to avoid flashing or blinking lights that could cause seizures. Consider the placement of on-screen text and captions when framing scenes.
• Have you provided captions, audio description, and a transcript? Visual content needs to be described for people who are blind or have limited vision. Auditory content needs to be described for people who are deaf or hearing impaired. Providing the right alternatives will make your video and audio accessible to more people.

Other moving content

Moving content can cause headaches, nausea, or dizziness. The movement can also be distracting.

• Do you plan to use animated GIFs or other moving images? Instead, consider using a short video that viewers can pause if they wish. Limit the number of times a GIF loops.
• Does any of your content flash or blink? Flashing and blinking can cause seizures. Make sure the flashing or blinking happens less frequently than three times per second.
• Do you have any carousels? Consider presenting the content another way. They have poor accessibility and usability.

WCAG criteria

Decisions made during the content creation process directly affect over 50% of the 61 Web Content Accessibility Guidelines (WCAG) 2.0 success criteria. The following lists of criteria include accurate success criteria numbers and levels, with very simplified descriptions.

The 27 success criteria listed here are related to the questions above:

• 1.1.1 Level A - Images are described. Alt text.
• 1.2.1 Level A - Media is described. Transcript.
• 1.2.2 Level A - Media is described. Captions.
• 1.2.3 Level A - Media is described. Transcript or audio description synced.
• 1.2.4 Level AA - Media is described. Live captions.
• 1.2.5 Level AA - Media is described. Audio description synced.
• 1.2.7 Level AAA - Media is described. Video pauses with extended audio description.
• 1.2.8 Level AAA - Media is described. Detailed descriptive transcript.
• 1.3.3 Level A - Description does not require senses.
• 1.4.1 Level A - Color is not the only indicator.
• 1.4.5 Level AA - Text is not part of an image.
• 1.4.7 Level AAA - Audio recordings don't have background sound.
• 1.4.9 Level AAA - Text is not part of an image, no exceptions.
• 2.2.2 Level A - Can stop anything that moves automatically.
• 2.3.1 Level A - Nothing flashes.
• 2.3.2 Level AAA - Nothing flashes at all.
• 2.4.2 Level A - The page has a title.
• 2.4.4 Level A - Links understood if moved. No more than 1 "read more".
• 2.4.6 Level AA - Pages, sections, and inputs are described.
• 2.4.9 Level AAA - Links understood if moved.
• 2.4.10 Level AAA - Sections are described.
• 3.1.2 Level AA - Language changes are clear.
• 3.1.3 Level AAA - Idioms and jargon are explained.
• 3.1.4 Level AAA - Abbreviations are expanded.
• 3.1.5 Level AAA - Plain language is used.
• 3.1.6 Level AAA - Tips to help with pronunciation.
• 3.3.2 Level A - Inputs are clearly labeled.

By considering the questions above, you will also address this WCAG 2.1 success criterion:

• 2.5.3 Level A - Software sees the same name the user does.

Content creators affect another eight WCAG 2.0 success criteria not addressed in detail above:

• 1.2.6 Level AAA - Media is described. Sign language.
• 1.2.9 Level AAA - Media is described. Live captions for audio-only.
• 1.3.1 Level A - The elements are semantic.
• 3.3.1 Level A - Errors are shown and described.
• 3.3.3 Level AA - Error correction is described.
• 3.3.4 Level AA - Success or failure is communicated.
• 3.3.5 Level AAA - Help text is available.
• 3.3.6 Level AAA - Errors are prevented or reversible.