WCAGコンプライアンスのためのアクセシビリティ監査を実行する方法

公開: 2022-06-28

WCAG（Webコンテンツアクセシビリティガイドライン）は、World Wide Webコンソーシアム（W3C）によって作成され、アクセシビリティに関して世界で最も認知されている標準です。

この記事では、WCAG2.1標準への準拠を検証するための監査を実行するために必要なタスクの概要を説明します。

アクセシビリティとは、より多くのユーザーがWebサイトのコンテンツと機能にアクセスできるようにすることです。

例えば：

一時的なアクセスの障壁–誰かが眼鏡をなくしてしまいました！
デバイスの問題–携帯電話などの制限のあるデバイス上にあります
状況–明るい日光、暗い部屋など
永続的な障害–視力、聴覚、認知の問題などはありません。
帯域幅の問題–接続が非常に遅い

ご覧のとおり、考慮する必要のある障害にはさまざまな形態があります。

WCAGガイドラインは次のように分類されます。

各セクションを実行する前に、テストを実行するために必要なもののリストを次に示します。

1.知覚可能

テキストのみを含むブラウザの選択（例：Lynx）
altタグ、見出しなどをチェックするためのツール（例：ScreamingFrog）
NVDAなどのスクリーンリーダー
ウェブサイトのアクセシビリティテストツール
Chrome開発ツール
選択したデバイスへのアクセス

これは、コンテンツがさまざまな形式でアクセスできるようにすることです。たとえば、誰かがコンテンツを見たり、聞いたり、タッチを使用してコンテンツを理解したりすることができます。これには、メニューやボタンなどのユーザーインターフェイス項目も含まれます。

WAVEアクセシビリティツールは、この分野の問題を見つけるために使用できる多くのツールの1つです。

上記の例では、ページは非常にうまく機能しています。色のコントラストの問題で1つのエラーと5つのエラーしかありません。

1つのエラーは、このページが言語を示していないことです。

しかし、ページにはたくさんの良いことがあります。たとえば、右側の画像では、2つの要素が緑色で強調表示されていますが、どちらも「ARIA」ラベルを使用して、スクリーンリーダーがこのコンテンツを理解できるようにしています。これについては後で詳しく説明します。

ガイドラインと成功基準を見てみましょう。

ガイドライン1.1-非テキストコンテンツに代わるテキストを提供する

非テキストコンテンツに代わるテキストコンテンツはありますか？

画面にテキスト以外のコンテンツがある場合は、それらの各要素の説明があることを確認する必要があります。

例を示す前に、要素に追加の説明を提供する方法であり、標準のHTMLが不可能な場合にのみ使用する必要があるARIAについて説明します。

HTMLを使用すると、キーボード制御、フォーカスなどが自動的に取得されます。これが優先されますが、ARIAはバックアップとして使用できます。

ARIAとは何ですか？

ARIA（アクセス可能なリッチインターネットアプリケーション）は、標準のHTMLでは十分に記述できないコンテンツを記述する方法です。主な目的はスクリーンリーダーです。標準のHTMLを使用できる場合は、要素とキーボードコントロールに自動的にフォーカスが提供されるため、これが最善のアプローチです。これが不可能な場合は、ARIAが代わりになります。

説明的な画像

説明的なイメージは、何か意味のあるものを描写するものです。たとえば、トヨタプリウスの車の写真。

画像が表示されない場合は、この画像が何を表しているのかを説明する方法が必要です。これは、Altタグの出番です。

WordPressなどのプラットフォームでは、画像をアップロードするときにaltタグを追加できます。

多くの場合、このaltタグを更新して、関連するキーワードがSEOの目的で含まれていることを確認しますが、これを超える必要があります。

叫ぶカエルはあなたのウェブサイト上のすべての画像の分析を行い、どの画像にaltタグがないか、altタグが重複しているか、altタグが長すぎるか、altタグが短すぎるかを表示します。

