候補を読み上げず、キーボードで選べないオートコンプリート

旅行サイトの予約フォームに「行き先」の欄があります。「por」と入力すると、欄の下にPorto、Portland、Portsmouthのリストが開き、その上に「候補3件」と表示されます。マウスならPortlandをクリックすれば欄に入ります。キーボードでは、作り方によって結果が違います。ある作りでは矢印キーが何もせず、Tabキーで欄から「検索」ボタンへ移ってしまい、リストはまったく使えません。別の作りでは、下矢印キーで青い強調が都市を移動し、Enterキーで選べますが、スクリーンリーダーは移動しても何も言わないか、「por」を読み返すだけです。「pxq」と入力すると行が「行き先が見つかりません」に変わりますが、これも読み上げられません。

達成基準2.1.1は、マウスでできることをキーボードでもできるよう求めています。一つ目の作りでは、候補はクリック処理を付けた li 要素で、フォーカスを受け取れず、どのキーも届きません。達成基準4.1.2は、操作部品の役割と状態、利用者が変えられる値を支援技術が取得できるよう求めています。二つ目の作りでは、入力欄は普通のテキスト欄のまま、リストには役割がなく、強調はCSSのクラスです。キーボードでは動きますが、どの候補が強調されているか、リストが開いているかを、ブラウザーはスクリーンリーダーに伝えられません。件数の行はステータスメッセージで、達成基準4.1.3はフォーカスを動かさずに伝えることを求めていますが、普通の p 要素です。

入力候補の付いた欄は、行き先、住所、商品など、フォームのいちばん大事な手順の入り口であることがよくあります。スマートフォンでは画面キーボードの下にリストが開くことがあり、画面が見える人も、選べるものがあるかを件数の行で知ることになります。

10グループ中4グループに影響

• 全盲 （影響あり）
• 弱視 （影響あり）
• 色覚 （影響なし）
• ろう （影響なし）
• 難聴 （影響なし）
• 発話 （影響なし）
• 手の操作 （影響あり）
• 届く範囲・力 （影響なし）
• 認知 （影響あり）
• 光過敏 （影響なし）

• 手の操作が限られる キーボードやスイッチの利用者は候補に届かないため、名前を最後まで正確に入力するしかなく、つづりを一文字間違えると何も一致しません。
• 視覚を使わない スクリーンリーダーの利用者には、候補が出たことも、どれが強調されているかも、何も一致しなかったことも伝わらず、途中までの語をそのまま送信してしまうことがあります。
• 視覚が限られる 入力欄を拡大している画面拡大ソフトの利用者には、その下でリストが開いたことが見えないことがあります。薄い背景色だけの強調は、強制配色で消えることがあります。
• 言語・認知・学習の能力が限られる 地名や商品名のつづりを候補に頼っている人は、リストから選べないと、その助けを失います。

スキャンはページを読み込み、ラベル付きのテキスト欄を見つけます。リストは誰かが入力するまで存在しないため、確認するものがありません。リストがあっても、ARIAのないマークアップには間違えようのある属性がありません。AIにオートコンプリートを頼むと、二つ目の作りそのもの、つまりkeydownの処理と active クラスを書くことがよくあります。リストに role="listbox" を付けても、入力欄に aria-activedescendant がなければ、強調は読み上げられないままです。下矢印キーでリストへフォーカスを移す例もあり、その場合は次の文字を入力しても入りません。リストが使えるかは、入力し、矢印キーを押し、読み上げを聞いて初めて分かります。