Searchbox role

Did you see any website without search form field? Almost every website usually has this search form field. The purpose of having this search form field on the website is to search as per user need and navigate to the respective sections quickly  instead of browsing the entire website. Imagine, this search form field is not constructed with html input type search and is constructed with the custom controls then this search form control might not be accessible to assistive technology users. if this search form control cannot be constructed with html input type search for some reason then we are left with the option of using new aria1.1 searchbox role to make this custom control accessible.

Aria1.1 Searchbox role can be used for the type of textbox intended for specifying search criteria . When searchbox role is applied to container then screen readers are expected to announce as “search edit type and text” or something like that. Search role and searchbox role are different from each other and they are not identical/same. To be precise, The role=”searchbox” must be provided for focusable element whereas role=”search” is the landmark that includes focusable active elements. On the similar lines, textbox role and searchbox role are different from each other and they are not same/identical. Searchbox role is equivalent of the html <input type=”search” element.

Author notes

  • Author must set the accessible name when searchbox role is used

 

 

Code snippet

 

<div id=’test’ role=’searchbox’ contenteditable=’true’></div>

 

References

 

aria-haspopup(property)

aria-haspopup attribute was present in the aria1.0 as well but few modifications have been made to this attribute in aria1.1. Before we get into that, Let us understand what is popup content as per the specification. Popup content usually appears as a block of content that is on top of other content. It could be menu, dialog, and so on..

In aria 1.0, aria-haspopup values are limited to only true/false. But in aria 1.1, aria-haspopup has list of token values and it is enumerated type. The token values are:

  • Aria-haspopup=”false”, indicates the element does not have any popup
  • Aria-haspopup=”true”, indicates that popup is menu
  • Aria-haspopup=”menu”, indicates that popup is menu
  • Aria-haspopup=”dialog”, indicates that popup is dialog
  • Aria-haspopup=”grid”, indicates that popup is grid
  • Aria-haspopup=”listbox”, indicates that popup is listbox
  • Aria-haspopup=”tree”, indicates that popup is tree

Aria-haspopup=”true” and aria-haspopup=”menu” are one and the same and aria-popup=”true” is for to support the backward compatibility.

Notes for assistive technology vendors

  • Any other value apart from the above mentioned token values should be treated as aria-haspopup=”false”, by assistive technologies which means that element does not have popup.

Author notes

  • Author should use Aria-haspopup attribute only for keyboard focusable elements.
  • Author should not set this attribute for the element that opens tooltip as popup and tooltip are not one and the same.

Sample Code Snippets

button haspopup unspecified

if given

<div id=”test” role=”button”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role but not expected to expose aria-haspopup

button haspopup true

Note: as discussed earlier, the ARIA spec says “To provide backward compatibility with ARIA 1.0 content, user agents must treat an aria-haspopup value of true as equivalent to a value of menu.”

if given

<div role=”button” aria-haspopup=”true” id=”test”>

OK

</div>

then for the element of id test, assistive technologies are expected to  expose the button role and aria-haspopup=”menu”

button haspopup false

if given

<div id=”test” role=”button” aria-haspopup=”false”>

OK

</div>

then for the element of id test, assistive technologies  are expected to expose the button role but are not expected to expose aria-haspopup

button haspopup dialog

if given

<div id=”test” role=”button” aria-haspopup=”dialog”>

OK

</div>

 

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of the dialog.

button haspopup grid

if given

<div id=”test” role=”button” aria-haspopup=”grid”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of grid.

button haspopup listbox

if given

<div id=”test” role=”button” aria-haspopup=”listbox”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of listbox.

button haspopup menu

if given

<div id=”test” role=”button” aria-haspopup=”menu”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of menu.

button haspopup tree

if given

<div id=”test” role=”button” aria-haspopup=”tree”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of tree.

 

button haspopup suman

if given

<div id=”test” role=”button” aria-haspopup=”suman”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role but are not expected to expose aria-haspopup as the value “suman” is not the accepted token value.

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

Accessibility Tools for Native Apps

I think everybody in the planet uses mobiles in this modern era and most of them use smart phones. In the earlier days, probably some years ago, we used to have basic phones through which we can make and receive calls and to the maximum, we can view SMS. With the evolution of smart phones, we can access the any information at our fingertips. The examples could be online shopping; booking flights, tickets, reading the materials, and so on… all these things are possible through apps on the phone. Imagine these apps are not accessible; people with disabilities are excluded in accessing the apps. As a whole, the phone is unusable for the people with disabilities. Making the apps accessible is very important in order to include people with disabilities. As soon as people hear app accessibility, they wonder how they can make the mobile apps accessible. Nothing to be panic. Like web accessibility, there are 2 methods to evaluate the accessibility on the native apps. One is manual and other one is automation. In this post, let us understand what automation tools are available for the native apps in the both iPhone and android platforms. Below are the tools that I have put together that I know but it does not mean that  it is end of the list and there might be many automation tools in the market. With that note, Let us begin

iPhone

WorldSpace Attest by Deque Systems