画像の詳細と一緒に画像を見ることができます：

装飾画像

装飾的な画像は、デザインを強化するためにある画像ですが、画像には説明する価値のあるものは何もありません。

'img'タグを使用する正当な理由がない限り、装飾画像はCSSbackgroundプロパティを使用する必要があります。スクリーンリーダーがCSSのbackgroundプロパティを確認すると、画像を無視することがわかります。

オーストラリアのMyEmergencyDoctorWebサイトで背景画像として説明されている画像の例を次に示します。

この背後にあるコードは次のとおりです。

この画像は<img>としてリストされていないため、role = imgを使用して、これが画像であることをスクリーンリーダーに通知します。「Aria-label」を使用して、画像を正確に説明します。また、画像を「background-image」として定義します。

注：背景画像に「img」タグを使用する場合は、nullのaltタグを定義する必要があります（例：alt =”“）。

背景色の代わりに<img>を使用する必要があるのはいつですか。

画像がコンテンツの重要な部分である場合は、<img>を使用します。たとえば、商品画像がある場合、これは<img>です。また、装飾目的で使用される単なる背景画像である画像を使用することもできますが、これらを画像として説明することは意味がありません（Googleによってインデックスが作成されます）。

上記の例では、表示される画像をimgとして定義する必要があるかどうか疑問に思うかもしれませんが、それはストック写真であり、代わりに背景画像として定義することにしました。

注：<img>はHTMLタグですが、background-imageは使用するCSSスタイルです。

UIコントロール

それが何であるかを説明するためにいくつかのテキストを必要とするさまざまなUIコントロールがあります。

たとえば、ボタンまたはフォームコントロール。

ボタンは、機能を完了するために使用されます。アイコンのみのボタンと、ボタンにテキストが含まれるボタンの場合があります。両方とも異なる方法で処理できます。

ARIAを使用すると、「role = button」を定義できますが、標準のHTMLでは、<button>タグを使用できます。どちらを使うべきですか？

これは、ボタンの機能を説明する「aria-label」を作成する必要があるXが含まれているボタンの例です。

<button aria-label =” Close” onclick =” myDialog.close（）”> X </ button>

テストする必要がある一般的なUIコントロールのリストは次のとおりです。

カテゴリー	例
入力コントロール	チェックボックス、ラジオボタン、リスト、ボタン、テキストフィールド、日付フィールド。
ナビゲーションコンポーネント	メニュー、タブ、ブレッドクラム、スライダー、アイコン、ページネーション、タグ、アイコン、検索フィールド、カルーセル
情報コンポーネント	プログレスバー、ツールチップ、通知、メッセージボックス、モーダルウィンドウ（ポップアップ）、
コンテナ	アコーディオン

フォームを使用している場合は、各フィールドに正しくラベルが付けられていることを確認する必要があります。優れたラベル付けの例を次に示します。

</ form>

注：フォームの場合は、次のことも確認する必要があります。

必須フィールドを明確にマークします。フィールドが必須の場合は、HTMLで正しくラベル付けする必要もあります。
ユーザー向けの説明があります（通常はフォームの上部にあります）
ユーザーは、フォームフィールドの入力でエラーが発生したときにヘルプを受け取ります（たとえば、日付の形式が正しくない場合、これを入力する必要があります）。

キャプチャ

これは、実装方法によっては非常に問題になる可能性があります。たとえば、写真が表示されていて、どの写真に信号が含まれているかを特定するように求められた場合です。

実装を確認し、関連する提案を行います。

マルチメディアコンテンツ

ビデオ/オーディオには、ビデオ/オーディオが何であるかを識別するために、少なくとも説明が必要です。

リンク

リンクがページ上ではっきりと目立つようにし（たとえば、異なる色）、関連するアンカーテキストとリンクの説明を使用するようにします。

ガイドライン1.2–時間ベースのメディア

