本連載は
改正された障害者差別解消法や、デジタル庁の取り組みからの影響を受け、アクセシビリティ向上への機運は日ごとに高まっているように感じます。著名な企業がアクセシビリティへのスタンスを表明するケースも増えてきました。
しかし、こうした情報が目に入っているのは、あなたがアクセシビリティに関心がある側の人だからです。多くの場合、社内でのアクセシビリティへの意識はまだまだ高くないのが実態です。
個人や有志による非公式な取り組みでも、アクセシビリティは徐々に改善することは可能です。しかし、いずれは限界を迎えます。企業が提供するWebサイトやWebアプリケーションは組織で開発されており、大規模であり、かつ成長していくからです。
継続的に取り組み、成果を出し続けるためには、こちら側も組織として取り組むことが重要です。組織全体へアクセシビリティを啓発し、開発プロセスに組み込む必要があります。本章
なお、続編として
座学での理解には限界があります。活動の下地ができたら、小規模な改善にトライします。手を動かして改善を行えば、実際に
個人で改善して、感覚をつかむ
まず個人で感覚をつかむために、今携わっているプロジェクトで改善を試してみましょう。このトライは小手調べで、実施することそのものが目的です。以下のものが取り組みやすいでしょう。
- UIのコントラストを部分的に改善する
- 非表示になっているフォーカスを表示する
- ボタンを
button
要素でマークアップする - 画像に代替テキストを付与する
今のフェーズで行え、かつあなたの裁量で変えられる範囲でかまいません。まずは
改善される箇所はほんの少しでもよいのです。ほんの数行のコードでも、利用者にとっては大きな意味を持ちます。押せなかったボタンが押せるようになったという変化は、無理矢理にでも使っていたユーザーや利用を諦めたユーザーには圧倒的な改善です。
ほかのプロジェクトとの整合性も気にする必要はありません。整合させようとしたら全体を一気に改修するしかなく、手が出せなくなってしまいます。部分的にアクセシブルであっても利用者にデメリットはありません。
複数人で改善に取り組むために──対象の絞り込み
個人で感覚をつかめたら、次はいよいよ複数人での活動に移ります。
複数人で取り組む場合、メンバーが個々に気になった箇所を改善していくのは避けましょう。改善を試みるメンバーは、たいてい社内のいろんなプロジェクトにそれぞれ分散してアサインされています。その状態で個別に改善すると、改善される箇所が散発的になり、以下のような課題が生じます。
- まとまった改善として実感できるまでにはかなりの時間がかかる
- 会社全体やプロダクト総体として見たときにどの程度良くなっているのかがわかりにくい
- 改善度合いを社内外にプレゼンテーションすることが難しい
結果として、モチベーションが維持できず、継続が困難になります。チームで取り組みを進めるには、対象を絞り込んで目標を立てることが必要です。この項では
対象を絞り込むには「プレスリリースが出せる単位」で考える
アクセシビリティには
これを打破し、目標を定めるには
プロダクトやサービスを通してユーザーに提供され、アクセスできたという結果を得ることが重要です。結果から逆算し、
プレスリリースが出せる単位は、
「提供形態」
「特定のアクセシビリティ観点」
たとえばfreeeでは、
提供形態や機能単位を絞り込むには
提供形態や機能単位を絞り込むには、プロダクトやサービスが何を提供しているかを洗い出し、
まず、どういう形でユーザーにサービスを提供しているかを、アクセシビリティに取り組みたいメンバーと一緒に洗い出します
複数のプロダクトを持っている会社は、プロダクトを列挙します。管理者用と従業員用のようにユーザータイプごとにプロダクトが分かれている場合は、それも挙げます。
それらのプロダクトが複数プラットフォームで提供されている場合は、プラットフォームごとに列挙します。Webブラウザ経由なのか、iOSやAndroidのネイティブアプリケーションなのか、組込み型なのか、などです。ハードウェアという点では、PCなのか、スマートフォンなのか、タブレットなのか、キオスク端末なのか、といった点もあります。
さらに機能という単位でも挙げます
リストアップを行うと、優先度を考える土台ができあがります。リストに対して高
- プロダクトのコアは何か
- それがなければこの会社のプロダクトとして成立しないと言い切れるもの
- 利用するうえで避けて通れないものは何か
- サインアップやログイン、ホーム画面など、それが使えなかったらそもそも利用開始できないもの
- 利用頻度が高い機能は何か
- 利用頻度が高い機能の操作を毎回誰かに代わってもらうのは難しい。アクセシブルでなければ継続利用は厳しくなる
- ユーザーが多い機能は何か
- 必須機能でなくてもユーザーが多ければ、改善によって多くの人が恩恵を受けられる
アクセシビリティ観点を絞り込むには──3つの観点
提供形態や機能単位を絞ったうえで、どのアクセシビリティ観点を改善するのかを絞ります。筆者のお勧めは
アクセシビリティ観点の絞り込み❶──知覚可能から改善
絞り込む観点はいくつかあります。そのうちのひとつは、アクセシビリティの原則から考えるものです。WCAGでは
アクセシビリティ観点の絞り込み❷──キーボード操作から改善
結果が見えやすく、かつ多くの達成基準に影響があるのは、
まず、キーボード操作は身近です。開発者が一部の操作をマウスを使わずにキーボードだけで操作していることもよくあるため、恩恵も実感できます。改善の担当者自身が利用者視点に立てるので、正解が比較的明確であり、手もとでも検証しやすいです。
反復操作を伴う業務アプリケーションの場合、キーボード操作による効率化も期待できます。また、自社プロダクトの弱点を埋める意味でもキーボード操作への対応は求められます。競合製品によっては、すでにキーボード操作を実装している場合があるからです。
アクセシビリティ観点の絞り込み❸──機械チェックで100点を目指す
機械チェックで100点を目指すアプローチも、取っかかりとしてはよいものです。
機械チェックで見つけられる課題は限定的ですが、取り組みの始めやすさ、問題の明確さ、改善のしやすさ、モチベーションの維持しやすさという点では優れています。エラーに対する対処がわかりやすいため、作業を分担しやすいというメリットもあります。
実際にfreeeでは、Lighthouseで100点を取ることから取り組んだチームがありました。スコアが明確に表示されるため取り組みが継続しやすく、周囲にも結果を伝えやすかったのです。
個人やチームの裁量を活用して改善する
改善対象を絞り込めたら、いよいよ実際の改善に取り組みます。手を動かすことで、問題のボリュームや対応する工数の感覚もつかめ、今後の見込みも立てやすくなります。
とはいえ現時点ではまだオフィシャルな活動ではなく、有志による取り組みです。大きく環境を変化させようとすると大変です。まずは個人や所属チームの裁量で手を動かせる範囲で試しましょう。
ソフトウェア開発の現場では、近年、デザイナーやエンジニアが一定の改善工数を裁量として持つケースがあります。freeeでは、エンジニアにはいわゆる
こうした時間に収まる中で、まずは着実に改善を積み上げましょう。対象が絞られていれば、完了までのマイルストーンは短くなります。テーマを絞り込んでいれば、学習も早く進むため、一定のモチベーションを持って進められます。何より、ひとつの機能において、
改善結果を社内で共有する
改善したら結果を社内で共有します。
ドキュメントや記事、スライドなど、あとから参照できる形で共有します。現時点では、アクセシビリティの対応事例は社内に蓄積されていないはずです。あとから参照できれば、興味を持つ人を増やすきっかけになり、同じ課題に遭遇したときの事例として活用できます。
キーボード操作やスクリーンリーダーの読み上げを改善した場合は、その操作の様子を動画として撮影するのが手っ取り早く、改善結果も具体的に伝わります[1]。
共有頻度としては、月次やスプリント単位など、定期的に出します。一気に出そうとすると時間がかかりますし、まとめる作業も大変です。一定のタイミングで出すほうが作業負荷も低く、出し方もパターン化できます。