This tool is licensed.  Attest IOS is available as library for native IOS applications, while developing the applications users can integrate the Attest library into their code and analyze the developed code at node level and also for the complete screen that is displayed, users can run the tests on simulated device or a real one. This can be achieved in three simple steps once the code is ready and opened in any IDE, generally for IOS we prefer XCODE.

  • Copy the provided license shell script into Run script section of Build Phases ->New Run Phase Script
  • Build the app to download the Attest framework ,configure the libraries and link binaries with libraries for the downloaded framework
  • Call required methods from the downloaded libraries to analyze the developed app at node level or screen level.

The results are listed in the console as json, along with it we can install a desktop application or run a http server to view them in readable html format.

This can be used to perform accessibility testing when the app is being developed. A free version available in github. When we run the automation testing on the any app by using this tool then no false positives are listed and results are accurate. This tool runs with around 18 rulesets and it is pretty good. To know more about this tool, visit WorldSpace Attest for iOS by Deque systems

 

 

 

 

Accessibility inspector by Apple

This tool helps to evaluate the app on iPhone but it requires MAC machine. Below are the step by step instructions to perform the automation testing by using accessibility inspector.

 

 

  • Install the latest Xcode in the MAC
  • Connect the MAC and iOS device
  • Navigate
    • Xcode > Open Developer Tool > Accessibility Inspector in the menu bar or Dock
    • Target chooser > select iPhone
    • Click Run Audit

 

That is all you are done, you would get the automation issues like accessible name is not provided for the buttons, zooming is not enabled and so on.. I felt that this tool is helpful! To know more about the accessibility inspector, visit Accessibility inspector by apple

 

Color contrast app by User Light Ltd

It is free app by user light and step by step instructions are provided below to perform the color contrast by using this app.

 

 

  • Take the screenshot of the screen that you would like to perform color contrast testing
  • Browse this screenshot through the app
  • Use two color pickers to select two colors (background & foreground) And see results at bottom

 

What we usually do is that we take the screenshot of native app screen and send it to our desktops. From the desktop, we use typical Color contrast analyzer

to perform the color contrast testing. This app helps avoid all these steps and we can perform the color contrast test on your mobile itself. This tool is pretty good and it is really helpful. To know more about this app, please visit Color contrast app for iOS by User light

 

Android

WorldSpace Attest by Deque Systems

This tool is licensed. Attest Mobile operates via a secure application on the developer’s mobile device that interfaces with a corresponding desktop application to provide detailed accessibility issue reporting, including advanced issue descriptions and remediation guidance from Deque University. This is available in two flavors:

  • As a service for android and a desktop client
  • As a library that can be integrated with code to analyze the app while being developed

 

  1. Testers: Mobile app and site quality assurance testing professionals can use the attest android service and desktop client to analyze an installed app. The pre-requisites include android version of 4.2 or higher, a space of 8 MB on the mobile, talk- back service should be off the desktop and mobile should be on same network. The analysis against accessibility can be done in three simple steps:
    • Install the Attest android service on the mobile through provided link of App store and enable the service
    • Install the desktop client – available for IOS and Windows, launch it and connect to the device. The desktop client can scan for all the android devices on which Attest service is installed.
    • Open the app on the connected device and click on a button in the desktop client. This runs analysis against the visible screen of the opened app and violations are listed in the desktop client in readable format.
  2. Developers: Android application developers can access the attest libraries available and integrate into the developed code. Once access to the libraries are obtained, they need to reference the required classes and call methods to run analysis against accessibility. This can be done at node level or at the complete screen level. This involves the following three simple steps:
    • Configure build.gradle file for required Attest libraries
    • Build the project so that the dependencies are downloaded for the project
    • Write a test calling the methods in the Attest library to run accessibility audit

 

This tool can be used during development of the product and also after it is installed on the mobile. When we run the automation testing on the any app by using this tool then it does not throw any false positives and it is 100% accurate. This tool runs with around 18 rulesets and it is pretty good. To know more about this tool, visit WorldSpace Attest for Android by Deque Systems or watch WorldSpace Attest-android API integration demo(video)

 

 

Google accessibility scanner

It is free service by Google and the below are the step by step instructions to perform automation testing with the help of this tool.

 

  • Download and Install this app from the play store
  • Navigate to settings>accessibility>google accessibility scanner
  • Turn on the google accessibility scanner. Once it is turned on, accessibility scanner icon pops up on the every screen of your app
  • Navigate to the app screen that you would like to perform automation testing and Tap on the accessibility scanner icon
  • That is all it shows results

 

Unfortunately, Talkback users cannot tap on the accessibility scanner very efficiently as it requires explore by touch. Once the results are displayed, talkback users can navigate the results screen and understand the issues on the screen. What I observed is that this scanner runs with 5 to 6 rules and it displays the issues like touch target size, text contrast, multiple items have same description, and so on.. what I noticed is that this just throws the issues that are designed related issues. To know more about this tool, visit Accessibility scanner by Google

 

Lint in Android Studio

There is a Lint feature in the Android studio and it comes by default along with the android studio. Basically it is for developers and this tool helps to identify the accessibility issues during the development phase of the app itself. Please visit android accessibility tutorial

To know related information.

How to Filter Accessibility Issues

  • File > Other settings > default settings >
  • Editor > Inspections

How to Run Lint

  • Analyze > inspect code

This tool throws the issues like label missing for attribute, content description is missing and so on.. if you take care of the accessibility issues thrown by lint during the development itself then your app is good in terms of accessibility to some extent.

 

 

 

 

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