swipeで切り替えるcarouselは一指で進めるbuttonを別に置く

swipeで写真や案内を切り替えるcarouselには、前後へ進むbuttonを別に置きます。画面を横へ払えることと、誰もが同じ内容へ進めることは別です。指を決まった方向へ動かす操作や二本指で広げる操作を使うなら、tapやclickのように一点を操作する方法でも同じ結果へ進めるようにします。carouselの動きを派手にするためではなく、読者が必要な案内を途中で失わないための設計です。

W3Cは4月24日、WCAG 2.1をProposed Recommendationとして公開しました。Pointer GesturesのSuccess Criterion 2.5.1では、複数のpointerを使う操作、または決まった経路を動かす操作で行う機能について、single pointerで経路を指定しない方法でも操作できることを示しています。署名のように経路自体が情報になる操作は例外です。画像を次へ送る、地図の倍率を変える、表示順を切り替えるといった画面は、まず別の操作方法を用意できるかを考えます。 WCAG 2.1 Proposed Recommendation

swipeできることと一指で操作できることを分ける

touch screenの画面では、横へswipeして次の写真を出す見せ方がよく使われます。ここでいうswipeは、指がどの方向へ、どれくらい動いたかによって処理が決まる操作です。開始位置と終了位置だけでなく、横へ動かしたことが必要になるため、buttonを一度押す操作とは違います。指先を細かく動かしにくい人、片手で端末を持つ人、mouseや別のpointer deviceを使う人にとっては、同じ操作が難しいことがあります。

single pointerの代替は、必ずしも同じgestureを簡略化することではありません。carouselなら「前へ」「次へ」のbuttonを置けばよい。写真を拡大する画面なら、拡大と縮小のbuttonを置けばよい。地図なら、現在地を動かすgestureだけに頼らず、検索、拡大、縮小、表示切替など、目的ごとのcontrolを用意します。読者が欲しいのはswipeを成功させることではなく、次の写真を見ることや、必要な場所を探すことです。操作方法と得たい結果を分けると、代替の作り方が見えます。

複数指を使うpinchも同じです。画面を広げて商品写真を拡大する機能があるなら、+と-のbutton、または拡大率を選ぶcontrolを置きます。pinchを残すことは構いません。しかし、pinchだけが使えた人だけに細部を見せる構成にはしません。写真の中にある重要な条件は、画像を拡大しなくても本文やcaptionで読めるようにします。画像操作の代替と、情報そのものの代替は別に確認します。

carouselは自動再生より先に目的を決める

carouselへ複数の案内を入れるとき、最初に決めるのはswipeの実装ではありません。そこに置く案内が、順に読ませたい説明なのか、どれか一つを選んでほしい案内なのか、同じ内容を飾りとして見せるだけなのかを決めます。目的が違えば、buttonの名前、表示する順番、止める方法も変わります。

たとえば、三つのserviceを紹介するcarouselを考えます。各slideが別のservice pageへ進む入口なら、写真だけを横へ送れるようにして終わりません。service名、短い説明、link先、前後buttonを各slideで確認します。swipeできない人も、buttonを押して同じslideへ進み、service pageへ移動できる状態にします。slideの切替を自動で進める場合は、読者が途中で本文を読めなくならないかも確認します。動く演出があることと、案内を読めることを同じ評価にしません。

反対に、会社の建物や制作物を一枚ずつ見せるだけなら、carouselが必要かを見直します。少ない写真を載せるために、独自script、swipe判定、前後button、responsive時の不具合を増やす理由はありません。縦に写真を並べる、一覧pageへlinkする、通常のgalleryを使う方法で目的を果たせるなら、その方が管理する場所は少なくなります。新しい操作を足す前に、読者が何を選ぶ必要があるかを確かめます。

代替buttonは画面の端に隠さない

前後buttonを追加しても、指で押しにくい位置に小さく置けば使いにくさは残ります。carouselの左右端へ矢印だけを薄く置く場合、写真の明るさによって矢印が見えなくなることがあります。hoverしたときだけ表示する作りでは、touch screenでbuttonの存在に気付けません。buttonは、どの方向へ進むかが文字または分かる記号で伝わり、現在のslideを覆わず、pointerで押せる位置に置きます。

表示を確かめるときは、PCのmouse操作だけで終えません。mobileの幅でpageを開き、左右buttonを一度ずつ押します。次に、carouselの中央を軽くtapしても意図しない切替が起きないかを見ます。swipeでも同じslideへ進めるか、最初と最後でbuttonがどう変わるか、slide内のlinkを押したときに別のslideへ動かないかを確認します。動きが速い場合は、buttonを押した人がどの内容へ移ったかを見失わないかも見ます。

説明用の仮例として、予約できる日程を横並びのcarouselで見せる画面を考えます。日付をswipeしないと次の週へ進めない作りでは、希望日を探せない人が出ます。この場合は「前の週」「次の週」のbuttonを置き、現在表示している期間を文字で示します。日程を選んだあとに確認画面へ進むなら、選んだ日時を画面上で確認できるようにします。ここで必要なのは、swipeを上手に使わせることではなく、日程を選び、確認し、申し込めることです。

例外を広げず操作の必要性を確かめる

Pointer Gesturesには、複数指や決まった経路が機能そのものに欠かせない場合の例外があります。手書きの署名を入力する画面では、指やpenで描いた経路が記録する内容になるため、buttonだけで同じ操作を置き換えられません。けれども、例外があるからといって、carousel、gallery、map、menuまでgestureだけで作ってよいことにはなりません。

判断するときは、「その指の動きがなければ、利用者が得たい結果を作れないか」と問い直します。答えが写真を送る、一覧を開く、倍率を変える、次のstepへ進むことであれば、single pointerのcontrolを置ける可能性があります。答えが線を描く、形を作る、二本の指でしか表せない内容を入力することであれば、例外に近づきます。画面の見た目がgestureを前提にしているかではなく、機能の中身を見て決めます。

制作を頼むときも、「mobileでswipeできるcarouselにしてください」とだけ伝えません。carouselへ載せる内容、各slideのlink先、前後button、buttonの文言、最初と最後の表示、keyboardでの移動、mobileで確認する画面幅を渡します。制作側はscriptやCSSを実装できます。どの案内を残し、読者が次に何を選べるべきかは、siteを持つ側が決めます。実装を任せることと、操作の目的を任せきりにすることは別です。

確認はgestureを使わない順から始める

公開前は、先にgestureを使わずに確認します。

この順番なら、swipeが快適かを確かめる前に、swipeできない人も必要な情報へ進めるかを見られます。gestureを外した状態で内容が読めないなら、animationの速度や画像の切替を調整しても問題は残ります。buttonを足しても、link先が古い、service名が写真でしか分からない、予約内容を確認できないといった問題は別に直します。

WCAG 2.1のPointer Gesturesは、画面からgestureをなくすための話ではありません。複雑な操作を残す場合にも、単純なpointer操作で同じ目的を果たせるようにする考え方です。最初の一手は、公開中のcarouselを一つ選び、swipeせずに最初から最後まで進むことです。途中で読めないslideや押せないlinkがあれば、button、本文、link先を分けて直します。操作の演出より、読者が案内を選べることを優先します。