w3c / aria-practices

WAI-ARIA Authoring Practices Guide (APG)
https://www.w3.org/wai/aria/apg/
Other
1.21k stars 337 forks source link

Regarding expected behaviors for carousels #831

Open accdc opened 6 years ago

accdc commented 6 years ago

Sorry, I posted this in the wrong place earlier.

This is a placeholder for Carousel.

To follow up with our discussion https://www.w3.org/2018/08/13-aria-apg-minutes.html

Personally, I think using interactive form controls such as ARIA Tabs or Listboxes and the like is overkill for carousels, and that a standard Button role is simpler and provides all of the same functionality without forcing screen reader users into and out of Browse/Virtual cursor and Forms/Applications cursor modes when attempting to interact with it.

This is important for variable scenarios when the carousel paradigm may be used to represent interactive regions such as those including links and buttons, or structural content such as headings, images, and tables, or when even representing simulated wizard constructs consisting of sequential forms.

Also, if what was suggested during the call is done, where when the focused Tab is activated focus moves to the slide container, this breaks the ARIA Tab paradigm where focus is not supposed to be moved away from selected tabs when activated, which will end up being just another case of hacking something that isn't meant to be used for such a purpose and breaking it slightly to do something else.

devarshipant commented 6 years ago

Echoing @accdc;

Consider a carousel operable using left / right arrow keys, that doesn't disrupt focus, and conveys desired information (and status) on the active slide.

It might help to be aligned with Carousel recommendations in Web Accessibility tutorial, or they should be consistent.