2.1.4: Character Key Shortcuts

Success Criterion 2.1.4 Character Key Shortcuts (Level A): If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

  • Turn off

    A mechanism is available to turn the shortcut off;

  • Remap

    A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);

  • Active only on focus

    The keyboard shortcut for a user interface component is only active when that component has focus.

 

 

 

 

 

Description

 

Some applications may have character key shortcut keys to trigger actions and this character key shortcuts help keyboard users in using the application efficiently and effectively. Before we understand how the character key shortcuts are used by different users, it is important to know what is this character key shortcuts all about

Character key shortcuts are nothing, but actions get performed/triggered as soon as user presses characters on the keyboard, and this characters include letters(upper-case and lower-case), punctuations, numbers or symbols. Let me explain you this with an example. As you all know, there is popular web Gmail application to check our emails. Gmail has provided character key shortcuts for the users to perform certain actions quickly. When user presses character “Y” in the Gmail web, for the instance, email is going to be archived. Similarly, when user presses “M”, for the instance, mails are going to be muted.

 

Problems/challenges

 

although this character key shortcuts are very helpful for the keyboard users in accessing the things quickly, it creates problems for the speech input users and low dexterity users. Let us understand how this character key shortcuts are going to create problems for those users.

As you may be aware of, speech input users use speech recognition software such as dragon to access the computers/web. While dictating the text at the text field by speech user when character key shortcuts are present then it is going to pick the character key shortcuts instead of the text is being typed at the text field. This behavior creates problem to speech input users and as a result, speech input users cannot use the application properly. On other hand, there are some keyboard users(such as users with low dexterity, users with tremors, and so on.) who are prone to hit the keys accidently. When they do so, character key shortcuts get enabled unexpectedly. This behavior ends up with frustrating experience for such users. In a nutshell, character key shortcuts create challenges/problems for the speech input users and some keyboard users(such as users with low dexterity, users with tremors, and so on.)

 

 

Solution

WCAG 2.1 introduces character key shortcuts checkpoint to address the challenges with character key shortcuts that people with disabilities face. When author follows the guidance that is provided in this checkpoint then the challenges with character key shortcuts are going to be resolved. Let us look into what guidance this checkpoint is providing

 

  1. Turnoff: users should be able to turn off/disable the character key shortcuts, so that It helps both speech input users and low dexterity users to access the applications without any difficulties
  2. Remap: users should be able to remap the shortcuts with one or more modifier keys(such as alt, shift, control, and so on…), so that It helps both speech input users and low dexterity users to access the applications without any difficulties
  3. Active only on focus: users should be able to use the character key shortcuts only when that UI component(such as listbox, dropdown, and so on…) is in focus, so that it does not create a problem for any user

 

When author follows any one of above 3 points then challenges with the character key shortcuts that I mentioned in the problem section of this blog post are going to be addressed. In a nutshell, both speech input users and low dexterity users would not face any challenges when one of above 3 points is met.

 

 

 

Exceptions

This checkpoint is not applicable for the UI components such as listboxes and drop-downs. the reason is that, even though character key shortcuts are present for those UI components, those character key shortcuts work only when the UI components are in the focus. Therefore, this checkpoint does not affect such UI components.

 

Complimentary info on 2.1.4: character key shortcuts

When users have the provision to remap the character key shortcuts then it is going to help cognitive disability users too. Remapping the character key shortcuts with user’s familiar keyboard short cuts helps the users to use the same keyboard shortcut keys across various applications and thereby, it reduces the cognitive load.

 

 

References

 

 

 

2.5.1:Pointer Gestures

Success Criterion 2.5.1 Pointer Gestures (Level A): All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

 

 

 

Description

 

Problems/challenges

With the advent of smart or touch phones/devices, most of us started using the web on the mobiles. While accessing the web on mobile devices, it is quite common that users need to use certain gestures to complete the task. If those gestures are simpler then all the users including people with disabilities can use those gestures without much difficulties. However, there might be complex gestures as well to do certain tasks on the web. It may be true that people without disabilities would not have any problem in accessing those complex gestures, but A user may find it difficult or impossible to accomplish these if they have impaired fine motor control, or if they use a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulation. The examples of such complex gestures are pinch to zoom, split tap(where we hold one finger and tap with other finger), 2 or 3 finger tap, 2 or 3 finger scroll, and so on.. the examples that I provided as part of complex gestures are called as multipoint gestures. Multipoint gestures are nothing, but it requires more than one touch point to activate the functionality. Since multipoint gesture require more than one touch point to activate the functionality, it is kind of problem for the people who have low dexterity/people who use  a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulation in accessing the same. In addition, remembering such multipoint gestures increases cognitive load and thereby it creates problem for the people with cognitive disabilities too.

