Intent of this success criterion

Authors who ensure the accessibility of user interfaces within their content will encounter fewer challenges when implementing these guidelines, avoid the need to create custom solutions and workarounds to address accessibility concerns, and avoid the need to provide accessible alternate versions for content rendered in a technology that does not fully address these guidelines.

Providing accessible user interfaces or equivalent alternatives ensures compatibility with assistive technology used by users with disabilities such as screen readers, screen magnifiers, and speech recognition software. Allowing users a keyboard method of exiting non-accessible content ensures that users with disabilities will not get trapped in content that is not perceivable or operable by them. In addition, ensuring that users can avoid flickering or flashing content that might induce seizures is a critical safety consideration even in non- conforming content.

Techniques for Addressing G4.2 L1 SC1

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 4.2 L1 SC1.

Instructions: Select the situation(s) below that match your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the option for the techniques you are using listed immediately following.

Situation A: Links to alternatives are provided within a delivery unit

Providing links to alternatives within a delivery unit when the original content is not WCAG2.0-conformant at level 1. Each link (and target content) is explicitly associated with specific original content the target content is replacing. For each such link, an explanation is given "close to" the link as to the need for the alternative content.

Situation B: Alternative delivery units are provided according to the user's preferences and needs

Providing alternative delivery units according to the user's preferences and needs when the original delivery unit is not WCAG2.0-conformant at level 1. For example, for an existing inaccessible delivery unit, a separate accessible delivery unit might be provided as a stop-gap measure until the original delivery unit is redesigned for accessibility.

Optional Techniques (Advisory) for 4.2 L1 SC1

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Additional Technology-Independent Techniques (Advisory)

Additional HTML Techniques (Advisory)

Additional CSS Techniques (Advisory)

Additional Client-Side Scripting Techniques (Advisory)

Benefits: How 4.2 L1 SC1 Helps People With Disabilities

The benefits of determining and documenting technology requirements are that individuals can identify (either through site documentation or automatically through metadata) whether or not they are likely to be able to use a site. In conjunction with a search engine or a proxy server, this could be used to automatically filter out sites a user can not access or to automatically filter to the top sites that would be most usable. Documenting technology requirements will cause authors to evaluate assumptions about user agents and will minimize the number of sites that are inadvertently inaccessible because they are unaware of backward compatibility issues. The benefits of ensuring user interface accessibility and providing accessible alternatives are that individuals who must use alternative browsing technologies and devices will be able to access the content. Individuals who can not afford or otherwise do not have access to newer technologies also benefit from backward compatibility in that they will not need to purchase upgrades or equipment as often.

Examples of 4.2 L1 SC1

Example 1: an online store that lists required technologies. By documenting minimum user agent requirements, the store makes it possible for people using particular technologies to determine whether they are going to have trouble using the store or its checkout mechanism before they begin shopping. This prevents users from finding that, after they have selected their products and initiated a checkout process, they are unable to complete their transaction. They can, therefore, choose alternatives where they can be assured greater success.
Example 2: an intranet site that transforms gracefully. A large company was concerned about the ability to address individuals at many diverse office locations that have different technology bases. To address the problem, they created two versions of their content and documented the requirements for each, making it easy for individual locations to determine which version would work best for their technologies.
Example 3: an informational site ensuring backward compatibility. An information site covers a wide variety of subjects and wants to enable their visitors to quickly find the topics they're looking for. To do this, they have implemented an interactive menu system that is To ensure that their visitors who do not use these specific user agents are still able to effectively use the site, a navigation mechanism that does not depend on the interactive menu system they are using is presented to user agents that do not support the newer technology.
Example 4: A Java applet uses the accessibility API defined by the language. Refer to the IBM Guidelines for Writing Accessible Applications Using 100% Pure Java.

Guide to Guideline 4.2 Level 1 Success Criterion 1

Key Terms and Important Concepts