User Experience Designs with Accessibility In Mind Part 1

Last week I was preparing for a session to the user experience team on accessibility. As I am reading more and more resources, I am getting more knowledge on the subject. I have given 10s of trainings for developers and accessibility consultants. The trainings I gave for visual designers and the user experience designers are limited. So, I started researching more on the subject to provide the best training to the team.

I started understanding “Is accessibility a part of user experience or the instructional design team?” “What additional care do the user experience professionals need to take to incorporate accessibility in their research and design work flow?”. “What accessibility guidelines and what user groups do they need to target?” etc.

In my opinion, user experience designers need not learn all the 61 WCAG 2.0 guidelines. To begin with understanding the needs of different disabilities and researching to provide solutions for them in the user experience designs they create is the best way.

Understanding the impact of various disabilities for user experience design

The disabilities that are highly impacted with the digital content are

Blindness

A person with visual impairments depends on screen reading technology to interact with the digital content. They cannot identify the color of the content, the size or the element or the position on the screen layout. So, do not depend on sensory characteristics such as color, size, shape, visual location or orientation to convey information. Providing a textual or programmatic alternate helps the users to identify the same.

Eg: An instruction before a registration form says “Fields marked with red are mandatory”. For a user with blindness who relies on screen reading technology will not be able to locate the fields marked in red color. Substituting the mandatory fields with a star symbol and provide the instruction “Fields marked with * (star) are mandatory” will include screen reader users. In one of the applications I recently encountered, the instruction says “Tap on the light bulb to load more conversations”. How can a screen reader user identify the light bulb icon unless an alternate text is provided?

This adjustment in the design will also benefit users with color blindness. The point to highlight here is, “Color or any other sensory characteristic should not be the only way to provide an instruction or convey some information to the user”.

Low Vision

When designing don’t think that every user can see as you can. Some users may have poor vision and may need more contrasting colors to read the text, Some need the text to be resized, some users need sufficient space between the elements etc. WCAG 2.0 guidelines 1.4.3 Contrast Minimum and 1.4.4 resize text provides enough information and resources on the requirements of low vision users. Few other low vision user requirements such as touch target area and element spacing are drafted by W3C low vision task force and may be added as requirements in the next set of accessibility guidelines.

Provide sufficient color contrast between the text and its background. WCAG 2.0 recommends 4.5 : 1 contrast for regular text and 3 : 1 for large text. Whenever possible use real text not the text on images, some browsers and assistive technologies do not allow the users to enlarge the text on images. Read more about Images of text

Motor disabilities

Certain disabilities impact the users moment of hand and hence cannot use mouse. They highly depend on physical keyboards. Providing functionalities that are mouse dependent Eg: Showing items of a menu on mouse hover, restricts keyboard only users to use the component. A clear visual focus indicator should also be provided for all focusable elements such as links and form elements. Non availability of focus indicator may confuse the users current location while navigating the web page.

Cognitive Difficulties

Not all the users will have the same memory. As we grow older chances that we forget things which we are good remembering when we are young. The forms that does not have proper labels impact users of cognitive difficulties. In modern technologies placeholders are used as labels for form elements. These placeholders are replaced with the text entered by the users after filling the form. After filling the form if the user want to verify the information entered, they cannot relate the content with the label. This does not mean placeholders should not be used but they should not create barriers for users. Look at our articles problems with placeholders and solutions for placeholders for accessibility.

I hope the introductory article gave a basic understanding of the user experience designs on accessibility. In part 2 I will explain other design considerations for accessibility and resources that help to make the user experience designs accessible.

Optgroup for Accessibility

Earlier developers use to customize the html tags like div, ul, and li in order to group the related elements in a drop-down list. Most of such customized widgets are not keyboard accessible and not screen reader friendly making them completely inaccessible.

Thanks to HTML5 for introducing <optgroup> tag which can be used to group the elements in a drop down without much effort  and it is pretty much accessible for keyboard and screen reader users.

Optgroup is used to group the options in a selection list. Instead of having long list of options in a selection list, grouping them together helps user to handle them easily. Optgroup should be coded inside a <select> tag.

Nested grouping is not possible with optgroup tag. It mainly supports two attributes “label” and “disabled”. If an optgroup has the attribute “disabled”, then the particular options will be greyed out by few browsers and users cannot select the options either with keyboard or mouse.

 

