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.


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.


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.


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>

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.


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

*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.


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?


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

Grouping Related Form Elements

The related elements in a form need to be grouped together. The technique of grouping related form elements allows users to understand the relationship of the controls and interact with the form more quickly and effectively. Grouping related form elements can be established by enclosing them within the fieldset element. All controls within a given fieldset are then related. The first element inside the fieldset must be a legend element, which provides a label or description for the group.

The grouping related form elements can also be established using WAI ARIA group role and radiogroup role. The relation with the group heading can be then established using aria-labelledby property.

Grouping related form elements such as radio buttons and check boxes is extremely important in a screen reader perspective. Associating the group heading with the group is equally important. Eg: the radio buttons male and female need to be associated to a group heading such as gender. Similarly a group heading such as What colors do you like? need to be associated with the group of check boxes in it. The other grouping we commonly observe are address groups such as postal address and residential address, SSN or phone numbers having the fields split into parts etc.

The fieldset element draws a box around the related elements, however this can be controlled using CSS techniques.

Example 1: Using fieldset and legend

In the example below HTML native controls <fieldset> and <legend> are used for grouping related form elements

Select one of the payment modes below and continue payment

Mode of payment

Example 2: Fieldset and legend with different types of elements with logical grouping

Residential Address

Postal Address

Example 3: Grouping radio buttons using radiogroup role and aria-labelledby for group heading (ARIA)

Mode of payment

Example 4: Grouping related elements using role group (ARIA)

Social Security#

Example 5: Reading the radiogroup label along with each radio button (ARIA)

In this example role radio group is used to group the radio buttons and aria-labelledby is used to refer the group heading and individual labels of each radio button. aria-labelledby is specified for each radio button refering the id of label and the group heading. So even in NVDA group label is announced along with each radio button, not just while navigating into the group.

Mode of payment

Demonetisation and Disability

Demonetisation, cashless transactions, digital banking, eradication of black money, Whatever you call on the great initiative taken by the Prime Minister, I whole heartedly accept the move. In my own little way I am supporting by making 80 to 85 percent of my monthly spending with e-cash. Along the way I see many problems being a non-visual user. I am sure these problems are true to every individual with visual challenges in the country.

Before I drive you through the problems, let me provide you with some realities and a little background of banking support for persons with disabilities.

The background

In 2007 India ratified United Nations Convention on rights of persons with disabilities. This means

Countries that join in the Convention engage themselves to develop and carry out policies, laws and administrative measures for securing the rights recognized in the Convention and abolish laws, regulations, customs and practices that constitute discrimination (Article 4).