Apart from multipoint gestures, sometimes, users need to follow specific/particular path to complete certain tasks, and these gestures are called as path-based gestures. The example for such path-based gesture is swiping. When user swipes from left to right and vice-versa on the content slider  then it displays next/previous slide correspondingly. Since path-based gestures require users to follow particular path, it is kind of problem again for the people who have low dexterity in accessing the same.

 

Solution

WCAG 2.1 introduced the new checkpoint called “2.5.1:pointer gestures” to address the problems with multipoint and path-based gestures for people who have low dexterity. This success Criterion states that functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture. To satisfy this success criterion, authors need to provide an alternative mechanism for the people with motor disabilities to access those path-based and multipoint gestures. The alternative is to provide single pointer. Single pointer is nothing, but pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures. Let me explain with few examples how the single pointer is an alternative for multipoint and path-based gestures.

  1. There is map on the web. To zoom the map, user may have to pinch with 2 finger(multipoint gesture). The + and – buttons can be added on the map as alternative for the users who cannot perform such gestures
  2. There is photo gallery on the web. Users may have to swipe(path-based gesture) to display next/previous photos. The right and left arrow icons can be added on the gallery as an alternative for the users who cannot perform such gestures

 

 

Basically, providing single pointer as an alternative for the multipoint and path-based gestures enables all the users including people with disabilities in accessing all the functionalities/features on the web.

 

 

 

Exceptions

  1. This checkpoint is not applicable If Those multipoint and path-based gestures are essential to the content. For an example, signature requires path-based gesture, and it is sometimes essential
  2. This checkpoint is applicable for only author supplied gestures but not user agent, operating system, assistive technology gestures

 

 

Complimentary info on 2.5.1: pointer gestures

The end points that follow particular path considers to be path-based gesture in this success criterion. However, the end points that do not follow particular path(random path) considers to be free-form gesture and this is not considered as path-based gesture. The example of free-form is drag and drop. Although free-form gestures do need single-pointer gestures as an alternative, this seems to be difficult for the author to implement. Therefore, free-form gestures are not covered as part of this success criterion

 

 

References

Understanding success criterion 2.5.1:Pointer Gestures

 

 

 

1.4.10:Reflow

Success Criterion 1.4.10 Reflow (Level AA): Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

  • Vertical scrolling content at a width equivalent to 320 CSS pixels;
  • Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Except for parts of the content which require two-dimensional layout for usage or meaning.

 

 

Description

As you may be aware of, certain group of low vision users use browser zoom functionality to see the web content. However, this sometimes might be difficult to view the content by scrolling in both horizontal and vertical directions. To put it simpler, it takes lot of time and effort to read the web content by scrolling into both the directions. This is kind of problem.

WCAG 2.1 introduced the new checkpoint called “1.4.10: reflow” to address such problems for the low vision users. This success criterion requires Content to be presented without loss of information or functionality, and without requiring scrolling in two dimensions when the content is zoomed up to 400%. When authors follow this success criterion then entire web content reflows in one single column  without horizontal scrolling at 400% zoom. This enables low vision users to read the web content smoothly without horizontal scrolling.

Another important point to remember is that reflow should happen only at 400% zoom of screen resolution 1280px by 1024px but reflow need not to happen at 400% zoom of any screen resolution. This means that 400% zoom at screen resolution of 1280px(width) by 1024px(height) is nothing but 320px(width) by 256px(height). To put the things simpler, authors need to make sure that content should reflow either at 320px by 256px screen resolution or at 400
% zoom of 1280px by 1024px screen resolution. Basically, if your site is responsive then this checkpoint is almost going to be satisfied

 

Exceptions

This checkpoint is not applicable for the content that requires 2-dimensional scrolling. The reason is that such content will not deserve the meaning if it reflows in one direction. Examples of such content are data tables, videos, graphs, and so on.

 

 

Complimentary info on 1.4.10: reflow

The success criterion applies to both horizontally and vertically written languages. When 400% zoom is done on the horizontally written language content that scrolls vertically(ex: English)then it should not have horizontal scrolling. Similarly, when 400% zoom is done on the vertically written language content that scrolls horizontally then it should not have vertical scrolling. For the content that is horizontally written languages, the content should reflow vertically at 320px(width). For the content that is vertically written languages, the content should reflow horizontally at 256px(height).