Attributes available for optgroup tag
Attribute Description
label To name the group of options inside the drop-down list.
disabled Indicates whether the items present in group are selectable or not.

Sample Code

<label for=”food”>what is your favorite food? </label>
<select id=”food” name=”food”>
<optgroup label=”Fruits”>
<option value=”1″>Apple</option>
<option value=”2″>Banana</option>
<option value=”3″>Kiwi</option>
</optgroup>
<optgroup label=”Juices”>
<option value=”4″>Apple</option>
<option value=”5″>Banana</option>
<option value=”6″>Kiwi</option>
</optgroup>
<optgroup label=”Salads”>
<option value=”7″>Broccoli</option>
<option value=”8″>Cabbage</option>
<option value=”9″>Sprouts</option>
</optgroup>
</select>

Screen Reader Behaviour

Screen reader announces the label along with the option value for the user. If an option group is having disabled attribute then screen reader will not announce them at all. Each screen reader announces the optgroup in its own way which is as following.

Screen reader behaviour for optgroup
SR + Browser SR behavior
JAWS 17 + IE 11 SR announces the option value along with its group name while using arrow keys.
Ex: Apple (Fruits), Banana(Fruits)
NVDA 2017.1 + FF 51 SR does not announce the group name when navigating using arrow keys. But by expanding options using space key, SR announces as “Fruits grouping – Apple 1 of 3 – Level 2” for each of the options when arrow keys are pressed.
Chromevox 53 + Chrome 56 SR does not support optgroup and announces them as a normal select box.
Voiceover iOS9 + Safari SR announces the group name along with options on swiping from left to right. SR appends the word ‘heading’ for group names (Fruits, Juices…).
Ex: Fruits Heading, Apple, Banana, KIWI, Juices heading…
Talkback V6.0 + FF SR announces the group name along with options on swiping from left to right. But SR appends the word ‘disabled’ for group names (Fruits, Juices…).
Ex: Fruits disabled, Apple, Banana, KIWI, Juices disabled…

Examples & Reference:

  1. WCAG 2.0 Techniques External Website
  2. W3Schools Optgroup External Website

Keyboard Interaction for Disabled Elements

In many contexts few elements on the screen are in disabled mode. The question often araises is “Do these disabled elements need keyboard focus?”. The HTML5 native behaviour of disabled” attributeExternal Website does not allow the users to focus on the disabled elements. As per W3C form elements such as buttons, input elements, select, text area, option, optgroup element that has disabled attribute and fieldset element that has disabled attribute fall into the disabled element category. Though often developers use disabled attribute to links, that is not a scemantic code. So, avoid using HTML5 disabled attribute for links or do not make link as a disabled element.

When the native HTML5 disabled attribute does not allow users to have keyboard focus, how do users retrieve important information conveyed through the disabled elements? Eg: steps involved in a check-out process?? If developers allow keyboard focus to the disabled elements is this not overwriting the default spec behavior and will it not be a bad user experience where a widgit has more disabled elements than interactive elements? Eg: defined in the seat selection widget.

I have posted this question in various forums to seek opinions from the experts. I will discuss that later, but before that let us see how to provide keyboard focus to and how to avoid focus to a disabled element. In addition, if the native HTML5 disabled attribute does not provide the state to a screen reader user, how do we inform it.

In the first example for pagination elements, I have used HTML5 disabled attribute for previous button in first section and next button in the next section. Links 1 and 10 are also are in inactive state. The for sure expected behaviour is that the screen reader reads it as unavailable or disabled depending on the screen reader used. A debatable discussion is going around if keyboard focus need to be provided for disabled elements or not. The HTML native attribute disabled is causing not to focus on the elements with tab key. This is consistant in Internet explorer. Both the button and link are not recievving keyboard focus. In Mozilla Firefox buttons are not recieving focus but links are recieving focus though disabled attribute is used. Though not specifically mentioned in the web AIM article Keyboard AccessibilityExternal Website, keyboard should be focussed to all interactive elements. Considering disabled elements as non-interactive, I want to propose that disabled elements should not recieve keyboard focus?

