この文章について

これは Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」で基調講演をするにあたって、登壇内容を整理するために書いたものです。登壇内容とは一部に差異があります。

イベント映像

この文章はむちゃくちゃに長いので、登壇映像を見たほうがいいかもしれません。わたしの発表は13:23くらいから30分ちょっとです

登壇資料（内容は同一です）

目的

Web業界で「エンジニア」の肩書で仕事している人をターゲットとし、彼らに伝わりやすいかたちでWebアクセシビリティを捉えなおすことを目的とします
その上で、Webアクセシビリティに明日から取り組んでいけるよう、知識体系やツールの紹介を行います

Webアクセシビリティとは何か

まず、Webアクセシビリティという概念がどんなものかについて、敢えて具体的な説明の比率を少なめにして説明をしておきたいいです。

Webアクセシビリティは、英語の意味をそのままとれば「アクセス可能性」みたいな表現のしかたができます。日本語では「利用のしやすさ」という表現をされていることがあるようです。日本国内でWebアクセシビリティの普及活動をしているウェブアクセシビリティ基盤委員会の説明でも、「利用しやすさ」という表現が見られます。

しかし、「利用しやすさ」という言い方だけで説明してしまうのは、「ユーザビリティ = 使いやすさ」との境界が曖昧になってしまう問題があるように思えます。実際のところユーザビリティとアクセシビリティの境界は曖昧な部分もあるのですが、言葉のニュアンスの違いは把握しておいたほうがいいでしょう。

「ユーザビリティ」という言葉が使われる場合、しばしば「特定の状況で」「特定のユーザーにとって」という条件をつけて「使いやすい」という説明がされます。一方、「アクセシビリティ」という言葉が使われる場合は「どんな状況でも」「誰でも」と条件を付けた上で、「使える」という説明がされます。

つまり、「ユーザビリティ」は狭く深く使いやすさを追求していくのに対し、「アクセシビリティ」は浅く広く、使える人の範囲の広さを追求していく概念なのです。

誰かにとって使いやすいものを作ろうとすると、それ以前にまず「使える」ものを作る段階があるはずです。また、その「誰か」も、あなたの想像のできないような状況であなたのWebを使おうとしている可能性があります。「誰か」の裾野を広げ、ユーザーの母集団を増やす行為がWebアクセシビリティの取り組みと言えるでしょう。

Webアクセシビリティによくある誤解

Webアクセシビリティの説明として、よく「障害者や高齢者のための」という言い方がされます。ひどいときは「視覚障害者のための」と、より狭いターゲットが決め打ちされて理解されてしまっていたりもします。

しかしこれはWebアクセシビリティの本来の主旨からするとズレた理解と言わざるを得ません。、Webアクセシビリティでは一般的に、障害者や高齢者だけをターゲットとして、彼らのためだけの施策をするのは好ましくないとされています。

もちろん、アクセシビリティを考慮せずに作られたWebで不便を被ることが多いのは障害者や高齢者です。我々がWebアクセシビリティに取り組んだ結果としてわかりやすく得をしやすいのも彼らでしょう。しかし、あくまでWebアクセシビリティは「誰でも」「どんな状況でも」を目指すものです。

我々がWebの何かを企画・開発するうえでは、しばしばターゲットを定めてから進めていきます。たとえば「30代の会社員の女性が帰宅途中の電車の中でスマートフォンで見るWebサービスを作りたい」みたいなものを先に決めたとしましょう。わかりやすくするためにペルソナと呼ばれる具体的な人物像を作ったりする場合もしばしばあります。そしてそこから「落ち着いた色合いだけどかわいい雰囲気」とか「スマートフォンに最適化されたUI」のような要件ができていくずです。

しかし、「30代の会社員の女性が帰宅途中の電車の中でスマートフォンで見るWebサービス」の実際のユーザーには多様性があるはずです。実は朝の出勤前に自宅からサービスを利用するかもしれません。PCからサービスを利用したいかもしれません。実は10代や20代だったり40代以上だったりするかもしれません。会社員でなかったり、女性でなかったりするかもしれません。もしかしたら、海外からアクセスしてくるかもしません。

Webアクセシビリティで「誰でも」「どんな状況でも」を目指すのは、ターゲットを決めてそこに最適化されたものを作るという普通のやり方に逆行するように思えます。あるいは、こういったやり方に慣れ親しんでいるからこそ「視覚障害者のための」のような決め打ちをした施策をしてしまうのかもしれません。

