Tag: wcag

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

• Using aria role=”status” to provide success or other feedback
• ARIA19: using ARIA role=alert or Live Regions to Identify Errors
• Using aria role=”progressbar” to convey the progress of the process

References

• Understanding Success Criterion 4.1.3: Status Messages

 

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

• Understanding success criterion 1.3.4: orientation

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

• WCAG 2.1 IS A W3C RECOMMENDATION-W3C blog
• What’s New in WCAG 2.1-Web accessibility initiative(WAI)
• W3C Issues Improved Accessibility Guidance for Websites and Applications(press release)