jsx-a11yとコンポーネントレベルのガードレール

アクセシビリティの間違いの多くは、コードを見れば簡単に見つけられます。linterを使えば、実際のユーザーが問題に遭遇するずっと前に、入力中に指摘できます。🛡️

eslint-plugin-jsx-a11yパッケージは、JSX用のアクセシビリティルールをESLintに追加します。コンポーネントに、よくある既知のa11yエラーがないか確認します。

プラグインのrecommended設定を拡張すると、各ルールを手動で1つずつ有効にすることなく、しっかりした基本ルール一式をまとめて有効にできます。

プラグインは、imgにalt属性がない場合に警告します。この1つのルールだけでも、非常に一般的で影響の大きいアクセシビリティ上の問題を防げます。

キーボード対応なしでdivにonClickを設定すると、警告が出ます。修正するには、フォーカス可能でキーボード操作に対応した本物のbuttonを使います。

ルールによって、フォームコントロールに関連付けられたlabelがあるか確認できます。ラベルのないフィールドには警告が出るため、名前のない状態でユーザーに届くことはありません。

プラグインは、ARIA属性とroleが実在し、正しく使われているか確認します。aria-lableのようなタイプミスや無効なroleもすぐに検出されます。

linterが確認できるのは静的なコードだけです。altテキストが意味のある内容か、フォーカスの順序が適切かは判断できないため、手動テストも重要です。

アクセシビリティを共有コンポーネントに組み込んでください。常に本物のbutton要素を描画する再利用可能なButtonを作れば、アプリ全体に適切な動作を広げられます。

ESLintをpipelineで実行し、a11yの警告があればビルドを失敗させます。これにより、コードレビューをすり抜けて本番環境に入るリグレッションを防げます。

ESLintのエディター拡張機能を使うと、警告がコード上に直接表示されます。この迅速なフィードバックにより、チームはコードを書きながらアクセシビリティのパターンを身につけられます。

チームがプロジェクトにeslint-plugin-jsx-a11yを追加しました。それでも、このプラグインに何を期待してはいけませんか。

jsx-a11yでよくあるエラーを検出し、アクセシブルな共有コンポーネントを作り、CIでチェックを必須にしてください。そのうえで、残りの確認には手動テストも引き続き利用します。✅