アクセシブルなインターフェース構築における推測を止める方法
ウェブ上の普通のボタンが、キーボードでクリックしようとしたときに奇妙な動作をすることはありますか？あるいは、モーダルを開いたときにスクリーンリーダーが突然意味不明なことを読み上げ始めることは？大抵の場合、問題はARIA属性にあります。私たちは「目分量」でそれらを追加することに慣れていて、aria-labelやrole="button"が.bad semanticsを魔法のように修正してくれることを期待しています。しかしアクセシビリティは魔法ではなく、厳格なインタラクションパターンです。
w3c/aria-practicesリポジトリには、私が「フロントエンド開発者のバイブル」と呼ぶものが存在します。それは単なる退屈な仕様ではなく、Living Authoring Practices Guide（APG）で、ドロップダウン、タブ、スライダー、アコーディオンが誰もが使えるように動作する方法を正確に説明します。
このプロジェクトについて
このプロジェクトはW3Cのワーキンググループが運営しています。本質的に，这些人就是ウェブ標準を発明する人々です。リポジトリでは、インターフェースパターンの実装例を参照できます。モーダルを閉じた後にフォーカスをボタンに戻す必要があるかどうか、タブの切り替えにどの矢印キーを使用するべきか分からない場合は、ここを見ればわかります。
多くの開発者は依然としてアクセシビリティ（a11y）をオプションのものと考えています。しかし、プロジェクトが成長すると、適切なキーボードナビゲーションの欠如は技術的負債になります。このリポジトリは、コンポーネント設計の段階でその負債を排除するのに役立ちます。
このリポジトリが提供するもの
中には乾燥したルールだけでなく、動作するコード例もあります。このプロジェクトで私が常に参照しているものをいくつか紹介します。
すぐに使えるデザインパターン
ComboboxやTree Viewなどの各複雑な要素ごとに、専用のセクションがあります。期待されるキーボード動作と必要なロールを説明します。車輪の再発明をする必要がなくなり、要件のリストを取得してコンポーネントに対してチェックするだけです。
リファレンスコード例
examplesフォルダには、純粋なHTML、CSS、JavaScriptでの実装があります。不要な抽象化やReact、Vueはなく、生のアクセシビリティロジックのみです。これは、スクリーンリーダーがコンテキストを正しくアナウンスするように、id要素をaria-controlsやaria-labelledbyでリンクする方法を理解する必要がある場合に便利です。
テストとリンティング
興味深いことに、作者たちは厳格なリンティングを使用しています。HTMLはNU HTML Validatorで検証し、JSとCSSは標準のESLintとStylelintで検証します。このプロジェクトに貢献することを決めた場合、HTMLバリデーターのためにJDKをインストールする必要があります。これは真剣さのレベルを示しています：コード例でさえ、検証エラーは1つも許可されていません。
これで何が変わるのか
私はこのリポジトリをチェックリストとしてよく使用します。例えば、カスタムselectを作成している場合、「アクセシブルなselectの作成方法」を検索する代わりに、APGに移動してSelect-Only Comboboxセクションを参照します。
そこでは次のようなことがわかります：
- 親要素に必要な属性。
aria-expanded状態をどのように管理するか。- Home、End、またはPageUpキーを押했을 때的动作。
ちなみに、リポジトリにはサンプルの自動テストスクリプトがあります。npm testコマンドは、ブラウザで要素の動作をチェックするテストを実行します。これは、自分のプロジェクトでアクセシビリティテストを自動化する方法の良い例です。
技術的な側面
このプロジェクトはNode.js上で動作します。ローカルで作業するには、以下が必要です：
- Node.jsとnpm（リンティングとテストの実行用）。
- HTML検証用のJDK（Java Development Kit）。
興味深いポイント：プロジェクトにはコミット時の自動エラー修正が設定されています。CSSでスペースを間違えたり、JavaScriptでキャメルケースを忘れた場合、リンティングがリポジトリにコードを入れる前に自分で修正を試みます。
aria-practicesを見るべき人
第一に—コンポーネントライブラリの開発者です。独自のデザインシステムを作成している場合、これらのプラクティスを無視することは単なるオプションではありません。このプロジェクトはQAエンジニアにも便利です：インターフェースがアクセシビリティをテスト的时候会現す動作を正確に確認できます。
このリポジトリを読むことが軽い夕方の娯楽だとは言いません。テキストは乾燥しており、要件は多いです。しかし、真に全員にとって動作するインターフェースを構築する唯一の方法です。マウスを使う人だけでなく。
閉じたときにモーダルがページの端に「飛ぶ」ことに疲れている場合、またはaria-liveが何のためにあるのかをようやく理解したい場合は、このリポジトリをクローンして、W3Cの専門家がどのように行っているのかを確認してください。プロジェクトへのリンク：w3c/aria-practices。
関連プロジェクト