既存Webアプリのアクセシビリティを改善する方法

「自治体案件の入札要件にJIS X 8341-3の準拠が入っていて、既存のシステムがどこまで対応できているか分からない」「大手企業との契約更新でアクセシビリティ方針の提出を求められたが、開発時に一度も検証していない」というご相談が増えています。多くの場合、期限は数ヶ月後に迫っているのに、社内に何を直せばいいか判断できる人がいません。

アクセシビリティ対応は「見た目を整える」作業だと誤解されがちですが、実際はキーボード操作・スクリーンリーダー・コントラスト・フォーカス管理といった、通常のマウス中心の開発では意識されない観点の積み重ねです。この記事では、既存アプリを後から改善する前提で、何から見るべきか、自動チェックと手動チェックの役割分担、現実的な段階対応の進め方を整理します。

なぜ「後から」の対応は難しいのか

新規開発時にアクセシビリティを設計に組み込むのと、稼働中のアプリに後付けするのとでは難易度がまったく違います。理由は3つあります。

1. 構造的な問題は表面の修正では直らない。例えばdivやspanでボタンを実装している(セマンティックでないマークアップ)場合、CSSで見た目を整えてもスクリーンリーダーには「ボタン」として認識されず、role属性の追加やHTML要素の置き換えが必要になり、影響範囲がコンポーネント全体に及びます。
2. コンポーネントの再利用が裏目に出る。共通化されたモーダルやドロップダウンに問題があると、それを使っている全ページに同じ不具合が波及します。裏を返せば「共通コンポーネントを直せば一気に多くのページが改善する」ので、優先順位づけ次第で効率は大きく変わります。
3. 検証を後から一括でやると量が膨大になる。ページ単位・機能単位でチェックすると、既存アプリでは数十〜数百件の指摘が一度に出ることが珍しくありません。全部を同時に潰そうとすると期限内に終わらず、かといって場当たり的に直すと再発します。

これらを前提に、「まず何を見るか」から始めるのが現実的です。

最初に見るべき6つの観点

WCAG(Web Content Accessibility Guidelines)やJIS X 8341-3は項目数が多く、全部を一度に理解しようとすると挫折します。実務では、影響が大きく検出しやすい以下の6観点から着手するのが効率的です。

1. キーボード操作
マウスを使わずTabキーだけで全機能を操作できるか。フォーム入力、モーダルの開閉、ドロップダウンメニュー、日付ピッカーなど、JSで作り込んだUIパーツほど「マウス前提」で実装されがちで、キーボードで操作不能になっているケースが多発します。特にモーダルは「開いたらフォーカスがモーダル内に移る」「Escで閉じる」「閉じたら元の位置にフォーカスが戻る」の3点が抜けている実装をよく見ます。

2. スクリーンリーダーでの読み上げ
VoiceOver(Mac/iOS)やNVDA(Windows、無料)で実際にページを読ませてみます。見た目上は問題なくても、「ボタン」「リンク」といった要素の役割が読み上げられない、フォームのラベルと入力欄が紐づいていない(labelタグやaria-labelの欠落)、エラーメッセージが読み上げられずユーザーが気づけない、といった問題が高確率で見つかります。

3. コントラスト比
文字色と背景色のコントラスト比が基準(通常テキストで4.5:1以上、大きいテキストで3:1以上)を満たしているか。薄いグレーの補足テキストやボタンのdisabled状態、プレースホルダーテキストで未達になっているケースが典型です。ブランドカラーがそもそも基準を満たさない色味の場合、デザインシステム側の見直しが必要になることもあります。

4. 代替テキスト(alt属性)
画像・アイコン・グラフに適切なalt属性があるか。「装飾目的の画像にはalt=""(空)を設定して読み上げをスキップさせる」「情報を持つ画像には内容を説明するaltを入れる」という使い分けができておらず、全画像にファイル名がそのまま読み上げられる、あるいは全部alt無しで存在自体が無視される、という両極端な状態になっているケースが多いです。

5. フォーカスの可視化
Tabキーで移動した際、今どこにフォーカスがあるか視覚的に分かるか。outline: noneをリセットCSSやデザイン都合で全消ししているサイトは非常に多く、これをやるとキーボードユーザーは自分がどこを操作しているか一切分からなくなります。デザインを崩さずフォーカスを可視化する(独自のfocus-visibleスタイルを当てる)対応が必要です。

6. ARIA属性の適切さ
aria-label、aria-expanded、aria-liveなどのARIA属性が正しく使われているか。ここで重要な原則は「ネイティブHTML要素で実現できるものはARIAを足すより先にネイティブ要素に寄せる」ことです。ARIAは後付けで付与するほど誤用のリスクが上がり、間違ったARIAは「何もないより悪い」(誤った情報がスクリーンリーダーに伝わる)結果になりがちです。

自動チェックと手動チェックの役割分担

「アクセシビリティチェックツールで100点になったから対応完了」という誤解が非常に多いですが、これは危険です。自動チェックで検出できるのはWCAG違反全体の3〜4割程度と言われており、残りは人間の目と操作でしか見つかりません。

自動チェックで拾えるもの(まず機械的に潰す)
- axe DevTools、Lighthouse(Accessibilityスコア)、WAVEなどのツールで、コントラスト比不足、alt属性の欠落、見出し構造の乱れ、フォームのlabel欠落といった「静的な構造の問題」を検出できます。
- CI に組み込める(axe-core のnpmパッケージや pa11y-ci など)ため、一度直した箇所が後戻りしないようリグレッション防止に使えます。
- ただし自動チェックは「HTML構造上おかしいか」しか判定できず、「実際に使えるか」は判定できません。alt="image123.jpg"のような機械的に無意味なaltも、属性が存在するというだけで自動チェックを通過してしまいます。

