座学での理解には限界があります。活動の下地ができたら、小規模な改善にトライします。手を動かして改善を行えば、実際に「使えなかったものが使えるようになる」という実感を持てます。

個人で改善して⁠、感覚をつかむ

まず個人で感覚をつかむために、今携わっているプロジェクトで改善を試してみましょう。このトライは小手調べで、実施することそのものが目的です。以下のものが取り組みやすいでしょう。

• UIのコントラストを部分的に改善する
• 非表示になっているフォーカスを表示する
• ボタンをbutton要素でマークアップする
• 画像に代替テキストを付与する

今のフェーズで行え、かつあなたの裁量で変えられる範囲でかまいません。まずは「アクセシビリティを改善するためのコミットが実際に出現した」という事実を作りましょう。

改善される箇所はほんの少しでもよいのです。ほんの数行のコードでも、利用者にとっては大きな意味を持ちます。押せなかったボタンが押せるようになったという変化は、無理矢理にでも使っていたユーザーや利用を諦めたユーザーには圧倒的な改善です。

ほかのプロジェクトとの整合性も気にする必要はありません。整合させようとしたら全体を一気に改修するしかなく、手が出せなくなってしまいます。部分的にアクセシブルであっても利用者にデメリットはありません。

複数人で改善に取り組むために─⁠─対象の絞り込み

個人で感覚をつかめたら、次はいよいよ複数人での活動に移ります。

複数人で取り組む場合、メンバーが個々に気になった箇所を改善していくのは避けましょう。改善を試みるメンバーは、たいてい社内のいろんなプロジェクトにそれぞれ分散してアサインされています。その状態で個別に改善すると、改善される箇所が散発的になり、以下のような課題が生じます。

• まとまった改善として実感できるまでにはかなりの時間がかかる
• 会社全体やプロダクト総体として見たときにどの程度良くなっているのかがわかりにくい
• 改善度合いを社内外にプレゼンテーションすることが難しい

結果として、モチベーションが維持できず、継続が困難になります。チームで取り組みを進めるには、対象を絞り込んで目標を立てることが必要です。この項では「対象の絞り込み」の方法を紹介します。

対象を絞り込むには「プレスリリースが出せる単位」で考える

アクセシビリティには「幅広さ」が常につきまといます。より幅広い局面でアクセスできることを目指すと、すべての画面で、すべての機能で、すべての利用状況で、すべてのアクセス手段で使えなければならない……といった思考に陥ります。しかし改善は始まったばかりで、リソースは有限です。途方に暮れてしまうのも無理はありません。

これを打破し、目標を定めるには「社外向けのお知らせやプレスリリースが出せる単位」を考えることが有効です。

プロダクトやサービスを通してユーザーに提供され、アクセスできたという結果を得ることが重要です。結果から逆算し、「⁠このサービスやプロダクトがアクセシブルになっていることが、社内や社外、ユーザーに伝わるようにするにはどうしたらよいのか」を考えると、優先度や着手順を決めていく道筋が作れます。

プレスリリースが出せる単位は、「⁠提供形態や機能単位」×「特定のアクセシビリティ観点」で考えます。

「提供形態」とは、どのプロダクトの、どのプラットフォームでの提供版を対象にするか、ということです。freeeでいえば、freee会計なのかfreee人事労務なのか、そのWeb版なのかスマートフォンアプリケーション版なのか、という大枠を指します。「⁠機能単位」とは、アプリケーションのどの部分をアクセシブルにするか、ということです。アプリケーションは一定の機能単位を使えることでタスクが実行でき、目的が達成されます。特定の1画面だけの対応だと、ユーザーのゴールである「設定を終える」「⁠作業を実施する」という流れ全体で見たときはアクセシブルにならない可能性があります。画面を飛び石で改善するのではなく、まず一定の機能単位すべてがアクセシブルになる姿を目指します。

「特定のアクセシビリティ観点」とは、多数あるアクセシビリティの改善ポイントのうちのどこに対応するか、ということです。スクリーンリーダーでの読み上げ、キーボード操作、ビジュアルデザインによる見やすさの改善、ナビゲーションラベルの改善など、改善の観点は多岐にわたります。改善に不慣れだったりリソースを割きづらかったりする状況で、さまざまな観点に同時に対応しようとすると部分的な対応にとどまります。そのため、改善に取り組み始めた段階では、改善する観点をあえて絞ったほうが成果を上げやすくなります。

たとえばfreeeでは、「⁠提供形態」としてfreee人事労務の従業員向けスマートフォンアプリケーションを、「⁠機能単位」としてアプリケーションでの主要タスクである勤怠打刻と給与明細閲覧を対象にしました。次に「特定のアクセシビリティ観点」として、スクリーンリーダーで利用可能にすることを選びました。そして、この3つの交点に絞り、改善を行い、そのお知らせを社外に向けて発信しました（図1⁠）⁠。機能としては小さい単位ですし、アクセシブルになったのはスクリーンリーダー利用時に限定されます。しかし、この改善によって、視覚障害者である従業員が自身で打刻したり、給与明細を閲覧したりできるようになったのです。

提供形態や機能単位を絞り込むには

提供形態や機能単位を絞り込むには、プロダクトやサービスが何を提供しているかを洗い出し、「⁠ここが使えなかったら致命的」という箇所を見出します。

まず、どういう形でユーザーにサービスを提供しているかを、アクセシビリティに取り組みたいメンバーと一緒に洗い出します（一人で行うと抜け漏れが起きるためです⁠）⁠。

複数のプロダクトを持っている会社は、プロダクトを列挙します。管理者用と従業員用のようにユーザータイプごとにプロダクトが分かれている場合は、それも挙げます。

