Webサイトのアクセシビリティにどう向き合う？

11月23日に開催されたMTDDC Meetup Tokyo 2024で、「Webサイトのアクセシビリティにどう向き合う？」というタイトルで登壇しました。参加者の皆様からの投票で、この日の3人のベストスピーカーのうちの1人にも選んでいただきました。

これは、その発表内容を記事にするものです。時間や構成の都合により発表に含めなかった情報や、あとで追記したくなったことを書き足したりもしています。Movable Typeのイベントでの登壇だったため、CMSで構築したWebサイトを運用・管理・制作している人を前提とした内容になっています（少なくとも、そういうつもりで作っています）。

発表スライドは以下に公開してあります。

Webサイトのアクセシビリティにどう向き合う？（Googleスライド）

アクセシビリティとは

会場に集まっていただいた方に「『アクセシビリティってそもそも何？』という状態の人」に挙手を求めてみましたが、誰も手を挙げませんでした。5個のセッションが同時で進行しているなかで来てくれる方々なので当然といえば当然ですが、先日別のイベントではアクセシビリティについて全く知らないという人にも多く会ったので、アクセシビリティという言葉の認知自体を広げていく必要を強く感じています。

アクセシビリティについて、短い時間で理解してもらうには、「アクセシビリティが高い状態」がどんな状態であるかを説明するのがいちばん楽に感じています。

• 障害者や高齢者を含めて、より幅広い人たちが使える
• ユーザーの能力や、操作方法や、デバイスやブラウザの多様さに対応できる
  • 視覚的に見やすい文字・色彩・レイアウト
  • わかりやすい言葉遣い、わかりやすいサイト構成
  • 動きや音がユーザーの邪魔をしない
  • PCでもスマホでも使える、ChromeでもFirefoxでもSafariでも使える
  • キーボードでも操作できる、スクリーンリーダーでも読める

なぜアクセシビリティが重要なのか

アクセシビリティが重要である理由の第一には、様々な人の権利が守られなければならないということがあります。

障害者は、特定のWebサイトを使うことができないということがしばしば発生します。障害者が社会的にマイノリティであるために、障害者にとって不便なものの存在がそもそも認識されにくく、不公正になっているということは、Webに限らず様々な分野でこれまで数多く指摘され、そして数多く改善されてきました。たとえば街中での移動に関しては点字ブロックや、階段に取りつけられたスロープが取り付けられたように、様々な分野で改善のための工夫がなされてきました。

Webが生活必需品となっている時代である以上、知る権利、教育を受ける権利、働く権利、健康で文化的に生きる権利を守るためには、アクセシビリティの高いWebサイトはなくてはならないものです。Webが使えなかったり使いづらかったりすることで、こういった権利の危機に晒されやすいという点では、高齢者や外国出身で日本語が得意でない人も同じく、アクセシビリティを必要とします。

また、そもそもWebサイトにはそれぞれ目的があるはずです。まずはWebサイトを見てもらい、そこから商品を買ってもらったり、サービスを申し込んでもらったりといった次の目的があったり、あるいはWeb上でサービスを提供するのが目的かもしれません。いずれにしろ、Webサイトを使うことができない人は、それらの目的を達成できません。Webサイトを使えないことで取りこぼしている顧客がいるかもしれないのです。

そして、誰かにとっての「使えない」が「使える」に変化することが、他の誰かの「使いづらい」が「使いやすい」へと変化することに繋がることも、よくあることです。「使えない」人は少なくても「使いづらい」人はそれなりに多いかもしれません。ユーザーの身体能力や認知能力だけでなく、使っているデバイスの種類、OSの種類、ブラウザの種類、利用しているシーン、操作方法の好みなど、ユーザーの状況はとても多様です。

アクセシビリティに取り組むことは、多様なユーザーの多様なニーズに向き合うことでもあるのです。

ユーザビリティとアクセシビリティ

「アクセシビリティ」に比べれば、「ユーザビリティ」の方が馴染みのある言葉かもしれません。この二つには、ユーザーや利用状況を特定するかどうかに大きな違いがあります。

ユーザビリティ

