Webアプリの「見えにくさ」カイゼンのためにやったこと 〜 アクセシビリティのはじめの一歩 〜

🔒前回のおさらい

　前回は「セキュリティ初心者がDevSecOpsに挑戦してみた話」で、AWSやSonarQubeを活用したセキュリティ対策を紹介しました。

🎯 今回のテーマ

　今回は、自分たちが作ったWebアプリをより多くの人に使ってもらえるよう、「アクセシビリティ」改善に取り組んだ話をします。

📚 アクセシビリティの基本を学ぶ

　アクセシビリティという言葉は知っているものの、それがどういう意味なのか詳しく知らなかったため、まずはチームでアクセシビリティについての動画を見ました。

　動画は今年(2025年)4月に実施された Qiita Conference 2025 のDay1のセッションで、イベントを視聴していたメンバーからのおすすめになります。

[Qiita Conference 2025 Day1動画]
https://youtu.be/ZFQNzqJqsvQ?si=n6oIH3E9FTZ9i-Ja&t=874

[資料]

　この動画で、ユーザビリティとアクセサビリティの違いや、Webアプリのアクセサビリティをチェックするツール（axe-core/playwright）があることを学びました。

ユーザビリティ
あくまで「誰か（特定の人）」にとっての使いやすさを追求します。
（例）オンラインストアで日常品をまとめ買いする人が、頻繁に購入する商品を効率的に見つけられるよう、購入履歴からのワンタップ再注文やパーソナライズされたおすすめで快適さを追求する。など

アクセサビリティ
「多様な能力を持つ最も幅広い層の人々」にとっての使いやすさを追求します。
特定のターゲットユーザーだけでなく、高齢者、障害者、外国ルーツの人々など、これまで対象外とされがちだった人々も含めて、少なくとも「使える」状態を確保することを目指します

※アクセシビリティは 「a11y(エーイレブンワイ)」 （accessibility の a + 11文字 + y）と呼ぶことも学習の中で知りました。

axe-core/playwright（ツール）
e2eテストツールである Playwright のテストで アクセシビリティ検証を実行できる。
Playwright のテストコードの中でページ操作後、レポート出力のコードを書くだけで、その状態の DOM に対して axe-core によるチェックを行いレポートを出すことが可能である

※axe-core（アクセコア） は、WebサイトやWebアプリケーションがアクセシビリティの基準を満たしているかどうかを、ウェブアクセシビリティの国際基準であるWCAG（Web Content Accessibility Guidelines）に基づいて検証を行うものだそうです。

💭 仮説とペルソナ設定

　アクセシビリティについて学ぶことで、高齢者、障害者、外国ルーツにも使いやすいよう、Webアプリをカイゼンするんだなというイメージは掴めました。しかし、対象者のそれぞれのシーンを考え、対応するとなるといくら時間があっても足りないと考え、まずは2日でツール診断とカイゼンすることにしました。
　スコープを限定するためには、ペルソナを設定して仮説を立てることで検証範囲を絞れるのではないか？ということで、ペルソナを設定し仮説を立てました。

[考えたペルソナ]

ユース名：
視覚に特性を持った人が医療保険申込と外貨保険申込をカスタマイズして申込完了する

ペルソナ：
30歳、男性
色の見え方でP型、D型の特性を持っている
※色覚異常のP型（1型）は赤系の色が見分けにくく、D型（2型）は緑系の色が見分けにくいタイプです。

前提条件：
・スマートフォンを使って申込を行う
・商品の紹介ページで、一定の医療保険と外貨保険の商品概要を理解している

シナリオ（操作フロー）：
1. 公式の商品紹介ページより、申込ページにアクセスする
2. 医療保険のデフォルトプランから主契約・特約をカスタマイズする
3. 申込手続きに進み、クレカ、本人登録を経て申込が完了する

制約・課題（仮説）：
・①入力画面のSuccess,Errorの枠が見えないので、入力エラーに気付けない
・②見積金額が赤文字になっているので見えず、合計金額が分からず進みたくなくなる
・③「必須」が枠が見えず、文字も背景に同化して見えないので、全項目入力するしかない
・④PDFアイコン見えず契約概要のダウンロードに気付きづらいので、文書を保存しない
・⑤チェックしてくださいのバルーンが薄く、チェック項目を見逃してしまう
・⑥赤文字の注釈が背景と同化して見えないので、注意事項に気付けない

仮説を立てた上で、axe-core/playwrightを実行すると、レポートに次の箇所のアクセシビリティエラーが出て、アプリ修正が必要になるという仮説を立てた上で、レポート出力する前に、自分たちで色覚に特性のある人の視点に立って画面を触り、以下の様な仮説を立ててみました。

[仮説①：Success,Errorの枠が見えない]

[仮説２：見積金額が赤文字になっているので見えない]

[仮説３：「必須」が見えない]

[仮説４：PDFアイコン見えず契約概要のダウンロードに気付きづらい]

[仮説５：チェックしてくださいのバルーンが薄い]

[仮説６：赤文字の注釈が見えない]

🔧 axe-core/playwright実行

