1.3.4: Orientation -New SC in the WCAG 2.1

Success Criterion 1.3.4 Orientation (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.
Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where binary display orientation is not applicable.

 

Description

There are some users, especially people with cerebral palsy who uses wheel chair, keep their phone/tab in the fixed orientation(either portrait or landscape). In other words, phone/tab is mounted on their wheel chairs and cannot be rotated very easily. What if website is designed in such a way that it needs to be viewed only in the particular orientation and user is expected to rotate their device to match the requirement. In that case, website is going to become unusable for those users and it is a problem.

WCAG 2.1 introduced a new checkpoint/success criteria  called “1.3.4: Orientation” to address this type of problems.  This success criterion requires the content to be displayed in both orientations(portrait and landscape). In a simple words, websites and applications need to support both orientations by not restricting the orientation. Changes in content or functionality due to the size of display are not covered by this criteria which is focused on restrictions of orientation.

Pass scenarios

Let us look into the few scenarios where it meets this success criteria.

  • Online video site: A video is shown in either portrait or in landscape based on the user’s chosen orientation.
  • Messaging website: A messaging website can display messages in both portrait and landscape orientations.
  • eReader web app: An eReader web app can display the contents of a book in both portrait and landscape orientation.

 

In all the above cases, the content is displayed in the both orientations and therefore, it satisfies this success criterion.

Exception scenarios

There are exceptions to this success criterion. If the specific display orientation is essential then it is not required to meet this success criteria. Let us look into the few examples where the specific orientation is essential

  • Check deposit in banking app: An example where orientation is essential could be a banking app that requires the device be in landscape mode to easily and accurately capture an image of a check for deposit. These paper forms are typically about twice as wide as they are high.
  • Piano app: An example where orientation is essential could be a piano app that requires the device to be in landscape mode to allow room for enough of the piano keys to be functionally usable. Since a piano app is emulating a physical piano keyboard that needs to retain relative physical characteristics between keys, either too few keys would be available, or the keys would be much too narrow.

 

In the above cases, it Is not necessary to meet this success criterion as specific orientation is essential. In other words, if screen orientation is changed for the above cases then purpose is going to be lost.

Optional notes on the device level orientation and system level orientation

Device level orientation and system level orientation are not one and the same. Device level orientation generally refers to the actual rotation of the device either from the landscape to portrait or portrait to landscape but not the content as a whole. What does it mean? Let me put it in the simple way. While viewing the website in the portrait on your device, we might want to view it to the landscape for the different reason. What we do is that we rotate the actual device from the portrait to landscape in order to view in the landscape orientation. When we do so, do you think website is also going to be changed as per the device landscape orientation. Answer is no. the reason is that we are just rotating the device but not the content as a whole. Ok, then whose responsibility is to change the content as per the device orientation. Answer is the system level orientation.

Even though the content Is not restricted to particular orientation, there are certain scenarios where the content would not reflow as per the device display orientation. When does that happen? It happens when the device is locked at particular orientation. The content would not re-flow how much ever we turn the device when the device is locked. To put it in the simpler, when we rotate the device with the device orientation locked then device is going to be turned but the content does not re-flow as per the device orientation despite of the content is not being restricted by the author. It is important to distinguish between an author’s responsibility not to restrict content to a specific orientation, and device-specific settings governing the locking of display orientation.

Many hand-held devices offer a mechanical switch or a system setting (or both) to allow the user to lock the device display to a specific orientation. Where a user decides to lock their entire device to an orientation, all applications are expected to pick up that setting and to display content accordingly.

This Success Criterion complements device “lock orientation” settings. A web page that does not restrict its display orientation will always support the system-level orientation setting, since the system setting is picked up by the user agent. Alternatively, where a device-level orientation lock is not in place, the user agent should display the page according to the orientation of the device (either its default, or the current orientation determined by any device sensors).

 

Benefits

  • Users with dexterity impairments, who have a mounted device will be able to use the content in their fixed orientation.
  • Users with low-vision will be able to view content in the orientation that works best for them, for example to increase the text size by viewing content in landscape.

Techniques

Here are the few techniques that author can use to meet this success criterion

  • Using CSS to set the orientation to allow both landscape and portrait.
  • Use of show/hide controls to allow access to content in different orientations.

·        References

WCAG2.1 overview

Web content accessibility guidelines(WCAG)2.1 has become W3C recommendation just a couple of days ago and it is on 5 June 2018. I think this should be most memorable day for all of us. In fact, we need to celebrate this day as we have got additional guidelines almost after 10 and half years. Yes, WCAG2.0 evolved on 11 December 2008 as W3C recommendation. With the introduction of WCAG2.1, let us hope that web is going to be much more accessible than ever before. now it is the time to explore this topic.

What’s new in WCAG 2.1

The important information that we need to understand is that all success criteria from 2.0 are included in 2.1. The 2.0 success criteria are exactly the same (verbatim, word-for-word) in 2.1. WCAG 2.1 provides 17 additional success criteria and out of 17  success criteria, 5 of them are levelA, 7 of them are levelAA, and 5 of them are levelAAA. All these success criteria addresses:

  • mobile accessibility
  • people with low vision
  • people with cognitive and learning disabilities

For users of mobile devices, WCAG 2.1 provides updated guidance including support for user interactions using touch, handling more complex gestures, and for avoiding unintended activation of an interface. For users with low vision, WCAG 2.1 extends contrast requirements to graphics, and introduces new requirements for text and layout customization to support better visual perception of web content and controls. For users with cognitive, language, and learning disabilities, WCAG 2.1 improvements include a requirement to provide information about the specific purpose of input controls, as well as additional requirements to support timeouts due to inactivity. This can help many users better understand web content and how to successfully interact with it.

As with WCAG 2.0, following these guidelines will continue to make content more accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and learning disabilities and cognitive limitations. Following these guidelines can also make websites more usable for all users.

All the names of the new guidelines are listed below as we are going to discuss each one of them as deep as possible in the coming blog posts.

 

  • 1.3.4 Orientation (Level AA)
  • 1.3.5 Identify Input Purpose (AA)
  • 1.3.6 Identify Purpose (AAA)
  • 1.4.10 Reflow (AA)
  • 1.4.11 Non-Text Contrast (AA)
  • 1.4.12 Text Spacing (AA)
  • 1.4.13 Content on Hover or Focus (AA)
  • 2.1.4 Character Key Shortcuts (A)
  • 2.2.6 Timeouts (AAA)
  • 2.3.3 Animation from Interactions (AAA)
  • 2.5.1 Pointer Gestures (A)
  • 2.5.2 Pointer Cancellation (A)
  • 2.5.3 Label in Name (A)
  • 2.5.4 Motion Actuation (A)
  • 2.5.5 Target Size (AAA)
  • 2.5.6 Concurrent Input Mechanisms (AAA)
  • 4.1.3 Status Messages (AA)

References

3Ws(WWW) of accessibility

You might be wondering what is 3ws(WWW) of accessibility. Surely, it does not stand for world wide website and it stands for:

 

  • First w-what is accessibility
  • Middle w-why accessibility is important
  • Last W-when to implement accessibility

What

Accessibility is nothing but providing equal opportunity or equal access on the digital content for all the users including people with disabilities. If your site is accessible, people with disabilities can perceive, operate, navigate and understand the content like anybody else.

 

Why

you would agree with me that today web is playing vital role in our day to day activities.

Simple examples:

 

  • If I want to do online shopping then I will open amazon website and place the order
  • If I want to transfer money to my friend then I will open banking website and do the transaction
  • If I want to have some food then I will open food website and place my favorite food
  • More importantly, if I want to learn something then I will open relevant website and will do the study on the web itself.

These are very simple activities. We can do much more activities on the web in the day to day life. imagine these sites are not accessible, people with disabilities are excluded on your website. It is essential that the Web be accessible in order to provide equal access and equal opportunity to people with disabilities. Moreover, nearly, 20% of the population suffers from one or other disorder. To tap or to reach this population, one should make their web accessible. Making sites accessible results in maximizing the profits of the organization too.

 

When

Some organizations might think that accessibility is an extra thing and would want to do at the end. If you think so, accessibility(it) becomes expensive and time consuming. Accessibility should be embedded during development process itself but not at the end. This would save your time, money, and effort. even modern technologies like react, angular, view supports in incorporating the accessibility during the development itself.