しかし、普通のWeb開発では、ターゲットを意識しつつも、そうではないユーザーが存在する可能性を意識的または無意識的にに受け入れているはずです。「スマートフォン向けのWebサービスだから」という理由でスマートフォン以外からのアクセスを遮断したりしないだろうし、年齢や性別を厳密に認証するのは非現実的です（もちろん、このあたりに敢えてコストを割いてサービスの優位性を作ることもあります）。そして、想定外のユーザーが使用することによって予想外の売り上げを生むこともあります。

このように、ターゲットを定めて開発をすることと、ユーザーの多様性を受け入れて裾野を広げることは必ずしも矛盾しません。Webアクセシビリティはこういった例と同じく、ユーザーの多様性を受けいれていくことなのです。

Webアクセシビリティの捉え方

こういった誤解が発生しがちなのは、ユーザーの側からの視点でWebアクセシビリティが説明されることが多いからではないかと私は考えています。すなわち、「あなたが歳をとって老眼になったり、何かの都合で障害者となってしまったとき、Webが使えないと困りますよね。だからWebアクセシビリティをやりましょう」というような説明です。Web開発者ではない人もいる場でWebアクセシビリティを説明するときには、このほうがわかりやすそうではあります。

しかし今回のセッションはWebエンジニア向けのものです。なので、Web開発者の視点でWebアクセシビリティを捉えなおしてみたいと思います。

たとえば、PC向けに作られたWebサイトに、スマートフォン向けに最適化されたUIを追加したとします。レスポンシブなレイアウトにして、同じ画面がPCにもスマートフォンにも最適な状態で見られるようになっていると良いでしょう。すると、これまでPC向けの画面を我慢してスマートフォンで使っていた人たちは便利に使えるようになります。PCでしか使えないと思っていたものがスマートフォンでも使えるようになって、外出先で使う人が増えるかもしれません。ふだんPCを使わない人が使うようになるかもしれません。

つまりこの例では、スマートフォンに最適化したレイアウトを加えたことで、Webサイトを使うユーザーも使える状況も広げることができたといえます。こういったケースがWebアクセシビリティの話として扱われることはあまり多くありませんが、これも立派にWebアクセシビリティの例であるといえます。その証拠といっては難がありますが、Webアクセシビリティの標準化ガイドラインであるWCAG (Web Content Accessibility Guidelines) では、「1.4.10 リフロー」という項目でレスポンシブなレイアウトを推奨していたりもします。なぜなら、Webコンテンツを拡大して使用する弱視のユーザーにとっても、レスポンシブレイアウトになっているとスクロールを縦（または横）の一方向に限定して使用できる利点があるからです。

このように、Webアクセシビリティは必ずしも障害者や高齢者のために特別に何かするものというわけではなく、ふつうのWeb開発でも既に足を踏み入れている領域にあるのです。

加点法で見るWebアクセシビリティ

Web開発者にとってのWebアクセシビリティは、Webの品質を支える要素のひとつとして捉えるべきだと私は考えています。すなわち、バグの少ないプログラムを書いてユーザーがエラー画面を見る頻度を減らしたり、SPA化やパフォーマンスチューニングによってユーザーが待たされる時間を減らしたり、美しく機能的なユーザーインターフェース提供したりするのと同種のものなのです。

Webアクセシビリティの観点で問題があると、ハンディキャップを抱えるユーザーにより感情的な反応を受けてしまいがちです。ユーザーにとっては「なんで自分がこんなに不便をしなければならないんだ」という負の感情を持ってしまうのは仕方ないように思えます。

しかし、それによって「Webアクセシビリティは常に100点を取らなければいけないもの」として、減点法で考えてしまいがちになってしまったり、「いまは100点を取れないから」とすべてを後回しにしてしまうケースが多く発生していしまっているように思います。先程の例のとおり、ふつうに質の高いWeb開発をする中で、すでに皆さんはWebアクセシビリティの世界に足を踏み入れているのです。

