Text alternatives for non-text content

Text alternatives enable non-text content like images, graphs, audio and video to be transformed into different formats like large print, braille, speech, symbols or simpler language. User agents, such as screen readers, convert alternative text into speech or braille. This allows someone who cannot see an image, to hear or feel the description.

Non-text content exceptions

Exceptions apply for certain non-text content, such as controls or input elements, time-based media, tests, sensory experiences, decoration or formatting, invisible content and CAPTCHAs.

Controls, input

For non-text content that’s a control or accepts user input, such as images used as buttons or image maps, a name is provided to describe its purpose. This helps people know what it is and why it’s there. (Refer to success criterion 4.1.2 for controls and input requirements.)

Time-based media

Any media which has duration as a property (such as video or audio). A text alternative that describes what it is and/or gives its title must be included. This tells people what the media file is so they can decide what, if anything, they want to do with it. For live (as opposed to pre-recorded) audio-only or video-only content, provide a descriptive label. (Refer to success criterion 1.2 for additional requirements for time-based media.)

Test

Sometimes a test must be presented in non-text format. In these cases, audio or visual information can’t be changed to text because it would defeat the purpose of the test, such as a hearing test or a spelling test. In these cases, a text alternative describing the purpose of the non-text content must be included.

Sensory

Sometimes content intends to create an experience that words can’t fully capture, such as a symphony or visual art. In these cases, use a descriptive label and where possible, descriptive text. If the reason for the content can be described, it’s helpful to include that information.

Decoration, formatting, invisible

If the content is purely decorative or only for visual formatting, then it must be created so assistive technology can ignore it, such as using “mark as decorative.”

CAPTCHA

To prevent bots from submitting forms, CAPTCHAs are sometimes used to confirm users are human. However, they’re not foolproof security measures and can be bypassed by sophisticated bots. They can also be difficult for users, particularly those with disabilities, to complete.

Alternatives to CAPTCHAs

WCAG provides the following recommendations to confirm users are human:

• CAPTCHA must not be the only way of verifying the authenticity of a user
• If used, an alternative form of verification must be available to those who are unable to pass it
• CAPTCHAs must include a text alternative which describes its purpose, without describing the puzzle that needs to be completed
• Honeypots can be an effective alternative to CAPTCHAs that does not require users to complete a challenge

Honeypots

Honeypots are hidden form fields intended to be filled by bots but not humans. They detect bots through the presence of data in the honeypot field when the form is submitted.

This approach is invisible to sighted users and doesn’t require them to solve any puzzles. This makes them a potentially more accessible solution for users who struggle with traditional CAPTCHAs.

To hide honeypots from screen readers, it’s recommended to use ARIA (Accessible Rich Internet Applications) code. This ensures the field is not present for users who rely on assistive technologies.

To hide a honeypot field, use the “aria-hidden” attribute. For example:

<div aria-hidden="true">

  <label for="honeypot">Leave this field blank:</label>

  <input type="text" id="honeypot" name="honeypot">

</div>

It’s important to note some advanced bots may be able to bypass honeypots, so it’s a good idea to use a combination of methods to ensure forms are secure.