Taken from The convention in briefExternal Website (

Following this ratification, Reserve bank of India passed two circulars in November 2007External Website and June 2008External Website to address the needs of persons with disabilities. The summary of these circulars is to avoid discrimination in providing the banking facilities to the customers on the grounds of their disability.

Even after this initiative many bankers repeatedly denied facilities such as debit cards and internet banking for persons with disabilities.

Problems with digital banking

Let us now suppose that debit card and internet banking facilities are made available for persons with disabilities. Understand the next challenges for them.

As per 2011 censusExternal Website almost 27 million of total population in India have a disability. Almost 18 million have been reported in rural India.

Non-availability of banking facilities

As I have outlined in earlier sections, despite of circulars by RBI, many bankers deny cheque, debit/ credit card and online banking facilities for persons with disabilities. Due to this many of them cannot be a part in the demonetization initiative.

Digital illiteracy

Due to very limited education facilities and typical Indian parenting problems many people with disabilities have to be at home, only can do primary education or restrict themselves to home education system. This cause a huge barrier for digital literacy. This means people with disabilities cannot use online banking facilities and can be a part of demonetization.

Problems for rest of persons with disabilities

The story is not over yet. The digital accessibility comes into picture. Most of the banking websites, mobile applications and the payment gateway systems are inaccessible. Below are few such problems that prevent persons with disabilities from participating in the cashless society or that prevent from being part of demonetization.

1. Inaccessible websites

As I have outlined in a blog earlier this year most of the public sector websites are inaccessible. I am sure most of the private sector websites will not stand behind. For instance the private sector website I use does not allow a JAWS user to transfer funds. The fund transfer link itself cannot be located when accessed with the JAWS screen reader. It is very much important to make the bank websites accessible.

Secondly we should not forget the payment gateways such as payUmoney, mobikwik, Paytm etc. As a frequent user the experience is definitely not a satisfaction to me.

Finally the check-out or payment pages of the websites through which the user does the transaction too are not accessible. I used to have a real tough time paying the electricity bill as the providers website is inaccessible. I often used to fail 3 times and used to be successful in 4th or 5th attempt.

So the bottom line is, if the cash less transactions need to be successful the service providers such as electricity, tax, telephone and other consumer required websites, payment gateways and bank websites need to be made accessible.

2. Mobile applications and Accessibility

To encourage cash less transactions, governments are launching the mobile apps for the citizens. Ideally these apps should serve the users as their personal wallets. The one recently launched by honorable Chief Minister of Andhra Pradesh called AP Purse is one such app. I have not checked it’s accessibility though, these apps need to be made accessible. Similar problems of websites outlined above holds same for mobile applications. The service provider apps, bank websites and gateway applications need to be accessible in-order to be a transaction successful.

The rural part of India and most of the urban regions highly rely on smart phones for various transactions. Major part of cash less transactions are going to be mobile driven. The mobile app accessibility should be a high priority for service providers and the government agencies.

3. Accessibility of swipe machines

The next untouched area so far or generally ignorred is the accessibility of swipe machines or electronic data capture (EDC) devices. These are also called as point of sale terminals. Debit / Credit cards are used to make payments through these point of sale terminals. In general the visually challenged customer will not know the amount swiped by the retailer unless a message pops up into the users mobile. On the other hand the user has to compromise on the debit / credit card secret pin to a unknown person. May be an accessible alternate need to be brainstormed to this problem. These kind of payment is going to hit largely in the market with the new cash less initiative of Government of India.

These are the major areas Government of India should immediately look at. Through this article I am highlighting the needs and fore-seen problems of persons with disabilities because of cash less society. In no way I am against the initiative of Government of India. On the other hand if the above said problems are taken care by the committee formed by GOI, additional set of users i.e. citizens with disabilities can take part in the cash less initiative and benefit out of the incentives provided.

Last updated on 22nd December, 2016

aria-valuetext property

Aria-valuetext property works similar to a aria-valuenow property. It Defines the human readable text alternative of aria-valuenow for a range widget. If aria-valuetext property is defined for any widget, author should also specify aria-valuenow unless aria-valuenow cannot be determined.

The major difference between aria-valuetext and aria-value now is the type of value determined through them. Aria-valuetext should pass a string value to the user where as aria-valuenow property pass a numeric value. Authors are encouraged to use aria-valuetext only when the aria-valuenow property cannot meaningfully pass the information to the user. Eg: on a slider having severity as high, medium and low, conveying the same through aria-valuenow with 1, 2 and 3 does not meaningfully convey the intended information to the user. If aria-valuetext is provided, assistive technologies should rely on it, not aria-valuenow.

Also read aria-valuemax, aria-valuemin and aria-valuenow to understand how aria-valuetext should be used in various range widgets.

Values of aria-valuetext property

The value of the aria-valuetext property must be a string.

aria-valuetext used in roles

Inheritted into roles:

aria-valuetext property examples

Web Accessibility Suits and Settlements in 2016

It is almost at the end of year 2016. It is the time to look at the legal updates. The web accessibility suits that are filed in the courts, the settlements that are agreed without law suits and new laws that came into force.

DIRECTIVE (EU) 2016/2102External Website of the European Parliament and of the Council is the major update in the world. India just passed Right to persons with disabilities bill(PDF)External Website in Rajya SabhaExternal Website on 14th December and was tabled in Lok SabhaExternal Website yesterday. The historic day can be today i.e. December 16, 2016.

The other major update on the legal front is the launch of the book “STRUCTURED NEGOTIATION: A WINNING ALTERNATIVE TO LAWSUITS”External Website by LAINEY FEINGOLD. LAINEY FEINGOLD is instrumental in convincing many large organizations towards an agreement to make accessible products without legal suits. The book can be purchased from the American Bar AssociationExternal Website. Use coupon code LFLEGAL10 to receive 10% off the purchase price.

Below are few legal suits and settlements in 2016

Note that all the below links target to external websites.

Related Links