= 誰かにとっての使いやすさ

• ターゲットとなるユーザーと利用状況を限定する
• その人にとっての効果・効率・満足度・目標の達成度合い

アクセシビリティ

= 使える人・状況の広さ

• ターゲットを限定しない（障害者や高齢者にも限定しない）
• どんな人・どんな利用状況であっても、まず使えることを目指す
• その上で、使いやすい状況（その人にとってもユーザビリティの高い状況）になっていれば、なお良い

ユーザビリティは、山の頂上部分の高さみたいなものです。ターゲットとなるユーザー、つまり狭い頂上付近の高さが高くなるようにしていくのが、ユーザビリティの改善です。

一方、アクセシビリティは山の裾野の広さみたいなものです。なるべく広い範囲のユーザーが、少なくとも「使える」ようにしていくことが、アクセシビリティでは求められます。そしてなるべく多くの人が「使いやすい」と感じられるようになることが理想でもあります。

Webアクセシビリティと法律・人権

今回、「Webアクセシビリティは人権である」という点をかなり強調したつもりです。先に述べたとおり、アクセシビリティを語る上で、障害者の人権という側面を避けて通ることはできません。

障害者の人権について考えるときの土台となるのが、2006年に国連議会で採択された「障害者権利条約」です。日本は条約の批准のために、障害者基本法や障害者差別解消法などの国内法を整備し、2013年に批准しました。この条約には「障害の社会モデル」の考え方が反映され、「合理的配慮」についての項目があり、そしてインターネットを含めた情報通信機器やシステムの利用について触れられているなど、Webアクセシビリティを考える上で重要な、様々なトピックが関連します。

障害の社会モデル

皆さんは「『障害者』ってどんな人のことですか？」と聞かれたら、どう答えるでしょうか？「『手足が自由に動かせない』『耳が聞こえない』『目が見えない』のような状態にある人」という答え方をする人もいるかもしれません。あるいはそれらの事実に基づいて行政機関が「手帳」を交付した人、と考える人もいるかもしれません。

これらはいずれも、医学的な事実に基づいて「障害者」であると判断しています。こういった「障害」の捉え方を「障害の医学モデル」もしくは「障害の個人モデル」と呼びます。一方、障害者権利条約や、近年の障害者に関する取り組みでは、しばしば「障害の社会モデル」という考え方がとられます。これは、個々人の心身にある機能障害（impairment）ではなく、その状態にある人が 社会生活を営む上での不便や不自由（社会的障壁）こそが「障害（disability）」である という考え方です。

つまり、社会環境の不備によって、心身に機能障害のある人が障害者にされてしまっているというのです。

これは、社会環境が改善されて社会的障壁がなくなれば、心身の機能障害があったとしても、障害者ではなくなるということでもあります。あるいは機能障害の程度が医学モデルで「障害者」と扱われない軽度のものであっても、社会的障壁によって不便や不自由に感じることがあるなら、社会モデルでは障害者だということになります。そして、社会的障壁が存在し続けていることは人権の侵害であり、是正されるべきことだというのです。

合理的配慮

では、社会的障壁がなくなるようにとにかく頑張りましょう、という簡単な話でもありません。社会というものは急には変わりませんし、どんなに社会が変わっても、本当に全ての人の不便や不自由を解消できるなんてうまい話があるわけではありません。

そこで登場するのが 合理的配慮 です。合理的配慮は、社会的障壁によって不便や不自由のある人がいるときに、その問題を社会全体で解決していけるように、誰かに過重な負担が強いられることのないように調整しましょうという考え方です。

いわば、エッジケースに対する「運用でカバー」 です。

2024年4月に日本の障害者差別解消法の改正が施行され、民間事業者に対して合理的配慮の提供が義務化されました。つまり、民間でも、お客さんから合理的配慮を求められることがあれば、真摯に対応する義務があるということです。

この法改正による義務化の内容については、内閣府のリーフレットにわかりやすく説明されています。

Webアクセシビリティは法的義務なのか

合理的配慮の義務化にあたって、「Webアクセシビリティが義務になる」という説が囁かれました。あるいは、それを理由にWeb制作会社やアクセシビリティツール提供事業者が営業活動を活発化させるという動きがありました。

