ウェブアプリケーションのアクセシビリティは、もはや企業が無視できないものとなっています。インクルーシブであるべきという道義的責任と、アクセシビリティ関連法規による法的リスクが相まって、アクセシビリティに配慮した構築やテストの方法を理解することは、あらゆるフロントエンド開発者にとって不可欠な知識となっています。

Web Content Accessibility Guidelines（WCAG）は、障害の有無にかかわらず誰もがウェブサイトを利用できるようにするための基準を定めています。多くの法規制ではレベルAAへの準拠が求められますが、これは基準を意識的に理解し、遵守されているかを検証する努力なしには達成できません。

アクセシビリティへの配慮は、開発プロセス全体に組み込むことができます。

• アプローチ： 計画と開発の進め方
• 自動化： 自動テストへのチェックの組み込み
• 手動テスト： アプリケーションの監査
• エンジニアリングの先へ： コードを超えた課題への対処

アプローチ

アクセシビリティについて考える

最初のステップは、アクセシビリティについて考え始めることです。WCAGのドキュメントを読んで、多くのウェブページが抱える一般的なアクセシビリティの問題を理解し、アクセシビリティの課題を推進する存在になりましょう。表面的に触れただけでも、これまで幸運にも考える必要がなかった問題がどれほど多く存在するかにすぐに気づくはずです。

目標は、可能な限り早い段階でアクセシビリティが考慮されるようにすることです。企画やリファインメントのミーティングでアクセシビリティの懸念を提起し、最初からアプローチに組み込まれるようにしましょう。すべての人にとってのアクセシビリティを悪化させる変更には異議を唱え、アクセシビリティ負債を積み重ねないようにしてください。問題の検出を自動テストだけに頼るのでは不十分です。

既存のソリューションを再利用する

公開されているライブラリや社内のライブラリを活用することは、車輪の再発明を避け、よくあるアクセシビリティの問題を一から解決する手間を省く優れた方法です。MUIやChakraのようなコンポーネントフレームワークを使えば、アクセシビリティに配慮された汎用的なコンポーネントを利用できます。独自のコンポーネントをデザインシステムライブラリとして社内で共有すれば、こうしたアクセシビリティのベストプラクティスを横断的に共有でき、一度解決した課題をチーム間で再利用できます。

可能な限りネイティブなブラウザ要素を使いましょう。これらは幅広いユースケースでアクセシブルになるように実装されています。本当にカスタムの<select>や<input type="date" />を自作する必要があるでしょうか？

どうしてもカスタムコンポーネントを自作する必要がある場合は、react-ariaが主要なコンポーネントのほとんどに対応した、アクセシビリティと振る舞いを提供するReactフックのセットを提供しています。

Storybook

Storybookは、フロントエンドのコンポーネントを分離して開発、ドキュメント化、テストするための優れたツールです。アクセシビリティテストに役立つ機能もいくつか備えています。

accessibility addonを使えば、各ストーリーがaxeでスキャンされ、検出された問題がパネルに表示されます。これにより、コンポーネント開発中に潜在的なアクセシビリティの問題について素早くフィードバックを得られます。

このアドオンは、さまざまな色覚特性を持つユーザーにUIがどのように見えるかをシミュレートするためのカラーフィルターも提供します。これを使えば、色覚に特性のあるユーザーにとってもUIが使いやすいかを簡単にテストできます。

自動化

アクセシビリティのリントルールを活用する

静的解析でも一部のアクセシビリティの問題を検出できます。ESLintの設定をeslint-plugin-jsx-a11yのようなもので拡張すれば、imgタグのalt属性の欠落や不正なaria属性といった問題を検出できます。

これにより、JSXを記述している最中にIDE上で即座にフィードバックを得られます。

Testing Libraryで単体テストを書く