Intrestingly NVDA is not recognizing the state of a disabled link on Mozilla firefox. I have raised a bug with NVDA, NVDA Issue #6886External Website. The NVDA team have educated me that the disabled links as specified by the W3C HTML5 disabled specExternal Website says, disabled attribute should not be used for links. On the other hand as discussed earlier, in firefox the inactive anchor element (link) too is recieving keyboard focus. If as content author you agree that non-interactive elements should not recieve focus, use tabindex=”-1″ to remove the disabled element from tab chain.

In the second example for progressbar, I have made the current page link as active and all the future step links as inactive. The user should still be able to navigate to those elements with tab key. A screen reader user can hear the role and the disabled state. Since HTML5 disabled attribute is not allowed by the spec, I have used aria-disabled state. On the other hand to have consistancy in all the browsers that the elements are navigable with tab key of the keyboard, I have used tabindex=”0″ which will enable tab focus irrespective of browser default behavior.

In the third example, for seat selection widget, I have made selected seats available for keyboard users and avoided tab focus to booked / unavailable seats. If for any reason if the disabled elements are operable by keyboard, then use negetive tabindex to avoid focus. Keyboard focus is maintained only on the available seats. The non-available seats can only be identified to a screen reader user with arrow key navigation. In many ticket booking websites time taken to book a ticket becomes crutial. Though WCAG 2.0 2.2.1 Timing adjustable governs in allowing the user to have extended time limit, it will be frustrating for keyboard only users and screen reader users to navigate to all unavailable seats. Use of disabled attribute is allowing the screen reader users to identify the non available seats by speaking the state aloud. In any screen reader / browser combination if the state is not announced, content authors can substitute disabled attribute with aria-disabled state.

Do we have a definitive answer to the question “Do the disabled elements need focus?”. We had enough discussions on webAIM forumExternal Website and W3C WAI Interest GroupExternal Website. Most of the experts agreed that keyboard focus on to a disabled element depends on the situation wher it has been used. The accessibility consultant should be able to judge it. How do you let screen reader user know if an element is disabled. Use HTML5 disabled attribute or aria-disabled state. How do you make interaction more specific to the situation? Read our article Tabindex for accessibility, good bad and ugly.

WCAG 2.1 First Public Working Draft Out For Review

After the W3C recommendation to WCAG 2.0External Website in December 2008, Web Content Accessibility Guidelines 2.1External Website is going to be a major update. WCAG 2.1External Website is a dot version to WCAG 2.0.External Website The success criteria in WCAG 2.0 remains as it is and new success criteria are proposed in the WCAG 2.1 First Public Working draft.External Website

The Accessibility Working Group seeks feedback from public on the WCAG 2.1 First Public Working draftExternal Website. This document contains 28 new success criteria. 3 of these are formally accepted by the Accessibility Working Group and the remaining 25 are proposals to WCAG 2.1 public working draft review. The Accessibility working group is looking for public review and comments on these proposed success criteria. There are 35 more proposed success criteria but are currently not included in this draft. Full set of success criteriaExternal Website are also available for review.

In the WCAG 2.1 Public Working DraftExternal Website more user groups and devices are taken into consideration. For instance adapting text to help the low vision users, Speech Input to help users with motor difficulties, plane language to help users with cognitive difficulties. The needs of persons with disabilities while interacting with hand held devices such as mobiles are also considered with success criteria such as linearization and target size.

Feedback for WCAG 2.1 Public Working draftExternal Website can be provided on Github.External Website Please raise new issues for your comments, putting each separate topic into a separate issue. If it is not feasible to file issues in this tool, you can also submit comments by email to public-agwg-comments@w3.org.

The Working Group requests comments on this draft be filed by 31 March 2017. The Working Group plans to publish updated Working Drafts frequently over the course of 2017 to incorporate input received and continued review of proposals. The final WCAG 2.1 is planned to release by end of 2017 and hence early feedback is critical.

Read the W3c blogExternal Website about the public working draft. Also reading the blog by David MacDonaldWCAG 2.1 First Public Working Draft Out For Review

After the W3C recommendation to WCAG 2.0External Website in December 2008, Web Content Accessibility Guidelines 2.1External Website is going to be a major update. WCAG 2.1External Website is a dot version to WCAG 2.0.External Website The success criteria in WCAG 2.0 remains as it is and new success criteria are proposed in the WCAG 2.1 First Public Working draft.External Website