It is often misunderstood that 1.4.4-resize text and 1.4.10-reflow are kind of similar, but both are different concepts. 1.4.4-resize text talks about all the content and functionality should be available at 200% zoom whereas 1.4.10-reflow talks about the all the content and functionality should be available at 400% without horizontal scrolling.

 

 

 

References

 

 

 

 

 

1.4.13-content on hover or focus

Success Criterion 1.4.13 Content on Hover or Focus (Level AA): Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

Dismissible

A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;

Hoverable

If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;

Persistent

The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

 

Description

While browsing the web, we quiet commonly see the tooltips. These tooltips typically appear when we hover or focus on the elements. Authors use these tooltips to provide more information about the trigger/target. Tooltip content could be submenus, non-modal, help text, so on… Users without disabilities neither have any concern accessing the tooltip content nor have disruptions with the tooltip content. However, users with disabilities might have disruptions with the tooltip content as well as problems/challenges in accessing tooltip content itself. tooltips, in general, impose lot of challenges to people with disabilities and let us look into them in-detail.

Problems/challenges with the tooltips

 

  1. You might know that certain group of low vision users use screen magnifier to view the web content. When these users magnify the web content, only less portion of the web content is visible in the view port. To access the complete web content, users of magnifier need to keep on pan the screen by using pointer and view the content in the restricted area. Imagine if entire portion of the restricted view port triggers additional content/tooltip then it is difficult or impossible for the users to pan the screen without retriggering additional content, and this is going to create a very big problem for such users.
  2. You might know that certain group of low vision users use keyboard. While accessing the web, low vision users who use keyboard may encounter the unexpected tooltips when they focus on the certain elements. This unexpected behavior may create a problem for the low vision users in accessing the obscured content.
  3. You might know that certain group of low vision users use large cursors. When those users use large cursor then large cursor may overlap the additional content/tooltip that is displayed on hovering the trigger/target. To view the additional content/tooltip content in such scenarios, users of low vision might have to move the pointer from trigger/target to the additional content/tooltip content. While doing so, tooltip content sometimes may get disappeared altogether, and this makes difficult or impossible for the low vision users to access the tooltip In addition, magnifier users might also need to move their mouse pointer to tooltip content to view/access the tooltip content properly. It is impossible or difficult for such users to view/access the tooltip content if the tooltip content gets disappeared as soon as pointer off from the trigger/target.
  4. You might know that certain group of cognitive disabilities take longer time to perceive the content. While they are perceiving the tooltip content, tooltips sometimes get disappeared automatically. When tooltips disappear automatically after a while then it is going to be difficult for such users to perceive the tooltip content.

 

Solution

WCAG 2.1 introduces content on hover or focus checkpoint to address the tooltip challenges that people with disabilities face. When author follows the guidance that is provided in this checkpoint then most of the tooltip challenges are going to be resolved. Let us look into what guidance this checkpoint is providing

  1. Dismissible: tooltip content should be dismissed when user presses escape key in the keyboard unless tooltip content does not obscure any content or tooltip content displays on the white/decorative background. This condition helps to resolve the problem 1 and 2 that are mentioned in the problem section of this blog post.
  2. Hoverable: user should be able to hover the tooltip content when pointer is moved from trigger/target to the tooltip content. Basically, the tooltip content should not be disappeared as soon as pointer of from the target. This condition helps to resolve the problem 3 that is mentioned in the problem section of this blog post.
  3. Persistent: tooltip content should remain on the screen unless user dismisses it or user navigates away from both trigger and tooltip content or the instance itself is invalid. Basically, tooltip content should not be disappeared after a while. This condition helps to resolve the problem 4 that is mentioned in the problem section of this blog post.

 

 

 

When author follows these 3 conditions then most of the tooltip challenges that I mentioned in the problem section of this blog post are going to be addressed. In a nutshell, people with low vision and people with cognitive disabilities would not face most of the tooltip challenges when the conditions of this checkpoint are met.

 

 

 

 

 

 

exceptions

This checkpoint is applicable only for the author supplied tooltips but not user agent based tooltips. To give an example, tooltips that are displayed with the HTML title attribute are an exception to this checkpoint.

 

 

References

 

 

 

 

2.5.3: label in name-New SC in the WCAG 2.1

Success Criterion 2.5.3 Label in Name (Level A): For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

A best practice is to have the text of the label at the start of the name

 

Description

 

