Javascript Question posted in
A very good W3school tutorial can be found here.

Javascript – In NVDA, Button receives focus upon pressing Enter/space in the inner icon when aria-label/aria-labelled is used

Steps to Reproduce the Issue:

Open the link: https://nvda-test.w3spaces.com/button-accessibility-label.html
Two buttons: This page contains two buttons, each with a focusable icon inside.
ARIA Attributes: The first button has an aria-label attribute or an aria-labelledby attribute, while the second button does not have either.
NVDA Behavior: When using a screen reader like NVDA, focusing the icon within the first button (the one with aria-label or aria-labelledby) and pressing Enter or Space will cause the focus to return back to the button itself. This issue doesn’t occur with the second button (without ARIA attributes).
Project Use Case:

In my project, I have a button with a close icon inside. Ideally, focusing the close icon and pressing Enter/Space should remove the button from the page. This works as expected without NVDA, but the issue mentioned above arises when NVDA is enabled. While removing the aria-labelledby attribute from the button fixes this issue, but it’s necessary for other accessibility concerns and hence cannot be removed.

I want to prevent the focus from returning to the button when pressing Enter/Space on the icon inside the button, while still maintaining the aria-label or aria-labelledby attribute on the button for accessibility.

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    The issue got resolved by changing the NVDA from "Browse mode" to "Focus mode". Figured out @keydown on Space/Enter won't fire because NVDA intercepts the keys if it is in browse mode, which is normal.Switching to focus mode (insert + space will hear a "typewriter" sound), the code should get passed through and focus does not switch back to button


  2. 0

    The problem isn’t related to ARIA, and isn’t specific to NVDA. It also occurrs with Jaws, whether or not there is a label on the button.

    IF we look at your code:

    <button class="w3-btn w3-orange w3-xlarge" aria-label="home">Button<i tabindex="0" class="w3-margin-left fa fa-home"></i></button>

    In fact you have a nested focus issue.
    The button is naturally focusable, and by adding tabindex=0 on the <i> element, you create a second focusable element inside the button.
    If you use tab to navigate through the page, you will observe that you have two tab stops: one for the button, and another one specifically for your icon.

    This is an accessibility antipattern, and maybe even an UI design antipattern. It must be avoided at all cost. It raises several questions / problems:

    • What is the accessible name of the icon ?
    • When clicking / pressing enter on the icon, should the click also be triggered on the button ?
    • When the focus is on the icon, is the focus also at the same time on the button ?

    This goes much beyond screen reader accessibility.

    For the two last questions, the answer can as well be yes or no, and not what you expect. It’s hard to control in all situations, so is better avoided.

    For the first question, every focusable element must have their own accessible name, sufficiently clear and distinguishable from others, so a screen reader user exactly knows what is the element for / what it does.
    In your code, the icon has no accessible name on its own. So the screen reader doesn’t know well what to say / show on braille display, this is undefined behavior. Most (if not all) screen readers try to find some text beyond the element, and end up taking the same accessible name as the button. This creates confusion, as the same thing seem to appear twice.

    The solution is normally very simple: remove tabindex=0 from <i>, and the problem should be gone.

    However, if clicking on the icon triggers another action than clicking on the button, you should instead:

    • Change your code to put the icon outside of the button
    • Keep tabindex=0
    • Put a proper accessible name on the icon
    • Consider also putting the icon outside of the icon visually or design the UI in another way, as you will anyway encounter the nested click problem with the mouse or touch screen
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search