The Accessibility Working Group seeks feedback from public on the WCAG 2.1 First Public Working draftExternal Website. This document contains 28 new success criteria. 3 of these are formally accepted by the Accessibility Working Group and the remaining 25 are proposals to WCAG 2.1 public working draft review. The Accessibility working group is looking for public review and comments on these proposed success criteria. There are 35 more proposed success criteria but are currently not included in this draft. Full set of success criteriaExternal Website are also available for review.

In the WCAG 2.1 Public Working DraftExternal Website more user groups and devices are taken into consideration. For instance adapting text to help the low vision users, Speech Input to help users with motor difficulties, plane language to help users with cognitive difficulties. The needs of persons with disabilities while interacting with hand held devices such as mobiles are also considered with success criteria such as linearization and target size.

Feedback for WCAG 2.1 Public Working draftExternal Website can be provided on Github.External Website Please raise new issues for your comments, putting each separate topic into a separate issue. If it is not feasible to file issues in this tool, you can also submit comments by email to public-agwg-comments@w3.org.

The Working Group requests comments on this draft be filed by 31 March 2017. The Working Group plans to publish updated Working Drafts frequently over the course of 2017 to incorporate input received and continued review of proposals. The final WCAG 2.1 is planned to release by end of 2017 and hence early feedback is critical.

Read the W3c blogExternal Website about the public working draft. Also reading the blog by David MacDonaldExternal Website on Summary on WCAG 2.1 public working draft and how to submit comments.

on Summary on WCAG 2.1 public working draft and how to submit comments is worth.

Screen Reader and Browser Combination for Accessibility

Screen reader testing is a common action item while testing for accessibility. Since the web content is rendered on browsers, it is very important to know the best screen reader and browser combination for accessibility testing. Currently for both desktop and mobile devices many browsers are available in the market so as the screen readers. Testing with all screen reader and browser combinations is practically impossible. Making web content accessible for all screen reader and browser combinations is next to impossible.

In general Chrome takes highest market share in browser usage, statistics from Wikipedia article.External Website This does not hold good when someone want to take a base for accessibility testing. The Web AIM screen reader user surveyExternal Website yields different results. Chrome is placed at third position after Internet Explorer and Firefox on Windows operating system. Undoubtedly Safari holds top position for both OSx and IOS. For  Android Mozilla have tried making great support with Talkback and Chrome is also significantly good while using with talkback. Further in the survey it is evident that JAWS with Internet Explorer, NVDA with Firefox and Safari with OSx are the highly used screen reader and browser combinations by the end users on desktop operating systems. For the accessibility testing is this screen reader and browser combination perfect pair? Let us see.

Listing down the highly used Screen Readers

  • JAWS (Job Access With Speech)
  • NVDA (Non-Visual Desktop Access)
  • VoiceOver (OSx and IOS)
  • Talkback (Android)

Listing down popular browsers

  • Internet Explorer (Windows OS)
  • Firefox (Windows OS and Android)
  • Chrome (Windows OS and Android)
  • Safari (OSx and IOS)

Screen reader and Browser combination

Let us first find the easy pairing screen reader and browser combinations.

VoiceOver and Safari

VoiceOver is the inbuilt screen reader both on OSx and IOS. Safari is the primary browser on these two Apple operating systems. Apple has put its best efforts in making the best screen reader VoiceOver and packaging it with its hardware devices and the operating systems. Being the operating  system and inbuilt screen reader tightly coupled together undoubtedly VoiceOver with Safari on both OSx and IOS is the best screen reader and browser combination. Both in terms of usage statistics’ and accessibility implementation this pairing is best on said operating systems.

NVDA with Firefox

Users can access the content on all three major Windows operating system supported browsers i.e Internet Explorer, Firefox and Chrome using NVDA. However NVDA recommends FirefoxExternal Website for best experience. For accessibility testing, NVDA with Firefox is a best screen reader and browser combination.

JAWS with Internet Explorer

JAWS For Windows (JFW) is the popular screen reader first released in 1995 few years after Windows Operating system was released into the market by MicroSoft. Internet Explorer is one browser which is in the market since then. Narrator the inbuilt screen reader for Microsoft does not have enough support on browser, and Internet Explorer  is the major browser, the web support of JAWS is highly dependent on Internet explorer. I have not found any other solid evidence than this to support of JAWS with Internet Explorer. So, the recommended screen reader and browser combination is Jaws with internet explorer.

