アクセシビリティは「やさしさ」ではなく「技術」：リリースの足を止めない、現場での向き合い方

大規模なリアーキテクトやデザインリニューアルを伴うプロジェクトでは、アクセシビリティの優先度が一時的に下がってしまう局面は珍しくありません。

問題は、その状態が固定化して、ずっと後回しになってしまうことです。

この記事では、理想を追えない状況でも最低限の品質を落とさず、アクセシビリティをプロジェクト進行の足枷にしない2つのポイントを話します。

アクセシビリティ issue を仕分ける

リリーススピードを保つために、アクセシビリティの対応として「今直しておきたい issue」と「後で直す issue」に仕分けます。

仕分けの判断基準のひとつには、そのプロダクトで担保したいアクセシビリティの範囲として、影響を受けるユーザーの広さが考えられると思います。

• 今直す：多くのユーザーに影響する挙動。選択や送信などの UI がどの環境でも操作できるか、キーボード操作が滞りなくできるか、見出しレベルが適切に設定されているか、ツールのチェックでエラーが出ていないかなど。
• 後で直す：特定の環境のみに発生する挙動やプラスアルファの品質。特定のスクリーンリーダーのみで発生する読み上げの違和感や、特定の操作でのみ発生するバグ、プロダクト全体で一貫性を持たせるコード修正など。

WCAG の Understanding Docs にも達成方法が多数載っているように、アクセシブルにする手段や方法は複数存在します。

そのプロダクトで担保したい基準に鑑み、チームとしてアクセシビリティ力をスケールすることも視野に入れながら、品質の維持かつリリーススピードに合わせて運用負荷が上がらないような達成方法を選びとっていくことが大事です。（そして、一度選んだ達成方法を絶対解とせずに、ユーザーの反応やチームの習熟度に応じて最適な達成方法を探り続けるのも大事。）

こうして「すべてを完璧に」対応するのではなく、「このプロダクトにとっての最低限を対応する」ラインを引くことで、リリースのスピードを維持しながら品質の底抜けを防ぐことができると思います。

「最低限の品質」を仕組みに変える

アクセシビリティの推進役が品質をチェックするだけでは、チームのアクセシビリティ力はなかなかスケールしませんし、属人性も高いままです。

そこでフェーズに合わせて仕組み化を目指していきます。

AIにレビューさせる

プルリクエスト時にAIにレビューさせる仕組みを導入します。

ツールで機械的にチェックできる項目、例えば画像の alt 属性の有無や見出しレベルのスキップなどに加え、そのプロジェクトで一貫した、プロジェクト固有の達成方法をマークダウンでリスト化し蓄積しておきます。

そのリストを元に AI にレビューさせるプロンプトを実行することで、最低限の品質維持を目指します。

例えば、

• CSS の flex レイアウトで order を使用する場合、読み上げ順が見た目と異なってしまう場合があるので注意を促す
• ページやセクションの「タイトルとして機能する」テキストには、見出し要素を使用するようレビューさせる。ただし見出し直下に実質的なコンテンツがない場合は、見出し要素は使用しないと補足させる
• （ARIA の使いどころを決めているプロジェクトでは）ARIA を追加した箇所について、入れる必要性の経緯をコメントで求めさせる

など、ツールだけではチェック・判断しきれない細部の蓄積がアクセシビリティ品質を保つ根っこだったりします。

このような AI によるレビューの導入で、チェック側の負荷も下がりますし、レビューを繰り返し受けることで、そのプロジェクトで気をつけるべき勘所が自然とチームの中で醸成されるきっかけになると思います。

同期的にアクセシビリティのチェック会を実施する

デザイナーやエンジニアと一緒に、アクセシビリティ観点でコードをチェックするチェック会を定期的に実施します。

ツールでのチェック、キーボード操作、スクリーンリーダーでの操作など、実際に一緒に行って、アクセシビリティ観点で気になる箇所や、なぜその達成方法を選んだのかといった、チェックの勘所と意図を伝えていく場です。

推進役と一緒に具体的な項目をチェックを繰り返すことで「なぜアクセシビリティ対応が必要なのか」「どういう手段を選択してアクセシビリティ対応するのか」を実感として持ってもらうことができるので、職能を横断したメンバー間で、継続的なチェック会の実施が定着しやすくなります。

また、この場を通して、アクセシビリティをチーム共通のスキルにしていけると思います。

例を挙げてみます。あるページで「見出しレベル」を確認していたときのことです。デザインでは太字で大きい見た目なので、見出し（ h2 や h3 ）で実装されていましたが、見出しに続くコンテンツは存在しませんでした。

「デザインが太字で大きいから見出しにする」のではなく、 「そのテキストがコンテンツを適切に要約しているか」「次に続くコンテンツを内包しているか」 でマークアップを選び、この場合は太字で大きい見た目でも段落要素が妥当であると伝えました。

他の例も挙げてみましょう。見出しの直前に、見出しを補足するテキストや画像があります。素直に実装すれば表示順通りで、この場合、スクリーンリーダーの見出しジャンプ機能を使うと、見出し直前のコンテンツ（補足のテキストや画像）はスキップされます。

どの環境や操作法であっても見た目通りの順序で情報を伝えたいのか、装飾的な意味合いが強くスキップしたとしても伝えたい情報はデリバリーできるのか、企画やデザイン意図に立ち戻って実装方法を検討する必要があることを伝えました。

その時メンバーから 「アクセシビリティってお気持ちではなく技術なんですね」 という言葉が出ました。

アクセシビリティは、特定の誰かへの「やさしさ」や「配慮」という曖昧な概念ではないのですよね。

仕様に基づき、適切な構造を選択し、意図をアクセシブルにデリバリーするための「再現性のある技術」なんです。

時間がかかっても取り組むべきもの

チームがアクセシビリティを「時間のかかるよくわからないもの」から「時間がかかっても、取り組むべきもの」として認識できるようになるまで、こうした仕組みを作って、歩幅を合わせながら一緒に歩んでいく。

優先度が下がっても、手を離さずに、仕組みで粘り強くつないでいく。それが、最終的にプロダクトの価値を最も高める道だと思います。

アクセシビリティ記事、まだ続きます。

以下記事も、ぜひ合わせてご覧ください。

また、Gaji-Laboが支援させていただいたジョブメドレーのアクセシビリティ向上の取り組みと、「プロジェクトをやりきる」文化を読んでいただけると、よりリアルにプロジェクトの現場感がわかると思います。こちらもお読みいただけたらうれしいです。