There are certain group of people with disabilities, especially who are having learning and physical challenges, use speech recognition software like dragon naturally speaking to access the computers. Let us understand what speech recognition software is all about. Speech recognition software converts speech to text as opposed to the screen readers. Those users of speech recognition software access the computers with the speech input and there are voice commands to perform the regular activities on the computer like opening MS word document, , opening files/folder, sending the email, browsing the web and so on.. now that we understand that how those users of speech recognition software access the computers. On the similar lines, when user is trying to activate the send button by using voice commands after composing the email, for the instance, send button does not get activated in spite of the multiple attempts. The reason could be that, even though there is a visible text as send for the user interface control but the control may not have same text as an accessible name in the accessibility tree rather control has the submit as an accessible name in the accessible tree. As visible name of the control is send and accessible name of the control is submit, speech recognition software never understand and never activate this control  when user is trying to activate send button with the speech input. This creates problem and intern it impacts the ability to use the control itself for those users of speech recognition software.

In order to address this problem, WCAG 2.1 introduce this new SC. The intent of this Success Criterion (SC) is to help ensure that people with disabilities who rely on visual labels can also use those labels programmatically. In other words, the accessible name of the control must contain the text that is visible on the control but It does not mean that accessible name of the control need not to be identical with the visible label of the control. In addition, when the accessible name is different from visible label of the control then it is high chance that speech input users may accidently activate the hidden commands. As a result, speech input users get confused and disoriented with the unexpected actions. Text to speech(screen reader) users get best experience when accessible name of the control is matched with the visible name of the control.

Pass scenarios

  • Accessible name of the control matches visible label of the control
  • the words of the visible label in the accessible name are not scattered and are in the same order as they are in the visible label

 

References

 

1.4.12: Text Spacing-New SC in the WCAG 2.1

Success Criterion 1.4.12 Text Spacing (Level AA): In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

 

Description

There are certain group                 of low vision users, especially people who are suffering from Age-related Macular Degeneration, read the content on the web by customizing the original view. What does it mean? Let us understand this. Few low vision users feel very difficult to read the content on the web in it’s default view.  The reason is that block of text seems to be cluttered due to the small spacing for the low vision users and this makes it hard to read. To overcome this challenge, those low vision users use the stylesheets/extensions/bookmarklets  to make the same block of the text readable. You might be wondering what exactly these tools do. These tools enable the low vision user to adjust the spacing between characters/words/lines/paragraphs on the web and that intern helps the user’s readability. So far all is good and we understand that there are tools/assistive technologies that enables the low vision user to adjust the text spacing. However, when they try to adjust the text spacing via these tools then what if the text is cut off vertically, text is cut of horizontally, text is overlapped, and text is fixed. When we encounter such problems while using those tools then it is going to be problem for the low vision users to read the content on the web.

In order to address this problem, WCAG2.1 introduced this new success criterion. The intent of this Success Criterion (SC) is to ensure that people can override text spacing to improve their reading experience. Having said that, do you think user can adjust/override the text spacing to any extent. Answer is no. the success criterion clearly specifies that distances between paragraphs, lines, words and characters must be able to be increased to certain values without leading to loss of functionality or readability. The below are the specifications for the same.

  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.

 

author responsibility

This SC does not dictate that authors must set all their content to the specified metrics. Rather, it specifies that an author’s content has the ability to be set to those metrics without loss of content or functionality. The author requirement is two-fold:

  • to not interfere with a user’s ability to override the author settings, and
  • to ensure that content modified to Success Criterion 1.4.12’s metrics does not break content.

 

Benefits

  • People with low vision who require increased space between lines, words, and letters are able to read text.
  • People with dyslexia may increase space between lines, words, and letters to increase reading speed.
  • Although not required by this SC, white space between blocks of text can help people with cognitive disabilities discern sections and call out boxes. To put it more simpler, Many people with cognitive disabilities have trouble tracking lines of text when a block of text is single spaced. Providing spacing between 1.5 to 2 allows them to start a new line more easily once they have finished the previous one.

 

Pass scenarios

The below are the few scenarios where this success criterion is met

  • Spacing can be adjusted to the SC’s metrics
  • Text is not cut off in the both directions(horizontally and vertically)
  • Text is not overlapped
  • Plugin technologies that have a built-in ability to modify styles to the specified metrics.

Not applicable/exceptional  scenarios