Talkback with Firefox or Chrome

Talkback is the screen reader for Android operating System. Chrome being the native browser on Android, Talkback have increased a lot of support mechanism on the mobile Chrome. Before the talkback support on Chrome, Firefox have done a lot of work to make Firefox a preferred browser on Android to use with talkback. Read Marco Zehe series External Website of articles on the topic. So, primarily Talk with Firefox on Android is a best screen reader and browser combination. Chrome with talkback is also a recommendation.

These are based on my experience and knowledge. Any thoughts, opinion’s or views are welcome.

Budget 2017- 18, “500 railway stations will be made differently-abled friendly

The development in travel & hospitality and Tourisms are two major sectors Government of India is looking forward. These are also undoubtedly high revenue generating and employment creating sectors. Are the fruits of the travel reaching to every Indian citizen including those who have disabilities? Are the tourism spots friendly for tourists with blindness and mobility difficulties? In these two sectors the journey on trains are unavoidable. Making railway stations and the entire train journey accessible is extremely important to include persons with disabilities and elderly take part of the wonderful tourism spots.

As part of Indian budget 2017-2018 Arun jaitly, the union Finance Minister have announced that the Central Government will make 500 railway stations differently-able friendly. I am happy that in entire budget plan shared by the finance minister at least one statement is made that benefits persons with disabilities.

The statement that was made by the Finance Minister is “500 railway stations will be made differently-abled friendly by providing lifts and escalators”.

I wonder will it be sufficient to provide lifts and escalators to make a railway station differently abled friendly? Is the government bothered only about the wheel chair users? Even for them these are not only the areas of consideration at a railway station. Through this article I want to highlight few areas that need reasonable adjustments to make persons with disabilities impacted.

Entering into the railway stations

As any person with disability reaches the railway station a psychological disturbance begins in mind until they come out of the destination railway station. A blind passenger may face difficulty in identifying the entrance gate in the crowded area outside the station. Many stations I have observed have stairs up or down to enter into the railway station. One cannot find a ramp that allows the wheel chair user to safely enter the station. In many cases one cannot find handrails that support passengers who have difficulty in climbing or descending stairs. Once the person enters into the station first thing they have to do is to purchase a ticket. If the person is a traveler they have to take train ticket. In many railway stations the ticket counters are not at proper height and almost all of them does not have adequate space below them for a wheelchair to access the counter independently. For a blind user it is a very tough job. In the noisy environment god knows if the ticket provider in the counter rightly heard what the blind passenger asked for. The ticket provider if repeats the information provided the blind user they confirm that they got the right information else they have to depend on some sighted to get the ticket cross checked. If the person visits the railway station to receive their friends or relatives they have to buy a platform ticket. Interestingly many railway stations have ticket vending machines that allows the users to take a ticket with cash or smart card. The same problems that a wheel chair user encountered at the counter repeats here. For a blind user this is an impossible task. Since these machines are niether voice enabled nor accessible they have to completely depend on the sighted counter parts.

The game just began

Now the passenger has to find the timing of the train and on to which platform the train is going to arrive. The voice announcements are provided on every railway station, but one has to patiently wait for the train you are looking for. The electronic displays are not for blind passengers. I remember many railway stations are providing machines that allows the user to check the train running information ofcourse they are not blind friendly.

Once the passenger find the information they require, they begin the journey towards the platform. Don’t expect lifts or ramps to move between the platforms. The foot over bridges are definitely a hurdle for wheelchair users. I think this is the area the railway ministry is going to look after as per the budget announcement 2017- 18. Lifts are definitely a good option for wheel chair users but in a heavily populated stations number of lifts that are made available is a devatable concept. Though our railway departments quote it for differently abled, these will be useful for elderly, pregnant women and patients travelling. I am not sure how the railway department is going to avoid the usage of these lifts by persons without a disability. Else it will become like a coach provided for differently-abled, mostly used by non-disable community. In addition, I urge the honorable ministry to look after all the possible global standards while building the lifts. I mean the wide doors for a wheelchair to enter, Braille embossment for the physical buttons, voice output, hand railing inside the lift etc.

As I read through many articles over the internet I got to understand that the escalators are not wheelchair friendly. I think most of these are talking about the stair modal. In my research on the very topic I have found that Japan have wheelchair accessible escalators, hope our finance minister is also talking about similar built during the budget as he says specifically for differently-abled friendly.