この分野は、よりアクセスしやすくする必要のあるビデオおよびオーディオコンテンツのケータリングに関するものです。

事前に録音された音声のみまたはビデオのみで利用可能な音声文字変換はありますか？

ビデオの文字起こしは、ビデオの音声をテキストに翻訳することです。音声文字変換には、動画に表示されるビジュアルなどを説明する音声情報は含まれません。これは個別に処理されます。

音声文字変換のヒント！

Rev.comは、オーディオ/ビデオのキャプション/文字起こしを作成するための優れたサービスです。ズームビデオのライブキャプションサービスも提供しています。

録音済みのオーディオに使用できるキャプションはありますか？

キャプションは、ビデオ内に表示されるテキストで、ユーザーが何を言っているかをユーザーに通知します。

音声ガイドまたは代替メディア（事前に録音されたもの）はありますか？

ビデオを見ているとき、キャプションはビデオ内に表示されているものを説明するのに十分でない場合があります。ここで音声ガイドも必要になります。

たとえば、音声ガイドは、誰かが話しているときにバックグラウンドで何が起こっているかを説明できるため、ユーザーにコンテキストを提供します。

音声ガイドを含む文字起こしの例を次に示します。

これはあなたのウェブサイトの訪問者にとっては素晴らしいですが、SEOにとっても良いことです！

アクセス可能なプレーヤーを選択するためのヒント：

使用するビデオプレーヤーがアクセシビリティに必要なものをサポートしていることを確認する必要があります。

クローズドキャプションをサポート
音声ガイドはオン/オフを切り替えることができます
キーワードコントロールはメディアプレーヤーで使用できます
メディアプレーヤーはさまざまなデバイスやブラウザで動作します
すべてのコントロールにアクセスできます。

ライブオーディオのキャプションはありますか？

通常、Webサイトにはライブビデオまたはオーディオコンテンツはありませんが、その場合は、キャプションを同時に作成して、ユーザーが話しているときに表示されるキャプションを表示できるようにする必要があります。

ライブビデオとオーディオに自動的に字幕を付けるために利用できるツールがあります。

事前に録音された同期メディアの音声ガイドはありますか？

これは、ビデオとオーディオを含むメディア用です。メディアに付随する音声情報が欲しい。

ガイドライン1.3–適応可能–ソフトウェアが理解できる形式で情報を提示します。

スクリーンリーダーなどのソフトウェアで正しく解釈できるように、何かを見て視覚的に解釈できるものがプログラムで記述されていることを確認する必要があります。

コンテンツには論理的な構造があり、その構造内の各コンテンツとの関係を理解するのは簡単ですか？

Webページを表示すると、通常、見出し、段落、太字のコンテンツ、表などが表示されます。また、表の詳細を表示すると、見出しが表示され、どの行がどの見出しに関連しているかが明確にわかります。

確認する必要があるものは次のとおりです。

コンテンツは小見出しに分割されていますか？
必要に応じてリストや表などを使用していますか？
コンテンツ全体で他の構造要素に使用されている正しいHTMLはありますか？
必要に応じて使用されるラベルと代替テキストはありますか（フォームなど）？

ヒント

良い出発点は、有効なhtmlをチェックするバリデーターツール（W3.org htmlバリデーターなど）を使用してWebサイトをテストすることです。

必須フィールドを赤で表示するフォームの例を次に示します。これは視覚的なユーザーにとっては問題ありませんが、点字ディスプレイを使用している人はどうでしょうか。

この問題を解決するために、必須フィールドである姓のラベルに「required」という単語も追加されます。

 <label for = "lastname" class = "required">姓（必須）：</ label>
<input type = "text" size = "25" value = "" />
<style type = "text / css">
  。必要 {
    赤色;
  }
</ style>

意味のあるコンテンツの順序はありますか？

