WAI ARIA 1.1 New Roles, states and properties

In last few years Maxability have published several articles on each WAI ARIA 1.0 roles, states and properties. W3C WAI ARIA Working Group have published a latest Candidate RecommendationExternal Website on October 27, 2016. According to this candidate recommendationExternal Website of WAI ARIA 1.1, new roles, states and properties are introduced. In addition the values of some properties are enhanced to meet the needs of more complex widgets. On the other hand efforts are put to enhance the mapping of land mark roles such as role=”form” to behave as a HTML form element which wasn’t mapped in WAI ARIA 1.0.

New Roles in WAI ARIA 1.1

The following new roles are introduced in WAI ARIA 1.1. Detailed explanation of each role will be published as different articles in coming months.

  • role=”cell”: A cell in a tabular container.
  • role=”feed”: A scrollable list of articles where scrolling may cause articles to be added to or removed from either end of the list.
  • role=”figure”: A perceivable section of content that typically contains a graphical document, images, code snippets, or example text.
  • role=”none”: An element whose implicit native role semantics will not be mapped to the accessibility API.
  • role=”searchbox”: A type of textbox intended for specifying search criteria.
  • role=”switch”: A type of checkbox that represents on/off values, as opposed to checked/unchecked values.
  • role=”table”: A section containing data arranged in rows and columns.
  • role=”term”: The term role is used to explicitly identify a word or phrase for which a definition has been provided by the author or is expected to be provided by the user.

New States and properties in WAI ARIA 1.1

The following new states and properties are introduced in WAI ARIA 1.1. Detailed explanation of each state or property will be published as different articles in coming months.

  • aria-colcount (property): Defines the total number of columns in a table, grid, or treegrid.
  • aria-colindex (property): Defines an element’s column index or position with respect to the total number of columns within a table, grid, or treegrid.
  • aria-colspan (property): Defines the number of columns spanned by a cell or gridcell within a table, grid, or treegrid.
  • aria-current (state): Indicates the element that represents the current item within a container or set of related elements.
  • aria-details (property): Identifies the element that provides a detailed, extended description for the object.
  • aria-errormessage (property): Identifies the element that provides an error message for the object.
  • aria-keyshortcuts (property): Indicates keyboard shortcuts that an author has implemented to activate or give focus to an element.
  • aria-modal (property): Indicates whether an element is modal when displayed.
  • aria-placeholder (property): Defines a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format.
  • aria-roledescription (property): Defines a human-readable, author-localized description for the role of an element.
  • Aaia-rowcount (property): Defines the total number of rows in a table, grid, or treegrid.
  • aria-rowindex (property): Defines an element’s row index or position with respect to the total number of rows within a table, grid, or treegrid.
  • aria-rowspan (property): Defines the number of rows spanned by a cell or gridcell within a table, grid, or treegrid.

This article will be updated if the final WAI ARIA 1.1 spec makes any changes.

How to make focus indicator accessible

External Website

A focus indicator is a dotted or solid line present around the tab-able elements such as links, buttons, and form fields. While navigating the page through keyboard tab key, the focus indicator appears around elements when they receive keyboard focus. It helps users to visually determine which element has current keyboard focus. All major browsers like Firefox, Chrome, Internet Explorer and Safari shows a thin dotted or solid line around the elements when they receive the keyboard TAB focus. But the focus indicator look different in each of the browsers. For example, Internet explorer and Firefox shows a dotted line whereas Chrome shows a blue solid line. In this article lets discuss on why focus indicator is suppressed in a web page and how to make focus indicator accessible for user.

 

Benefits of Focus Indicator:

A visible focus indicator not only helps users with certain disabilities but also helps sighted users to know where the current keyboard focus is when navigating the page through keyboard alone.
Following are different groups who majorly get benefited with presence of focus indicator:
Motor – Users who cannot use mouse and completely rely upon keyboard to navigate the web page and access interactions present in it.
Visual – Users who have low vision use screen readers often and keyboard to navigate the web page.\
Cognitive – Users with memory limitations may lose the track they are working on.

 

CSS Outline property

What if we don’t like the default dotted focus indicator and want to create something fancy? Can an author or developer create a customized focus indicators for interactive elements? Yes, a customized focus indicator can be shown using “outline” which is a CSS property that draws a line around the elements.

 