私に受託の経験が無いため詳しくないのですが、過去にはWebアクセシビリティの話題が、受託のWeb制作会社を中心とした時期があったらしいです。受託の場合はWebアクセシビリティ要件は守らされるもので、どうしてもそれを満たせているかの減点法になってしまいます。しかし近年では自社サービスでWebアクセシビリティに力を入れているところも増えています。納品時点での完璧を目指す受託制作に比べて、自社サービスはリリース後も徐々に改善しく性質があります。だからこそ、継続して少しずつ良くしていくやら方、そのために加点法で評価していく見方が合っているはずです。

私もWebアクセシビリティにもう長く取り組んでいますが、絶対に完璧なものを作ることはまだできていませんし、今後も不可能だと思っています。Webアクセシビリティは絶対に完璧にしなければならない減点法のものではなく、ユーザーの裾野を広め、普遍的な価値を高めるための加点法のものとして捉えるほうが、よりWebアクセシビリティの本質に近いと私は考えています。

Webアクセシビリティの具体像

ここまでWebアクセシビリティという概念について、その概要とWeb開発者がどのように捉えるべきかについて説明しました。ここからは、具体的にWebアクセシビリティを構成する概念を解説していきます。

Webアクセシビリティで意識されるおもな問題

さきほど「Webアクセシビリティは障害者や高齢者のためだけのものではない」という説明をしましたが、しかし現実にWebアクセシビリティの恩恵を受けるのはやはり彼らです。

そこでひとまず、ここではWebアクセシビリティで意識されるハンディキャップの内容や、それに対してどのようなことをするべきかを紹介します。これらはあくまで代表的なハンディキャップの例であり、これらが意識しなければいけないものの全てではないことに注意してください。

全盲

全く目が見えない（または視力が非常に弱い）人の場合、スクリーンリーダー（画面読み上げソフトウェア）を使用して、音声や点字ディスプレイによってWebページの内容を読み取っています。そのため、画像の内容や、画面上の要素の位置関係を読み取ることができません。画像に対しては代替テキストを付与したり、位置関係については説明の仕方を工夫したりする必要があります。

ロービジョン

視力が非常に弱い人のことを弱視またはロービジョンという呼び方をします。スクリーンリーダーを使用している場合もありますが、画面を拡大したり色を反転させたりして自分の眼に合った見え方にしてWebを使用している人もいます。コントラストの低い色合いを使用していると情報を読み取れなかったり、広い画面領域を使用するWebページが使いづらかったりします。

色覚多様性

色の見え方は人によって違うことがあります。他の人にくらべて判別しづらい色合いのある人の割合は日本人男性の5％ほどと言われていて、特に赤と緑の区別がしづらい人が多くいます。そのため、たとえば正常と異常の状態を赤と緑の色だけで表現している場合、そういった人たちにはその区別が困難になってしまいます。

上肢障害

手や腕に障害があったり、あるいは寝たきりの状態であったりすると、マウスやトラックパッドなどのポインティングデバイスを上手く使えない場合があります。そういう場合でもキーボードを駆使したり、あるいはその人にあわせて工夫した道具を使ってWebを使用していることがあります。ポインティングデバイスによるホバーやドラッグ＆ドロップなどの細かなアクションが難しかったり、キーボードで操作できないUIを扱えなかったりする可能性があります。

聴覚障害

フロントエンドエンジニアの立場ではあまり関係しないことも多いですが、Webで動画や音声を扱う場合には聴覚障害のある人がそれらの情報を読み取れるかを意識する必要があります。書き起こしのテキストを提供したり、字幕や手話など音声以外の方法で情報を伝えなければなりません。最近は音声認識ソフトウェアでリアルタイムに字幕を提供したりすることもできます。
一時的な障害
ここまで挙げたようなハンディキャップは、自分には関係ないものと思われるかもしれません。しかし多くの人は歳を取ると視力が弱まるし、事故や病気によってハンディキャップを負うこともあり得ます。さらに、一時的にそういう状態になることだって考えられます。

たとえばスノーボードなどのスポーツをやっていて腕を骨折してしまうというのはよくあるはずです。両手の手首をギプスで固定してしまったらマウスやトラックパッドの使用は困難になるでしょう。たとえばメガネをしている人は、メガネを踏んで壊してしまった途端に画面を見るのが大変になったりするかもしれません。電車のなかで動画の埋め込まれたWebページを見ていて、イヤホンを家に忘れたので音声が聞けないなんて状態も、一時的に聴覚が使えないハンディキャップを負ったと言えるでしょう。