Webページを表示すると、ナビゲーションバーが表示され、次にいくつかのコンテンツ、見出し、小見出し、テキストの段落が表示されます。これが意味のある順序で提示されていることを確認する必要があります。
見出しスタイルを使用して、セクションの重要性を示します。通常、コンテンツのページを識別するための<h1>スタイルは1つだけであり、複数のH2、H3などがある場合があります。
ナビゲーションをコンテンツとは別にします（たとえば、<nav>を使用してナビゲーションを定義します）
有効なHTMLを使用する

意味のある見出しの典型的な構造は次のとおりです。

ユーザーは、形状やサイズを認識できない場合、または空間的な形状やサイズに関する情報を使用できない場合に、コンテンツを理解できますか？

これを説明する最も簡単な方法は、例を使用することです。

ソフトウェア製品の機能の比較表があり、製品に機能がある場合、この列にひし形の画像が表示されるとします。これでは不十分です。このひし形が何を表しているかを示すテキストを追加する必要があります。

ウェブサイトは縦向きと横向きのモードでうまく機能しますか？

Webサイトは、意味を失うことなく、縦向きまたは横向きのモードに適応できる必要があります。

Webサイトがレスポンシブデザインを正しく実装している場合、向きを変更すると、別のビューポートに適応します（つまり、画面のサイズに基づいてより適切なディスプレイを選択します）。

フォームへの入力は正しく記述されていますか？

これの目的は、フォームに入力する必要のあるフィールドに関する十分な情報がプログラムで確実に存在するようにすることです。

また、可能であれば、ユーザーがすべてを完了する必要がないように、自動入力を有効にしてください。

ページ上の要素の目的をプログラムで把握できますか？

この例は、WebサイトのセクションにARIAの「role」要素を使用することです。

たとえば、ロゴ/会社名などを含むバナーは、「role=banner」と記述できます。

または、電子メール、名前、住所などのフォームに入力ラベルを使用します。

これは、HTMLでこれをどのように表示するかです。

グラフのテキストバージョンはありますか？

グラフタイプのコンテンツがある場合は、このコンテンツの内容をまとめた表が必要になります。

ガイドライン1.4–コンテンツを見て聞く

これは、人々がコンテンツを見たり聞いたりしやすいようにすることです。

情報を伝えるために色が使用されている場合、代替テキストはありますか？

フォームがあり、必須フィールドが赤で表示されているとします。

これは、スクリーンリーダーにはあまり意味がありません。

ただし、次の例のように、「required」という単語をテーブルに追加できます。

<label for =” lastname” class =” required”>姓（必須）：</ label> <input id =” lastname” type =” text” size =” 25” value =”” /> <style type = ” text / css”> .required {color：red; } </ style>

オーディオが3秒以上再生された場合に、オーディオを一時停止または停止するメカニズムはありますか？

スクリーンリーダーを使用していて、ビデオが自動的に同時に再生される場合は、2つの音声が聞こえます。

理想的には、この問題を解決するビデオの自動再生はありません。

自動再生がある場合は、3秒未満であることを確認し、そうでない場合は、再生中のビデオのオーディオを制御する方法があることを確認してください。

背景のテキストと画像/色の間に良いコントラストがありますか？

デザインやブランディングにおいて色がどれほど重要かは誰もが知っていますが、視覚障害のあるサイトへの訪問者にとって、色は彼らの体験に大きな違いをもたらすことはありません。

たとえば、色覚異常の人は赤、オレンジ、黄色、緑の違いを見ることはなく、あなたもそれらに対応する必要があります。

ここで重要なのは、Webサイトで見られる最も一般的なアクセシビリティの問題の1つであるコントラスト比に注意することです。

テキストの色とその背景の間に十分なコントラストがありますか？カラーコントラストチェッカーのようなツールはあなたが見つけるのを助けることができます！

背景色が左側にあり、テキストの色が右側にあります。スコアは真ん中です。

テキストが大きい場合（たとえば、18ポイントまたは14ポイント太字）、コントラストは少なくとも4.5：1または3.1にすることをお勧めします。

