passed validity tests for the version of the technology in use (whether it be conforming to a schema, Document Type Definition (DTD), or other tests described in the specification)
structural elements and attributes are used as defined in the specification
This guideline further emphasizes that following specifications increases the likelihood of accessible content. While other guidelines refer to individual pieces of content, this guideline takes a step back to look at the broad picture. It also exists to help cover future technologies or issues that we did not anticipate at the time of writing this guideline. Thus, the benefits of following specifications are primarily that assistive technologies and user agents can render the content according to spec.
Following specifications for markup and other file formats makes it possible to more easily reformat, repurpose and reuse content, which is important to users who can only make full use of content when presented in a particular format.
Example 1: structural elements.
Throughout a historical Web site, structural elements are used appropriately to indicate the presence of quotations, definitions and bibliographic references. Because these elements have (only) been used according to specification, user agents can be configured so that these elements are differentiated from the rest of the content, allowing an end user to optimize her use of the site for research purposes.
Example 2: presentation elements.
A Web author wishes to focus attention on a series of words on a page for purely artistic reasons. He uses elements designed for applying stylistic and presentation characteristics, rather than elements that are designed to convey information about the structure or organization of a page, to enhance the visual presentation and avoids implying unintended meaning about page organization for non-visual or text-only users.
Example 3: accessible APIs.
A Java applet uses the accessibility API defined by the language. Refer to the IBM Guidelines for Writing Accessible Applications Using 100% Pure Java.
Requirements (a) through (j)
If the application renders visual text, it should conform to the VisualText checkpoints.
If the application renders images, it should conform to the Image checkpoints.
If the application renders animations, it should conform to the Animation checkpoints.
If the application renders video, it should conform to the Video checkpoints.
If the application renders audio, it should conform to the Audio checkpoints.
If the application performs its own event handling, it should conform to the Events checkpoints.
If the application implements a selection mechanism, it should conform to the Selection checkpoints.
If the application implements voice or pointer input, it should conform to the Input Modality checkpoints.
accessibility conventions of the markup or programming language (API's or specific markup) are used (@@in UAAG somewhere?)
none at this time
Editorial Note: We removed the criteria, "the interface has been tested using a variety of assistive technologies and preferably real people with disabilities who use assistive technologies to determine that those assistive technologies are able to access all information on the page or hidden within the page." because it is not testable. The techniques documents (particularly gateway) should address the importance of including testing in an accessible authoring process.
When selecting required technologies, consider that assistive hardware and software is often slow to adapt to technological advances, and the availability of assistive technology varies across natural languages. Verify that assistive technology compatible with the technologies you choose is available in the natural language(s) of your content.
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
avoid the need to provide accessible alternate versions for content rendered in a technology that does not fully address these guidelines
Benefits of determining and documenting technology requirements:
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.
Benefits of ensuring user interface accessibility and providing accessible alternatives:
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.
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, finding out that 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, the 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 only supported in the most recent version of two popular user agents. 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.
An interface component created by the author that is in addition to those provided by the user agent. For example, an HTML checkbox would not be a programmatic user interface component because the author is using an interface component supported by the user agent. A checkbox function implemented in script, however, would be a programmatic user interface component because it provides functionality that is not known or supported by user agents and can not be made accessible by user agents even if the user agent complied with UAAG.