これは何
Qiitaでは現在アクセシビリティ改善プロジェクトを立ち上げて、アクセシビリティ改善の取り組みを進めています！
この記事では、具体的にどのように改善を進めてきたのかと、実際やってみてどうだったかを紹介します。
背景
アクセシビリティ改善プロジェクトを立ち上げる前から、UIデザインや実装時に、クリックできる要素のタップエリアや、背景と文字色のコントラスト、画像やアイコンに適切な読み上げが設定されているかなどなどアクセシビリティ対応自体は行なっていました。
社内でも「アクセシビリティ」という言葉は浸透しており、デザインや実装、レビュー時に「アクセシビリティ対応の観点で〜」といった会話が自然に起きるような状態でした。
一方で明確なルールや基準は設けられていなかった為、漏れが生じたり人によって対応に差が出たりしてしまっていました。
また、インタラクションのある複雑な動きのUIではアクセシビリティ対応ができていませんでした。
こうした背景から、よりアクセシビリティ対応を向上させること・誰でもアクセシビリティ対応ができるようにするために、アクセシビリティ改善プロジェクトを立ち上げました。
アクセシビリティプ改善プロジェクトでやったこと
アクセシビリティチェッカーを活用して問題発見・修正
まずはわかっている&すぐに対応できる範囲でアクセシビリティ対応ができていない箇所の対応をしていきました。
axe DevToolsやANDIといったアクセシビリティチェックツールを活用し、主要なページをチェックしてissue化・対応していきました。
アイコンフォントの読み上げやラベルとフォームの紐付けなど、今までもやっていた部分でも対応が漏れている箇所があり、そうした部分の修正を行いました。
アクセシビリティ改善の進め方を調べる
並行して書籍やドキュメントを読んだりイベントを視聴したりして、どのように改善を進めていくと良いかを考えました。
特に参考にしていたのはこちらです。
-
Webアプリケーションアクセシビリティ ――今日から始める現場からの改善：書籍案内｜技術評論社
- 第7章「アクセシビリティの組織導入」
-
ウェブアクセシビリティ導入ガイドブック｜デジタル庁
- 「ウェブアクセシビリティの実践プロセス」の章
- freeeアクセシビリティー・ガイドライン
アクセシビリティ対応方針の作成
大体方向性が見えてきたら、アクセシビリティ対応方針を作成して社内に共有しました。
まずは草案を作成し、プロジェクトメンバー+デザイングループメンバーで内容のレビューと合意、それを社内全体に共有という形で進めました。
アクセシビリティ対応方針には、目指す適合レベル、適合範囲、対応順序、チェック方法などを記載しています。
勉強会の開催
続いて作成したアクセシビリティ対応の方針をメンバーに共有するために、社内でアクセシビリティ勉強会を開催しました。
そもそもアクセシビリティとは何か、なぜQiitaでアクセシビリティに取り組むのか、どうやってアクセシビリティに取り組むのかといった内容を共有し、最後に実際にVoiceOverを使ってアクセシビリティチェックをしてみました。
アクセシビリティHandbookの作成
合わせてアクセシビリティHandbookを作成し、アクセシビリティ対応の参考になるようにしました。
WCAGやUnderstanding WCAG、各社が公開しているアクセシビリティガイドライン、スクリーンリーダーやアクセシビリティチェッカー、おすすめのドキュメントや書籍などの情報をまとめています。
アクセシビリティチェックを進める
アクセシビリティチェックはfreeeさんが公開しているアクセシビリティー・チェック・リストを参考にGoogleフォームでチェックフォームを作成し、誰でもチェックができるようにしました。
アクセシビリティチェック自体もissue化してしまい、優先度の高いページから順に期日を切ってチェックをしています。
アクセシビリティチェックの結果をissue化する
アクセシビリティチェックを対応した人がチェック結果でNGだった部分をissue化するようにしています。
その中で重大な内容のものや影響範囲が大きいものから期日を切って対応をしていっています。
現時点で54件のissueが作成されており、そのうち17件が対応完了しています。
まだチェックが終わっていないページもたくさんあるので長い道のりです！
改善の内容はリリースノート - Qiitaで更新しています。
勉強会の開催
実際にみんなでアクセシビリティ対応を進めていく中で、アクセシビリティ対応に時間かかり過ぎてしまうという課題が出てきました。
そこで、アクセシビリティについての理解を深める&知識を増やすために、勉強会をスタートしました。
持ち回りでWCAGの内容などを整理して共有し、みんなで内容を話すという時間をとっています。
「この項目ってこの機能が該当するかも」「ここの理解ってこういうことで合ってる？」といった内容を話し合い、情報交換や課題の発見の場として役立っています。
実際やってみてどうだったか
ここからは、実際にこれらの内容を進めてみてどうだったかをまとめていきます。
「アクセシビリティ」が浸透しているのは大きい
元々Qiitaでは「アクセシビリティ対応しよう」「アクセシビリティ対応大切だよね」というコミュニケーションが日頃からされていて、「アクセシビリティ」がすでに浸透している状態でした。
そのため、「アクセシビリティ改善のプロジェクト始めたい」となった時も、説明コストがほぼなくスムーズにスタートでき、メンバーも各々でキャッチアップをしてくれました。
これは元々のセマンティックなマークアップやWCAGといったガイドラインを大切にする文化が大きいと思います。
人を巻き込む
一人でやり切るには、やることも多いしかかる期間も長く、走り続けるのが難しいです。
そこで、ドキュメントやアクセシビリティチェックフォームを用意して誰でもissueに着手できる状態にしたのがよかったです。
アクセシビリティチェックまでをissueにすれば、その先の改善のissueはチェックをした人が作成できるので、うまく分担することができます。
とりあえずチケットを切る
人を巻き込むと近いですが、とりあえずissueを作って期日を切ってしまえば、誰かが進められる状態になります。
自分がやらなきゃいけないタスクでも、issueにしてしまえばみんなから見れる状態になるので、「やらなきゃいけない」状態にできて良いです。
アクセシビリティ対応の期日を明確に決めることは難しいので、まずは希望ベースで期日を決めて適宜調整しながら着手するという進め方をしています。
いろんなところで躓きながらも進めている
とはいえ日々どう進めれば良いか頭を抱えながら進めています。
チェックの仕方はこれであっているのか、チェック結果がNGだった部分の修正方法はこれであっているのかなどなど、日々メンバー同士で話し合って進めています。
だからこそ、こうしてどんなふうに進めてきたかを共有することで、少しでも誰かの参考になれば嬉しいです！
今後やっていくこと
今後もやっていかないといけないこともたくさんあります。
例えばアクセシビリティHandbookは情報を網羅しただけなので、「アクセシビリティ対応やろうと思ったけど何から始めよう」という人にはむかない内容になっています。
また、アクセシビリティチェックフォームも実際に運用する中で、改善すべき点が見えてきました。
アクセシビリティチェックとissue化の進め方も、ページごとのアクセシビリティチェックでは対応しづらい課題もあったりします。
こうした部分をアップデートしていき、より誰でもアクセシビリティに取り組みやすい状態を整備してアクセシビリティ改善を進めていきます 