Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessibility issue: inactive buttons in tab order #1086

Open
scoutb-cogapp opened this issue Aug 13, 2024 · 3 comments
Open

Accessibility issue: inactive buttons in tab order #1086

scoutb-cogapp opened this issue Aug 13, 2024 · 3 comments

Comments

@scoutb-cogapp
Copy link

UV version: [email protected]

I'm submitting a: bug report => please fork one of these codesandbox examples with a repro of your issue and include a link to it below

Page area

back and forward buttons in header panel as well as image controls

Issue description

The back buttons for the first image and the forward buttons for the last image are inactive.

  • in the header panel there are two on each side, one to move back or forth by one image and one to move all the way to the beginning/end of the images.
  • in the image controls there is also an arrow on either side of the image that moves to the previous or next image.

The problem is that the inactivity is insufficiently conveyed: The items remain in the tabbing order so are still accessed when a user navigates by keyboard. This indicates they are acvite. The colour change for the buttons in the header panel is also relatively subtle and will not be visible to all users.

Steps to reproduce

  1. open this manifest
  2. navigate to any of the backward buttons and observe that they are accessible even though this is the first image and there is no previous image to move to
  3. activate a screenreader and navigate to the same buttons, observe that they are announced no different from when they are active

Expected behaviour

I would expect tab order to skip inactive links/buttons/elements. Sometimes it can be useful to screenreader users to have them there so they know about certain functionality. In this case, I see no reason to do so since a user will know that where there is a next button, there will be a previous button once there is a previous item.

Possible fix

Remove the buttons from the tab order when they become inactive.

Alternatively, if it is desired that they remain in the tab order, ensure that their inactive state is in some form known to and announced by assistive technologies.

WCAG criterion

4.1.2 Name, Role, Value (Level A)

Related code example

<button class="btn imageBtn first disabled" title="First Image"><i class="uv-icon-first" aria-hidden="true"></i><span class="sr-only">First Image</span></button>
@hannahb-cogapp
Copy link

At the moment the buttons receive styling to indicate that they're disabled with the "disabled" class, this doesn't indicate to screen readers that the button is disabled. In addition to the disabled class the buttons should receive the HTML disabled attribute.

@demiankatz
Copy link
Contributor

@Saira-A very recently (yesterday, in fact) fixed some of these in #1093. @Saira-A, did you try systematically searching the code for other instances of the 'disabled' class? I haven't tried that, but it might be easy to extend your fix further if there are more references that we missed. Or maybe we need to create utility methods for disabling and enabling things so we can more easily change this from a central place if we need a different strategy in the future (and to reduce code lines).

@Saira-A
Copy link

Saira-A commented Aug 29, 2024

@Saira-A very recently (yesterday, in fact) fixed some of these in #1093. @Saira-A, did you try systematically searching the code for other instances of the 'disabled' class? I haven't tried that, but it might be easy to extend your fix further if there are more references that we missed. Or maybe we need to create utility methods for disabling and enabling things so we can more easily change this from a central place if we need a different strategy in the future (and to reduce code lines).

Yes, I think the search bar in the footer panel works the same way

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Accessibility Backlog
Development

No branches or pull requests

5 participants