Once the person climbs over the footover bridge, it will be difficult for a blind passenger to locate the platform where they have to step down. While at Hyderabad, I used to count the passages to reach the 10th platform. If I miss the count I used to step into a wrong platform.

As someone reaches the platform, the most dangerous part arrives. As a blind passenger walks with the white cane in hand, on one side the stalls are placed with seating area , on the other side is the 4 to 5 feed deep rail track, the journey is between. The co-passengers walk in the opposite direction, others walk crossing you, few keep luggage on the way, few stand on the path in a circle and talk on everything under the sky. Unless the blind passenger walk slowly and carefully either they ay bump into the passenger coming opposite or the passenger talking on the path or step over to the luggage. On the other side the deep rail track whose edge does not have raised indication for the white cane to identify the edge. But where is the journey to? Usually to the coach one has to board. Where will the coach positioned? May be at the beginning, at the end or in between who knows? The sighted who can read the electronic board knows, not the blind passenger. Once the train arrives, is the on boarding process a happy path? For a blind passenger, it might be better to certain extend but definitely a great pain for wheelchair users. Usually the wheelchair passenger and wheelchair will be carried by porters. This process is more embarrassing for women passengers.

I am not talking about the conditions in the train for now, but let me point some more inaccessible features of the railway stations in India.

Other areas of concentration

No one know where the toilets are. I have never found an accessible, wheelchair and other physically handicapped friendly toilets.

In the railway stations or on the platforms no seating places are marked or reserved for persons with disabilities.

The water drinking facilities are mostly not wheelchair friendly.

Last one but very important concern is the railway staff is not sensetised towards disability.

I on behalf of crores of Indians with disabilities urge honorable ministry to look into all kinds of problems faced by them not just by overlooking at few touch points.

Related News and Articles

Star Rating Widget

A star rating widget usually contains images of 5 stars which is used to rate an object. The widget is mostly seen in e-commerce, entertainment and several service providing portals where the feedback of the user is valued. A user simply clicks on the stars to rate an item. For example if there are 5 stars and user clicks on 3rd star, the rating would 3-star out of 5.

A mouse user can easily navigate to a particular star and clicks on it to give rating. Mostly an image would be used with 5 stars and developers track where an user is clicking with mouse and change the image dynamically. But users who rely on keyboard may not be able to activate the star using keyboard alone.

To make it accessible with keyboard as well, semantic HTML elements like radio buttons has to be used to represent each star.

An example of star rating widget is present in W3C Web Accessibility Tutorials External Website website. Lets see how it is implemented in W3C tutorials.

Implementation:

Radio buttons are used to represent 5 stars and each radio button is associated with a label respectively. An off-screen text is provided with in a span and SVG is used to display the “Star” images visually on the screen. The off-screen text and svg are enclosed in the label.

As native HTML radio buttons are used to represent each star, the widget is available for keyboard users as well. Initially all stars are in grey color and if a radio button is checked, the corresponding svg star gets an underline and also color of all stars present till the selected radio button changes to yellow. The screen reader user knows the rating from the off-screen text present in the label.

Drawback:

In IE, when keyboard focus is on 3-star radio button and user activates it, the 3-star radio button gets checked. Now on hit of TAB key, the focus moves to the svg of 4th radio button but a visible focus indicator or underline is not present around the star image. Hence keyboard user may not understand on which element the keyboard focus is on.

Ideally the focus should come out of the rating widget since all the radio buttons belongs to single group. Due to the presence of svg element, the focus is moving to the next star without a keyboard focus indicator.

Remedy:

To overcome the above problem, just add “focusable” attribute to the svg element. If the attribute value is set “true” then svg element won’t receive keyboard focus. (tabindex=”-1” doesn’t work in this case).

HTML Code:

<input value=”0″ id=”star0″ checked type=”radio” name=”rating” class=”visuallyhidden”>
<label for=”star0″>
<span class=”visuallyhidden”>0 Stars</span>
<svg viewBox=”0 0 512 512″ focusable=”false”>
<g stroke-width=”70″ stroke-linecap=”square”>
<path d=”M91.5, 442.5 L409.366489, 124.633512″></path>
<path d=”M90.9861965, 124.986197 L409.184248, 443.184248″></path>
</g>
</svg>
</label>