WCAG (Web Content Accessibility Guidelines)

このようにさまざまな種類のハンディキャップが意識されているわけですが、これらひとつひとつをいちいち意識してくのは大変です。人や状態によって程度の重い軽いもありますし、スクリーンリーダーや展示ディスプレイなどは軽い気持ちで体験してみるのも難しいものです。

そこで参照するべきなのが WCAG (Web Content Accessibility Guidelines) です。これはW3Cによって標準化されているガイドラインで、最新のバージョンは WCAG 2.1 で、ひとつ前の WCAG 2.0 は ISO/IEC 40500:2012 や JIS X 8341-3:2016 と一致するようになっています。つまりWCAG 2.0に従っていればJISや国際規格にも従っていることになるわけですが、WCAG2.1はWCAG 2.0の上位互換となるよう設計されており、Web技術の変化によって追加された項目もあるため、最新版であるWCAG 2.1を使用することが推奨されています。

WCAGの主要な部分は、「達成基準」と呼ばれる項目の集合によってできています。達成基準にはそれぞれA, AA, AAA（シングルエー、ダブルエー、トリプルエー）という「適合レベル」が付けられています。レベルAに指定されているものは達成が容易かつ実現されていない場合に問題の大きいものであり、レベルAAAに指定されているものの中には達成が非常に難しいものも含まれています。

WCAGの原文はもちろん英語ですが、ウェブアクセシビリティ基盤委員会による日本語訳が用意されているため、日本語ネイティブスピーカーの方はこちらを参照したほうが良いでしょう。

原文 https://www.w3.org/TR/WCAG21/
日本語訳 https://waic.jp/docs/WCAG21/

また、WCAGの関連文書の中には Understanding WCAG 2.1というものがあり、こちらには各達成基準が設定されている意図や、具体的な実装方法のヒントが書かれています。こちらもウェブアクセシビリティ基盤委員会により、日本語訳が公開されています。

なお、WCAGにはさらに改訂版となる WCAG 2.2や、その先のバージョンであるWCAG 3.0の策定作業が行われています。このあたりの紹介は先日の2021年のWebアクセシビリティという記事を参照ください

Webアクセシビリティの四つの原則

WCAGの達成基準は大きく分けて4つの大分類に分けられています。この4つは「アクセシビリティの四つの原則」と呼ばれています。

知覚可能
操作可能
理解可能
堅牢 (robust)

それぞれ具体的にどのようなものが求められているのか紹介します。以下の例は代表的でわかりやすいものを紹介するのを目的としていて、達成基準のレベルなどを考慮していません。

「知覚可能」はWebページ上の内容を認識できることが求められます
- 画像に代替テキストをつける
- 動画・音声に字幕や書き起こしや手話通訳をつける
- コントラストのハッキリとした色を使う
- 色やレイアウトに頼った説明をしないようにする
  -「操作可能」はフォームやボタンのようなUIを配置するとき、それが誰でも操作できることを求めています。
- マウスだけでなくキーボードでも操作できるようにする
- 動きのあるコンテンツを停止・一時停止できるようにする
- 見出しやheader/nav/main/footer要素でページ内ジャンプできるようにする
- 操作に時間制限を設けない
「理解可能」はページの内容やUIの挙動を、理解できることや予測できること、そしてそれらに一貫性があることを求めています。
- ページの言語が lang=”ja” のような属性値などで機械的に解釈できる
- フォームの入力内容のエラー箇所がユーザーにわかるようにする
- データの削除や決済前に確認したり、修正や確認ができるようにする
- ナビゲーションの位置や文言が一貫している
「堅牢」は、Webページが標準仕様になっていること、それによってスクリーンリーダー（画面読み上げソフトウェア）のような支援技術が連携できるようになっていることを求めています。
- HTMLの文法エラーがない
- スクリーンリーダーのような支援技術が適切な情報を読み取れるようになっている

こうしたかたちで、この4原則に対して様々な基準が定義されています。HTMLをコーディングする上でひと工夫すれば良くなるものもあれば、ビジュアルデザインに関するもの、コンテンツの根幹に関わるものまで様々な領域に跨っています。

WAI-ARIA

ガイドラインではないのですが、WAI-ARIAについてもここで少し触れておきます。WAI-ARIAはW3Cによって定められているHTMLの仕様で、HTMLの要素に対してUIのセマンティクスを付与する属性を追加したものです。

