サーバーサイドエンジニアがアクセシビリティで気にすべきこと

Web Content Accessibility Guidelines (WCAG) 2.1 をサーバーサイドエンジニアのロールで気にすべきことがないか精読してみました。
読んだ結果、思ったことを記載します。

前提

A11YJ でサーバーサイドのアクセシビリティについて質問をしたところ、以下のアドバイスを頂きました。

• WCAG の達成方法集ではなく、WCAG の達成基準、書籍を精読する。
• サーバーの可用性など、非機能要件に該当する事項とアクセシビリティは切り離して考える。

Webアーキテクチャ構成で、サーバーサイドエンジニアが考量する範囲は変わるかと思います。
JavaScriptの厚いフロントエンドではなく、

• Djangoのテンプレート、JSF等、サーバー側でHTMLをレンダリングするWebアーキテクチャ

をイメージして気になったことを記載しています。

達成基準で、サーバーサイドに関係しそうな内容の抜粋

以下、読んでいて気になったことを記載します。

達成基準 1.1.1 非テキストコンテンツ

ここは、CAPTCHAについての記載がサーバーサイドに関連するかなと思いました。

• CAPTCHA 非テキストコンテンツが、コンピュータではなく人間がコンテンツにアクセスしていることを確認する目的で用いられているとき、テキストによる代替は、その非テキストコンテンツの目的を特定し、説明している。なおかつ、他の感覚による知覚>に対応して出力する CAPTCHA の代替形式を提供することで、様々な障害に対応している。

CAPTCHA の画像はサーバーサイドで生成することが多いのではないかと思います。
アクセシビリティ観点で問題になることがある認識はサーバーサイドのエンジニアも持った方がいいかと思いました。

7.1.1.1 非テキストコンテンツに関する達成基準：CAPTCHA - 富士通 に対策として、以下の記載があります。

• 「CAPTCHA」を3つ以上の感覚に対応した形式で提供する
• 「CAPTCHA」を使用しないでも済むように、カスタマーサービスなどの担当者への連絡手段を提供する
• 事前に許可したユーザーには「CAPTCHA」を要求しないようにする

CAPTCHA は、今年 2019年に reCAPTCHA v3 がリリースされています。
これは、人間に入力を求めない方式なので、うまく使えればアクセシビリティの問題は改善できるかもしれません。
* Googleの「reCAPTCHA v3」を実装する at softelメモ

また、まだベータ版ですが、Enterprise版のあるようです。以下に概要説明のリンクを記載します。
reCAPTCHA Enterprise の概要  |  reCAPTCHA Enterprise のドキュメント  |  Google Cloud

• 使用イメージ
  個人的に、reCAPTCHA v3 のみだと、誤検知リスクがあるように思いました。
  reCAPTCHA v2 のみか reCAPTCHA v3 でロボット扱いになった場合に、reCAPTCHA v2 を使用するのが良いのかと思います。

  1. 案1
     reCAPTCHA v2 のみ

  2. 案2
     reCAPTCHA v3 と reCAPTCHA v2 を ２段階でかける。

達成基準 2.2.1 タイミング調整可能

コンテンツの制限時間を調整する機能に対する達成基準です。

コンテンツに制限時間を設定する場合は、次に挙げる事項のうち、少なくとも一つを満たしている * 解除
制限時間があるコンテンツを利用する前に、利用者がその制限時間を解除することができる。又は、 * 調整
制限時間があるコンテンツを利用する前に、利用者が少なくともデフォルト設定の 10 倍を超える、大幅な制限時間の調整をすることができる。又は、 * 延長
時間切れになる前に利用者に警告し、かつ少なくとも 20 秒間の猶予をもって、例えば「スペースキーを押す」などの簡単な操作により、利用者が制限時間を少なくとも 10 倍以上延長することができる。又は、 * リアルタイムの例外
リアルタイムのイベント (例えば、オークション) において制限時間が必須の要素で、その制限時間に代わる手段が存在しない。又は、 * 必要不可欠な例外
制限時間が必要不可欠なもので、制限時間を延長することがコンテンツの動作を無効にすることになる。又は、 * 20 時間の例外
制限時間が 20 時間よりも長い。

上記を読んで、以下３点を考えました。

• パスワードの忘れのリンクの有効期限
  一般的に24時間な気がする。

• セッションタイムアウト
  入力負荷の大きい作業のタイムアウト時間を長く保つ、もしくは入力に反応して延長するようにする。

• ログイン認証に使用するクッキーのタイムアウト
  明示的にログアウトしなければ、ログアウトしない？

達成基準 2.2.2 一時停止、停止、非表示

自動更新する情報に関するに関する達成基準です。

(レベル A) * 自動更新
自動更新する情報が、(1) 自動的に開始し、 (2) その他のコンテンツと並行して提示される場合、利用者がそれを一時停止、停止、もしくは非表示にする、又はその更新頻度を調整することのできるメカニズムがある。ただし、その自動更新が必要不可欠な動作の一部である場合は除く。

