Home

Even Grounds, Accessibility Consulting

Making web sites, documents, software and hardware accessible to people with disabilities. Accessibility, WCAG and Section 508 compliance testing and auditing.

  • Services
  • About Us
  • Customers
  • Contact Us
  • Articles
  • Blog
  • Developers' Corner
  • Press
  • Resources

Skip table of contents

  • WCAG Tutorial
  • Introduction
  • About The Author
  • Using The Tutorial
  • WCAG 2.0 Overview
  • Navigating The WCAG 2.0 Documents
  • Principle 1: Perceivable
    • 1.1: Text Alternatives
    • 1.2: Time-based Media
    • 1.3: Adaptable
    • 1.4: Distinguishable
  • Principle 2: Operable
    • 2.1: Keyboard Accessible
    • 2.2: Enough Time
    • 2.3: Seizures
    • 2.4: Navigable
  • Principle 3: Understandable
    • 3.1: Readable
    • 3.2: Predictable
    • 3.3: Input Assistance
  • Principle 4: Robust
    • 4.1: Compatible
  • Appendix
    • Contrast Analyser
    • HTML And CSS Validators
    • Web Accessibility Toolbar

Do you need help with accessibility? Hire us!

1.1: Text Alternatives

Guideline 1.1: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, Braille, speech, symbols or simpler language.

This guideline ensures that anything that is not in an electronic text format originally, is converted, or represented as electronic text. The reason for providing electronic text is that it can be represented in many different ways, fulfilling the needs of people with disabilities. When information is provided as visual or audible elements, technologies will not be able to interpret these with just a few exceptions.

Please note that information has to be actual text, not images of text, as these are not convertible into other formats.

1.1.1: Non-text Content (Level A)

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)

  • Controls, Input: If non-text content is a control or accepts user input, then it has a
    name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)
  • Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content.
    (Refer to Guideline 1.2 for additional requirements for media.)
  • Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
  • Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
  • CAPTCHA: If the purpose non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
  • Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

Non-text content is everything that is presented to people for the intent of using any sensory perception. While this definition is very generic, keep in mind that information can be conveyed to people through many different means. Primarily, information is conveyed through hearing and vision. However, we can encounter tactile information, for example when a cellular phone vibrates in case of an incoming call or message.

Before we look into making non-text content accessible, we have to differentiate between informational and non-informational content. A video that presents a person describing a product is informational. The background decoration, or the background noise is not informational. However, when this product is related to sea-side activities, and the background is a beach and the noise is the waves, all of a sudden it becomes informational. All content has to be evaluated in its own context.

There are different opinions about whether non-informational content should be presented to people with disabilities. Some argue that people who cannot see have the right to receive an interpretation of all visual effects, or people who cannot hear should receive an interpretation of what others can hear. Some, however, argue that at this age of information overload it is only necessary to communicate relevant information to minimize the time for people to obtain content to be efficient in their every day lives.

Pictures and visual information

It is recommended to describe pictures in 4-6 words if possible. Make sure all words are relevant to the picture. For example, the description "This is a picture of a dog" mostly contains redundant words, as we know that "this is a picture of" something that we are going to describe. Thus, describing a picture of a dog could be as simple as "dog".

In certain other instances, it is next to impossible to describe pictures in a few words. For example, when the picture is a complex diagram, much more information is needed to provide a full explanation. In such a case, it is not sufficient to say "diagram", the entire content needs to be described.

When simple pictures are described, you could use an alt tag to describe them.

We can also use an alt tag to provide description for the different areas of image maps.

For longer descriptions, we can use several methods. We can add a short description of the picture, and right next to it provide a long description. This long description can be on the same page, or we can place it on a different page and link to it.

In many instances, the longdesc attribute is used to provide a detailed explanation of the picture from a separate resource.

Where 1.1.1 Does Not Apply

Success Criterion 1.1.1 does not apply to certain types of non-text content, either because of the nature of the content, or because it is detailed somewhere else.

Controls, input

