CSSのoutlineは消す前にkeyboardで移動した位置を見えるようにする

linkやbutton、入力欄のoutlineをCSSで消すなら、keyboardで操作したときに現在位置が見える表示を代わりに用意します。mouseでpageを見ていると、薄い枠線がデザインを崩して見えることがあります。しかし、Tab keyでlinkやformを移動する人にとっては、その枠線や色の変化が、次に操作する場所を知る手掛かりです。見た目を整えるために消すなら、操作できることまで消さないようにします。

WCAG 2.0のSuccess Criterion 2.4.7は、keyboardで操作できるuser interfaceに、focus indicatorが見える操作方法を求めています。ここで必要なのは、特定の色や枠線を使うことではありません。利用者がkeyboardで移動したとき、どのlink、button、入力欄へfocusがあるかを見分けられることです。

outlineを消すこととfocusを見せないことは別である

browserが標準で表示するoutlineは、linkやbuttonがfocusを受けたときに出ることがあります。制作時にoutline: none;やoutline: 0;を共通CSSへ書くと、標準のindicatorを消せます。けれども、これだけでは代わりの表示がありません。mouseでhoverした色だけを用意しても、keyboardだけで移動するときには位置が分からないままです。

focusの表示は、hoverの表示をそのまま使っても構いません。ただし、hoverだけでなく:focusにも同じ条件を指定します。background color、border、outline、文字色などを変える場合は、周りの色と混ざって見えなくならないかを確認します。色だけを薄く変えるより、枠線、background、文字のいずれかを十分に変え、現在位置が分かるようにした方がよいでしょう。

a:focus,
button:focus,
input:focus,
textarea:focus,
select:focus {
  outline: 3px solid #005a9c;
  outline-offset: 2px;
}

この例は、全てのsiteへ同じ色と太さを勧めるものではありません。すでにborderがあるbuttonや入力欄では、外側のoutlineの方が見つけやすい場合があります。dark backgroundの上では、別の色が必要になることもあります。共通CSSを一行で消す前に、実際のbackground、文字、画像の上でfocusが見えるかを確認します。

menuとformでは操作の順序から確認する

focus indicatorは、CSSだけを見ても確認できません。公開pageを開き、mouseを使わずにTab keyで順に移動します。top pageなら、logo、global menu、本文のlink、footerのlinkへどう移動するかを見ます。問い合わせpageなら、入力欄、確認事項、送信buttonまで進み、どの要素が現在選ばれているかを確認します。

説明用の仮例として、headerに複数のmenuがあり、本文に資料請求button、問い合わせformに名前、mail address、内容の入力欄があるpageを考えます。Tab keyを押すたびに、focusがlogoからmenuへ、menuから本文へ、formの各欄へ移ります。このとき、見た目の順番とfocusが移る順番が大きく食い違うと、利用者はどこへ進んだのか分かりません。

CSSで位置を変えている要素や、JavaScriptで開くmenuは特に確認が必要です。画面では右側に見えるbuttonがHTMLでは先に置かれていると、keyboardでは想定と違う順序で移動することがあります。見栄えのためにtabindexを増やして順序を直そうとすると、別のpageでさらに順序が崩れる場合があります。最初にHTMLの順序を、読む人と操作する人の順序として整えます。

Tab keyだけで全ての操作を終えられるかは、siteの目的によって確認する範囲が変わります。問い合わせが目的なら、form入力と送信までが最優先です。資料pageへ読者を案内するsiteなら、記事から資料linkまで移動できることを先に見ます。全ての装飾要素を確認対象にするのではなく、利用者が情報を読み、連絡や申込みへ進む道を選びます。

errorとfocusの役割を混同しない

formの入力にerrorがある場合、red borderやmessageを表示することがあります。これは入力内容を直す必要があることを伝える表示です。一方、focus indicatorは、今keyboard操作が届く場所を伝える表示です。errorの色が付いているからといって、focusが見えるとは限りません。

たとえばmail address欄が未入力でerrorになったあと、利用者がTabでその欄へ戻る場面を考えます。error borderだけでは、どの欄を修正する必要があるかは分かっても、いま文字を入力できる状態かは分かりにくいことがあります。input:focusの表示を残し、errorの説明を入力欄の近くに置けば、「どこへ入力するか」と「何を直すか」を分けて伝えられます。

.form-field input:focus,
.form-field textarea:focus {
  outline: 3px solid #005a9c;
  outline-offset: 2px;
}

.form-field.is-error input,
.form-field.is-error textarea {
  border-color: #b00020;
}

このように、errorとfocusへ別の指定を置くと、errorの状態でも現在位置が見えます。二つの色を置いたから十分ではありません。実際にkeyboardで入力欄へ進み、messageが読めるか、focusがborderや背景に隠れないかを確かめます。errorを表示するJavaScriptがfocusを勝手に別の場所へ移す場合も、利用者がどこへ戻ったか分かる表示が必要です。

WCAG 2.0のC15 techniqueは、focusを受けたlinkやinputへCSSで視覚的なfeedbackを与える例を示しています。これは一つの実装例です。特定のCSSを貼ればpage全体が使いやすくなるわけではありません。header、本文、form、modal windowのように、操作する場所ごとにfocusが見え、次の操作へ進めるかを確認します。

共通CSSを直す前に対象pageを決める

a:focusやbutton:focusを共通CSSで直すと、site全体に影響します。だからといって、一つずつのpageだけで表示を足すと、同じbuttonでもpageごとにfocusの見え方が変わります。まず、共通のlink、button、form controlのうち、どこまでを同じruleで扱うかを決めます。そのうえで、dark background、写真の上、white backgroundなど、代表的な場所で確認します。

既存themeを修正するときは、どのCSSがoutlineを消しているかを探します。reset stylesheet、button用のclass、form pluginのstylesheetなど、複数のfileが同じ要素へ指定していることがあります。新しいruleを最後に足して一時的に見えるようになっても、別のpageでより強いselectorが上書きしているかもしれません。まず、問題が出る要素を一つ選び、browserの開発者toolでどのruleが効いているかを確認します。

作業を分けるときは、次の順が扱いやすいでしょう。

1. mouseを使わずに代表pageを開き、focusが見えないlink、button、inputを記録する。
2. その要素でoutlineやbackgroundを消しているCSS ruleを確認する。
3. 共通に使えるfocus表示を一つ決め、まず代表要素へ適用する。
4. header、本文、form、dark backgroundの上でTab操作を繰り返す。
5. error表示やJavaScriptで開くmenuがあるpageを別に確認する。
6. 修正したfile、対象class、確認したpage、未確認の場所を記録する。

この手順は、全てのpageを同じ色の枠線にするためのものではありません。keyboardで操作するとき、利用者が自分の位置を見失わないことを確かめるためのものです。CSSの見栄えを整える作業と、公開後に問い合わせや申込みへ進める状態を守る作業を一つにします。

最初の一手は、問い合わせpageを開いてTab keyを押し、最初に見失う場所を一つ記録することです。その要素のoutlineを消しているruleを確認し、代わりのfocus表示を付けます。mouseで見た印象ではなく、実際に操作した順序で確認します。