Nominations open for 8th NCPEDP-Mphasis Universal Design Awards

National Centre for Promotion of Employment for Disabled People (NCPEDP) is a non-profit voluntary organisation founded in 1996 working as an interface between various stakeholders – Government, Industry and Civil Society Organisations (both national and international) for the empowerment of persons with disabilities.

NCPEDP has long believed that accessibility is the bedrock of inclusion. However, it is not limited to just the physical space. It includes, among many others, transport infrastructure, information & technology, aids and appliances. Access therefore, is an issue that cuts across disabilities, sectors, abilities and age groups and forms the very basis of Empowerment! And, a concept that is intrinsic to any kind of access is ‘Universal Design’, which means a design that is usable to the greatest extent possible by everyone, regardless of age, ability, or situation.

Thus, to recognise exemplary and innovative work towards the cause of accessibility that promotes the principles of Universal Design, NCPEDP with the support of Mphasis launched the ‘NCPEDP-Mphasis Universal Design Awards’ in 2010.

2017 will see the eighth edition of the Awards which are given in 3 categories: Persons with Disabilities, Working Professionals, and Companies/Organisations. The Awards cover accessibility in the following fields:

  1. Built Environment
  2. Transport
  3. Information and Communication Technology
  4. Services
  5. Aids and Appliances

We have been tremendously motivated by the huge response that the Awards have received since it’s inception and this year, we look forward to seeing an even greater excitement!

 

The Concept Note along with the Nomination Forms can be found at NCPEDPExternal Website . We have also enclosed last year’s commemorative brochure for your reference.

We would appreciate if you could please nominate deserving candidates and also help us disseminate the documents further to relevant individuals/organisations in your mailing lists. The last date for sending nominations is Wednesday, 31st May, 2017.  Please send us your nominations at
secretariat.ncpedp@gmail.com.

More details and registration process can be found at NCPEDPExternal Website

Note: The last date for nomination submission is 31st May 2017.

Global Accessibility Awareness Day GAAD 2017

The 6th edition of Global Accessibility Awareness Day GAAD 2017 is on May 18th. GAAD is marked on third Thursday in May every year. It’s interesting to see the world talking about accessibility and experiencing the problems arising due to inaccessible digital content, and software products. GAAD is also an opertunity for each one of us to understand the problems faced by persons with disabilities. Awareness towards accessibility and sensitivity towards disabilities are the primary objectives of global accessibility awareness day (GAAD). These are the primary objectives for Maxability too and hence we promote GAAD through our blog.

Attend a global accessibility awareness day GAAD 2017 event in your city. Check the list of citiesExternal Website that conduct GAAD 2017. Many companies plan to have an awareness campaigns internal to their organization. Reachout to HR, Diversity & Inclusion or accessibility teams within your organizations to know more.

No GAAD 2017 events in your city? Your company is not aware of GAAD 2017? Don’t worry, We have some ideas for you. See below how to create awareness yourself and encourage teams around you.

Simple checks to observe accessibility

  • Can a user with wheel chair comfortably reach your work station from the main entrance?
  • Write the sentence “Today is Global Accessibility Awareness Day” on Facebook and post it to public. Wait!!! do this just with keyboard. Some computer users cannot use mouse.
  • Try calling a friend from your smart phone, the challenge is do it in sunlight. This is how low vision users experience the digital content
  • Watch videoExternal Website, just watch it, close your years, experience the difficulty faced by deaf or hard-of-hearing users.
  • If you own a website or a developer/ QA engineer do these simple checks on your websites. It just takes 10 minutes

Global Accessibility Awareness Day GAAD 2017 events in India

Deque Software Pvt Ltd at Hyderabad

WHEN: 18 MAY 2017

02:00 PM to 7:00 PM
WHERE:
T-HUB CATALYST BUILDING
IIIT-H Campus, Gachibowli
Hyderabad- India
Phone: 9652129697
Registration and informationExternal Website

Mitra Jyothi, Prakat Solutions and CIS at Bangalore

When: May 18th, From 2: 00 pm to 7: 00 p.m
Where:
NIMHANS Convention Centre
Hosur Road

Lakkasandra, Behind Bus Stop

Bengaluru, KARNATAKA 560029

Registration and informationExternal Website

GAAD 2017 celebrations by Paypal at Bangalore

When: May 18th, From 10: 00 am to 1: 00 p.m
Where:
PayPal India Pvt. Ltd.
8th Floor, Tower 11, Pritech Park SEZ
RMZ Eco Space Campus, Bellandur, Outer Ring Road
Bengaluru, Karnataka 560103

Registration and other detailsExternal Website

GAAD 2017 by Aubergine Solutions Pvt. Ltd at Ahmedabad

On May 19th, between 5.30 pm and 6.30 pm on basics of web accessibility. Details on GAAD 2017 at AhmedabadExternal Website.

About Global Accessibility Awareness Day (GAAD)

ASP .NET Web Form Controls Accessibility