Ajax ではなく、定期的にF5リロードする画面があったりする場合は、自動リロードのON/OFFを切り替えるボタンをつけた方がいいかもしれません。

達成基準 2.2.4 割り込み

(レベル AAA) 割り込みは、利用者が延期、又は抑制することができる。ただし、緊急を要する割り込みは除く。

Redmine で １つのチケットを同時編集時に、自分の編集を優先するか、他人の編集を優先するか確認ダイアログが表示されますが、あの楽観的排他制御のロジックが思い浮かびました。
自前で実装するのは、中々大変だと思いますが、大人数での同時編集が想定される機能だと実装するのはいいのかもしれません。
Scrapbox - チームのための新しい共有ノート はリアルタイムに編集が反映されるので、この観点は考慮できているのかもしれません。

達成基準 2.2.5 再認証

(レベル AAA) 認証済のセッションが切れた場合は、再認証後でもデータを失うことなく利用者が操作を継続できる。

セッション情報の永続保持の機能かもしれません。前回ログイン時の画面項目の情報を保持しておくことはシステム上できるので、
サーバー側で保存しておいたフォームの情報を復旧したり、localstorageで保存した情報を復旧させるなどはできるかと思います。

もしくは、タイムアウトさせないような実装をするのも１つの方法かと思います。

達成基準 2.2.6 タイムアウト

(レベル AAA)
データの損失を引き起こす恐れのある利用者の無操作の残り時間が警告される。ただし、利用者が 20 時間以上何もしなくてもデータが保持される場合は、この限りではない。

• 注記 プライバシー関連の規制により、利用者を認証する前や利用者のデータが保存される前に、利用者の明確な同意が必要になる可能性がある。利用者が未成年の場合、ほとんどの裁判管轄、国又は地域で、利用者からの明示的な同意を要請することができない。この達成基準に適合するためのアプローチとしてデータの保存を検討する場合は、プライバシーの専門家や弁護士に相談するのが望ましい。

Webシステムで扱っている情報の質に依るところが大きいかと思いました。
ほとんど残り時間の表示はみたことがありませんが、仮に実装するとユーザーとしては嬉しいケースもありそうに思います。

達成基準 2.4.5 複数の手段

(レベル AA) ウェブページ一式の中で、あるウェブページを見つける複数の手段が利用できる。ただし、ウェブページが一連のプロセスの中の 1 ステップ又は結果である場合は除く。

WCAG 2.0 の解説書 達成基準 2.4.5 を理解する | WCAG 2.0解説書 の内容も引用します。

達成基準 2.4.5 の具体的なメリット: * 複数の手段でサイトをナビゲートする機会を提供することによって、人々が情報をより早く見つけるのに役立つことができる。視覚障害のある利用者は、画面拡大ソフト又はスクリーンリーダーを用いて大きなナビゲーションバーを経由してスクロールするよりも、検索機能を使用してサイト内の適切な部分へナビゲートしていくほうが容易なことがある。認知障害のある人は、複数のウェブページを読んで横断するするよりも、サイト全体を見渡すことのできる目次又はサイトマップを好むことがある。中には、サイトのコンセプトやレイアウトを最もよく理解できるように、ウェブページからウェブページへと順番に移動しながらサイト内を探索するのを好む利用者もいるかもしれない。

• 認知に制約のある利用者は、階層構造を用いたナビゲーションスキームは分かりづらいことがあるため、検索機能を使うほうがより容易なことがある。

UI/UX担当が画面遷移設計に関らないケースでは、エンジニアが画面遷移設計を担当することがあります。個人的な経験では、導線が異常に少ない 孤立する<wbr>画面 はたまに見ることがあります。
このケースは、複数のアクセスする手段を提供するのが良かったり、もしくは、アクセスする手段を提供することに無理があって、よくよく考えると、別の画面で代替可能で、作ることが無駄であった。
ということもあった気がします。
サーバーサイドエンジニアも頭の片隅に置いておくと幸せになれるかと思います。

達成基準 2.4.8 現在位置

(レベル AAA) ウェブページ一式の中での利用者の位置に関する情報が利用できる。

以下、2点が浮かびました。

• 404エラー、500エラー、401エラー等、元のページから遷移した結果、元のページにも戻れずTOPページに戻るしかない。

• パンくずリストを実装する。

達成基準 3.2.4 一貫した識別性

(レベル AA) ウェブページ一式の中で同じ機能を有するコンポーネントは、一貫して識別できる。

これも、2.4.8 に続き、エラーページのHTTPレスポンスコードについて、正しくコードを返すことが該当するかなと思いました。
ページのコンポーネントが、エラーを示すのか、コンポーネント表示直前のサーバーサイドのWeb API が エラーコードを返すのかパターンはあるかと思います。

達成基準 3.3.1 エラーの特定