しかし、 Webアクセシビリティは障害者差別解消法における「合理的配慮」の範囲には含まれないとする考え方が一般的 です。なぜなら、障害者差別解消法の条文では、障害者側から合理的配慮を求められた場合に、加重な負担とならない範囲で合理的配慮を行うことを定めているからです。

第八条

（中略）

2 事業者は、その事業を行うに当たり、障害者から現に社会的障壁の除去を必要としている旨の意思の表明があった場合において、その実施に伴う負担が過重でないときは、障害者の権利利益を侵害することとならないよう、当該障害者の性別、年齢及び障害の状態に応じて、社会的障壁の除去の実施について必要かつ合理的な配慮をしなければならない。

障害を理由とする差別の解消の推進に関する法律（平成二十五年法律第六十五号）

Webアクセシビリティは、障害者からの合理的配慮を求める申し出によって行うものというよりは、それに先んじて改善して、使えるユーザーの幅を広げていこうという性質のものです。こういったものは 事前的改善措置 または 環境の整備 と呼ばれ、障害者差別解消法では 努力義務 となっています。

第五条 行政機関等及び事業者は、社会的障壁の除去の実施についての必要かつ合理的な配慮を的確に行うため、自ら設置する施設の構造の改善及び設備の整備、関係職員に対する研修その他の必要な環境の整備に努めなければならない。

障害を理由とする差別の解消の推進に関する法律（平成二十五年法律第六十五号）

内閣府の「障害を理由とする差別の解消の推進に関する基本方針」にもまさに、Webサイトにおける合理的配慮と環境の整備の例について触れたものがあります。

・ オンラインでの申込手続が必要な場合に、手続を行うためのウェブサイトが障害者にとって利用しづらいものとなっていることから、手続に際しての支援を求める申出があった場合に、求めに応じて電話や電子メールでの対応を行う（合理的配慮の提供）とともに、以後、障害者がオンライン申込みの際に不便を感じることのないよう、ウェブサイトの改良を行う（環境の整備）。

障害を理由とする差別の解消の推進に関する基本方針（令和５年３月14日閣議決定）※令和６年４月１日より施行

Webアクセシビリティと障害者差別解消法については、ほかにも記事を書いています。

Webサイト運営者に求められること

現状では、日本にはWebアクセシビリティを義務付ける法律はなく、努力義務に留まっています。しかし、海外ではWebアクセシビリティについて具体的に基準を決めた法律を作っている国も増えてきています。日本も近いうちにそういった法規制が行われていく可能性があります。すでに努力義務でもあり、そして障害者の人権を守るためにも、できることから始めていくべきでしょう。

また、合理的配慮は既に義務になっています。その義務を担っているのは多くの場合Webサイトではなく、メールや電話で問い合わせを受けたり、店舗や施設で対応をする現場のスタッフです。合理的配慮は過重な負担でない範囲での実施が求められていますが、さまざまな合理的配慮のリクエストに対して対応方法を検討し、「過重な負担でない範囲」を見極めること自体も現場にとっては負担となってしまいます。Webサイトのアクセシビリティ向上は、現場の負担を減らすことにも貢献できるはずです。

そして、障害者にとっても、合理的配慮を申し出ることは負担に感じる人がいるはずです。そもそも、どこから合理的配慮をリクエストするべきかわからないということも多いでしょう。私の勤務先でもあるfreeeではこの問題に対し、合理的配慮の問い合わせ窓口と、その対応について検討する委員会を設置しています。

アクセシビリティの基礎知識

Webサイトのアクセシビリティに取り組むやり方を説明する前に、Webアクセシビリティの話をするうえで重要な存在である 支援技術 と WCAG について説明をしておきます。

支援技術

心身の状態によって不便があるとき、それを補うための道具を使うことがあります。そういったものを「支援技術（Assistive Technology）」と呼びます。たとえば私は日常生活で近視用のメガネを着用していますが、この度入りのメガネも支援技術といえます。ルーペや、補聴器や、車椅子も支援技術です。