Couple of days ago one of my friends asked me if we can make asp.net form controls accessible. I said “YES” and explained how to make them accessible for user. So here I am penning down my thoughts on asp.net form controls.

In HTML, authors use <input> tag to create a text field or radio button or checkbox and <label> tag to provide a proper label for the input fields. The label and input fields are associated using ‘for’ and ‘id’ attributes. The value of ‘for’ attribute must be equal to value of ‘id’ attribute.

<label for=”firstname”>First Name</label><input type=”text” name=”fname” id=”firstname” />

Like HTML, ASP.NET has its own form controls for label and input elements. They are not same as those used in HTML. Let us see the asp.net equivalent tags for textbox, select drop down, check box and radio button.

 

Textbox:

The label and textbox in asp.net is written as

<asp:Label runat=”server”>First Name</asp:Label>
<asp:TextBox ID=”firstname” runat=”server” />

In asp.net, <asp:Label> will not support the conventional “for” attribute which is used to map the text fields. A property named “AssociatedControlID” is used for <asp:label> control. It is equivalent to “for” attribute in HTML. The value of “AssociatedControlID” must be equal to ID of text box.

<asp:Label AssociatedControlID=”firstname” runat=”server”>First Name</asp:Label>
<asp:TextBox ID=”firstname” runat=”server” />

The above asp.net code is converted into HTML when it is compiled and rendered in a browser. The “AssociatedControlID” attribute is converted to “for” attribute.

<label for=”firstname”>First Name</label>
<input type=”text” name=”firstname” id=”firstname” />

 

Note: If “AssociatedControlID” is not used, <asp:Label> is rendered as a <span> element instead of <label>.

<asp:Label runat=”server”>First Name</asp:Label> will be rendered as <span>First Name</span>

 

Checkbox & Radio button:

Unlike text field where explicit <asp:label> should be defined, it is not required to use <asp:label> explicitly for a checkbox and radio buttons in asp.net. Instead a property called “TEXT” has to be defined in checkbox tag and radio button.

<asp:CheckBox ID=”checkboxtest” text=”Web Accessibility” runat=”Server” />

It will be rendered as

<input id=”checkboxtest” type=”checkbox” name=”checkboxtest” /><label for=”checkboxtest”>Web Accessibility</label>

 

<asp:RadioButton ID=”radiobuttontest” GroupName=”web” text=”Web Accessibility” runat=”Server” />

It will be rendered as

<input id=”radiobuttontest” type=”radio” name=”web” value=”radiobuttontest” /><label for=”radiobuttontest”>Web Accessibility</label>

 

Fieldset:

To group the similar form fields, fieldset is used in HTML with a descriptive legend. Similarly in asp.net, “panel” is used to group the similar form elements.

<asp:Panel ID=”panelmain” runat=”server”>Form fields goes here</asp:Panel>
<asp:Panel> tag generates a <fieldset> tag enclosed in <div>.
<div id=”panelmain”><fieldset>Form fields goes here</fieldset></div>
To get a legend tag, a property names “GroupingText” has to be used for <asp:Panel> tag

<asp:Panel ID=”panelmain” runat=”server” GroupingText=”Sample grouping”>Form fields goes here</asp:Panel>

It is rendered as

<div id=”panelmain”>
<fieldset>
<legend>Sample Grouping</legend>
Form fields goes here
</fieldset>
</div>

 

References:

  1. Grouping related form elements
  2. Accessibility in ASP.NET External Website
  3. Form elements accessibility

User Experience Designs with Accessibility In Mind Part 2

Thank you for reading first of two part series on User experience designs with accessibility in mind. If you haven’t already read my previous post I recommend reading the first part.

Now as you have a basic understanding of different disabilities the impact they have on inclusive design, it is important to know the accessibility standards by W3C called Web Content Accessibility Guidelines WCAG 2.0External Website. Though WCAG 2.0 have more than 60 success criteria laid against 3 conformance levels (A, AA, AAA), W3C recommends only level A and level AA success criteria. Out of these there are only few success criteria that can be considered during the UX stage. You can find the relevant success criteria in the W3C Accessibility responsibility breakdownExternal Website page. Each success criteria that is considered during user experience stage are available in the table under Interaction design and usability.

Inclusive designExternal Website at Microsoft, Amazing information for designers to begin with and spend rest of the life designing products, websites and applications keeping accessibility in mind.

An excellent book authored by Derek Featherstone, Founder of Simply Accessible, Foundations of User experience and accessibilityExternal Website explains where does accessibility fits in the process of user experience.

The webinar by Rajesh Kalidindi, explains the design considerations for accessibility with real time examples. The session is very informative and impressive. It is definitely worth watching. Accessibility guide for UX professionals (webinar registration required)External Website

Fitting user experience designs into accessibility is a vast topic, however these resources will help user experience professionals understand and implement universally accessible and inclusive products, applications and websites. It is not only the WCAG guidelines to be considered but also the requirements of 20% people with disabilities who use your product, users who have age old difficulties, those who are not technology savvy and those who have language discomfort.

Other resources that are worth reading

Last updated on May 5, 2017

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.