When focus indicators are not visible?

The HTML elements are not rendered by browsers in the same way. Sometimes there would be mismatch in padding, margin for same elements when seen in different browsers. This behavior makes it difficult to achieve pixel perfect (maintain pixel to pixel accuracy as per visual design specifications) while developing a web page. Hence developers go for CSS reset style sheet which has a set of CSS rules that resets the styling of all HTML elements to a consistent baseline.

Sample code:
In the sample code, the css properties are set for few html elements in reset.css.

html, body, div, span, applet, object, iframe,h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, button, input {
margin: 0;
padding: 0;
border: 0;
font-size: 100%;
font: inherit;
vertical-align: baseline;
outline : 0;
}

As per above sample code, developers uses css property outline: none for following reasons.

  1. A large focus indicator which sometimes occupies the entire row if developer provides an image inside an anchor tag.
  2. It is rarely misunderstood that the focus indicator occupies some space and breaks pixel perfection
  3. Developers assume there is not harm with presence of outline and does not think to remove it.

 

Impact on Accessibility:

But, due to the presence of outline: none, all browsers suppress the default focus indicator they generally show for all interactive elements making it inaccessible for certain users. Motor disability group users who rely on keyboard will not know where their current keyboard focus is and hence cannot activate the interactive elements precisely. Hence they may have to rely on someone to complete their task.

Remedy:

  1. Removing outline:

    A straight forward remedy is to remove the “outline: none” property from reset css file. By removing it from reset.css, browsers will show the default focus indicator for all interactive elements and makes it accessible for all users.

  2. Define separate styles:

    Instead of removing the outline: none property, define separate styles for anchor element. In the above code snippet, remove the anchor and define it separately without outline: none.

    Sample code:
    html, body, div, span, applet, object, iframe,h1, h2, h3, h4, h5, h6, p, blockquote {
    margin: 0; padding: 0; border: 0; font-size: 100%; font: inherit; vertical-align: baseline; outline : 0;
    }
    a{
    margin: 0; padding: 0; border: 0; font-size: 100%; font: inherit; vertical-align: baseline;
    }

  3. CSS Pseudo classes:

    Pseudo class is used to define the special state of the element like hover (when user mouse over on an element), focus (when keyboard focus is on an element) or activates it.
    Instead of removing outline: none from reset css, use pseudo class: focus. Define the outline explicitly for anchor elements when they receive keyboard focus using “: focus” pseudo class.

    Sample code:
    html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, a {
    margin: 0; padding: 0; border: 0; font-size: 100%; font: inherit; vertical-align: baseline; outline: 0;
    }
    a: focus { outline: 1px dotted black }

    Here by default anchor element has outline: none property making browsers to suppress the default focus indicator. But as outline is explicitly define in :focus pseudo class, browsers will overwrite the outline:0 and shows dotted black focus indicator with width of 1px. Hence users will still know where the keyboard focus is when they navigate through TAB key

 

Conclusion:

As per 2.4.7 focus visible success criteria, any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. The presence of outline: none in reset.css or any of the css files makes browsers to suppress the default focus indicator around interactive elements thus arising accessibility problems. Authors or developers should not encourage using outline: none in CSS. If at all they have to use it, then pseudo classes must be used to make the focus indicator visible.

NVDA Expert Certification

NV Access are very pleased to announce that NVDA Expert Certification is now available!. The NVDA expert certification exam is online and free for any one. The exam takes 55 minutes with questions spread in 14 different sections.

NVDA expert certificate exam requires knowledge from basic to advanced. Some key elements one need to know are listed out on NVDA exam certification pageExternal Website. The questions are multiple choice in model. Most of the questions have a single answer structured with radio buttons, where more than one answer is applicable checkboxes are provided for the user to select the answer. The time limit is 55 minutes, the examiny can check the available time throughout the exam.

The online NVDA expert certificate exam is free for anyone but to have a certificate provided by NV Access a fee of AUD 100 is applicable. In addition an accessible PDF form of certificate will be provided. The names of certified NVDA experts will be published on NV Access website. Current list of certificate holders are available hereExternal Website. In case if the participant is unable to pass the exam 3 weeks time is provided for preparing and reappearing for the exam.

Hope this information helps many NVDA experts looking for such Accreditation.

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.