フロントエンドが押さえたいWebアクセシビリティの基礎 ── WCAG・WAI-ARIAを実プロダクトで試す
はじめに こんにちは。and factory フロントエンドエンジニアの坂内です。 4月の個人テーマとして、Webアクセシビリティ（WCAG・WAI-ARIA）の基礎を調べ、自社プロダクトで計測まで試したので共有します。 「アクセシビリティは大事」と聞くものの、何から手をつければよいか分からないと感じるエンジニアは多いはずです。本記事はフロントエンドの実装視点で、まず押さえておきたい範囲に絞ってまとめました。 結論 先に持ち帰ってほしいポイントを3つに絞ります。 実務の目標ラインはAAレベル準拠（JIS X 8341-3:2016もWCAG 2.0と同内容のため、AAが事実上のスタンダード） 大原則は「No ARIA is better than Bad ARIA」で、<button> を使えばロール・キーボード操作・フォーカスがすべて自動で揃う 自社プロダクト4ページの横断計測の平均は93点（自動検査の範囲）で、指摘はselectのラベル不足とコントラスト比不足が中心、修正コストも小さい 詳細を順番に説明します。 調査の背景 私が担当しているプロダクトは占いコンテンツのWebサービスです。複数ページで同じ <select> やドロップダウンが繰り返し登場するため、共通コンポーネント越しにUIを組み立てる構成です。 フロントエンドの実装では、<div> や <span> だけでUIを組む場面が増えました。Reactなどのライブラリでカスタムコンポーネントを作る場合、見た目はモーダルやドロップダウンに見えても、HTML上は意味を持たないただの箱になりがちです。 この状態では、スクリーンリーダーや支援技術を使うユーザーから見ると、機能の伝わらないコンポーネントが増えていきます。 現状把握として、ChromeのLighthouseでトップページを計測したところ、Accessibilityスコアは86点でした。検出された指摘は <select> のラベル不足やコントラスト比不足など、共通コンポーネントとデザイントークン由来の項目が中心です。共通部品の不備は複数ページに波及します。改修へ進む前段階として、まず基礎を押さえておきたいと判断しました。 以前からアクセシビリティは気になっていたテーマでもあり、チームでSEOやUI品質について話し合う機会が増えたことも後押しになりました。そこで4月の個人テーマとして、WCAG・WAI-ARIAの基礎調査と自社プロダクトの横断計測を据えました。次の章からWCAG・WAI-ARIAの順に整理し、最後に自社プロダクトの計測結果へつなげます。 WCAGとは WCAG（Web Content Accessibility Guidelines）は、W3Cが策定したWebアクセシビリティの国際ガイドラインです。障害のある人や高齢者を含むあらゆるユーザーが、Webコンテンツを利用できるようにするための指針です。 4つの原則（POUR） すべての達成基準は、次の4つの原則に分類できます。 原則 内容 例 Perceivable（知覚可能） 情報がユーザーに認識できる 画像のalt、字幕 Operable（操作可能） UIが操作できる キーボード操作対応 Understandable（理解可能） 内容や操作方法が理解できる エラー表示の分かりやすさ Robust（堅牢） 多様な環境で動く 正しいHTML構造 3段階の適合レベル レベル 位置づけ 具体例 A 最低限。これがないと使えない人が出る キーボード操作可能、画像にalt属性 AA 一般的に目指すべき標準 コントラスト比4.5:1以上、200%拡大対応 AAA 最高レベル。完全準拠は現実的に困難 コントラスト比7:1以上、手話付き動画 日本ではJIS X 8341-3:2016がWCAG 2.0と同内容のため、公的機関でも参照されています。実務で目標とする標準ラインは AA準拠 です。 ...