また、サイトの重要なコンテンツや情報を伝えるには、色以外のツールを使用してください。

たとえば、メインのCTAは通常、ユーザーに気付かせる色が原因でページに表示されます。 CTAをより使いやすくするために、サイズ、配置、太字、コントラストを使用して、色覚異常のある人がCTAを目立たせることができます。

テキストを大きくしても、Webサイトは通常どおり機能しますか？

明らかなのは、視覚障害のある人を助けるために画面上のテキストを拡大することです。

ただし、ユーザーがテキストサイズを大きくした場合でも、Webサイトを通常どおり機能させる必要があります。

たとえば、ユーザーがテキストを最大400％拡大する場合、情報が失われないようにする必要があります。

これがW3.orgからの画像です。テキストを拡大するときに、Webサイトが右のように表示されないようにする必要があります。

WCAG 2.1の要件は、問題なく200％拡大できることです。

必要な場合を除いて、テキストの画像は避けられますか？

あなたは大丈夫なテキスト（例えばあなたの会社名）を含むロゴを持っているかもしれません。

しかし、テキストの画像はどうですか？

テキストの画像がある場合は、少なくとも、それを説明するラベルを付ける必要があります。

ただし、次の場合を除いて、このタイプの画像は避けたほうがよいでしょう。

それは不可欠です
カスタマイズ可能

ウェブサイトはレスポンシブですか？

通常、下にスクロールしてWebページ全体を表示しますが、右または左にスクロールしないでください。

デスクトップから小さなデバイスに移動すると、画面が自動的に調整されるため、右または左にスクロールする必要はありません。

テキスト以外のコンテンツには十分なコントラストがありますか？

隣接する色のコントラスト比は少なくとも3：1である必要があります

この要件は、視力が比較的低い人向けです。

パフォーマンスを損なうことなく、間隔/行の高さを調整できますか？

行の高さ（行の間隔）は、フォントサイズの1.5倍以上にする必要があります。
次の段落の間隔は、フォントサイズの少なくとも2倍にする必要があります。
文字間隔（トラッキング）は、フォントサイズの0.12倍以上にする必要があります。
ワード間隔は、フォントサイズの0.16倍以上にする必要があります。

ホバーまたはフォーカス時にコンテンツが正しく表示されていますか？

要素にフォーカスする（たとえば、タブに移動する）か、要素にカーソルを合わせると、追加のコンテンツが表示されます。

たとえば、ボタンにカーソルを合わせるとポップアップが表示されます。

…またはサブメニューが表示されます。

このコンテンツは次のようにする必要があります。

却下可能–たとえば、[エスケープ]をクリックすると、コンテンツは表示されなくなります。

ホバー可能–コンテンツにカーソルを合わせると、マウスがトリガーの上にある限り、コンテンツが表示されます。

永続的–これは両方の組み合わせです。コンテンツは、ユーザーがコンテンツを閉じるか、ユーザーがマウスを離すか、コンテンツに重要な情報が含まれなくなるまで表示されたままになります。

注：これは、何か（画像など）にカーソルを合わせたときにタイトルなどのHTML要素が表示される場合には適用されません。

フォントは読みやすいですか？

一部のフォント/書体は、他のフォント/書体よりも読みやすくなっています。セリフまたはサンセリフが優先されますが、これは必須ではありません。彼らの重要な部分は、それが読みやすいということです。

2.操作可能

つまり、ユーザーはナビゲーションとユーザーインターフェイスを操作して使用できる必要があります。たとえば、キーボードを使用してユーザーインターフェイスを「操作」できます。

ガイドライン2.1–キーボードアクセス可能

多くのユーザーは、マウスやトラックパッドの代わりにキーボードを使用しています。これには、アクセシビリティの障壁があるユーザーやスクリーンリーダーを使用しているユーザーも含まれます。