モダンなWebアプリケーションには、HTMLにもとからあるUIコンポーネントだけでなく、巧みにdivやspanとCSSを組み合わせてよりリッチな体験を提供するコンポーネントが少なからず存在します。たとえばテキストフィールドと選択肢のリストがセットになったコンボボックスなどが良い例でしょう。WAI-ARIAでは要素の役割をrole属性で、要素のプロパティやステートをaria-で始まる名前の属性で表現することで、そういったUIコンポーネントの状態をスクリーンリーダーなどの支援技術に伝えることができます。

WAI-ARIAを活用した事例集はW3CがWAI-ARIA Authoring Practicesとして公開していて、ウェブアクセシビリティ基盤委員会による日本語訳も公開されています。

組織ごとのWebアクセシビリティ方針・ガイドライン

WCAGにはたくさんの達成基準が定義されており、達成が比較的容易で重篤な問題を引き起こしやすいA（シングルエー）から、AA（ダブルエー）、AAA（トリプルエー）までの3段階に分類されています。もちろんAAAまで全ての達成基準が満たせることに越したことはないのですが、現実的には困難でしょう。

多くの組織（行政機関や一般企業など）では、「Webアクセシビリティ方針」と呼ばれる「Webアクセシビリティをウチはここまでやります」という文書が公開されています。たとえば、内閣府の場合は「JIS X 8341-3:2016 (WCAG 2.0) の適合レベルAAに準拠」を目標として、さらに一部のレベルAAAの達成基準について「可能な範囲で対応を行って参ります」とし、外部から提供されたものや古いPDFなどは例外としています。

多くの場合、「レベルAに準拠・レベルAAに一部準拠」か「レベルAAに準拠・レベルAAAに一部準拠」というラインを引くことになるはずです。先にこのような目標を立てておくことで、Webアクセシビリティとリリースまでのスピードのバランスを取りやすくなり、アクセシビリティ改善のためのアクションも取りやすくなります。ユーザー側からも問題の指摘をしやすくなります。

さらに、WCAGをベースにして組織にフィットするかたちのガイドラインを定義している企業もあります。国内ではサイバーエージェントとfreeeのガイドラインが公開されています。WCAGの文章は難解で現場レベルで使用するには難しい側面があります。これらのガイドラインはWCAGから自社のWebアクセシビリティ方針にあわせて達成目標を抽出し、平易な書き方でわかりやすく目的・達成方法・チェック方法が記述されています。

私見ですが、Ameba Accessibility Guidelinesは具体例やチェック方法が充実しており、freeeアクセシビリティー・ガイドラインは参考情報の充実度がすごいと思っています（自慢）。

https://a11y-guidelines.freee.co.jp/

Webアクセシビリティの検証ツール

非常に多岐にわたるWCAGの項目を全て把握して、問題が起きていないか確認・修正していくのはとても大変な作業です。もちろんWebサイトがガイドラインに評価しているのかを人の手で試験することもあるのですが、日常的なWeb開発のなかでは、まずはチェックツールを使って問題を発見していくべきです。

aXe, Lighthouse

aXeは非常に広く使われているWebアクセシビリティ検証ツールで、ブラウザ拡張として手軽に使用できたり、axe-coreというライブラリを通してCIに組み込んだりすることができます。

axe-coreを使用している最も有名な製品がLighthouseでしょう。Lighthouseはアクセシビリティに限らずWebページの品質を測定するツールで、Chromeの開発者ツールにも組み込まれています。Lighthouseの面白いところはWebアクセシビリティも含めて100点満点で採点してくれるところで、Webアクセシビリティ改善のモチベーションを高く維持することにつながります。

eslint, markuplint

Reactであればeslint-plugin-jsx-a11y、Vueであればeslint-plugin-vue-a11yを使えば、コーディング時にWebアクセシビリティ観点のlintをかけることができます。HTMLを書く人向けにはmarkuplintというものも開発されています。

Visible

今日このあとのセッションで登壇予定の五十嵐さん（@TheGodOfNeet）が開発している自動診断・改善提案ツールです。これについてはぜひ本人の話を聞いてみたいなと思っています。
https://visi.dev/

acot

