WCAG 達成基準「入力目的の特定」
WCAG (Web Content Accessibility Guidelines) には、「入力目的の特定」という達成基準があります。
利用者の情報を集める入力フィールドのそれぞれの目的は、次の場合にプログラムによる解釈が可能である:
出典 : WCAG 2.2 達成基準 1.3.5「入力目的の特定」(レベル AA)
- 入力フィールドが、ユーザインタフェース コンポーネントの入力目的の節で示される目的を提供している、 かつ
- フォーム入力データとして想定される意味の特定をサポートする技術を用いて、コンテンツが実装されている。
ウェブの入力フォームをアクセシブルにするためには、各入力フィールドに対して適切なラベルを提供し (参考 : WCAG 2.2 達成基準 3.3.2「ラベル又は説明」)、入力フィールドとラベルをソースコードにおいても紐づけること (参考 : WCAG 2.2 達成基準 1.3.1「情報及び関係性」) が不可欠です。しかし、一部の認知障害のある人にとっては、ラベルだけでは入力フィールドの目的を理解しにくいという課題があり、何らかの追加の手がかりを提供することで、こうした課題を解決できる可能性があります。
上記の WCAG 達成基準「入力目的の特定」は、そのために規定されたものです。
実質的な解決は HTML の autocomplete 属性の記述
とは言え、達成基準の本文 (上記の引用) を読んだだけでは、具体的に何をすればよいのか、わかりにくいかもしれません。「利用者の情報を集める入力フィールド」とありますが、これは WCAG 2.2 の「7. ユーザインタフェース コンポーネントの入力目的」で挙げられている各項目 (氏名、ユーザー名、パスワード、住所、クレジットカード情報、生年月日、電話番号、メールアドレス、など) が該当します。「WCAG 2.2 解説書」の「達成基準 1.3.5 : 入力目的の特定」を見ると、こうした情報を入力させるフィールドに対して autocomplete
属性を記述することが、実質的な解決となっています。
HTML の仕様では、autocomplete
属性はフォームの自動入力補完 (オートフィル) のために用いられることになっていますが、WCAG においては、autocomplete
の属性値をもとにして、ユーザーエージェントや支援技術がアイコンによる視覚表現など異なるモダリティによってラベルを補足することが期待されています。
autocomplete
属性値をもとに、アイコンが付加されるイメージ。たとえばメールアドレスの入力欄には封筒のアイコンが、電話番号の入力欄には受話器のアイコンが表示されることで、各フィールドの目的がより識別しやすくなる。
autocomplete の自動入力補完は WCAG では副次的な位置づけ
元来 autocomplete
属性はフォームの自動入力補完のために用いるものであることから、アクセシビリティ診断による改善提案をさせていただく中で、自動入力補完が機能しなさそうなフィールド (つまりテキスト入力フィールド以外) に autocomplete
を記述することの是非が議論になることがあります。たとえば、都道府県を選択する <select>
要素などです。
これについて以前、W3C の AGWG (Accessibility Guidelines Working Group) に問い合わせてみたことがあります。ここで得られた見解としては、WCAG が autocomplete
を用いる意図は、あくまでも入力フィールドに対して (ラベルを補足する) アイコンなどの識別子が提示できることであって、自動入力補完ができることは副次的な位置づけのようです。したがって、WCAG 達成基準「入力目的の特定」を満たしているか否かという観点で言うと、「7. ユーザインタフェース コンポーネントの入力目的」に該当する入力フィールドには (テキスト入力フィールドであろうとなかろうと) おしなべて autocomplete
属性が記述されている必要があり、それがない場合、達成基準を満たさないという判定になります。
ちなみに、W3C の ACT Rules (アクセシビリティ適合テストのルール集) の「Autocomplete attribute has valid value」を見ると、テストケース (Test Cases) の合格例として、<form autocomplete="off">
要素の中に誕生月を選択する <select autocomplete="bday-month">
要素を内包する実装が紹介されています。この例からも、autocomplete
属性によって自動入力補完が機能しないことは問題ではなく、あくまでもフィールドの入力目的が特定できればよいことがわかります。
どの autocomplete 属性値を用いるか?
WCAG 2.2 の「7. ユーザインタフェース コンポーネントの入力目的」を見ると、使用可能な autocomplete
属性値がたくさんありますが、そのうちどれを用いるかは、慎重に検討する必要があります。
たとえば電話番号です。市外局番、市内局番、加入者番号、という想定で3つのフィールドに分割するケースがあります。それぞれのフィールドに対して、autocomplete="tel-area-code"
、autocomplete="tel-local-prefix"
、autocomplete="tel-local-suffix"
を記述すれば、WCAG 達成基準を満たすという点では OK です。しかしユーザー側から見た場合、携帯電話をメインで使っていたりする人だと、市外局番、市内局番、加入者番号、という区分がそもそもフィットしないかもしれません。ユーザビリティの観点 (電話番号の入力操作の手数を減らす) からも、電話番号の入力フィールドを一つにまとめて、autocomplete="tel-national"
(国番号を含む国際的な電話番号であれば autocomplete="tel"
) を記述する形に改善できれば、そのほうがよいと思います。
もう一つの例としては住所があります。住所に用いられる autocomplete
属性値には address-line
と address-level
があり、一見違いがわかりにくいですが、前者の address-line
は street-address
を細分化したもので、HTML Standard の例示を見ると「32 Vassar Street, MIT Room 32-G524」とあるので、通り (street) の名前と番地、建物名、部屋番号、が該当するようです。一方、後者の address-level
は、行政レベルに基づく住所情報であり、州、市、町、村、などが該当します。
これを日本の住所表記に当てはめると、以下のようになるかと思います。
- 都道府県 ...
address-level1
- 市区町村 ...
address-level2
- 丁目、番地、号、建物名と部屋番号 ...
street-address
またはaddress-line1〜3
本記事執筆時点の具体例として、Apple Account の編集フィールドでは、以下のようになっています。
- 都道府県 ...
address-level1
- 市区町村 ...
address-level2
- 番地 ...
address-line1
- 建物名、部屋番号 ...
address-line2
また、楽天会員 (Rakuten ID) の編集フィールドでは、以下のようになっています。
- 都道府県 ...
address-level1
- 市区町村 ...
address-level2
- それ以降の住所 ...
address-line1
(個人的には、ここはstreet-address
が適切な気がします。)
なお住所には、オートフィルの詳細トークンとして billing
と shipping
を付記して、その住所が請求先なのか配送先なのかを特定することもできます。これは WCAG 2.2 の「7. ユーザインタフェース コンポーネントの入力目的」を見ただけではわかりにくいですが、「WCAG 2.2 解説書」の「達成基準 1.3.5 : 入力目的の特定」の「事例」で紹介されています。
autocomplete 以外の解決はあるのか?
「WCAG 2.2 解説書」の「達成基準 1.3.5 : 入力目的の特定」を見ると、「意図」の最後の段落に以下の記述があります。
他のメタデータフォーマットに対するユーザエージェントと支援技術のサポートが成熟すると、入力フィールドの目的を特定するために HTML の autocomplete 属性に加えて、又はその代わりに WAI-Adapt: Symbols Module のようなメタデータスキームが使用される。それらのメタデータスキームはまた、コンテンツ制作者が提供した入力ラベルを特定して、入力のラベルづけの代わりに使用される定義済みの語彙又は記号に一致させる自動適応もサポートできる。
ここで触れられている WAI-Adapt: Symbols Module とは、AAC (Augmentative and Alternative Communication) を提供するユーザーエージェントが、ユーザーの好みでウェブコンテンツ内にシンボルを代替的に表示できるようにするための標準仕様です。現時点ではまだ勧告候補 (Candidate Recommendation) ということで、これはあくまでも将来的な展望と言えるでしょう。
ユーザーエージェント/支援技術の実際の対応は?
ところで、実際に autocomplete
属性をもとにして入力フィールドにアイコンを付加するようなユーザーエージェントや支援技術があるかというと、本記事執筆にあたって改めていろいろと探してみたのですが、正直、見当たりませんでした (Deque Systems が試作した Chrome 機能拡張があったりしますが、かなり古いためか、うまくインストールできませんでした)。もっとも、入力フィールドの目的をどんなアイコンで表現すると識別しやすいかは、人それぞれ異なる可能性があり、どちらかというと (汎用的なプロダクトというよりは) 個人がユーザースタイルシートのような形で持つものなのかもしれません。たとえば以下のデモのように、label:has(+ input[autocomplete="xxx"])::after{ アイコン画像を表示 }
というセレクタ設定を用いて、ラベルの後ろにアイコンを付加するといったことができます。
See the Pen 入力フィールドの autocomplte 属性値をもとにラベルにアイコンを付加する by @caztcha (@caztcha) on CodePen.
かように実際のユーザーが活用している様子が見えにくい現状では、WCAG で autocomplete
を実装すべきとされていることに対して「もやもや」を感じてしまうこともあるかもしれません。しかしながら、上掲のデモのようにユーザー個人による解決をサポートできる可能性があること、また副次的な位置づけとはいえ、自動入力補完は認知/学習障害や運動障害のあるユーザーにとっても有用な操作支援になることから、アクセシビリティの観点で autocomplete
を実装する意義は大いにあると思います。