Why do you choose to guide your clients towards the "grouped" carousel implementation pattern of rather than the "tabbed" pattern (cf. w3.org/TR/wai-aria-practices-1.1/#...)?
Also, when activating a slide using the slide picker buttons/dots in your "good carousel" example, you don't set focus to the activated slide (as suggested here w3.org/WAI/tutorials/carousels/fun...). Is there an accessibility reason for not doing this, or it was just out of scope for your article?
1) When testing the "tabbed" pattern with live low-vision, blind, and deafblind users at Accessible360, we found that that it was very confusing and unintuitive for them. Specifically:
Low-vision users struggled because carousels typically do not visually resemble tabbed interfaces, so they would have no reason to believe that those specific key commands are available. Some of the more experienced keyboard-only users were able to deduce the commands by trial and error, but none associated the carousels conceptually with tabbed interfaces. There was additional concern that since this was difficult even for experienced KB users to figure out, there would likely be disproportionate impact on users with cognitive disabilities.
Blind screen reader users struggled with the pattern because in practice they never experience tabbed interfaces where the tabs follow the tabpanels they control. Since aria-controls doesn't really do anything in current-gen screen readers, they would have to deduce that the tabs control the preceding content. Again there were concerns about cognitively impaired users. Anecdotally, the sighted and non-sighted members of the testing team had significant difficulty communicating their frustrations and expectations because of the discrepancies between the visual appearance and the programmatic implementation (meaning the use of terms like "tabs" or "tabpanels" in conversations lead to a lot of confusion).
2) Moving a keyboard user's focus programmatically is generally very disruptive, especially with non-native components (like carousels) that don't have established behaviors or clear instructions. The auditors at Accessible360 felt this was a violation of WCAG 3.2.2, which could be remediated with visible instructions, though a more intuitive solution seemed to be to just not move a user's focus. Keep in mind that carousel slides can contain a huge variety of content, some of which may be focusable natively, some not. If the slides were block-level link cards, setting focus to them may not be as strange since a keyboard user would probably have tabbed over them as they were exploring the carousel. But if the slides were wrappers containing multiple interactive elements and static content, the slide wrapper would need tabindex="-1" in order to receive focus, and we found that keyboard-only users were very confused about why they could reach those wrappers sometimes (from the slide dots) and not others (tabbing naturally).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for this thought provoking article Jason.
Why do you choose to guide your clients towards the "grouped" carousel implementation pattern of rather than the "tabbed" pattern (cf. w3.org/TR/wai-aria-practices-1.1/#...)?
Also, when activating a slide using the slide picker buttons/dots in your "good carousel" example, you don't set focus to the activated slide (as suggested here w3.org/WAI/tutorials/carousels/fun...). Is there an accessibility reason for not doing this, or it was just out of scope for your article?
Cheers
-- ickers
1) When testing the "tabbed" pattern with live low-vision, blind, and deafblind users at Accessible360, we found that that it was very confusing and unintuitive for them. Specifically:
aria-controlsdoesn't really do anything in current-gen screen readers, they would have to deduce that the tabs control the preceding content. Again there were concerns about cognitively impaired users. Anecdotally, the sighted and non-sighted members of the testing team had significant difficulty communicating their frustrations and expectations because of the discrepancies between the visual appearance and the programmatic implementation (meaning the use of terms like "tabs" or "tabpanels" in conversations lead to a lot of confusion).2) Moving a keyboard user's focus programmatically is generally very disruptive, especially with non-native components (like carousels) that don't have established behaviors or clear instructions. The auditors at Accessible360 felt this was a violation of WCAG 3.2.2, which could be remediated with visible instructions, though a more intuitive solution seemed to be to just not move a user's focus. Keep in mind that carousel slides can contain a huge variety of content, some of which may be focusable natively, some not. If the slides were block-level link cards, setting focus to them may not be as strange since a keyboard user would probably have tabbed over them as they were exploring the carousel. But if the slides were wrappers containing multiple interactive elements and static content, the slide wrapper would need
tabindex="-1"in order to receive focus, and we found that keyboard-only users were very confused about why they could reach those wrappers sometimes (from the slide dots) and not others (tabbing naturally).