This SC does not applicable for the below scenarios

  • PDF files as it is not implemented using markup
  • Video captions in the video player
  • Images of text that is built with canvas technology
  • There are cases where a text style property is not used in a language or script(e.g. applying word spacing for Japanese language would not have any effect as the language does not have words itself.

How to test this SC

Follow the below step by step instructions to test this SC

  1. Click Text Adaptation Bookmarklet – Steve Faulkner
  2. add the bookmarklet to the browser by following simple instructions that are given in the same link
  3. once the bookmarklet is added, open any web page
  4. navigate to browser bookmarks and activate “text spacing” bookmarklet
  5. the same web page displays with the SC metrics text spacing and check if the text is readable
  6. that is all you are done!

Techniques

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

 

References

 

 

4.1.3: Status Messages-New SC in the WCAG 2.1

Success Criterion 4.1.3 Status Messages (Level AA): In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Description

As you may aware of, people with visually challenged use the screen reader software to browse the website or access the information on the web. While browsing the website, it is natural thing for anyone to perform some actions like submitting the form, adding items to the cart,  and so on..) in order to get the information that he/she is looking for.  when an action is performed then updates or changes(popping the error messages, success messages after adding the item to the cart, and so on..)  may take place then and there without page refresh on the few websites. Those updates are obvious for the visual users but the same updates may not be obvious to the screen reader users. When screen reader users are not aware of these updates/changes then they do not get the same experience like how the sighted person experiences while browsing the information. As a result, screen reader users may not understand what is going on the page and might end up with the confusion/frustration

In order to address these type of situations, WCAG2.1 introduced this new checkpoint. The intent of this Success Criterion is to make users aware of important changes in content that are not given focus, and to do so in a way that doesn’t unnecessarily interrupt their work. Having said that, do you think all the changes that takes place in the dynamic website deal this success criterion? Answer is no. The scope of this Success Criterion is specific to changes in content that involve status messages. You might be wondering what status message is about. Status message has specific definition in the WCAG. There are two main criteria that determine whether something meets the definition of a status message:

  1. the message “provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors;”
  2. the message is not delivered via a change in context.

 

The changes to the content need not to be always addition of new text to the screen and may be in the other formats too(like non-displayed text specific to assistive technology users and non-text content. As long as the changes to the content meet above conditions, it fits within this success criterion.

Benefits

  • new content is announced to the screen reader users When appropriate roles or properties are assigned to status messages, in such a way as to assist blind and low vision users.
  • Assigning proper roles or properties to status messages provides possible future uses and personalization opportunities to assistive technologies for users with cognitive disabilities. assistive technologies for users with cognitive disabilities may achieve an alternative means of indicating (or even delaying or supressing) status messages, as preferred by the user

Pass scenarios

The below are the few scenarios where this success criterion is met

  • after recipient email address is selected from the suggested list in the email application, recipient email address is added on the screen. The screen reader announces as suman damera added. It is important to understand that the text “added” may not be visible on the screen but screen reader announces as suman damera added. In order to give the context to the screen reader users, the extra piece of information is necessary in the form of non-displayed content
  • after recipient email address is removed from the list of selected recipients in the email application, recipient email address is removed from the screen. The screen reader announces as suman damera removed. It is important to understand that the text ‘removed” may not be visible on the screen but screen reader announces as suman damera removed. In order to give the context to the screen reader users, the extra piece of information is necessary in the form of non-displayed content
  • while entering the password at the password text area in the few signup forms, there is a visual indication how strong the password is. . screen reader announces weak/weaker/strong
  • after the incorrect form submission, there is a message on the screen like 5 errors are found. screen reader announces as “5 errors are found”
  • after the successful form submission, there is message on the screen like your form has been successfully submitted, will contact you soon. screen reader announces the same.
  • after adding the items to shopping cart by using add to cart button of the product in the eCommerce websites, cart count gets updated visually like 0 to 1, 1 to 2, and so on.. screen reader announces as “item has been added to the cart and currently cart has 2 items”

 

Not applicable/exceptional  scenarios

The following scenarios identify situations where no additional author action is necessary. All cases are excepted from this Success Criterion since they do not meet the definition of “status messages.”

  • When an error message is displayed in the dialog then authors need to place the focus on the dialog. By doing so, screen reader announces the error message. In addition, this is not a change of content and it is change of context. Thus, this scenario does not fit into current success criterion.
  • When there is an expand/collapse element(such as menu, select, accordion, tree, ) and screen reader announces the state of the element(expand/collapse) appropriately then user understands whether content is revealed or hidden with the help of state itself. Thus, this scenario does not fit into current success criterion
  • When there is tablist widget and screen reader announces the selected state of the tab item appropriately then user understands whether content is revealed or hidden with the help of state itself. Thus, this scenario does not fit into current success criterion

 

 

Techniques

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

References

 

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.