理解可能原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法について実用的なアドバイスを提供します。理解可能とは、情報とユーザーインターフェースの操作が理解可能でなければならないと述べています。情報とユーザーインターフェイスの操作が理解可能でなければならない(英語)を参照してください。テキストコンテンツを読みやすく理解しやすいものにするこのガイドラインは、テキストコンテンツをできるだけわかりやすくすることに焦点を当てています。各ウェブページのデフォルトの人間の言語はコードで検出できるべきです。これは、読者が自分に合った言語で書かれたページにアクセスしたことを確認するなどの目的に不可欠です。属性を設定して、ページが書かれている言語を最もよく表す言語コードをそれに与えることです。文書の第一言語の設定を参照してください。属性を使用して適切な言語を設定します。言語に関係なく同じである単語や語句に異なる言語を設定する必要はありません(例えば、固有名詞、特定の言語の一部ではない専門用語など)。慣用句やスラングが使用されている場合は、そのような語句や単語に対して定義を提供するべきです。サイトでは、そのような言葉や用語の定義を含む用語集を、それらが現れたときにリンクできるように提供するか、少なくとも周囲のテキストやページ下部の説明リストのどこかに定義を提供するべきです。(AAA)略語が使用されている場合は、それらの展開や、必要に応じて定義を提供するべきです。属性を取り、略語をマウスオーバーしたとき、これが表示されます。内容はキーボードからはアクセスできず、スクリーンリーダーによって確実に読み上げられるわけでもありません。これを扱うためのより良い方法は、この場合も先と同様に略語の展開と説明を含む用語集のページへのリンクを提供するか、少なくともコンテキスト内の周囲のテキストにそれらを含めることです。略語を参照してください。(AAA)前期中等教育レベル(通常11〜14歳前後の子供)より高い読解力を必要とするテキストが提供される場合は、それを読むことができない人々を支援する補足説明資料を提供するか、あるいは前期中等教育レベルで書かれた代替バージョンを提供します。これは、全ての主題が全ての人に理解されるべきであるという意味ではありませんが、書くスタイルは全ての人にアクセス可能であるべきです。仕様)がない限り、プログラミングチュートリアルのような技術文書でさえも、全てのコンテンツを前期中等教育レベルで書くことをお勧めします。(AAA)コンテンツを完全に理解するために必要な単語の発音へのアクセスをユーザーに与えるためのメカニズムを提供するべきです。要素を使用して、正しい発音を含む音声ファイルを読者が再生できるようにするコントロールを作成できます。辞書のエントリーと同じように難しい言葉の後にテキストの発音ガイドを含めるのも理にかなっています。動画と音声のコンテンツ、および英語辞書の発音ガイド(英語)を参照してください。説明も参照してください。ウェブページを予測可能な方法で表示して操作させるこのガイドラインは、ユーザーインターフェースを直感的でわかりやすくすることに焦点を当てています。(A)コントロールや他のページ機能がフォーカスを受けたときに、ユーザーが混乱したり迷ったりするような方法でコンテキストを変更するべきではありません。人々はインターフェースによって驚かされることを望みません。彼らは物事が直感的で期待通りに振る舞うことを望みます。表示が変わる前にアクティブにする必要があります。役に立つ情報がいくつか含まれています。役に立つ実装のアイデアについては、キーボード・アクセシビリティを取り戻すを参照してください。(A)データがコントロールに入力されたとき、または設定が変更されたときに、コンテキストが予期せずに変更されるべきではありません。差し迫った変更が発生する前に、ユーザーに警告や通知をする必要があります。繰り返しますが、賢明なデザインを実装するべきです。ボタンを押してアプリケーションが現在のビューを終了すると、ユーザーは必要に応じて作業内容を保存するかなど、この操作の確認を求められるべきです。(AA)ナビゲーションのメニューやコントロールのスタイルと配置は、ウェブページの異なるページやビューの間で一貫しているべきで、例えば、新しい項目が追加されたとしても、既存の項目は同じ順序で現れるべきです。ユーザーが変更を始めた場合、例えば、ナビゲーションのために異なる配色や位置を選択すると、それらの選択は全てのページにわたって尊重されるべきです。全てのページやビューでナビゲーションコントロールを同じにします。モダンなレイアウトのマークアップについては、ページレイアウトを参照してください。便利なアクセス可能なナビゲーションメニューの例については、ボタンとしてのリンクのスタイリングも参照してください。(AA)同じ機能を持つコントロールやコンポーネントは、異なるページやビューでも同じように識別されるべきです。世界旅行サイトの全てのページに表示される通貨換算機は、意味論的にもラベルの観点からもまったく同じであるべきです。フォームのラベルのことです。詳細については、わかりやすいテキストラベルを参照してください。(AAA)ユーザーを混乱させたり、迷わせたりする可能性があるコンテキストの変更は、ユーザーから要求された場合にのみ行われるべきか、あるいは、ユーザーはそれらをオフにできるべきです。現在のビュー(例えば、コンテンツやコントロール)を大幅に変更するものが必要な場合は、変更をいつ実行するかをユーザーに制御させます(例えば、どのページを表示するか、いつギャラリーの次の写真に進むか...)。ページに回転木馬のようなものが必要な場合は、自動的に進まないようにするオプションを提供します。可能であれば、そのような機能を避ける方が良いでしょう。説明も参照してください。ユーザーが間違いを避けて修正できるようにするこのガイドラインは、必要なときにユーザーが正しい情報を間違いを最小限にとどめて入力できるように手助けすることを中心にしています。(A)ユーザーがフォームに入力したりオプションを選択したりするときに検出したエラーは、エラーに関連するフォームコントロールと共に、ユーザーに明確に報告するべきです。使用して、クライアント側のエラー検出と処理を実装することをお勧めします。エラーを検出したら、ユーザーが入力を修正するのを助けるために、直観的なエラーメッセージをフォーム入力の横に表示するべきです。ライブリージョンを使用して、ページ上の変更についてユーザーに警告することができます。サーバー側の検証は、クライアント側の検証と同時に常に使用するべきです。クライアント側の検証は、無効にしたり回避したりするのが簡単すぎるため、単独では信頼できません。動的コンテンツの更新を参照してください。(A)データ入力が必要な場合は、明確な指示を提供するべきです。組み合わせて使用できます。複雑な説明が必要な場合は、常に説明段落を含めることも、フォームをより直感的にすることを試みる必要があるかもしれません。フォームの作成方法を参照してください。(AA)エラーが検出され、修正の提案が判明したら、セキュリティ上の問題(例えば、パスワード入力時)やコンテキスト上の問題(例えば、クイズアプリでの回答時)が発生しない限り、ユーザーにこれらの情報を提供してください(例えば、ユーザーが既に選らんだことがあるユーザー名についての選択肢の提案)。サーバー側の機能の組み合わせを使用して、エントリが正しいかどうかを確認し、正しくない場合は、ユーザーに実行可能な提案を提示できます。チュートリアルの提案はありません。データなど)の場合は、少なくとも次のいずれかに該当するべきです。データにエラーがないかチェックされ、ユーザーにはエラーを修正する機会が与えられます。最終提出の前に情報を確認し修正するためのメカニズムが利用可能です。ウェブフレームワークを参照)。説明したように、クライアント側とサーバー側の検証を組み合わせてエラーを検出し、入力を修正できるようにユーザーに役立つメッセージを表示するべきです。必要に応じて、(製品の購入のような)一連のフォームフィールドに入力するタスクを実行した後、ユーザーに確認画面を表示して入力内容を見直し、正しくないものは修正できるようにするべきです。ような電子商取引サイトで一般的に使用されています。フォームの完成と提出を助けるために、コンテキストの中で指示と他の適切な合図を提供してください。他の同様の基準に基づいていますが、もっと徹底的なコンテキスト上のヘルプ情報とサービスを必要とします。各ページのヘルプページまたはサービスへの専用リンクを提供し、正常に完了したらどのように見えるか示す例を提供します。基づいており、機密データを含むものだけでなく、全てのユーザ入力状況に要件を拡張しています。説明も参照してください。inbox.現在、ニュースレターは英語でのみ提供されています。従って私の個人情報を扱うことに同意します。