それらのプロダクトが複数プラットフォームで提供されている場合は、プラットフォームごとに列挙します。Webブラウザ経由なのか、iOSやAndroidのネイティブアプリケーションなのか、組込み型なのか、などです。ハードウェアという点では、PCなのか、スマートフォンなのか、タブレットなのか、キオスク端末なのか、といった点もあります。

さらに機能という単位でも挙げます（図2⁠）⁠。機能はおおむね、集客や告知用のWebページ、サインアップやログイン、導入時チュートリアル、トップページやダッシュボード、ユーザー設定、個別処理を実施する機能に分けられます。

リストアップを行うと、優先度を考える土台ができあがります。リストに対して高（対応しないと使用不能⁠）⁠・中（使用不能かもしれない⁠）⁠・低（使用不能とまではいえない）の3段階ぐらいで優先度をつけます。優先度を考えるには以下のポイントがあります。

• プロダクトのコアは何か
• それがなければこの会社のプロダクトとして成立しないと言い切れるもの
• 利用するうえで避けて通れないものは何か
• サインアップやログイン、ホーム画面など、それが使えなかったらそもそも利用開始できないもの
• 利用頻度が高い機能は何か
• 利用頻度が高い機能の操作を毎回誰かに代わってもらうのは難しい。アクセシブルでなければ継続利用は厳しくなる
• ユーザーが多い機能は何か
• 必須機能でなくてもユーザーが多ければ、改善によって多くの人が恩恵を受けられる

アクセシビリティ観点を絞り込むには─⁠─3つの観点

提供形態や機能単位を絞ったうえで、どのアクセシビリティ観点を改善するのかを絞ります。筆者のお勧めは「知覚可能から改善」「⁠キーボード操作から改善」「⁠機械チェックで100点を目指す」という3つです。それぞれ解説します。

アクセシビリティ観点の絞り込み❶─⁠─知覚可能から改善

絞り込む観点はいくつかあります。そのうちのひとつは、アクセシビリティの原則から考えるものです。WCAGでは「知覚可能」「⁠操作可能」「⁠理解可能」「⁠堅牢性」の4つの原則を挙げています。ここからさらに絞り込むならば「知覚可能」です。要素の存在を知覚できなければ、それを操作することも、理解することもできないからです。逆にいえば、要素の存在を知覚さえできれば、支援技術を駆使したり、一時的に人の手を借りたりといった方法で切り抜けられる可能性が出現します。

アクセシビリティ観点の絞り込み❷─⁠─キーボード操作から改善

結果が見えやすく、かつ多くの達成基準に影響があるのは、「⁠キーボードのみですべての操作を可能にする」から取り組むというアプローチです。

まず、キーボード操作は身近です。開発者が一部の操作をマウスを使わずにキーボードだけで操作していることもよくあるため、恩恵も実感できます。改善の担当者自身が利用者視点に立てるので、正解が比較的明確であり、手もとでも検証しやすいです。

反復操作を伴う業務アプリケーションの場合、キーボード操作による効率化も期待できます。また、自社プロダクトの弱点を埋める意味でもキーボード操作への対応は求められます。競合製品によっては、すでにキーボード操作を実装している場合があるからです。

アクセシビリティ観点の絞り込み❸─⁠─機械チェックで100点を目指す

機械チェックで100点を目指すアプローチも、取っかかりとしてはよいものです。

機械チェックで見つけられる課題は限定的ですが、取り組みの始めやすさ、問題の明確さ、改善のしやすさ、モチベーションの維持しやすさという点では優れています。エラーに対する対処がわかりやすいため、作業を分担しやすいというメリットもあります。

実際にfreeeでは、Lighthouseで100点を取ることから取り組んだチームがありました。スコアが明確に表示されるため取り組みが継続しやすく、周囲にも結果を伝えやすかったのです。

個人やチームの裁量を活用して改善する

改善対象を絞り込めたら、いよいよ実際の改善に取り組みます。手を動かすことで、問題のボリュームや対応する工数の感覚もつかめ、今後の見込みも立てやすくなります。

とはいえ現時点ではまだオフィシャルな活動ではなく、有志による取り組みです。大きく環境を変化させようとすると大変です。まずは個人や所属チームの裁量で手を動かせる範囲で試しましょう。

ソフトウェア開発の現場では、近年、デザイナーやエンジニアが一定の改善工数を裁量として持つケースがあります。freeeでは、エンジニアにはいわゆる「20％ルール（週1日はチーム目標とは別の施策に工数を使える⁠）⁠」や「品質維持工数」が設定されています。デザイナーも、プロジェクトの進捗を妨げない範囲での別の活動が個人の裁量で実施されています。

こうした時間に収まる中で、まずは着実に改善を積み上げましょう。対象が絞られていれば、完了までのマイルストーンは短くなります。テーマを絞り込んでいれば、学習も早く進むため、一定のモチベーションを持って進められます。何より、ひとつの機能において、「⁠これまで使えなかったものが使えるようになっていく」という実感が得られることは醍醐味となります。

改善結果を社内で共有する

改善したら結果を社内で共有します。

ドキュメントや記事、スライドなど、あとから参照できる形で共有します。現時点では、アクセシビリティの対応事例は社内に蓄積されていないはずです。あとから参照できれば、興味を持つ人を増やすきっかけになり、同じ課題に遭遇したときの事例として活用できます。

キーボード操作やスクリーンリーダーの読み上げを改善した場合は、その操作の様子を動画として撮影するのが手っ取り早く、改善結果も具体的に伝わります[1]。

共有頻度としては、月次やスプリント単位など、定期的に出します。一気に出そうとすると時間がかかりますし、まとめる作業も大変です。一定のタイミングで出すほうが作業負荷も低く、出し方もパターン化できます。