When the non-text content is a control or an input element, it is also necessary to assign programmatically available information to the element. While in certain cases, textual information can be assigned too, this is not always the case.

Let's look at a check box for example. Information is communicated visually, based on whether the box is checked or not checked. Writing out the word "checked" and "unchecked" would completely defeat the purpose of a check box. Also, an application that takes the user input will use this information, for example, to determine if the user requested regular updates on a topic. So, at this point what matters is not only the visual appearance of the box, but also the information passed on to the application which can work with it. This information, therefore, is readily available. The developer should make sure that this information is communicated in a way that assistive technologies can make use of it.

Using a regular check box control by default communicates the information. When custom controls are used, this information should be communicated as well.

When the status information on a check box is available to assistive technologies, while it is not directly text based, now it can be directly communicated to the user in the form they communicate with their assistive technologies. For example, a screen reader can announce "checked" when the user navigates to this form field, or it can also display a symbol for Braille users.

Time-based media

WCAG discussed time-based media under guideline 1.2. What's important at this point is to ensure that all posted media has an associated description which contains the media's functionality.

For example if a video of a conference presentation is posted on a web site, assign text to the video which clearly states what the video is. When the user decides to view the video, you will have to provide alternative information based on guideline 1.2.

Test

In certain cases, tests have to be based on non-textual information. When this information is presented in a textual format, the test itself becomes meaningful.

An example would be a test for children where they are presented with a picture and they have to determine what is on that picture. In this instance, if the picture contained a textual equivalent, it would say "house" which would right away make the test question useless.

However, this picture still should contain some textual reference, in our example, the test question could be assigned to the picture.

Sensory

There are instances when the non-textual content is there to create a sensory experience. For example, the finalists of a photo contest have their pictures displayed on a web site. Maybe all pictures contain the same scenario, only the technique is different. It is not possible to select the single best one of the pictures just based on a description, the sensory experience is necessary.

However, in this instance, textual information should still be available to users describing the purpose of posting these pictures.

CAPTCHA

CAPTCHA is a technology used to eliminate unwanted and automated information submission. You have most likely seen forms where, before submitting your data, you have to type characters from an image in order to ensure that you are a human and not a machine. This solution is not accessible for people with visual impairment by default.

There are some alternatives you could use to ensure only humans interact with your site, while making it accessible to most people. One of the most common solutions is to provide a sound alternative, so instead of the verification image, users can request an audio recording of a series of characters which they can type in. This, however, is still not accessible to deaf blind people, or hardly accessible to people with cognitive disabilities.

Another very common solution is to provide a math challenge. Ask the users to add two one digit numbers and type the result into the edit field. As long as you provide this challenge in a textual environment, most users should be able to complete it.

When using human verification, you can also get very creative. For example, place a check box on the form which is checked and tell the users to uncheck it if they are a human.

It is also possible to provide different types of challenges and allow the user to choose.

If none of the above techniques would work in your situation, you can also provide live support for people with disabilities to submit information over the phone or email.

Decoration, formatting, invisible

We have already discussed decorative visual elements.

Formatting is an exception as well. It is not necessary to describe how a page looks, even though it is non-textual information, or to describe the font size of a letter. However, this information should be programmatically available to assistive technologies. For example, the font size can only be determined if it is typed text. When you post an image with text the font size is not exposed.

Also, you may wish to hide non-textual elements for the time being, which you don't have to describe, as well.


  • Previous: Principle 1: Perceivable
  • Next: 1.2: Time-based Media
Bookmark/Search this post with:
  • Delicious
  • Digg
  • StumbleUpon
  • Facebook
  • Google
  • Yahoo
  • Technorati

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

This blog uses CommentLuv plugin which will try and parse your sites feed and display a link to your last post, please be patient while it tries to find it for you
CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.

Accessibility Tips and Tricks


RSS

  • Articles
  • Blog
  • Developers' Corner
  • News
  • Press

Follow us on Twitter, YouTube, or on Facebook

 

Privacy Policy

Copyright 2007-2011 - Even Grounds Inc., Accessibility Consulting