知覚可能

テキストの説明や、アクセス可能なデータ表がうまくいくかもしれません（HTML 表の高度な機能とアクセシビリティを参照）。 longdesc 反対論については、 W3C のImage Description Extension (longdesc)も参照してください。

静的キャプションの選択肢については代替テキストを、その他の選択肢については音声トランスクリプト、 映像のテキストトラックを参照してください。

装飾画像は CSS 背景画像を使用して実装する必要があります（背景を参照）。 <img> 要素を介して画像を含める必要がある場合は、空白の alt（alt=""）を付けます。 そうしないと、スクリーンリーダーがファイルパスなどを読み上げようとする可能性があります。

自動再生する背景の動画や音声を含める場合は、できるだけ目立たないようにします。 コンテンツのように見せたり鳴らさないでください。 また、無効にするコントロールを提供してください。 理想的には、それをまったく含めないでください。

いかなるコンテンツ構造 — またはコンテンツ間に作られた視覚的関係 — もまた、プログラム的に決定されるか、またはテキストの説明から推論され得ます。 これが関連する主な状況は次のとおりです。

• テキストラベルとそれが説明するフォーム要素は、<label> 要素を使用して明確に関連付けられて、スクリーンリーダーなどが拾うことができます。
• 画像の代替テキスト。 コンテンツ画像には、その画像の内容を明確に説明するテキストが含まれているべきです。 これは、プログラム的に関連付けることができます（例えば、alt　テキスト）。 そうでない場合は、関連付けるのは簡単です（例えば、それを説明し、そのすぐ隣に置きます）。 これは、たとえあなたが画像を見ることができなくても、完全な意味がまだ推測できることを意味するはずです。
• リスト。 リスト項目の順序が重要で、順序付きリストを使用するべき場合（<ol>）。

HTML: アクセシビリティの基礎全体には、これに関する情報が満載されていますが、特に良いセマンティクス、UI コントロール、代替テキストを参照するべきです。

コントロールを操作したり、コンテンツを理解したりするための指示は、単一の感覚には依存しません。 これは、その感覚に関連する障碍を持つ人々、またはその感覚をサポートしていないデバイスにとってアクセスできないことを証明するかもしれません。 だから、例えば、

• 「続けるために丸いボタンをクリックしてください」
  それがあなたが押す必要があるボタンであることは明らかであるように、ボタンは明確にラベル付けすべきです。 複数のボタンがある場合は、それらの機能を区別するために全てが明確にラベル付けされていることを確認してください。
• 「ガイダンスに関する音声の説明を聞く」
  これは明らかに問題があります — 音声は聴覚障碍のある人にはアクセスできないのに対して、テキストは読むことができるだけでなく、必要に応じてスクリーンリーダーによって話させることもできます。
• 「メニューを表示するには、画面の右側からスワイプ」
  一部のユーザーは、障碍のためや、端末がタッチに対応していないために、画面をスワイプできない可能性があります。 キーボードショートカットや、キーボードなどの手段でアクティブにできるボタンなどの代替手段を提供する必要があります。

方向を理解する（英語）

53 個の入力フィールド（英語）のリストに従って、プログラム的にフィールドの目的を識別してください。