これが、リンク、ボタン、フォーム、その他のコントロールなど、Webサイトのすべての機能にキーボードからアクセスできる必要がある理由です。

キーボードからすべてにアクセスできますか？

今こそ、マウスの使用をやめ、キーボードのみを使用するときです。

あなたがチェックしている：

すべてが論理的な順序に従って前進または後退しますか（タブを使用して前進し、シフトタブを使用して後退します）。

特定のボタンやセクションなどを表示しているときに、この要素が強調表示されていることがわかりますか？次の例では、「記事」にタブで移動したことは明らかです。

Tabキーを使用してすべてにアクセスできますか？フォーカスがあるときにEnterキーを押すと、アクションがアクティブになりますか？

注：ポップアップが表示された場合は、これもナビゲートできる必要があります。

ヘッダーをスキップできますか？

スクリーンリーダーを使用している場合、すべてのページで同じヘッダーが読み上げられることは望ましくありません。それはあなたを狂わせるでしょう。したがって、[コンテンツにスキップ]リンクにタブで移動し、Enterキーを押すと、次のタブでそのセクションがスキップされます。

以下のWebサイトに最初にアクセスしたときにタブをクリックすると、[コンテンツにスキップ]リンクが表示されます。 Enterキーを押すと、コンテンツに直接移動します。

2番目のタブを押すと、[ナビゲーションにスキップ]リンクに移動します。これでEnterキーを押すと、ナビゲーションが表示されます。

もう一度タブを押すと、「ナビゲーションにスキップ」に移動します。これを選択すると、ナビゲーションに直接ジャンプします。

ショートカットとして使用される文字、句読点、数字、または記号がある場合は、このショートカットを無効にするか、1つ以上の印刷不可能な文字に変更する方法が必要です。他の唯一の例外は、要素にフォーカスがある場合にのみショートカットを使用できる場合です。

2.1.2キーボード（キーボードトラップ）で行き止まりになっている状況はありますか？

Webサイト上の場所にタブで移動し、前後にタブで移動することはできません。

これは、キーボードトラップとして知られています。曲が進むにつれて…罠にかかって、振り返ることができない…。

文字を使用して実装されたキーボードショートカットに代わるものはありますか？

ナビゲーションにキーボードを使用している人と一緒に文字キーのショートカットを使用すると、誤ってキーボードを押してしまう可能性があるため、適切ではありません。

したがって、代替手段を提供する必要があります。

a）このキャラクターを別のショートカットに再マップする機能

b）。消して

c）。これに焦点を合わせている場合にのみアクティブになります。つまり、ショートカットを使用した場合、実際にショートカットを使用しない限り、何も起こりません。

ガイドライン2.2–十分な時間

フォームの記入に時間制限を設定したが、アクセシビリティの必要がないユーザーのみを考慮した場合を想像してみてください。この制限時間は短すぎる可能性があります。

タイミングは調整できますか？

タイミングをオフにするのが理想的ですが、それを延長したり（つまり、制限時間に近づいたときに）、新しい時間に調整したりすることは問題ありません。

Webサイトのユーザーは、コンテンツの移動、点滅、または自動更新を一時停止、停止、または非表示にできますか？

それが動いている/点滅している、またはスコーリングしている場合：

a）。自動的に起動します

b）。 5秒以上続く

c）。他のコンテンツと並行して提示されます

次に、一時停止、停止、または削除するためのメカニズムがあります。

コンテンツの自動更新に関する同じ問題。

ガイドライン2.3–発作と身体反応

このガイドラインは、発作や身体的反応を引き起こす可能性のあるものが設計されていないことを確認するためのものです。

画面の「点滅」はガイドラインを満たしていますか？

ルール1は、オブジェクトの点滅を避けることですが、それが不可能な場合は、1秒間に3回を超えて点滅したり、一般的な点滅しきい値または赤の点滅しきい値を下回ったりしないようにしてください。

ガイドライン2.4–ナビゲート可能