Testing Libraryは、リファクタリングに強く、壊れにくいテストを書くことを開発者に促します。XPathのようなセレクタではなく、ユーザーと同じ方法でページ上の要素を探すクエリは、デザイン変更やリファクタリングによる破損に強くなります。たとえば、.password-inputというクラス名を持つ要素をクエリするのに比べ、ラベルがPasswordのinput要素としてパスワードフィールドを探す方法は、ページのデザインが全面的に刷新されても機能し続けます。

このアプローチは、よりアクセシブルなコンポーネント作りを促すという利点もあります。ラベルやaria属性が適切に設定されていれば、セマンティックなタグに基づいて要素をクエリする堅牢なテストを書きやすくなると同時に、スクリーンリーダーを使うユーザーが同じ要素を見つけやすくなります。Testing Libraryの組み込みセレクタを使ってクエリを書くのに苦労しているとしたら、それはUIがアクセシビリティ基準に従っていないからかもしれません。

Testing Libraryは、React、Angular、Svelte、素のDOMなど、さまざまなフレームワークとの統合を提供しています。

単体テストや統合テストでaxeを使う

axeは、ウェブページのアクセシビリティを自動テストするための強力なツールです。ページをスキャンしてアクセシビリティの問題を検出でき、自動テストパイプラインですでに使っているさまざまなテストツールとの統合も備えています。

axeはPlaywrightやPuppeteerのような自動ブラウザテストツールと組み合わせて使うことができます。アプリケーションの各ページをテストすることで、ユーザーにリリースされる前にアクセシビリティの問題を発見できます。既存のプロジェクトに追加する場合は、スナップショットテストを使って現在のアクセシビリティの問題のベースラインを定義し、新機能の追加時に状況を悪化させていないことを確認することもできます。

jest-axeを使えば、JSDOM環境でaxeを用いてアクセシビリティの問題を検出する単体テストを追加できます。統合テスト全体の結果を待つよりも、早い段階でフィードバックを得るのに役立ちます。

手動テスト

axeのような自動テストツールで検出できるアクセシビリティの問題は、平均して約60%に過ぎません。たとえば、自動ツールは<img />要素にalt属性が存在するかどうかは検出できますが、そのテキストが画像の内容を的確に説明しているかどうかまでは判断できません。そのため、手動テストもアクセシビリティ対応に含めるべきです。

VPATのようなドキュメントは手動テストの指針として利用でき、アプリケーションのアクセシビリティ基準への準拠を示すために外部のユーザーと共有することもできます。定期的に手動でアクセシビリティを評価・見直す体制を設けることで、問題の発見や経時的な改善の追跡に役立つだけでなく、アクセシビリティを優先的に取り組んでいることをユーザーに示すことにもなります。

実際に障害のあるユーザーにウェブサイトをテストしてもらうことが、システムが真にアクセシブルかどうかを知る最善の方法です。スクリーンリーダーを使って、あるいはマウスを使わずにウェブサイトを利用してみることで、実際の使いやすさがどの程度なのかを体感してみてください。

エンジニアリングの先へ

エンジニアリングのベストプラクティスだけでは、すべてのアクセシビリティ問題を解決することはできません。組織全体が役割を果たす必要があります。

デザイナーは、初期のUXやUIデザインの段階からアクセシビリティを考慮する必要があります。Figmaのようなツールには、デザインのモックがアクセシビリティに配慮して作成されるようにするためのアクセシビリティ統合機能があります。

ウェブコンテンツを作成するすべての人が、アクセシビリティとその重要性を認識する必要があります。CMSでは画像にaltテキストの入力が求められるかもしれませんが、すべての人がこのフィールドの重要性や、スクリーンリーダー利用者のために使いやすいキャプションを書く方法を理解しているでしょうか。制作されるすべての動画コンテンツにキャプションは付与されているでしょうか。

Employee Resource Groups（ERG）や部門横断的なワーキンググループのような取り組みを活用することで、組織全体でアクセシビリティの重要性を体系化し、推進することができます。オフィスの設備から社内システム、外部向けのウェブアプリケーションに至るまで、アクセシビリティはあらゆる場面で考慮されるべきであり、その要件を優先する文化を築くには、それを推進するチャンピオンが必要です。