Now when the keyboard focus is on 3rd star and on hit of TAB key, the focus moves out from the rating widget.

Spectator of Screen Reader? tools for you

Testing with a screen reader is one of the major activities while making a website accessible. For non-screen reader users it will be hard hearing the robotic voice output through-out the day. On the other hand they might be missing important information spoken out by the screen reader. Sometimes that make huge difference in identifying accessibility problems. If the test engineer miss to hear the word link, they end up raising a missing role bug under 4.1.2 Name, Role, Value.

Through this article I want to improve the productivity of sighted accessibility engineers by introducing tools such as

NVDA Speech Viewer

The NVDA speech viewer feature shows the information spoken out by NVDA as the user navigates through the page or types in some information. This can be activated from the tools menu in NVDA settings that can be invoked by pressing NVDA + N. (NVDA key may be insert key in most computers and caps key in case of some specific laptop layouts).

NVDA > Tools > Speech viewer or the hot keys NVDA + n followed by T and S.

Sample NVDA Speech viewer

JAWS Speech History

JAWS speech history feature introduced in JAWS 15, provides the content spoken out by JAWS in a panel. The JAWS speech history panel can be invoked by pressing JAWS key + spacebar followed by H (JAWS key may be insert key in most computers and caps key in case of some specific laptop layouts). Remember that JAWS speech history panel can show only last 50 sentences spoken out by JAWS. When the JAWS speech history panel is invoked the focus is presented at the last sentence spoken by JAWS. Use normal navigation keys to read the rest of the content in the panel. To clear the JAWS history press JAWS key + spacebar followed by shift h.

Sample_JAWS_History

In case for any reason JAWS Speech History is not displayed, check if it is enabled (By default this feature is enabled).

  1. Press INSERT+F2, and select Settings Center.
  2. Press CTRL+SHI3FT+D to load the default JAWS settings.
  3. In the Search edit box, type “speech history” without the quotes.
  4. Press DOWN ARROW to move to Enable Speech History in the filtered search results in the tree view.
  5. Check if Enable Speech History check box is checked.

VoiceOver Caption Panel

VoiceOver caption panel shows the content read out by voiceover as the user navigates through any web page or other portions of the computer. VoiceOver caption panel is switched on by default for voiceover users. For any reason if the caption panel is not available check if it is switched off by any chance. The caption panel feature can be found at
VoiceOver Utility > Visuals > Caption Panel tab

Sample_VoiceOver_caption_panel
*Knowledge and screen shot are the credits of Paul J Adam.

Talkback Display Speech output

The Display speech output feature is an option under talkback developer settings. When this feature is enabled the currently spoken text of talkback is displayed at the bottom of the screen. This allows the developers to understand the exact text read out by talkback. This feature may also be benefited by low vision users who want to follow talkback. This feature is not checked by default. Use the following steps to invoke the display speech output feature of talkback.

Settings> Accessibility> TalkBack > Settings > Developer options> display speech output.

I am not aware of any similar feature for VoiceOver on IOS.

How does these features help?

  • Useful for any sighted user trying to use screen reader for various reasons.
  • When developers do unit testing to understand the screen reader output.
  • When accessibility testers want to provide the exact speech output to reproduce a bug and show / email to developers.
  • For sighted accessibility testers who may be relying more on visual output than the audio spoken out by screen readers while testing.
  • For low vision users who depends on both audio output and display output.

These are few ways a visual speech output can be beneficial.

Section 508 Final Rule 2017 Refresh

On January 18, 2017 United States Access Board has released an update for the final rule on standards for electronic and information technology developed, procured, maintained, or used by Federal agencies covered by section 508 of the Rehabilitation Act of 1973, as well as the guidelines for telecommunications equipment and customer premises equipment covered by Section 255 of the Communications Act of 1934. The Section 508 standards and Section 255 guidelines refresh are intended to ensure that information and communication technology covered by the respective statutes is accessible to and usable by individuals with disabilities. The Revised 508 Standards and 255 Guidelines replace the current product-based regulatory approach with an approach based on ICT functions.