Webアクセシビリティでは、支援技術を使ってWebを使う場合を意識することがしばしばあります。Webを使う上で使用される支援技術には以下のようなものがあります。

表示拡大・ディスプレイの解像度変更

見えづらさのある人が、文字のサイズを大きくなるように設定をしたり、一時的に表示を拡大して使うケースがあります。

スクリーンリーダー（画面読み上げ機能）

画面を全く見ない状態でも、表示されている内容を音声で読み上げたり、点字ディスプレイに表示することで使用します

キーボードによる操作

手や腕や上半身を動かせないなど、マウスを使用できない場合に、動かせる部位を使用してキーボードのみで操作することがあります。本人の使える部位にあわせた特殊なハードウェアを使用する場合にも、キーボードの信号しか入力できないことがあります。もちろん、操作効率を高めるためにキーボード操作を好む人も多く存在します。

ほかにもさまざまな支援技術も存在しますし、その使い方も人それぞれです。そのため、特定の支援技術に対して最適化していくのではなく、あらゆる支援技術で使えるようにしていく必要があります。

WCAG (Web Content Accessibility Guidelines)

障害の種類、そしてユーザーの使い方は、細かいところまで見ていくと本当に人それぞれで、その全てを把握して全てに対応していくというのは困難です。そこで、Webアクセシビリティの活動は、網羅的なガイドラインを頼りに進めていくことになります。

Webアクセシビリティのガイドラインとして、広く使われているのがWCAG (Web Content Accessibility Guidelines) です。これはWebの標準化団体であるW3Cが策定しているガイドラインで、JIS X 8341-3:2016やISO/IEC 40500:2012との一致規格になっています。WebアクセシビリティといえばWCAGと言っても過言ではありません。

WCAGの最新バージョンは、2023年10月に勧告となったWCAG 2.2です。JIS X 8341-3:2016やISO/IEC 40500:2012の規格の内容は、2つ前のバージョンのWCAG 2.0のものとなっていますが、後方互換性が保たれています。WCAG 2.1以降でスマートフォン等を対象とした項目が追加されているため、JIS X 8341-3:2016準拠を求められる場合であっても、WCAG 2.2の内容も参考にしたほうが良いでしょう。

WCAGには本体とともに、解説書（Understanding）と達成方法集¹（Techniques）が用意されています。それぞれウェブアクセシビリティ基盤委員会が日本語訳を公開しています。ただし、解説書はWCAG 2.2で追加された項目以外は未訳で各ページにWCAG 2.1の同項目へのリンクが貼られており、達成方法集の日本語訳はまだ公開されていません。

• 日本語訳
  • WCAG 2.2 日本語訳 https://waic.jp/translations/WCAG22/
  • WCAG 2.2 解説書 https://waic.jp/translations/WCAG22/Understanding/
  • WCAG 2.1 達成方法集 https://waic.jp/translations/WCAG21/Techniques/
• 原文
  • WCAG 2.2 https://www.w3.org/TR/WCAG22/
  • Understanding WCAG 2.2 https://www.w3.org/WAI/WCAG22/Understanding/
  • Techniques for WCAG 2.2 https://www.w3.org/WAI/WCAG22/Techniques

WCAGの4原則と達成基準のレベル

WCAGには、アクセシビリティの高いWebコンテンツが満たすべき項目を「達成基準」として、4つの原則に沿って分類し、それぞれの達成基準にはA・AA・AAAの3段階の適合レベルがつけられています。

4つの原則とは以下のとおりです。

• 知覚可能: Web上の情報をユーザーが知覚できる
• 操作可能: クリックや文字入力を受け付ける部分を操作できる
• 理解可能: 書かれている内容、画面の変化、次にやることを理解できる
• 堅牢: 将来にわたって幅広く互換性がある

達成基準には「1.2.2」のような番号が振られていて、最初の数字が1なら知覚可能、2なら操作可能、3なら理解可能、4なら堅牢に関する項目であることがわかるようになっています。

達成基準の適合レベルは、Aには比較的達成がしやすく、また重大な問題となるものが並びます。AAAには技術的に達成が難しいものも含まれます。「どのレベルまでの達成基準を満たすか」という形で目標を立てたり、ユーザーにアクセシビリティの状況を示すのに利用できます。

