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.

Comments are closed.