Highlights of section 508 final rule

  1. New Regulatory Approach and Format
  2. Broad Application of Web Content Accessibility Guidelines 2.0
  3. Harmonization With International Standards
  4. Delineation of Covered Electronic ‘‘Content
  5. Expanded Interoperability Requirements
  6. Extended Compliance Date and Incorporation of Safe Harbor Provision for Section 508-Covered Legacy ICT

Section 508 final rule key Dates

  • The Section 508 final rule is effective from March 20, 2017. This means All ICT that is published on or after March 20, 2017 must be compliant as per the new Section 508 standards.
  • ICT that is published before March 20, 2017 must be still compliant as per old Section 508 standards.
  • Compliance with the section 508-based standards is not required until January 18, 2018.
  • Compliance with the section 255-based guidelines is not required until the guidelines are adopted by the Federal Communications Commission.

Related links

Usability and Accessibility a comparative study

Before we compare, let us understand the definitions of usability and accessibility for web.

Usability design is about designing products to be effective, efficient, and satisfying. The international standard, ISO 9241-11, provides guidance on usability and defines it as: “The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use”.

accessibility means that people with disabilities can perceive, understand, navigate, and interact with websites and applications, and that they can contribute equally without barriers.

Accessibility is a subset of usability. When a website or an application is made accessible, it means the product is useful for persons with disabilities. While satisfying the needs of users with disabilities in many instances all other users will also be benefited. Eg: Providing a clear link description that informs the target to the user is an accessibility requirement but greatly enhances the usability. Providing sufficient color contrast as per WCAG 2.0 standards is helpful for low vision users but greatly enhances the experience for mobile users in a day light.

Sometimes we find a problem on the page but find it difficult to judge if it is an accessibility problem or an usability problem or both or neither. Many accessibility consultants when finds a bug on the page that is definitely a problem for some set of disabilities but is not covered in a specific standard. They often go a step ahead and mark it as a best practice, good to have or an usability issue. Eg: Every focusable element on the page should have a visible focus indicator as per 2.4.7 focus visible. The visible focus indication depends on various factors such as the background of the element, browser tested on, use of additional styles for focus indicators or often the environment such as light focused on the screen. Raising it as an accessibility problem might be difficult but accessibility consultants will not be convinced to pass the scenario.

The below table compares Usability and accessibility on various parameters.

Usability and Accessibility a comparitive study
Criteria Accessibility Usability
ISO Standard ISO/IEC 40500:2012 ISO9241
Users can perceive, understand, navigate, and interact effectively and efficiently use the design and are satisfied with it.
Caters the needs of Every user but primarily the users with disabilities All users
Overlap Accessibility is a subset of usability Usability is broader than accessibility
Quantifying Measured accurately in most of the cases depending on number of instances the elements of the page fails to meet accessibility testing criteria. Measuring depends on number of mistakes made by a user or the number of times they are frustrated or the time taken to complete a task.
Solutions Most of the solutions to fix accessibility problems are technical and few are design centric. Most of the solutions require design considerations and few are technical.
Testing process An accessibility tester can individually test the website with the predefined set of testable statements and identify the problems. Need to involve end users or create personas. Depending on the website, use cases need to be provided to the user. Usability analyst need to check the quantitative checks such as time taken to complete a task, errors made while completing etc. The qualitative analysis such as how easy to learn, Can the user remember the interface, the overall satisfaction etc need to be evaluated.

Exercise

Read the scenarios below to identify if a particular scenario falls under accessibility or usability or both accessibility and Usability.

  1. A shopping website is provided with same title in all pages. Is it an accessibility problem, usability problem or both usability and accessibility problem?
  2. A link text on the page has a color contrast ratio of 4.2: 1 with its background color but yet not clearly visible when observed in a day light. Is this an accessibility problem, usability problem or both usability and accessibility problem?
  3. A web page has pagination links. The clickable area of pagination links is too small for some users to accurately activate. Is it an accessibility problem or usability problem or both usability and accessibility problem?
  4. A registration form contains a password field that needs at least one number and one special character having a minimum of 8 characters long. No instruction is provided to inform the user about the same. Is it an accessibility problem or usability problem or both usability and accessibility problem?
  5. A difficult navigation mechanism on a website to send feedback on sites accessibility. Is it an accessibility problem or usability problem or both usability and accessibility problem?

Answers

  1. Usability and accessibility
  2. Accessibility
  3. Usability
  4. Usability and accessibility
  5. Usability