これは、Webサイトを簡単にナビゲートできるようにすることです。

繰り返しのブロックをスキップできますか？

スクリーンリーダーを使用して、新しいページに到達するたびにナビゲーションを読み上げることを想像してみてください。今ではそれは面白くないでしょう。したがって、これらをスキップできる必要があります。先ほど例を挙げました。

すべてのページに正しいタイトルが付けられていますか？

すべてのページにわかりやすいタイトルが必要です。これはアクセシビリティに適していますが、SEOにも適しています。

Screaming Frogを使用して、ページタイトルをすべて1か所で確認できます。

フォーカスの順序は意味を保持していますか？

コンテンツをタブ移動しているが、意味をなさない順序でタブ移動する場合は、これを修正する必要があります。

リンクテキストからリンクの目的を判断できますか？

「ここをクリック」はあまり役立つアンカーテキストではありません。リンク先のコンテンツを説明する言葉が必要です。

アンカーテキストとは何ですか？

Webサイトまたは外部Webサイトの別のページにリンクしている場合、アンカーテキストは、ユーザーを送信するページに関連する表示テキストです。リンクを表示するだけでなく、実際のテキストを表示することをお勧めします。

Webページを見つける方法は複数ありますか？

ここではいくつかの例を示します。

サイトマップ–サイトマップ上のすべてのページのリストを用意する
クイックリンク–重要なページにアクセスするためのクイックリンクがあります
検索–関連するページを見つけるために検索します

キーボードフォーカスは表示されますか？

質問はそれをすべて言います！これは、以前のガイドラインの1つでもカバーされていました。どこかにタブで移動すると、その領域に焦点が合っていることを視覚的に確認できる必要があります。

ヘッダー、本文、フッターは明確に定義されていますか？

支援技術は、ヘッダー、フッター、およびボディを明確に識別できる必要があります。これらの領域を定義するhtmlタグがあります。

ガイドライン2.5入力モダリティ

このガイドラインは、キーボードやマウスを使用してナビゲートできない新しいインターフェイスに関するものです。たとえば、スマートフォンでは、スワイプ、ピンチ、ズーム、タップなどができます。

マルチポイントまたはパスベースのジェスチャを使用する機能は、ジェスチャを使用せずに単一のポインタで操作できますか（必須でない限り）？

パスベースのジェスチャは、特定のパスで移動する必要がある場所です。たとえば、上にスワイプして特定の機能にアクセスしたり、下にスワイプして他の機能にアクセスしたりします。マルチポイントジェスチャでは、2つ以上の接点を使用して機能にアクセスします。たとえば、2本の指を使用してピンチしてズームします。

単一のポインターによって開始されたアクションから抜け出す簡単な方法はありますか？

シングルポインタとは何ですか？

ここで、タップ、クリック、長押しなど、画面との1つの操作ポイントで機能にアクセスできます。

次の少なくとも1つが当てはまる必要があります。

ダウンイベントなし–ボタンを押すとトリガーが実装されます
中止または元に戻す– upイベントを使用し（つまり、ポインターが解放されると機能が有効になります）、中止する方法があります。たとえば、指で何かを押しているときに、指をまっすぐ持ち上げる代わりに、画面の別の部分にスライドすると、機能が中止されます。
アップ反転–アップイベントはダウンイベントを反転します
必須–ダウンイベントの機能を完了することが必須です。

コンポーネントの表示ラベルは、そのコンポーネントのプログラム名と一致していますか？

目の見えるユーザーがテキストを使用して音声を読み上げる場合、プログラム名が読み上げられます。これが表示されているラベルと一致する場合は、より良いエクスペリエンスになります。

モーションまたはジェスチャによって操作される機能は、他のUIコントロールによっても操作できますか？

何かを振ったり傾けたりして制御する場合、別のUIコントロールを使用してこの機能にアクセスできますか？

理解できる

これは、ページで使用されている言語が理解できることを確認することです。

