1. Perceivable

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.

Success Criterion 1.3.4 Orientation

WCAG 2.1

Level AA

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

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

Suggested Reading:

Success Criterion 1.3.5 Identify Input Purpose

WCAG 2.1

Level AA

The purpose of each input field collecting information about the user can be programmatically determined when:

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.

Try This: Update Your Autofill Settings in Chrome

  1. Open Chrome settings through the icon with the three vertical dots at the top right of the browser.
  2. Open the Advanced settings at the bottom of the settings screen.
  3. In the Passwords and Forms section of the Advanced settings, open the “Autofill Settings.”
  4. Fill in your details (at least first name, last name, and email).
  5. Visit the demo site and click into the form on the right to see how the values you entered are displayed.
Note: Depending on the version of Chrome you are using, the above settings may be accessed through different paths.

Also, try the demo site with a current version of Firefox and see what happens. You may notice some inconsistencies between the two browsers.

Suggested Reading:

Success Criterion 1.3.6 Identify Purpose

WCAG 2.1

Level AAA

In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined.

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.

Definition

WAI-ARIA: The two parts of the acronym represent “Web Accessibility Initiative,” the group at the World Wide Web Consortium (i.e., W3C) that works on accessibility specifications, and “Accessible Rich Internet Applications,” the specification introduced around the same time as HTML5. WAI-ARIA is used to add semantics for custom web elements (like a slider or popup menu) and web interactivity (like a control bar for a video player) to make them understandable by assistive technologies such as screen readers.

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.

Suggested Reading:

License

Icon for the Creative Commons Attribution-ShareAlike 4.0 International License

Introduction to Web Accessibility by Ryerson University, The Chang School is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License, except where otherwise noted.

Share This Book