昨年末にサイバーエージェントが新たに公開したツールがacotです。これはPuppeteerを使用してレンダリングされたWebページに対して検証を行うツールセットとして作られていて、aXe (Lighthouse) 単体よりさらに詳細な検証ができるようになるのではと期待しています。
https://github.com/acot-a11y/acot

ツールは万能ではない

手作業でアクセシビリティチェックをやっているとわかるのですが、こうしたツールを活用していくことで、格段に問題を発見しやすくなります。Pull Requestする前に1度aXeやLighthouseを実行して修正できそうなものを修正しておく習慣をつけるだけで、致命的な問題が起きる確立をかなり減らせるはずです。特にLighthouseは他の指標（SEO, Best Practice, PWA) と同時に検証でき、点数として数値化されることによって、継続して総合的な品質を高めていくことができるはずです。

しかし、Lighthouseが100点だったからといって、必ずしも問題がひとつも発生しない完璧なWebページになるとはかぎりません。WCAGの達成目標には機械的な評価が難しいものもあるし、「何らかの文字列が入っていれば検証ツール的にはOK」みたいな項目もたくさんあります。代表的な例としては画像の代替テキストは、人の眼で画像の内容を確かめないかぎりは正しい代替テキストになっているとはいえませんし、同じ画像であっても文脈によっては違う代替テキストを用意する必要があったりします。

法的制約

今回の文脈ではあまり強調しすぎないようにしたいので、その紹介だけに留めておきます。

Webアクセシビリティに関する情報は欧米に多く、その背景に障害者差別を禁止する法律が存在し、企業の社会的責任として取り組まざるを得ない事情があります。特に米国では Webアクセシビリティに関する訴訟が増加しており、年間2000件を超える訴訟が提起されています。Webをグローバルに展開しようとしている場合、Webアクセシビリティに取り組まないことが大きなリスクとなっています。

日本にも障害者差別解消法が2016年に施行され、「政機関等及び事業者は、社会的障壁の除去の実施についての必要かつ合理的な配慮」について「努めなければならない」と定められています。現在はあくまで努力義務があるだけという状態ですが、これを義務化する改正案が検討されています。法律の成立から施行までどれくらいの時間がかかるかはわかりませんが、義務化を機に、日本でもWebアクセシビリティに取り組むことが当たり前になり、取り組まないことがリスクとなる時代が到来するのではないかと思われます。

エンジニアがはじめるWebアクセシビリティ

ここまで、Webアクセシビリティがどう捉えられるべきなのか、具体的にどんな内容なのかを紹介してきました。ここからはより狭い視点で、エンジニアとしてWebアクセシビリティにどう向いあうべきかについて考えていきます。

Webアクセシビリティは難しすぎる

私は以前、Zennに「Webアクセシビリティ難しすぎる問題」という文章を書きました。ここまでWebアクセシビリティについて、なるべくやさしく説明してきたつもりですが、本気で考えると非常に難しいのです。

想像力を必要とする

最初に説明したとおり、Webアクセシビリティは具体的なターゲットを想定して施策を打つというより、あらゆる状況のあらゆるユーザーが使えるようにしていくものです。

しかしそれは、より抽象的なことを考えていく必要になるということでもあります。さまざまな状況のさまざまなユーザーにWebが使用されている場面を抽象化して、何を提供すると価値が届きやすいのかを考えなければなりません。あいだに一段抽象的なレイヤーが挟まってしまうのです。

しかも、多くの人にとって障害者のWebユーザーは未知の存在です。身近に当事者がいなければ、その存在を認識することもほとんど無いでしょう。先日もTwitterで視覚障害者のツイートに対して、その存在に驚きのリプライが集まっているところを目にしました。

そういった場合でもアクセシブルなWebを作れるように整備されているのがWCAGですが、これはこれで書き方が非常に難解で、これを読んでも一体何の役に立つのか、そもそも何の話をしているのかわかりにくいという問題があります。関連文書のUnderstanding WCAG 2.1を読めばそれぞれの達成基準の意図なども書かれているのですが、しかしその量も膨大です。

職域を跨いでしまう

さらに厄介な問題が、Webアクセシビリティの一言で括られている概念が、非常に広い分野に跨ってしまっていることです。そのため、ひとりでやろうとすると専門外の知識・職域外の行動が求められてしまいます。

