「Webアクセシビリティが義務化された」と聞くと、今あるサイトを全部作り直さないといけないのか、と戸惑うかもしれません。
先に整理すると、2024年4月1日から民間事業者にも義務となったのは、障害のある人への「合理的配慮の提供」です。 サイトをあらかじめ使いやすく整える「環境の整備」は、障害者差別解消法では努力義務に位置付けられています。内閣府の案内
ただ、この二つの言葉だけでは、何をすればいいのか分かりにくいですよね。
一つの申し込みフォームを例にすると、違いが見えてきます。
義務と努力義務を、一つのフォームで考える
例えば、イベントの申し込みフォームで、送信ボタンがマウスでしか押せないとします。
手を動かしにくいなどの理由で、キーボードを使って操作している人は、必要な情報を入力できても、最後の送信で止まってしまうかもしれません。
ここで、二つの対応を考えてみます。
| 対応 | 考え方 |
|---|---|
| 利用者から相談を受け、その人が申し込める方法を一緒に考える | 合理的配慮 |
| 相談が来る前に、フォームをキーボードでも使えるようにする | 環境の整備 |
困っている人に合わせて対応することと、困りにくい作りにしておくこと。 大まかには、この違いです。
法律では、事業者による合理的配慮を第8条第2項、環境の整備を第5条で定めています。合理的配慮は、障害のある人から困りごとを取り除く必要があると伝えられた場合に、負担が過重でない範囲で行うものです。障害者差別解消法の条文
今回の改正で、すべての民間サイトに特定のアクセシビリティ規格への適合が一律に義務付けられた、という意味ではありません。
一方で、「サイトの整備は努力義務だから、利用者から相談があっても対応しなくていい」と考えるのも違います。サイトを整えることと、個別の相談に応じることは、つながっています。
「別の方法でどうぞ」も、相手と相談して決める
フォームが使えないなら、メールや電話で受け付ければよい、と考えるかもしれません。
それが役立つ場合もあります。ただ、用意した方法を、相手が使えるとは限りません。
例えば、電話でのやり取りが難しい人に「電話してください」と案内しても、申し込めない状態は変わらないですよね。
大切なのは、こちらが代わりの方法を用意したことより、その方法で相手が用事を済ませられることです。
先ほどのフォームなら、例えば次のように話を進められます。
どの操作で進めなくなっていますか。
メールでのお申し込みも考えられますが、その方法は利用できそうでしょうか。
これは説明用の例です。実際には、相手が困っていることや希望、事業者が対応できることを確かめながら決めます。
内閣府の基本方針でも、本人の意向を尊重し、対話を通じて、代わりの方法も含めて柔軟に検討することが示されています。内閣府：基本方針（2023年改定・本文）
求められた対応を、どんな場合でもそのまま実施するということではありません。ただ、「難しいのでできません」で終わらせず、理由を説明し、ほかにできることを考える必要があります。
なお、本人が困りごとを伝えること自体が難しい場合もあります。基本方針は、支援者などが本人を補佐して伝える場合や、困っていることが明らかなときに事業者側から対話を働きかけることにも触れています。
先に直しておくと、相談しなくても使える
フォームを最初からキーボードでも使えるようにしておけば、利用者は事情を説明し、別の申し込み方を尋ねる手間をかけずに済みます。
事業者も、その都度申し込みを受け直す対応を減らせるかもしれません。
これが、環境を先に整える意味です。
「困ったらお問い合わせください」と書いておくことも大切ですが、問い合わせの入口まで使いにくかったら、相談するところにもたどり着けません。
問い合わせが来ていないことだけでは、問題なく使えているとは分からないんですね。
Webアクセシビリティは、こうした場面で、情報を受け取ったり、サービスを利用したりできるようにするための取り組みです。デジタル庁も、代替テキストを用意するなど、アクセシビリティを確保したWeb環境を整えることを説明しています。デジタル庁の解説
努力義務も、法律に定められた取り組みです。また、障害を理由とする不当な差別的取扱いの禁止は、今回の義務化以前からあります。「Webは努力義務」の一言で、対応の要否をまとめて判断しないようにしたいところです。
コーダーが最初に見たいのは、操作が止まる場所
法律の話を読んでも、実際のサイトで何から確認するかは迷います。
求人でマークアップエンジニアという呼び方が使われるとき、アクセシビリティを意識したコーディングが仕事内容に挙がっていることがあります。呼び方と担当範囲の違いはコーダーとマークアップエンジニアの違い｜仕事内容と求人の見分け方にまとめました。
最初は、申し込みや問い合わせなど、利用者が何かを完了させる流れを一つ選ぶと、確認する目的がはっきりします。
例えば、問い合わせページを開き、必要事項を入力して、送信するまで。その途中に、使い方によって進めなくなる場所がないかを見ていきます。
キーボードで移動し、操作できるか
マウスから手を離し、Tabキーでリンクや入力欄を移動してみます。戻るときはShift＋Tabです。
このとき、次の二つを分けて確認します。
- 必要なリンクやボタン、入力欄に移動できるか。
- 移動した先で、実際に操作できるか。
さらに、今どこを選んでいるのか、画面を見て分かることも大切です。移動はしていても、位置を示す枠などが見えなければ、次に何を操作するのか迷ってしまいます。
入力欄が、何を入れる場所なのか分かるか
目で見ると、「お名前」という文字の下に入力欄があれば、その関係を理解できます。
でも、画面の情報を音声などで受け取る場合にも、その関係が伝わるようにする必要があります。そこで、入力欄の説明とフォーム部品を結び付けるlabelが役立ちます。
文字が近くに置かれているだけか、HTMLでも対応付けられているかを確認します。
また、入力を間違えたとき、「エラーがあります」だけでは直す場所が分かりません。「メールアドレスに＠がありません」のように、何を直せばよいかが伝わるかも見たいところです。
画像を見なくても、必要な情報が分かるか
画像だけのボタンやリンクでは、何をするものかが伝わる名前を確認します。
例えば、虫めがねの画像だけで検索するボタンなら、「虫めがね」という形より「検索」という操作を伝える方が分かりやすくなります。
反対に、すでに同じボタン内に「検索」と書いてあれば、画像のaltは空にできる場合があります。画像ごとに説明を増やすより、必要な情報が届いているかを見ます。
これらは、最初の確認項目です。ほかにも文字と背景のコントラスト、見出しの構造などがあります。ここで挙げた項目を確認しただけで、サイト全体が規格に適合したと判断することはできません。 W3Cにも、初めて確認する人向けのチェックガイドがあります。
見つけた問題は、困る場面とセットで伝える
問題を見つけたら、「アクセシビリティに対応していません」だけでなく、どこで何ができないかを伝えると、修正の相談がしやすくなります。
例えば、こんな伝え方です。
問い合わせフォームの送信ボタンに、Tabキーで移動できません。キーボード操作では送信を完了できないため、ボタンの実装を確認したいです。
これなら、確認した場所、起きていること、利用者への影響が分かります。
コーダーが一人で法律上の対応をすべて判断する必要はありません。見つけた問題を、ディレクターやサイトの運営担当者と共有し、修正や案内方法を相談していきます。
こうした確認や共有も、Web制作の仕事につながっています。実務で必要になる力については、コーダーが実務で重宝されるスキルはHTML/CSSだけではないにも書いています。
次にサイトを確認するときは、まず一つのフォームを、マウスを使わず最後まで操作してみてください。送信を試す場合は、テスト環境や関係者と確認した方法で行います。
「ページが表示される」と「その人が用事を済ませられる」の間に、何があるのか。そこを見ると、アクセシビリティがコードや日々の確認作業とどうつながるか、考えやすくなります。
