CODEWITHSUNDEEP
htmluser-interfaceaccessibilityrolesaccessibilityservice
Scorpio
Scorpio

Reputation: 1171

Not able to find the correct accessibility role for list elements

 <ul class="draggable-list" role="listbox">
    -- list runs in for loop around 5 li elements (all draggable elements)
    <li tabindex="0" role="option">
    </li>
 </ul>

All the drag drop li elements are working fine on mouse click drag and drop. But when I try to use keyboard enter for accessibility.. there is a on key press function which works fine in chrome but fails in IE and Safari. I have tried role="listitem" but then on enter key press nothing happens on any of the browsers. is there any specific role i can use across browsers for list items which needs to be moved (basically need on key press event to fire, where I am deciding the location to move). I have tried role="application" this works across browser but there some other accessibility issue that come up. Everyone in the team suggested not to use application as a role for list elements (That doesn't seem correct to me as well but thts the only role which has worked on IE and safari safari for key press event)

list item

Note: list item doesn't have any keyboard interactions

Upvotes: 1

Views: 3056

Answers (2)

slugolicious
slugolicious

Reputation: 17535

Note that specifying a role does not give you any behavior. See "What adding a role does not do"

Adding an ARIA role will not make an element look or act differently for people not using assistive technology. It does not change the behaviours, states and properties of the host element but only the native role semantics.

In other words, changing the role only changes how the screen reader announces the element (the "semantics"). It doesn't cause the element to behave any differently.

Also note that the following in a previous answer is not quite accurate:

"A lot of screen-readers (depending on their user-settings) do not pass key-presses to the browser"

This is not true. Depending on the role of the element, the screen reader (with default settings) can switch between virtual/explorer/browse mode to application/forms mode, thus passing key presses to the browser (and thus to your element). For a list of roles that do this, see "5.1 Fundamental Keyboard Navigation Conventions". Even though that section talks about keyboard navigation and which roles require you to implement arrow key navigation, it essentially tells you which roles will allow key presses to pass through to your element.

So if you want key presses, use one of the roles listed in that section. As a last resort, use role="application".

Upvotes: 2

Tobias Christian Jensen
Tobias Christian Jensen

Reputation: 182

From my experience, you can never be certain that role="application" will work consistently from time to time.

Roles: role="listitem" is supposed to be used when one or more options are to be selected. What you are describing sounds to me more like a regular list that the user can re-order, and not something like a <select>. If I'm correct, you could consider using a role="list" with role="listitem" for children - and as it happens, that comes for free when using a <ul>, so you can completely skip the role attributes here. You can also keep using the role="listitem", because some screen-readers will let users go item-by-item a little easier. Depends on your needs and preferences.

But addressing the real problem: A lot of screen-readers (depending on their user-settings) do not pass key-presses to the browser, so your onkeypress will not fire. At least not reliably. That's because the screen-reader relies heavily on keyboard shortcuts, and those might differ from user to user. You would not want to overwrite those. However, when something can be tabbed to, the screen-reader will happily fire an onclick event when the user presses the Enter key.

When grabbing an item, you could consider adding aria-grabbed="true" and aria-dropeffect="move". Both are marked as "Deprecated", as a new method of conveying these are in the works, but I think they are still supported by some major screen-readers, and I have yet to find a proper alternative.

Upvotes: 0

Related Questions