目次／情報設計・仕様設計／仕様設計

ウェブアクセシビリティ（準拠と配慮）

項目番号 033

10秒でわかる！要点まとめ

「できない準拠」より「やれている配慮」のほうが100億倍マシ
JISの「準拠」は方針の策定と試験結果の公開がセット。安請け合いすると自分の首が絞まる
クライアントは「誰かを排除したい」とは思っていない。箔が欲しいのか本当にアクセシブルにしたいのかを見極める

1. 概要：誰もが、ほぼ同じコストで、同じ目標を達成できる状態

ウェブアクセシビリティとは、誰もが、ほぼ同じコストで、ほぼ同じ量の情報を得られ、同じ目標を達成できることを指します。

「誰もが」 — 障害の有無だけでなく、利用環境、年齢、身体的能力の多様性を含みます
「ほぼ同じコストで」 — 金銭的負担だけでなく、所要時間、身体的・精神的な負荷の公平さを含みます

ここで効いてくるのが、「平等（Equality）」ではなく「公平（Equity）」という考え方です。全員に同じ高さの箱を配るのが平等。それぞれの背丈に合わせて必要な台を置くのが公平です。アクセシビリティが目指すのは後者です。

もうひとつ、障害を個人の問題とみなす「医療モデル」ではなく、社会環境の不備が障害を生んでいるとする「社会モデル」の視点も重要です。段差があるから車椅子で入れないのであって、車椅子が問題なのではありません。

2. なぜ重要なのか：「知っていたら、やってたのに」を言わせないため

クライアントワークで一番言われたくない言葉は、「知っていたら、やってたのに……」です。

ディレクターが「難しそうだから」「予算がなさそうだから」と説明を省略すると、クライアントは知らないうちに「誰かを排除しているサイト」を発注してしまうことになります。あとで気づいたクライアントの立場からすれば、「なぜ最初に教えてくれなかったのか」という話になります。

制作者側の実態として、アクセシビリティのコミュニティイベントに参加するような熱心な層でも、実際に業務で実践できているのは3割程度と言われます。だからこそ、アクセシビリティを責任と捉え、最初から選択肢としてきちんと提案し、判断はクライアントに委ねるという姿勢が要ります。提案しないことは、判断の機会を奪うことです。

なお、アクセシビリティ対応は「福祉」ではなく「品質」の話でもあります。Netflixは2012年の敗訴を機に配信動画の100%字幕化を命じられましたが、それが結果的に自動翻訳の効率化や国内外での視聴率向上につながりました。ウェブは本来、載るだけで圧倒的にアクセシブルになるものです。

3. 実務のポイント：「準拠」と「配慮」を区別する

国内で最も誤解が多いのがここです。クライアントから「JISに準拠したい」と言われて、軽く「わかりました」と答えるのが、いちばん危ない対応です。

「準拠」には方針・試験・費用がセットで必要

JIS X 8341-3:2016 の「準拠」は、方針の策定と試験結果の公開がセットで初めて表明できるものです。

試験は熟練の専門家が行っても1ページあたり1時間弱、複雑なUIなら3時間以上かかります。サイト全体で「準拠」を謳うには40ページ程度のランダムサンプリング試験が必要で、当然そのぶんの費用が発生します。

グローバル標準の WCAG 2.2 の「適合表明」はさらに厳しく、「一部準拠」や「配慮」といった段階的な概念がありません。適合しているかしていないかの二択で、対象の単位も「一式」ではなくサイト全体です。

	ダメな約束 🙅	良い案内 🙆
準拠	「準拠します」と約束したのに、方針も作らず試験もしない	準拠を目標とした計画と試験を、金額の入った見積もりとして見せる
配慮	—	準拠が現実的でないなら、「配慮」として何をやるかを具体的に提案する

ユーザーが困るかどうかを決めるのは、表明の有無ではなく実態です。実が伴うのであれば「配慮」という表記でも決して悪くありません。この理想と現実のすり合わせが、ディレクターの腕の見せどころです。

100点が取れない案件で、何をするか

バックエンドシステムへの依存、デザインレギュレーション、YouTube等のサードパーティ製ウィジェット、動画やアニメーションの多用——実際の案件には、100点（準拠）を阻む要因が溢れています。そこでクライアントと握るべきは、次の3つです。

できることをやる。直せるところから直す
新たに問題が生まれないようにする（代替テキストの記入マニュアルを運用側に渡すなど）
年単位の長期改修計画を立てる（運用フローに組み込む）

クライアントはたいてい「誰かを排除したい」とは思っていません。「準拠」という箔が欲しいだけなのか、本当にアクセシブルにしたいのかを対話で見極め、一歩ずつ進む計画を設計します。

最低限のライン

要件レベルの議論とは別に、仕様書に必ず盛り込むべき基本があります。画像へのalt属性、文字と背景のコントラスト比、タップ領域の確保（44px以上）、キーボードだけで操作できること。詳しくは 032 ユーザ環境定義を参照してください。

4. スキルアップのヒント：ひとりでやらない

アクセシビリティのバッドノウハウは、「ひとりでやること」です。

ディレクターの役割は、すべての技術仕様を完璧に理解することではありません。チームのデザイナーやエンジニアを信じて頼り、クライアントと「できる範囲の配慮」を現実的に握り合うことです。

手を動かして体感するなら、まず Chrome の Lighthouse でアクセシビリティを点数化してみてください。次に、スマホの VoiceOver（iOS）／TalkBack（Android）をONにして、目を閉じて自社サイトを操作してみる。「altがないと何が起きるか」は、読むより体感したほうが早いです。

クライアントへの説明資料としては、Porta11y（ポータリー）のブックレットが最初の一歩として使えます。体系的に学ぶなら『Webアクセシビリティの教科書』が定番です。