こんにちは、RightTouchでデザインエンジニアをしている @kan_dai です。
今回は、僕が個人的にプロダクトのウェブアクセシビリティの改善に取り組んでいることについて紹介します。
この記事で紹介するのは比較的小さく簡単に始めることができる内容で、プロダクト開発に関わる人で「ウェブアクセシビリティ対応をしたいけど、何から手をつけたらいいかわからない」という方がいれば参考になれば嬉しいです。
はじめに
世間的にウェブアクセシビリティという言葉や認知が広がり、それに伴いWebサービスでもウェブアクセシビリティ対応をすることは一般的になってきたように思います。
RightTouchでもファーストプロダクトのQANT Webをリリースしてから3年が経ちプロダクトも増え、ありがたいことに色んな方に使ってもらう機会が増えている現状です。
それに伴いアクセシビリティの重要性も高まっています。しかし、しっかりとしたアクセシビリティ対応にはスキルも知識も工数も必要だと考えています。
RightTouchでも基本的にはアクセシビリティ対応されたライブラリやデザインシステムを用いた開発をしていますが、専門のチームやチェック体制はないので、開発を進めていく中でアクセシビリティ対応しきれていない場所はどうしても出てきてしまいます。
そんな状況で、少しでもプロダクトのアクセシビリティ改善に役立てばと思って僕が実践していることを紹介します。
そもそもなぜアクセシビリティ改善に取り組むのか
実際にやっていることを紹介する前に、そもそもなぜ取り組むのかも簡単に書いておきます。
最初に書いたように世間的に求められることが増えているのもそうですが、その他にも以下のような理由があります。
やっておいてマイナスになることはない
アクセシビリティの改善は、限定的なケースだけでなく多くのケースで使いやすさが向上することが多いと考えています。
アクセシビリティというと、たとえば目が不自由な方向けにスクリーンリーダーで読み上げ可能な実装をする・ポインター操作ではなくキーボード操作できるようにするなどの例があります。
この例で言うと、たとえばキーボード操作は目が不自由な方以外でも使いますし、多くのケースで使いやすくなるのがイメージしやすいと思います。
読み上げ可能にするのも、歩きながら情報を得るために使われている場合もあるかもしれません。なので、どのように使われるかは実はいろんなケースがあって、対応しておくことで誰かの役に立つことは多いのではないかと思います。
これらの理由から基本的にやっておいてマイナスになることはないと考えています。
小さなところから取り組むことができる
アクセシビリティ対応というと難しいイメージがあるかもしれません。実際に難しいケースはあるかもしれませんが、小さな課題から取り組むこともできます。
たとえば、「画像にalt属性を入れる」というのはわかりやすいですが、「画面遷移する要素はaタグでマークアップする」のように、正しい要素でマークアップするだけでもブラウザ標準の支援が受けやすくなるため立派なアクセシビリティ対応です。
こうした小さな改善の積み重ねが、将来的に役立つ可能性があります。
知識としてアンテナを張っておきたい
チームに 「アクセシビリティについてわかる人がいない」という状況は避けたいと考えています。
専門家とまではいかなくても、チームにある程度わかる人がいた方が相談や質問が来たときにも対応することが可能になりますし、将来的に組織が大きくなったときや、アクセシビリティ対応が本格的なプロジェクトとして立ち上がったときにも役立ちます。
そういった意味で、日頃からアクセシビリティ改善に取り組むことで情報へのアンテナを張っておきたいという気持ちがあります。
実際にどうやっているか
ここからは、どのようにアクセシビリティ改善に取り組んでいるかを紹介します。
まず前提として、私の場合は自社プロダクトに関わっており、プロダクトの仕様や仕事の進め方にはある程度裁量がある状態です。その中で、できる範囲でアクセシビリティ改善に取り組んでいます。
具体的には以下のような形で、課題が見つかったらissueに溜めておいて、プランニングでスプリントに取り入れるのを繰り返し行っています。
- チェックリストを用いてアクセシビリティチェックを行う
- 見つかった課題をGitHubでissueにしておく
- スプリントの中で取り組めそうなものを1つか2つ取り入れる
チェックリストを用いてアクセシビリティのチェックを行う
まずは現状を把握するために、WCAG(Web Content Accessibility Guidelines) 2.2を参考にチェックリストを作成し、対象のプロダクトのアクセシビリティのチェックをします。
WCAGには「レベルA（通称: シングル・エー）」「レベルAA（通称: ダブル・エー）」「レベルAAA（通称: トリプル・エー）」の3つの適合レベルがあり、Aは最低限の基準で対応もしやすい、AAAは発展的な基準で対応が難しいとされています。
一般的には、レベルAとレベルAAの達成がされているのが望ましい状態とされているので、それに倣ってAとAAを基準にチェックを行いました。
あきらかに問題があるものには「x」をつけつつ、詳しくみないと判断できないものはいったん「△」にしておくなどして、このチェック自体も時間をかけすぎないように行いました。
簡易的にチェックをしただけでもいくつかの問題が見つかり、たとえば、以下のようなものがありました。
- 画像アップロード機能があるが、alt属性を追加できる機能がない
- ボタンにフォーカスしても見た目が変わらずキーボード操作している場合に選択されているかが視覚的に分かりづらい
ちなみに、この時は自分でチェックを行いましたが、今だったらコーディングエージェントやAI搭載ブラウザを利用してアクセシビリティチェックをしてもらうことも便利だと思います。
たとえば、以下はClaudeCodeで特定のディレクトリ配下で アクセシビリティ上の問題を調査して5つピックアップしてください と指示した結果です。
何から始めたら良いのかわからない、アクセシビリティの知識がない場合などはAIにチェックしてもらい、そのまま修正までしてもらうなど、できる範囲で対応することを始めるのは良いと思います。
見つかった課題をGitHubでissueにしておく
僕のチームではタスクをGitHubのissueで管理して、GitHubプロジェクトを用いたスクラム開発を行っています。
実際にアクセシビリティチェックで見つかった課題を、すぐやる・やらないにかかわらずGitHubのissueにしておきます。
スプリント中に取り組めそうなものを取り入れる
スプリントのプランニングを行いメインでやるタスクが決まったら、起票したアクセシビリティタスクの中からメインタスクとの工数の兼ね合いで、できそうなものがあればスプリントに追加します。
基本的には1スプリントに1タスク程度を目安にしていますが、可能であれば取り組むという感じで、メインタスクで忙しい場合などは組み込めない場合もあります。
小さく積み上げていくことが大事だと考えているので、無理して続かなくなるよりはそういったスタンスで取り組んでいくことを心がけています。
成果・効果
この取り組み自体は去年から続けており、対応できないスプリントもありますが、着実にいくつかの課題を改善できました。
効果が直接的に見えにくい領域ではあるので、何かに現れることは期待せずに、「誰かの役に立っているかもしれない」「プロダクトが良くなっている」 ということ自体をモチベーションにしています。
まとめ
リソースが限られる中でのアクセシビリティ改善を小さく積み上げていく取り組みについて紹介しました。同じような状況の方の参考になれば幸いです！
RightTouchでは、アクセシビリティ改善や良いプロダクトを作りたいエンジニアを募集しています。興味のある方はぜひお声がけください！