(レベル A) 入力エラーが自動的に検出された場合は、エラーとなっている箇所が特定され、そのエラーが利用者にテキストで説明される。

JavaScript でバリデーションを行なっている場合も、サーバー側のバリデーションは必要で、その際どこに遷移させるかは検討しておいた方が良い気がします。
あとは、サーバー側でしかチェックが不可能な事象をどうユーザーに通知するか、見せ方の設計は必要に思います。

達成基準 3.3.3 エラー修正の提案

(レベル AA) 入力エラーが自動的に検出され、修正方法を提案できる場合、その提案が利用者に提示される。ただし、セキュリティ又はコンテンツの目的を損なう場合は除く。

サーバー側でのみチェック可能なエラー全般の話かと思いました。
Form送信後に、項目単位でエラーのケースと、置かれた状況がエラーのケースの2種類が発生するかと思います。
前者の場合は項目に対してフォーカスさせる、置かれた状況がエラーのケースは全体的にエラーを示す情報枠を実装しておいて、
その枠にエラーを表示させるのが良いかと思いました。

達成基準 3.3.4 エラー回避 (法的、金融、データ)

(レベル AA)
利用者にとって法律行為もしくは金融取引が生じる、利用者が制御可能なデータストレージシステム上のデータを変更もしくは削除する、又は利用者が試験の解答を送信するウェブページでは、次に挙げる事項のうち、少なくとも一つを満たしている

• 取消: 送信を取り消すことができる。
• チェック: 利用者が入力したデータの入力エラーがチェックされ、利用者には修正する機会が提供される。
• 確認: 送信を完了する前に、利用者が情報の見直し、確認及び修正をするメカニズムが利用できる。

データ、という括りなので更新系全般の話でしょうか？
以下、3点浮かびました。
* バリデーションを実施可能なポイントでしっかり実施する。
* 確認画面でやっぱり入力し直したい際、入力画面に戻ると有効期限切れで良い場合と悪い場合がある。
* metaリフレッシュのリダイレクトを2回以上していて、戻るボタンで戻ることができない。

達成基準 3.3.6 エラー回避 (すべて)

3.3.4 とほぼ同じ内容で、(レベル AAA) です。
全てのWebシステムに実装すべきだが、金融、法的なサービスだと優先度が上がるということかと思います。
この項目はセキュリティにも関連するところなので、しっかり実装したいところです。

4. 堅牢 (robust)

セキュリティの観点でのrobust かと思いましたが、支援技術に対してrobustでした。

7. ユーザインタフェース コンポーネントの入力目的

入力項目の名称につけるべき一般的な名前について記載されています。
個人情報の項目についてのみの記載ですが、載っている項目はこの名前に従ってつけるのが無難ではないかと思いました。

引用するには長すぎると思いましたので、リンクを記載します。
7. ユーザインタフェース コンポーネントの入力目的

また、autocomplete 機能の命名とも関連はあるように思いました。
最適なフォームの作成  |  Web  |  Google Developers

個人情報系の項目名として何をつければ良いのか迷った場合は、２つの参考になりそうで、基本的に理由がなければ従うべきであると思いました。

達成方法集

数は少ないですが、達成方法集 も勿論考慮に入れたほうが良いかと思います。
サーバサイドスクリプトの達成方法 | WCAG 2.0 達成方法集

感想

Web Content Accessibility Guidelines (WCAG) 2.1 を精読した感想を記載します。

• reCAPTCHA v2、reCAPTCHA v3
  reCAPTCHA v2、reCAPTCHA v3 について初めて突っ込んで調べてみて興味を持ちました。
  導入もそこまで難しいものではなさそうです。

• 一次情報 を確認するのは重要。
  W3C勧告をちゃんと読んだのは初めてでしたが、要約されていない生文書を読むと、要約文書から欠落していた情報からの気づきがありました。

• 機能要件の優先度中 に割り当てられる要件が、多く記載されていると思った。
  個人的感覚です。
  設計段階で盛り込まないと、テスト時に気づかずそのまま未実装でリリースされる機能が多そうです。
  設計段階の一読して漏れがないか確認するのが良いかと思いました。

• 達成基準なので、実装方法については明記されていない
  達成基準なので、実装方法については明記されていません。
  WCAG 2.0 達成方法集 が具体的実装方法について記載されていますが、
  システムで採用している プログラミング言語、フレームワークでバリエーションは無数にあるので、その都度、実装方法は検討する必要があります。

• ユーザリティ向上にサーバーサイドエンジニアが寄与できる
  アクセシビリティを向上させると、ユーザビリティも向上する場合があります。
  ユーザビリティ は UI/UX デザイナーのものだと個人的には思いますが、その部分をサーバーサイドからサポートできるのは良いかなと思います。

A11YJ でいくつか、実装例に関するアドバイスも頂きましたが、人様のアドバイスなのでここに記載するのはやめておきました。
この記事の内容で気になった方は実際にSlackグループに参加することをお薦めします。

以上です。