総務省の「みんなの公共サイト運用ガイドライン」では、行政機関などの公共団体のWebサイトに対してJIS X 8341-3:2016（WCAG 2.0）の適合レベルAA準拠を求めています。

いろいろなWebサイトで、「Webアクセシビリティ方針」として、どの範囲のページでどのレベルの達成基準を満たすか（または、満たすことを目指すか）が示されています。

Webアクセシビリティはじめの一歩

ここからは、アクセシビリティについて何も意識したことがないWebサイト運営者が、最初にどんなことをすると良さそうかを紹介します。

ふたつのアンチパターン

最初に、いろいろ見聞きしてきたなかで、明らかにアンチパターンだと思われるものをふたつ紹介しておきます。どちらもWebサイト運営者が辿りつきやすく、そしてアクセシビリティを求めている人にとっては良くない状況を生んでしまいます。

Webサイト全体のリニューアルまで何もしない

「アクセシビリティを考えずに作ったサイトだから、リニューアルまでは改善できない」と思ってしまうのは非常にもったいない考え方です。

たしかに、WCAGの適合レベルAやAAをすべて満たすには、Webサイト全体を修正しなければ困難なものも多くあります。しかし、適合レベルAやAAを満たさなければ意味がないという性質のものではありません。すこしでも改善できる点があれば、それによって誰かが使えるようになるかもしれません。

また、リニューアルするまで放置しているうちに、コンテンツが増えていってしまうことも問題です。CMSで管理しているようなWebサイトの場合、複数のページが共有するテンプレートを修正することによって改善する問題もありますが、個別のページのコンテンツも修正が必要になります。ページの数が増えれば、問題は線形的に増えていってしまいます。新しく作られるページだけでも対策すれば、リニューアル時の作業量を減らせるし、新しく作られるページのアクセシビリティが高くなるならそのほうが良いでしょう。

なにより、アクセシビリティは基準を満たすためやるものではなく、Webサイトを使える人を増やす、使えなくて困る人を減らすためにやるものです。今日直せば、明日誰かが困らなくて済むかもしれません。まずはWebサイトの現状を把握し、簡単にできるところや、影響の大きいところから改善に取り組むべきでしょう。

ボタンを置くだけでアクセシビリティ対応完了！みたいな製品を導入する

よく「アクセシビリティ対策とは、文字を拡大したり読み上げ機能をもつボタンをページに置くことだ」と思っている人がいます。そういう機能を提供する製品も多数存在します。Webページに後付けでこういった機能を提供する製品は、「アクセシビリティオーバーレイ」と呼ばれます。

たしかに、文字を拡大したり音声読み上げしたりする機能がWebページに用意されていることで、そういった支援技術を普段使っておらず存在も知らないという人が便利になる可能性はあります。高齢者など、徐々に不自由を感じる場面が増えてきた人たちにとっては、こういったものが用意されていると便利かもしれません。

しかし、常に支援技術を必要とする人にとっては、Webサイト側の用意したバラバラのツールを使う意味はありません 。すべてのWebサイトで必要とする支援機能が使えなければ困るからです。そういった機能を使わなくても、WindowsやmacOSやiOSやAndroid OSには多彩な優れた支援機能が備わっているし、より高機能な支援技術製品も数多く配布・販売されています。常に支援技術を必要とする人たちはそれらを使っているため、Webサイト側の用意した機能を使う必然性はありません。

アクセシビリティオーバーレイについては、オーバーレイ ファクトシートというページで問題点が指摘されています。

こういった製品を導入しても、Webサイトの根本的な問題は解決しません。支援技術のユーザー向けの情報が欠けていたり不正確だったりするものは修正できないし、そもそもこういった製品のUIが（アクセシビリティを謳うにも関わらず）デザインや実装の初歩的なミスを犯していて、アクセシビリティが高いとはとても言えないようなケースすらあります。