多くのWebのプロジェクトでは、企画からデザインから実装までのあいだのどこかに分業が挟まるはずです。しかしWCAGはその分業の切れ目で分かれたりせず、あくまで4つの原則とそこらの小分類によって達成基準が並んでいます。その中から自分が何を意識しなければならないのかを抽出するのも非常に困難です。

あなたがエンジニアの立場でWebアクセシビリティに取り組もうとすると、どんな代替テキストを付ければいいのかわからない画像や、文字が小さく色のコントラストの低いUIデザインや、字幕の用意されていない動画や、見出しの不明瞭なテキストを同僚から受け取ることになるでしょう。

このように、Webアクセシビリティの取り組みを1人だけであったり、エンジニアだけでやっていくのは非常に難しいのです。

Webエンジニアとしてやるべきこと

では、Webアクセシビリティのためにエンジニアが何をするべきなのでしょうか。

一番きれいな形は、企画の開始時点からWebアクセシビリティに取り組むことが要件に入っていて、関係者全員で統一されたWebアクセシビリティ方針が策定され、全員がそれに基いて作業していくことです。それが最初からできていれば、Webアクセシビリティがここまで大きく関心を持たれることなく、当然のように粛々と行われるものだったでしょう。現実にはそんなことは起きず、Webにはアクセシビリティの問題が溢れてしまっています。

結局、関係者内で方針を検討したり具体的なアクションを起こしたりしないまま、Webアクセシビリティを後回しにしてしまう場合がほとんどでしょう。Webアクセシビリティについて発信していると、よく「いつかやらなければと思っているけど～」という反応をいただきます。そのあとには大抵「要件とのバランスが」「クライアントの理解が」「コストが」という話が続いてきます。

こうなってしまうのは、やはり最初にも述べたWebアクセシビリティへの誤解が影響してしまっているのではと思っています。すなわち「Webアクセシビリティは特定の人たちへの特別な対応だ」で「やらないと怒られるから仕方なく追加でやるもの」という認識になってしまっているのでしょう。そういう状態だと、怒られないように仕上げるには莫大な工数が必要で、それを捻出するためにクライアントを説得したり、やるべきだった要件を押しのけてやらなければならない。それがしんどいので後回しになってしまうのです。

しかしそのあと述べたとおり、Webアクセシビリティはあくまで「すべての人たちへの普遍的な対応」であり、それはバグや障害が起きなかったりページが早く表示されたりするのと同じ、品質を構成する要素なのです。だからこそ、普段の開発のなかでやれる範囲のことを少しずつやっていくのが良いはずです。

Webのエキスパートを自覚する

まず重要なことは、おそらくWebの技術に関して、あなたのプロジェクトでいちばん詳しいのはあなたを含むエンジニアであるはずということです。Webの仕組み、性質、他のメディアとの特徴の違いについて、エンジニアほど詳しく説明できる人はいないはずです。エンジニアこそWebエンジニアをリードすることができるはずなのです。

おそらく、Webの表示速度のようなパフォーマンスの問題、コードのリファクタリングのようなユーザーに見えない部分の品質のような、いわゆる非機能要件についてエンジニアがその改善をリードしていることは多くあるはずです。Webアクセシビリティもそれらと同じく、エンジニアがリードできはずなのです。

おそらく、あなたと仕事をともにするデザイナーやディレクター、あるいは案件を発注してきたクライアントといった人たちは、あなたほどWebの仕組みを理解していないでしょう。技術的に難しいことや思ったより簡単に実現できることの取捨選択をしていくのは難しいでしょう。そんな人たちに「Webアクセシビリティの方針はどうしますか？」という質問をしたところで、その重要性を理解することが難しかったり、あるいは「全部やればいいんでしょ？」と実現可能性の低い方針を作ろうとしてしまうでしょう。

まずは、あなたの理解と想像力でカバーできる範囲で、WCAGのレベルA相当の達成基準のうち比較的容易に着手できそうなものに何があるのかを考えてみるのが良いでしょう。その際、おそらくWCAGより、サイバーエージェントやfreeeのガイドラインを読んでみるとわかりやすいはずです。Ameba Accessibility Guidelinesにはレベル表記がありますし、freeeアクセシビリティー・ガイドラインでは[MUST]と書かれているものが厳しめのレベルA相当です。読んでみると、意外とこれまでに既にできているものや、ほんの少しの手間ですぐできそうなものが多いことに気付けるはずです。

