EWG:Draft Oct 26 Non-text Objects

3-F - Non-text Objects

This page is the text proposed in the Nov Plenary Meeting.

Go to the Oct 26 Draft of this Provision

Go to the Sandbox of this Provision

Proposed text in Oct 26 draft:
All non-text objects that are presented to the user must have a text alternative that presents equivalent information, except for the situations listed below.

1. Controls-Input: If a non-text objects is a control or accepts user input, then it must have a name that describes its purpose. (See also User Interface Components provisions)
2. Media: If a non-text object is synchronized media, live audio-only or live video-only content, then text alternatives must identify at least the non-text object with a descriptive text label. (For synchronized media, see also Audio and/or Video provisions)
3. Test: If a non-text object is a test or exercise that must be presented in non-text format, then text alternatives must identify at least the non-text object with a descriptive text label. (For synchronized media, see also Audio and/or Video provisions)
4. Sensory: If a non-text object is primarily intended to create a specific sensory experience, then text alternatives must identify at least the non-text object with a descriptive text label. (For synchronized media, see also Audio and/or Video provisions)
5. CAPTCHA: If the purpose of a non-text object 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 object must be provided and alternative forms in different modalities must be provided to accommodate different disabilities.
6. Decoration, Formatting, Invisible Objects: If a non-text object is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented such that it can be ignored by assistive technology.

• Note: In order to achieve this provision, non text objects in data operated on by the software would need to be associated with textual equivalents that the software can obtain as readily as it can obtain the non-text object itself. Where a non-text object is a scanned image of text, textual equivalents would need to allow for the inclusion of the text of the scanned image of text. Where a non-text object is a dynamic presentation, graphs, or other derived information from a data source, textual equivalents would need to allow for the inclusion of the data used.

Rationale: Harmonization with WCAG 2.0 which provides more guidance on the text alternatives themselves. The word "objects" is used in this provision to make it clear to software developers that their user interface is to be included. If the word "content" was used they may not think this applies to their work.

Comments from ITAA
a. The second bullet says there are exceptions to the exception, and it is not clear which of the following bullets these are. The structure should make this clear.

b. Formatting of "test" is wrong.

c. Define CAPTCHA. The specification of the alternatives to the CAPTCHA should be limited to 1 – “an alternative form”