Webサイト運営者は、こういった製品を導入したことで「これでアクセシビリティのことは大丈夫だ」と思い込んでしまう危険があります。そのように誤認させる説明を掲載している製品も存在しています。「アクセシビリティのことがよくわからない」という人ほど、これらの製品に手を出してしまうのは危険です。

アクセシビリティを必要としている人たちのことを知る

Webアクセシビリティの取り組みを進められなかったり、前述のようなアンチパターンを踏んでしまったりする要因は、アクセシビリティを必要とする、障害のある人のことをよく知らないことにあるのではないかと思います。

まずは、どんな人がどんなところで困るのかに目を向け、そしてそれが自分たちのWebサイトでも起きる問題であるかどうかを確認するのが良いでしょう。

「見えにくい、読みにくい『困った！』を解決するデザイン」は、アクセシビリティについて知る最初の一冊に最適な本です。また、Webに限らずあらゆる「見えにくい、読みにくい」が紹介されているため、開発者以外の人にも勧めている本です。

この本では、6人の登場人物の、さまざまデザインに対する「困った」の声を紹介します。あなたの身近なところにいる人が、実は意外なところで困っているかもしれないことに気付かされます。

「困った！」デザインの解説にあたり、どんな人が・どんなときに・どんなふうに困るかを紹介しようと考えていました。しかし、困りごとのパターン別に「困る人」を描くと、あたかも困りごとのために存在する、自分とは切り離された人のように感じられるという懸念がありました。そこで本書では、6人の登場人物一人ひとりに、永続的な理由、一時的な理由、状況による理由で困ってもらいました。例えばケイくんは、色覚特性や年齢によって困り、イヤホンを忘れて困ります。ケイくんの困りごとは誰もが直面しうるもので、その解決はわたしたちみんなに利益をもたらします。

登場人物｜困った！を解決するデザイン

デザインのプロセスのなかで使えるツールとしては、インクルーシブなペルソナ拡張というものがあります。これはターゲットとなるユーザー像が、もし障害をもっていたり、高齢であったり、モバイルで利用していたらどんなことに困るか、どんな解決策があるのかを記載したシートです。既存のペルソナと組み合わせることで、Webサイトのユーザーに対してどのようなデザインが有効であるかを検討することができます。

いずれの資料もすばらしいものですが、障害の当事者そのものではないことに注意してください。資料のカバーできていないところ、あなたの想像力の及ばないところに、常に思わぬ不便が存在していると考えるべきです。

もし身近なところにアクセシビリティを必要とする当事者がいるなら、まずはその人たちの話を聞いてみるべきです。現状のWebサイトをみてもらったり、継続的にアドバイスを貰うようにできると良いでしょう。実際のユーザーが実際に困っていることは、「⚪︎⚪︎さんが使えるように」という具体的なイメージとモチベーションを生むことができます。

ウェブアクセシビリティ導入ガイドブックで、現状のWebサイトを評価する

当事者がどんなことに困るのかがなんとなくわかってきたら、自分のサイトに困りそうな場所があるかどうかを探してみるのが良いでしょう。とはいえ、網羅的なチェックをいきなりやるのはかなりの手間が必要だし、WCAGの達成基準に対する知識も要求されます。

そこで、デジタル庁の「ウェブアクセシビリティ導入ガイドブック」を見ながら、そこで挙げられているものが自身のWebサイトに当てはまる場所があるかどうかを見てみることを提案します。ウェブアクセシビリティ導入ガイドブックでは、WCAGの達成基準をもとに、具体例を示して、Webサイトに発生しがちな問題がわかりやすく紹介されています。

非干渉の要件から改善する

WCAGには、「非干渉の要件」と呼ばれる、すべてのWebページで達成を求めている項目が4つあります。アクセシビリティの改善に取り組むページや対応する達成基準の範囲を絞り込む場合でも、これらの項目は満たさなければなりません。

• 音声の制御（1.4.2）
• キーボードトラップなし（2.1.2）
• 3 回の閃光、又は閾値以下（2.3.1）
• 一時停止、停止、非表示（2.2.2）

これらはウェブアクセシビリティ導入ガイドブックでは「重大」として掲載されています。

知覚可能の要件から改善する