手動チェックでしか拾えないもの
- キーボードだけで実際に全操作フローを完走できるか(購入、申込み、検索など主要導線)
- スクリーンリーダーでの読み上げが「意味として通じるか」(alt属性の内容の質、読み上げ順序の論理性)
- フォーカストラップ(モーダル内でTabが正しく循環するか)、フォーカスの喪失(要素が動的に消えた時にフォーカスがどこにも移らず迷子になる)
- 色だけに依存した情報伝達がないか(エラーを赤色だけで示し、テキストや記号の併記がない、など)

現実的な進め方は「自動チェックで機械的に潰せるものを先に全部潰し、残った工数を手動チェックが必要な主要導線に集中投下する」順序です。全ページを手動で舐めるのは工数的に非現実的なので、コンバージョンに直結するフロー(申込み・問い合わせ・検索・決済など)を優先して手動検証します。

段階対応の優先順位

期限がある中で全部を一度に直すのは現実的でないため、影響度・実装コスト・調達要件の必達ラインの3軸で段階分けします。

フェーズ1: 致命的な操作不能を解消(1〜2ヶ月)
- キーボードで主要導線が完走できない箇所(モーダル、ドロップダウン、カルーセル)
- フォームのlabel欠落によりスクリーンリーダーで入力欄の用途が分からない箇所
- コントラスト比が著しく低い(3:1未満など)本文テキスト

このフェーズは「使えない」から「使える」への転換で、ユーザー影響が最も大きく、調達要件でも真っ先にチェックされる項目です。

フェーズ2: 構造的な整合性を整える(2〜4ヶ月目)
- 見出し構造(h1〜h6)の論理的な階層化
- ARIA属性の誤用修正、フォーカス可視化の全面適用
- 画像・アイコンのalt属性を意味のある内容へ置き換え

フェーズ3: 準拠レベルの底上げと運用定着(4ヶ月目以降)
- WCAG準拠レベル(A→AA)の網羅的な達成
- デザインシステム・コンポーネントライブラリへのアクセシビリティ基準の組み込み(新規実装で後退させない仕組み)
- 定期監査体制の構築(自動チェックのCI組み込み、四半期ごとの手動監査)

ここで重要なのは、フェーズ3を飛ばして「フェーズ1だけ直して終わり」にしないことです。フェーズ1のみの対応は一時的な調達要件クリアにはなりますが、次の機能追加で新しいコンポーネントがまた同じ問題を再生産し、半年後に同じ指摘が再発します。デザインシステムへの組み込みまで含めて初めて「改善」ではなく「体質改善」になります。

外注する際の進め方

社内にアクセシビリティの知見を持つエンジニアがいない場合、外部への依頼を検討することになりますが、進め方を誤ると「診断レポートだけもらって、直す人がいない」という状態に陥りがちです。

• 診断と実装を分離しない。監査会社による診断レポートは詳細ですが、実際にコードを直すのは別チームということが多く、レポートの指摘内容とコードの現実(フレームワークの制約、コンポーネント構造)がかみ合わず実装段階で詰まるケースがあります。実装まで一貫して担当できるチームに依頼すると、「直すとしたらどれくらいの工数か」まで含めた現実的な見積もりが最初から得られます。
• 調達要件の必達ラインを最初に確認する。JIS X 8341-3の等級(AA相当が一般的)、提出が必要な適合度合いの説明書式(みんなの公共サイト運用ガイドラインの様式など)を先に確認し、「どこまでやれば要件を満たすか」の合意を取ってから着手します。過剰品質は工数の無駄になり、不足は納品後の差し戻しになります。
• 対応後の証跡を残す。自動チェックツールのスコア推移、手動テストのチェックリストと結果を記録として残しておくと、後日の説明責任(自治体からの追加確認、社内稟議)に対応しやすくなります。

既存プロダクト全般の改善で最初に見るべき観点は既存プロダクトの改善、外部チームが最初に見る観点で整理しています。またモバイル画面での使い勝手の問題はアクセシビリティと重なる部分が多く、既存SaaSのモバイル使い勝手を見直すも合わせて参照すると、UI改善全体の優先順位がつけやすくなります。

torcheees では、Rails・React/Next.jsなどフロントエンド技術に精通したチームが、診断から実装まで一貫して対応します。監査レポートを渡して終わりではなく、実際にコンポーネントを直し、デザインシステムに落とし込むところまで担当できるのが強みです。モダナイゼーション支援の一環として、既存アプリのアクセシビリティ改善もご相談いただけます。

まとめ

• キーボード操作・スクリーンリーダー・コントラスト・alt属性・フォーカス可視化・ARIAの6観点から着手し、自動チェックで機械的に潰せるものを先に処理してから手動チェックを主要導線に集中させる
• 期限がある中では「致命的な操作不能の解消→構造整合性→準拠レベルとデザインシステムへの組み込み」の3段階で優先順位をつけ、フェーズ1だけで終わらせず体質改善まで進める
• 外注時は診断と実装を分離せず、調達要件の必達ラインを先に確認した上で、証跡を残しながら進める

自治体・大手企業との取引でアクセシビリティ対応が必要になった、あるいは既存アプリの現状把握から始めたいという場合、torcheees では診断から、継続的な改善支援まで一貫してご相談いただけます。お問い合わせフォームからお気軽にご連絡ください。