できることから始める

何もしていなかったところからWebアクセシビリティの改善に着手するのなら、まずはLighthouseのスコアを取ってみるのが良いでしょう。LighthouseであればChromeに標準搭載だし、100点満点で採点されるのでモチベーションの維持になります。あなたのWebサービスの主要な画面や、サインアップフロー内の画面のスコアを取って、スクリーンショットを撮ってSlackにでも貼っておきましょう。

エンジニアとしてはついついCIに組み込んだりすることを考えたくなりますが、まずは手作業で、大事な画面に絞ってやってみるのでも十分でしょう。雰囲気が掴めてきたら、定期的にスコアを取ってトラッキングしていくと良さそうです。

そして結果を見て、直せそうなものを直してみましょう。Lighthouseのレポートには発見された問題の項目ごとに、該当箇所のHTMLソースと簡単な説明が表示されています。説明の最後のLearn moreリンクをクリックすれば web.dev 上のドキュメントを読むことができます。ドキュメントの最後にはaXeを開発するdeque社のDeque University上のドキュメントへのリンクが貼られていて、より詳しい情報を読むことができます。Deque University にはWCAGでの達成基準の番号も書かれているので、さらにWCAGやその関連文書、各社のガイドラインまで辿っていくことができます。WCAGまでくれば日本語訳も充実しているので、英語のドキュメントを読むのが苦手な人でもどう直せばいいのか調べやすいはずです。

そして少しずつ直して、そのたびスコアが上がっていくのを見ていきましょう。最初のうちはあっさりスコアを上げられる場所も多いはずです。

もちろんスコアが100になったからといって完璧になったわけではないのはさきほど説明したとおりです。しかし、高いスコアを出しているWebページであれば、何か問題が顕在化したときにも修正しやすくなっているはずです。

Webアクセシビリティを推進する体制を確立する

こうして少しずつLighthouseスコアを上げられるようになったら、それをまずはエンジニアにも広めていきましょう。Pull RequestをレビューするときにaXeやLighthouseの結果を見せてみたり、定期的にスコアを計測する仕組みを作って（あるいは手作業でスコアを記録して）いけば、同僚の理解も得やすいはずです。

しかし、aXeやLighthouseで指摘される問題や、あるいはWCAGなどのガイドラインを読み進めていくうちに、いよいよエンジニアの立場だけでは改善しようのないものが存在することに気付くはずです。コントラストの低い色の組み合わせで作られたビジュアルデザインや、字幕がなく音声を聴かないと（または、映像を見ないと）内容を理解できない動画素材など、エンジニアのコントロール下にない場所に問題があるときは、いよいよエンジニア以外の立場の人を巻き込んでいかなければなりません。

おそらくここでのゴールは、Webアクセシビリティを継続的に改善していく体制を作ることにあります。そのためには開発組織としてのWebアクセシビリティ方針を策定し、それに向かって少しずつでいいので前進していくことができる必要があります。

私はここで、やはりエンジニアのエキスパートとして他職種をリードしてほしいのですが、Webアクセシビリティには先述のとおりの難しさがあるので、一筋縄ではないでしょう。まずはエンジニアの中で目線をあわせ、その範囲を少しずつ広げていくやり方をとるのが良いはずです。

おわりに

これまで日本語で書かれたWebアクセシビリティに関する情報は、フロントエンドエンジニアにターゲットを絞ったものは多くありませんでした。今回はエンジニアを対象としてアクセシビリティのをする機会をいただけたおかげで、エンジニアの立場でWebアクセシビリティを捉えなおし、意識して第一歩を踏み出すための情報というかたちでの整理をすることができました。

Webアクセシビリティは、もはやWebサービスをグローバル展開するときには取り組むことが必須のものになっています。日本国内に限定したサービスでもこの先求められてくる時代が来るでしょう。その必要が出たときに慌ててすべてのコードやメディアやコンテンツを見直すようなことにならないよう、今からでもできることを始めておくべきだと私は考えています。

今回最も伝えたかったことは、Webアクセシビリティは特別なものではなく、品質の一部として継続的に向上させていくものだということです。だからこそ減点法ではなく加点法のものと捉えて、できる場所からやっていくやり方が必要となるはずです。そして品質を継続的に向上させていく行為は、エンジニアが最も得意とするもののはずなのです。

Discussion