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.
How to write alternative text for images and graphics
Follow these tips to write text alternatives (alt text) for images or graphics:
- Alt text should be kept short and concise, how much or little you write is very context specific. A general rule is to keep your alt text under 125 characters, which is roughly 25 words
- Do not write ‘image of’ or ‘photo of’ in the alt text. The computer already knows it’s an image; the point is to describe what’s in the image
- Think about why you’re using the image. What’s its purpose? What do you want to tell people by using it? Knowing this helps you write meaningful text descriptions. If you’re struggling with what to write, consider calling someone who isn’t looking at the picture and describing it to them. This can help you narrow down what you’re trying to say with the image
Review the official source for success criterion 1.1.1.
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.
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.)
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.)
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.
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.”
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 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:
<label for="honeypot">Leave this field blank:</label>
<input type="text" id="honeypot" name="honeypot">
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.