Webアクセシビリティの4原則のうちの「知覚可能」は、それができなければ「操作可能」「理解可能」にもならないため非常に重要です。WCAGの達成基準で1.X.Xの番号のついている、適合レベルAの項目に満たせていないものがあるなら（たぶんあります）、そこから着手することには合理性があります。

知覚可能の達成基準はコンテンツの内容にかなり依存するので、Webサイトの性質によってはかなりの難易度になります。とはいえ新しく追加されるページだけでも知覚可能の問題を減らしていければ、それらのページの情報をより多くの人に届けられるかもしれません。コンテンツの管理に関わる人たちへ考慮するべき点を周知することになるので、アクセシビリティに関する理解を得て、協力関係を作っていくための第一歩にもなるでしょう。

機械的なチェックで見つかるところから改善する

SEOに取り組んでいる人にはおなじみのLighthouseには、「ユーザー補助（Accessibility）」として、アクセシビリティに関するスコアリングを行う機能があります。このチェックは、axe-coreというライブラリを使ってチェックされ、Lighthouseのスコアリングルールに従って採点されます。こういった機械的なチェックツールで見つけられる問題から直していくのは、特に当事者が周囲にいないWebサイト運営者にとっては効果がわかりやすく可視化され、取りかかりやすいものだと思います。

アクセシビリティのチェックだけを目的とするなら、Lighthouseよりも axe Devtoolsブラウザ拡張の利用をお勧めします。スコアリングはしてくれませんが、アクセシビリティチェックに特化しているぶん使いやすいです。

自動チェックには2つの注意点があります。ひとつは 自動チェックだけでは完璧なアクセシビリティチェックにはならない ということ、そして 自動チェックの指摘を潰すために間違ったやり方で修正すると、アクセシビリティがむしろ下がる ということです。Lighthouseのスコアを上げることを目的として、かなり残念なことをしてしまっているサイトにはたまに出くわします……。

ウェブアクセシビリティ導入ガイドブックによると自動チェックツールで発見できる問題は全体の2割から3割程度といいます。とはいえ自動チェックツールで発見できる問題を修正するだけでも、かなりアクセシビリティが向上する体感を待っています。うまく使いこなせば、間違いなく強力な武器になります。

キーボード操作から改善する

アクセシビリティをあまり気にせず作られたWebページでは、文字入力以外の操作は、マウスポインタかタッチスクリーンで行う前提になっているでしょう。それでも、適切なHTML要素を使って作られたWebページであれば、何も特別なことをしなくてもキーボードで操作できるようになっています。

キーボードによる操作は、さまざまな支援技術で利用するために必要な要素でもあります。たとえばスクリーンリーダーを使う全盲のユーザーは、マウスポインタの位置を把握することが困難なため、ほとんどの操作をキーボードで行うことになります。

キーボードでうまく操作できない場所があるということは、適切なHTML要素を選べていなかったり、必要な要素がCSSにより隠されてしまったり、JavaScriptでの動きの実装でキーボードでの操作を考慮できていなかったりすることが原因です。キーボードで操作できるかどうかが、実装の適切さのひとつの目安になります。

アクセシビリティに本格的に取り組む

ここまでが、予備知識のない状態から「とりあえず」で始められるアクションの紹介でした。あまり教科書通りなやり方ではなく、とにかく何か少しでも良くできるやり方を紹介したつもりです。

アクセシビリティの世界は奥が深く、ある特性を持つ人にとって使いやすくなるだろうという調整が、ほかの特性の人にとって良くない結果を生んでしまうこともしばしばあります。アクセシビリティは何かをやって終わりにできるという代物ではなく、常にいま取り残されていそうな人がどこにいるのか、目を向けていかなければなりません。

当事者を知る

先にも触れましたが、やはりアクセシビリティを必要とする当事者を知ろうとするアクションを無しに、アクセシビリティに取り組んでいくことはできません。クラウドソーシングサービスなども用いて、障害当事者が参加したWebアクセシビリティへの取り組みにしていくべきでしょう。さまざまな障害をもつ人を、制作・開発・運用チームの一員として迎え入れられるとベストです。