　レポート出力は簡単でした。npmモジュールをインストールして、e2eテストのplaywrightのテストコードにレポート追加のコードを追加するだけで、e2eテストの実行でレポートが出力できました。

[npmモジュールインストール]

npm install -D @axe-core/playwright
npm install -D axe-html-reporter

[e2eテストにレポート出力追加]

import { test, expect, Page } from "@playwright/test";
// 【追加】axe-core/playwrightモジュール
import { AxeBuilder } from "@axe-core/playwright";
// 【追加】レポート出力用モジュール
import { createHtmlReport } from "axe-html-reporter";

// 【追加】レポート出力用のオブジェクト作成
const axeCheck = async (page: Page, screenName: string) => {
    const results = await new AxeBuilder({ page }).analyze();
    if (results.violations.length > 0) {
        createHtmlReport({ results, options: { reportFileName: `${screenName}.html` } });
    }
};

test("AxeCheckAll", async ({ page }) => {
    await page.goto("http://localhost:4173/");

    // デモ画面
    await expect(page.getByText(/^保険料お申し込みデモ$/)).toBeVisible();
    await await page
        .getByRole("button", { name: "複数の保険商品お申し込みへ進む" })
        .click();

    // 01画面
    await page.waitForSelector("text=/^保険料お見積り$/", { timeout: 10000 });
    await expect(page.getByText(/^保険料お見積り$/)).toBeVisible();
    // 【追加】レポート出力用オブジェクトで対象画面のレポート出力
    await axeCheck(page, "01gamen");
    const input = await page.getByPlaceholder("例）1990");
    await expect(input).toBeVisibl
    ：
    ：

[e2eテスト実行]

npx playwright test --project chromium

📊 レポート確認

　出力されたレポートを見てみると、次が分かりました。

分かったこと

• DOMに対してのエラー表示のためコードの対象箇所が分かりづらく、修正箇所の特定に時間がかかる
• 画面表示されたDOMの静的解析を行うため、HTMLを動的に表示非表示するものに関してはチェックされない。

[axe-core レポート]

レポートの中には、コントラスト比率NG が多数出力されており、Web基準を調べると私たちのアプリは、文字の色と背景のコントラスト比が4.5以上ない箇所が多く、高齢者や視覚に特性がある人にとっては、見づらいアプリとなっていたようです。

コントラスト
コントラスト（contrast)とは隣り合う色や明るさの 差 のことを言います。

　仮説を検証してみると、DOMの静的解析のため、レポート出力時に表示されていない仮説①のSuccessやErrorはチェックされませんでした。また、想定していた色覚特性P型、D型に対してのエラーは出ず、axe-core/playwrite ではP型、D型のチェックは出来ないことがわかりました。P型、D型でどう見えるかは、色のシミュレーターで確認できるようです。

[色のシミュレーター]

　CSSで指定した色のコントラストはチェックするものの、アイコンやイメージ画像コントラストはチェックしないため、単純なテキストのコントラスト比率で仮説②③⑤⑥がレポートに出力される結果となりました。

制約・課題（仮説）：
・❌①入力画面のSuccess,Errorの枠が見えないので、入力エラーに気付けない
・⭕️②見積金額が赤文字になっているので見えず、合計金額が分からず進みたくなくなる
・⭕️③「必須」が枠が見えず、文字も背景に同化して見えないので、全項目入力するしかない
・❌④PDFアイコン見えず契約概要のダウンロードに気付きづらいので、文書を保存しない
・⭕️⑤チェックしてくださいのバルーンが薄く、チェック項目を見逃してしまう
・⭕️⑥赤文字の注釈が背景と同化して見えないので、注意事項に気付けない

[仮説２：見積金額が赤文字になっているので見えない]

[仮説３：「必須」が見えない]

[仮説５：チェックしてくださいのバルーンが薄い]

[仮説６：赤文字の注釈が見えない]

🛠 コントラスト対応手順

コントラストの修正は、まず、Chromeの開発者ツールで色のコントラスト比や色を確認します。

[要素にマウスオーバーでコントラストが確認できる]

[要素をクリックしてCSSよりカラーコードが確認できる]

その後、 コントラスト比率チェッカー でコントラストを確認しながら、変更後の色を決め、デザイン画面の色を修正することで、レポートでエラーが出ないことを確認しました。
仮説②③⑤⑥はどれもコントラストが4.５以下だったため4.5以上の色に変更することでアクセシビリティ対応（コントラスト対応）ができました。

✅ まとめ

　今回の取り組みでは、「Webアプリを見えにくさ」という身近だけれど見落としがちな課題に向き合いました。axe-core/playwrightを使って実際の画面で診断を行い、「色覚特性を持つユーザーが困りそうなポイント」を具体的に検証できたことで、コントラスト比の重要性を体感的に理解できたのは大きな収穫でした。

アクセシビリティ対応は“はじめの一歩”が一番むずかしい。でも今回のように、

• ペルソナ設定で対象を明確にする
• ツールで仮説を可視化する
• 小さな改善を積み重ねる

ことで、現実的に進められる手応えを得られました。動画にもありましたが、完璧を目指すのではなく、「できることから始める」ことこそが、アクセシビリティの第一歩だと実感しています。皆さんもぜひトライして見てください。