1.3 Adaptable (Level AA and AAA)

WCAG 2.1 added two new Level AA and one new Level AAA Success Criteria for Guideline 1.3.

Orientation Explained

When WCAG 2.0 was introduced in 2008, the first iPhone had only just been released. At that time there was no real consideration regarding device orientation because, typically, there was no need. Today, however, mobile devices have become as prevalent as computer screens, and orientation is a key characteristic of such devices. Even computer monitors these days typically have an orientation setting that allow a monitor to be turned to a vertical orientation.

It is common for people to mount a mobile device on their wheelchair arm, for instance. Depending on preference, the device may be positioned in either a portrait or landscape orientation. If web content is limited to a particular orientation, it can make content difficult to access effectively in cases like this.

There are occasions where orientation has to be limited to landscape or to portrait, but in general, such a limitation should be avoided.

Some examples where orientation may be restricted could include:

• A piano app, which would need to be in a landscape orientation in order for the piano keys to be wide enough to touch individually with a finger
• A cheque deposit function in a banking app, where landscape orientation would be required

Identify Input Purpose Explained

For people with cognitive disabilities, low vision, or some types of learning disabilities, it can be difficult to determine the purpose of a form field or the correct format for the data being entered. This success criteria indicates that browsers and assistive technologies must be able to determine the expected input.

While browsers have been able to do this for some time, it’s only recently that browsers have used their own strategies to automatically fill (autofill) forms with predefined data using technology-specific algorithms. For instance, Firefox will remember values entered into a field named “name” or “telephone.” So, the next time a field with the same name is encountered, it will offer up the values that were previously entered into a field with the same name. While this does provide some indication of the expected input, they are general and not exact. That is, “name” could refer to first or last name; “telephone” could include a country code, area code, and extension, and so on.

In HTML 5.2, the “autocomplete” attribute was added to help developers meet this requirement in WCAG 2.1. It can be used to provide specific descriptions about the purpose for form fields. For the name example, one could add autocomplete="given-name" and autocomplete="family-name" to make it clearer what name is expected for respective form fields. If these values have been previously saved, they would be offered to the user to choose from, so they are not required to type their name.

There is fairly good support for the autocomplete attribute across current browsers. Form developers are encouraged to use it to make it easier for people with disabilities to fill out forms. Consequently, it makes filling out forms more efficient for everyone, including frequent online shoppers, for example. For more about “autocomplete” see the suggested readings below.

Identify Purpose Explained

In addition to roles associated with various user interface elements that identify what an element is (e.g., role="link" for a link), this success criteria adds a purpose to that role (e.g., a link to the site’s home page).

These “purposes” are defined by the W3C’s Cognitive and Learning Disabilities Accessibility Task Force (COGA). It will likely be introduced with the next version of WAI-ARIA, which will provide standard ways to define purpose that will help make content on the Web easier to understand, particularly for those with cognitive disabilities.

For example, icons may be used to provide a visual representation of an element. The home link, for instance, might include a house icon, along with the word “home” to represent the link. Those who are then unable to read the word can make use of the visual representation. Being defined in a standard way (e.g., aria-function="home-link"), technology will be able to read (i.e., programmatically determine) these “purpose” attributes, making it possible for users to replace the icons with their own, perhaps using an arrow icon to represent home, for instance, which may be more meaningful to a particular person than a house icon.

Though standardizing how purpose will be identified is still a work in progress, there are already WAI-ARIA landmark roles that function to define the purpose of regions on a web page (e.g., banner, navigation, main, or complementary). This then makes it possible for technology to identify those regions. A user can potentially hide away everything except the main region on the page, which contains the primary content, so, for example, a person with an attention-related disability is not distracted by other elements on the page.

Personalization of this nature is an evolving area of research at W3C and elsewhere, which promises to optimize using the Web for each individual user in the not-too-distant future.