障害そのものや、支援技術を使った操作を体験してみるのも良いでしょう。「色のシミュレータ」というスマートフォンアプリでは、カメラの映像を使って見分けづらい色のある色覚特性での見え方再現することができます。ロービジョン体験キットでは、さまざまな見えづらさを体験することができます。書籍「Webアプリケーションアクセシビリティ」の付録には、支援技術が数多く紹介されており、 パソコンやスマートフォンのOSの標準機能として提供されているものも多くあります。freeeアクセシビリテイー・ガイドラインには、参考情報内にいろいろなスクリーンリーダーの操作方法がまとめられています。

こういった体験をする上で気をつけなければいけないのは、どんなに工夫したやり方をしても、ひとりひとりの当事者の世界そのものを体験することはできないという点です。シミュレーションに近い状況の人もいれば、あまり似ていない状況の人もいます。どんな情報を拾いあげ、どういう操作をしていくか、そのやり方はその人ならではのものです。擬似体験で当事者を理解したつもりになってしまうのは危険です。当事者と関わった経験が乏しければ、その傾向がより強まる点にも注意が必要です。

網羅的なチェックをする

本格的にアクセシビリティに取り組んでいくのなら、WCAGの適合レベルに基いて達成目標を立て、現状のWebサイトでその達成基準のどれを満たしてどれを満たしていないのかを網羅的にチェックしていくべきでしょう。

しかしこれをいきなりやるのは大変なことです。目標の立て方もよくわからないし、チェックの仕方もわからない、ページもいっぱいある、という状態になるはずです。なのでこのセッションでは、まずはウェブアクセシビリティ導入ガイドブックを読みながら該当しそうな箇所を探すというやり方を第一歩として紹介しました。

私は（自分が関わっているからという要素が強いですが）すぐに使える目標とチェックリストのセットとしてfreeeアクセシビリテイー・ガイドラインを使うことを推奨しています。このガイドラインは、WCAG 2.1の適合レベルAAと対応する²ように作ってあります（ただし一部に適合レベルを変更したものがあります）。チェックリストを記載したGoogle Spreadsheetもあり、すぐに使えるようになっています。

ただし、プロジェクトの要件としてWCAGやJISの適合レベルへの準拠が求められている場合には、必ずWCAGやJISに従ったテストをしてください。freeeのチェックリストでは、そこまでの保証はできません。

以下に、このチェックリストを使って自分がどんな手順でチェックしているかを載せた記事があります。

アクセシビリティを前提とした制作・開発・運用体制にしていく

freeeのチェックリストには、「デザイン」「コード」「プロダクト」の3種類のシートが用意されています。これは、デザイナーがデザインを作り、エンジニアがコードを書き、QA（品質保証）チームがリリース前の確認を行うという流れを意識したものです。

画面デザインを作った時点でチェックをしたり、コーディングでも人の目でのチェックやaxe-coreでのチェック、eslint (eslint-plugin-jsx-a11y, eslint-plugin-vuejs-accessibility)やbiomeやmarkuplintによるコードリントを行うようにすれば、「リリース直前になって問題が発覚してやり直しになる」という状況を防ぐことができます。Webサイトの場合、構築後もページやコンテンツが追加・変更されていくはずです。それらに関わる人たちにも、アクセシビリティの視点をもってコンテンツを検討したり、出来上がったものをチェックしてもらう必要があるでしょう。

制作・開発・運用に関わる人全員に、アクセシビリティの説明をして、チェックのためにスクリーンリーダーの使い方を説明して……というのは大変なことです。すこしでもそこを楽にできるようにAccessibility Visualizerというブラウザ拡張を作っています。これを使うことで、スクリーンリーダーが読み上げるはずの情報が可視化され、そして明らかに問題のある場所にはエラーメッセージを表示することができます（Firefox版もあります）。

1. WCAG 2.2からは、日本語版のタイトルが「達成方法集」ではなく「テクニック集」に変更される見込みです https://www.mitsue.co.jp/knowledge/blog/a11y/202411/21_0902.html ↩

2. WCAG 2.2でないのは、その対応作業をまだやっていないからです ↩