アクセシビリティ対応は、何をどこまでやればいいのか

アクセシビリティの相談は、二つのパターンに分かれます。

一つは、取引先や入札の条件として求められた場合。もう一つは、実際に使えないという指摘を受けた場合です。

前者はチェックリストを通せば済みます。後者は通せません。そして、その二つは同じ作業ではありません。

日本での位置づけ

障害者差別解消法の改正により、2024 年 4 月から、事業者による合理的配慮の提供が義務化されました。ウェブサイトそのものに対する直接の技術基準を課すものではありませんが、サービスを提供する側の責任は明確に強くなっています。

技術面の参照先は JIS X 8341-3 で、これは国際的な WCAG に対応しています。公的機関の調達では準拠が求められることが多く、民間でも大企業との取引で条件になる例が増えています。

つまり、法的な強制よりも、取引条件として先に来ることが多いということです。

チェックリストを通すことと、使えることの差

自動チェックツールを通せば、多くの項目は機械的に判定できます。コントラスト比、代替テキストの有無、見出しの構造、フォーカスの順序。

ここを全部通しても、画面が見えない人にとって使いやすいとは限りません。

理由は単純です。ツールが判定できるのは「壊れていないか」であって、「使えるか」ではありません。すべての項目に適合しながら、目の見える人が 4 秒でできる操作に、スクリーンリーダーの利用者が 90 秒かかる、という状態は普通に作れます。どのツールも警告を出しません。何も間違っていないからです。ただ、使いにくいだけです。

実際に何をやるか

順序があります。上から順に、費用対効果が高い順です。

一番目、キーボードだけで操作できるか。マウスを使わずに、タブキーだけで主要な操作を最後まで通してみてください。途中で止まる、どこにいるかわからなくなる、モーダルから出られない。ここで見つかる問題が最も多く、修正も比較的簡単です。

二番目、文字と色。コントラスト比を満たすこと。そして、色だけで情報を伝えていないこと。赤字がエラーを意味するなら、色以外にも印が必要です。

三番目、フォームのラベル。入力欄と説明が正しく結びついているか。ここが切れていると、スクリーンリーダーでは何を入力する欄なのかわかりません。

四番目、実際に音声で使ってみる。画面を消して、スクリーンリーダーで自社のサービスを 20 分使ってみてください。これは報告書では絶対に得られない情報が出ます。アイコンボタンが「ボタン」としか読まれない、読み込み中に何も通知されないので落ちたように聞こえる、といったことが数分でわかります。

後からやると高くつく理由

構造の問題だからです。

見た目の修正は後からでもできます。しかし、情報の構造、操作の順序、状態の伝え方は、作り方そのものに埋まっています。ここを後から変えるのは、作り直しに近くなります。

逆に、最初から考えて作った場合の追加費用はほとんどありません。使いにくい版を一度も作らないので、直す作業が発生しないからです。

対応が高いと言われるとき、それはたいてい後付けの費用のことを指しています。

副次的な効果について

これは説得の材料として実際に効くので書いておきます。

画面が見えない人向けに設計すると、プロダクトの構造を明示せざるを得なくなります。この画面の優先順位は何か、このボタンは何をするのか、押した後に何が起きるのか。これらはアクセシビリティの問題ではなく、設計の問題です。目が見える利用者は曖昧さを視覚的に補えるので、多くのチームはこの問いに正確に答えないまま作れてしまいます。

私がスクリーンリーダーを前提に設計し直した案件では、例外なく、見た目の版も良くなりました。ラベルが短く正確になり、手順が減り、曖昧だった部分が決まったからです。

字幕は電車の中で役に立ちます。大きいタップ領域は片手がふさがっている人に役に立ちます。高いコントラストは屋外で役に立ちます。これは理屈をこじつけているのではなく、一番厳しい条件で設計した結果として普通に起きることです。

発注する場合

「JIS X 8341-3 に準拠」とだけ書かれた見積もりは、自動チェックを通す作業を指していることがあります。それが必要な場合はそれで構いません。

実際に使えるようにしたい場合は、成果物に「スクリーンリーダーでの主要導線の通し確認」を明記してください。この一行が入っているかどうかで、作業の中身がかなり変わります。