3.1読み取り可能

以下をカバーします。

ページまたはページのセクションの言語をプログラムで決定できますか？

ページの先頭にこのようなものが表示されるはずです。「言語」はページの言語を示します。

ページで言語が変更された場合は、これも識別できる必要があります。

3.2予測可能

UIを予測可能な方法で実行する必要がありますが、驚くことではありません。

ページ上のナビゲーションは同じ順序ですか？

ユーザーがナビゲーションに変更を加えない限り、1つのページのナビゲーション位置は他のすべてのページで同じである必要があります。

コンポーネント、画像などはページ間で一貫して名前が付けられていますか？

あるページに画像があり、別のページに同じ画像がある場合は、画像に同じ名前を付ける必要があります。

投稿に複数のページがあり、ページに一貫性のあるページ1、ページ2、ページ3という名前を付けた場合。意味がない場合、ラベル付けは同じである必要はありませんが、一貫している必要があります。

3.3入力支援

これは、ユーザーがミスを回避または回復できるようにすることです。

入力エラー–何かを間違って入力していると、視覚的に間違っているように見えるかもしれませんが、問題を識別するテキストも必要です。

ラベル–ユーザーがテキストを入力する必要がある場合、フィールドを説明するラベルが関連付けられています。

入力エラー–ユーザーがエラーを犯した場合、それを修正する方法についての提案があります。

エラー防止–送信する前に、元に戻すか、エラーに関するフィードバックを受け取るか、確認することができる必要があります。

4.堅牢

アクセス可能であることに加えて、コンテンツはさまざまなブラウザ、テクノロジーなどをサポートする必要があります。

ガイドライン4.1互換

これには、さまざまなユーザーエージェントと支援技術を使用したテストが含まれます。このための適切な初期テストは、W3Cマークアップ検証ツールを使用して、エラーがあるかどうかを確認することです（つまり、html、xhmlなどの構造/構文が正しいことを検証します）。

出力の例を次に示します。

また、コンテンツが正しく読み込まれていることを確認するために、複数のブラウザに対してテストする必要があります。

また、テキストのみのブラウザ（Lynxなど）でページをロードすることも価値があります。

すべてのデータを正しく解析できますか？

コンテンツのセクション内に適切な開始タグと終了タグがあり、セクションの開始位置と終了位置を簡単に識別できますか？

要素は正しくネストされていますか？

要素を区別するのを難しくする重複した属性またはIDがありますか？

すべてのユーザーインターフェイスコントロールは、支援技術によって理解できますか？

コントロールの例と、理解するために必要なものを次に示します。

チェックボックス–チェックされているかどうか。
焦点–どの要素に焦点があり、これをプログラムで（視覚的にだけでなく）理解できますか？

ユーザーは、必ずしも作業を中断しない方法でフォーカスが与えられていないステータスメッセージに気づきますか？

あなたがページを閲覧していて、そのページで販売を発表するバナーがウェブサイトの上部に出てきたと想像してみてください。

フォームは正しい方法で設計されていますか？

フォームにアクセスできるようにするには、次の機能が有効になっていることを確認する必要があります。

タブを使用してフォーム内を移動する機能
タブを使用してフォーム内を移動する機能

<フォーム>

</ form>

明確にマークされた必須フィールド。フィールドが必須の場合は、HTMLで正しくラベル付けする必要もあります。
ユーザー向けの説明があります（通常はフォームの上部にあります）
ユーザーは、フォームフィールドの入力でエラーが発生したときにヘルプを受け取ります（たとえば、日付の形式が正しくない場合、これを入力する必要があります）。

概要

ご覧のとおり、包括的なアクセシビリティ監査を実行する際には、カバーすべき多くの根拠があります。しかし、それはすべて報われ、それがあなたのビジネスにもたらす利益はたくさんあります–ポジティブなブランドイメージを構築することから、より広い聴衆に到達し、あなたのSEOを改善することまで。