AEM has been developed to maximize compliance with the Web Content Accessibility Guidelines:
The Web Content Accessibility Guidelines version 2.0 (WCAG2) are a set of internationally recognized guidelines developed by the World Wide Web Consortium (W3C) under their Web Accessibility Initiative (WAI).
WCAG 2.0 consists of a set of technology independent guidelines and success criteria to help make web content accessible to, and usable by, persons with disabilities. They provide advice to web content authors, designers and developers on ensuring that the resources they produce are as accessible as possible to as many people as possible, regardless of any disability they have; for example, visual impairment, hearing loss, learning difficulties, age related limitations, amongst others.
For example, describing an image (or any other non-text content) by using the alt
attribute in HTML greatly benefits people who are blind or partially sighted. The textual description in the alt
attribute can either be converted into speech output or transmitted to electronic refreshable braille displays.
Additionally, WCAG 2.0 can result in advatages for other beneficiaries, including people who may be considered situationally disabled. People who, because of circumstances such as browsing technology, network connection speed or browsing environment, may experience barriers similar to people with disabilities.
Using Adobe Experience Manager, content authors and/or website owners can create web content that meets relevant WCAG 2.0 Level A and Level AA success criteria.
Therefore, understanding the aims of WCAG 2.0 and how the guidelines are structured is an important part of understanding web accessibility and how the guidelines can help in creating accessible web content.
The intention of WCAG 2.0 is to provide guidelines that:
Are technology-agnostic:
In other words, guidelines that can be applied to a range of web content formats, not just HTML. So WCAG 2.0 can cover content generated by or provided in PDF, Flash, JavaScript and other current and future web technologies. This aims to address a recognized weakness of WCAG 1.0, in that it was focused on HTML at the expense of other web content formats.
Are testable:
Each guideline is written in such a way that it can be objectively tested to ensure that a group of accessibility experts would generally agree that the guideline has been met. One of the challenges of accessibility guidelines is that while some can be technically testable, others require human judgment to ascertain whether or not the guideline has been successfully met. WCAG 2.0 has been written with the aim of reducing the subjectivity that was present in some of the WCAG 1.0 guidelines and checkpoints.
Support prioritized and contextual implementation:
As with WCAG 1.0, WCAG 2.0 guidelines are given priorities, relating to the likely impact of not following a guideline on a particular group of users with disabilities. This allows authors to make an informed decision on the most important guidelines for their particular situation. In addition, the concept of accessibility supported is introduced. This allows authors to make decisions on how best to use web technologies that may not have full accessibility support, or may require users to have specific assistive technologies and/or browsers in order to benefit from accessibility features.
These aims have significantly influenced the structure of WCAG 2.0.
It is not possible to create a web site that caters for every possible disability or type of person. The purpose of WCAG 2.0 is to help web authors create sites that are, as far as possible, accessible within certain conditions and within reason.
If you are familiar with WCAG 1.0, you will notice some changes in WCAG 2.0. These relate to scope, organization and aim.
WCAG 2.0 is structured in a way that introduces concepts of accessible web content creation in a progressively detailed manner. This may give the impression that WCAG 2.0 is a very complex set of interlinked documents, but the aim is to (progressively) provide more detailed information as and when authors need it - rather than providing it all in one very large document.
WCAG 2.0 consists of four key principles for accessible design. These are:
These principles are sometimes referred to by the acronym POUR.
Each principle consists of one or more guidelines.
Each guideline consists of one or more success criteria.
True
or False
for any given web page.In addition to the core WCAG 2.0 components of Principles, Guidelines and Success Criteria, there are a series of supporting documents. Some of them provide specific advice on how to meet aspects of the guidelines, others are more general references helping web authors, designers and developers of all abilities understand and use WCAG 2.0 as effectively as possible.
While WCAG 2.0 is a stable document, and will not change, most of these supporting resources are dynamic documents; they will change and grow over time, as new technologies emerge, and new examples are found of how web accessibility can be achieved.
Techniques for WCAG 2.0 are available on the Techniques for WCAG 2.0 page.
Techniques form the level below success criteria in the WCAG 2.0 hierarchy. They are classed by WAI as informative, not normative. In other words, a specific technique does not have to be followed in order for a resource to conform with WCAG 2.0.
Because techniques are much more specific than success criteria, they usually refer to a particular technology or content type (e.g. HTML, or video), or situation (e.g. e-commerce or e-learning application). You can think of techniques as proven examples of how specific guidelines and success criteria can be met, so they are helpful aids to authors and developers working in particular contexts.
Techniques can be accessed:
Each technique has a unique number, which relates to its collection. For example, one of the ARIA techniques is Technique ARIA2: Identifying required fields with the “required” property.
Techniques may be Sufficient, Advisory, or a Failure:
Details for techniques include a description, applicability, examples, resources for further information and details of how authors can test for successful application of the technique.
The list of techniques is not complete and WAI is constantly updating the list with new examples, reflecting developments in web technology, design approaches, and research findings. So it is well worth regularly checking the list of techniques for new additions.
This refers to a series of documents, which provide advice helping readers to appreciate the purpose of specific guidelines and success criteria. You can download an introduction, plus links to more detailed information.
Each individual guideline and success criterion also has its own ‘Understanding’ page, providing information on:
Each success criterion’s individual “understanding” page provides information on:
An example can be found at: Understanding Success Criterion 1.1.1 (“Non-text content”).
The ‘How to Meet’ section is available on the How To Meet WCAG 2.0 page. This section provides an alternative presentation of WCAG, allowing refining the content of the guidelines to those most relevant to a reader’s own interests or circumstances. Readers can filter the success criteria techniques they would like to view by specifying particular web content technologies such as Cascading Style Sheets or scripting, or specifying a particular priority level(s).
Without filtering, this resource provides all success criteria grouped by guideline. For each success criterion, the following is provided: