You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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.
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.
@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 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
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.
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
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
The text was updated successfully, but these errors were encountered: