Carousel behaviour needs more clarification and a demo with matching behaviour

オープン
  • 何か問題がありますか？
#136 コメント 8 件 リアクション 0 件 担当者 1 名 GitHub で見る

@Heydon がすでに取り組んでいます。

2019年11月13日 から。

評価

この issue はまだ評価されていません。

説明

accepted improvement needs discussion

How the carousel should behave when someone navigates with the tab key and/or with a screen reader is unclear and does not appear to describe what is happening in the demo. Such that the demo does not appear to behave quite as I would expect.

When navigating the carousel demo with the tab key I observed:

  • first tab press moves focus to the 'next' button.
  • second tab press moves focus to the first list item.
  • third tab press moves focus to the in-item topic link (personally not a fan sub-links in carousel items).
  • fourth-seventh tab presses move focus through the other visible items and topic links.
  • eighth tab press scrolls the carousel but doesn't appear to focus on anything specific (and certainly not the next list item).
  • ninth tab press appears to move focus to the last/7th item in the list and it's in-item link (rather unexpected).
  • tenth tab press again doesn't appear to focus on anything specific (not sure what to expect at this point).
  • eleventh tab press moves focus to the 'previous' button.
  • continued tab presses then move through the remaining now visible items and topic links.

If navigating with the tab key should (after the next button) move through the full list of items, then it is not doing this. If navigating with the tab key should trigger the carousel to scroll when moving onward from the last visible item, and then focus on the next/previous buttons before continuing through the new visible items, then the demo is not not doing this correctly either.

Which and what it is supposed to do is unclear from the documentation.

When navigating with screen reader controls (not the tab key) the behaviour is more consistent with what I would expect, though it takes 8 arrow presses to move through each item in the list rather than grouping the content within each item.

One of the big challenges with carousels for keyboard/switch/screenreader navigation is balancing between jumping through a list with next/previous (or scroll forward/backward) buttons, and being able to select an item that is currently visible in the carousel.

When navigating with keyboard control, it is nicely straightforward to ignore the next/previous buttons and move focus from item to item in the list, scrolling items into view as they gain focus. However, this quickly becomes tedious if a carousel contains a long list of items and the user cannot easily jump ahead.

When navigating without sight, it isn't obvious that not all list items are visible/available or that there is a way to skip ahead in the list.

And on mobile, I've seen some carousels without the next/previous arrows, which is not ideal for users who may not understand to swipe. Triggering scroll by touching a partially visible item at the edge of the screen, and keeping the item that currently has focus in the centre, can both help with this (Amy Leak did some user research around this for something else).

It would be good to document the navigation user journey for each type of user (keyboard/switch, screen reader, mobile with/without swipe gestures, etc) to be clearer about how a carousel should behave. And to ensure the demo matches the expected behaviour.

主要言語
JavaScript
スター
50
フォーク
19
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

bbc/gel のほかの issue

bbc/gel の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。