Clever Geek Handbook

障害者がアクセスできる州のWebサイト（アクセシビリティチェックリスト）

はじめに



「政府システムの設計」の一環として、障害者のためのサイトアクセシビリティのチェックリスト（あらゆる種類の開発者）を作成しました。これらのチェックリストは、各デザイナーとフロントエンドのデスクトップに登録する必要があります。 （州のプロジェクトだけでなく）すべてのプロジェクトに適しています;余分なものは何もありません。 非常に重要、重要かつ有用な情報のみが含まれています。

印刷して読んで同僚と共有しましょう。

これは重要なテキストと知識です。







ぼかしフィルターを使用してPhotoshopで処理されたテキスト



サイトのアクセシビリティ要件は、レベルAAのWCAG標準によって決定されます。 この規格は、すべての要件を十分詳細に説明し、説明へのリンク、使用されている手法、および一般的なエラーを含んでいます。 これにより、Webページのアクセシビリティとその適応を分析する際に、完全にこれに依存できます。 さらに、半自動エラー検出用の大きなツールボックスがあります。それは、ブラウザ用のバリデータとアドオンです。







このドキュメントは、標準の適用に関する実用的な推奨事項を提供し、サイトのアクセシビリティをチェックするツールとプロセスを説明し、主要な資料へのリンクとサイトのアクセシビリティに関するガイド、および最も一般的なウィジェットの実装例を提供します。







WCAG 2.0レベルAAは、さまざまなカテゴリのユーザーのアクセシビリティ基準を説明しています。 実際には、基準への良好なレベルのコンプライアンスを維持するために、テスターが次のカテゴリのユーザーの代わりに自己紹介する（またはテストに参加する）と便利です。









開発のすべての参加者（デザイナー、開発者、プロジェクトマネージャー、テスター、エディター）は、各アクセシビリティスペシャリストの主な責任を説明する簡単なチェックリストも見つけることができます。







こちらもご覧ください：









設計



  1. 情報やマークアップを提供する唯一の方法は色ではありません。







  2. WCAG 2.0に従ってコントラストを維持する必要があります。







    WAVE評価ツールを使用してHTMLのコントラストを測定できます







  3. 感覚特性に依存しないでください。







    この要件については、基準1.3.3の説明で詳しく説明します。







  4. フィールドとコントロールのフォーカス状態を視覚的に表示する必要があります。







  5. 原則的にアクセス可能にできない情報については、代替形式のプレゼンテーションを提供するか、これが不可能な場合でも、インターフェイスの機能のテキスト説明を提供する必要があります（たとえば、目の不自由なユーザーがページの機能を理解し、目が見える人に助けを求めることができるように）。


アクセシビリティガイドラインもご覧ください。 デザイナーのためのチェクリスト 。







検証ツール



  1. バリデーターは、一般的なHTMLの妥当性についてサイトをチェックします： https : //validator.w3.org/







  2. 専用のバリデーターでサイトを確認する：







    • HTMLコード分析に基づくhttp://achecker.ca/checker/バリデーター。 JavaScriptは考慮されません。エラーはテキスト形式で表示され、分析にはあまり便利ではありません。 潜在的な問題のリストを提供しますが、そのほとんどは真実ではありませんが、追加のチェックリストとして使用できます。

    • http://wave.webaim.org/およびChrome WAVE評価ツール拡張機能。 多数のエラーを見つけ、修正のヒントと標準へのリンクを提供し、便利な形式で情報を提供し、構文とアリア属性を強調します。







      主な利便性は、拡張機能がソースコードではなくページの現在の状態を分析できることです。







    • http://khan.github.io/tota11y/-ブックマークレットを使用してページに埋め込むことができるビジュアライザーとアクセシビリティ検証ツール。 コントラスト測定をサポートします。 Wave評価ツールとは異なり、すべてのエラーが一度に表示されるわけではなく、多くのエラーも検出されません。
    • Firefox用AInspectorサイドバー 。 以前のバリデータとは異なり、aria-attributesを使用するロジックのエラーを見つけることができます。 エラーのリストに加えて、手動で行うことが推奨されるチェックのリストも提供します。
    • アクセシビリティデベロッパーツールChrome 主に、aria-attributesを使用する際の正式なエラーをキャッチします。 マイナス面：不便なインターフェイスとわかりにくいエラー出力形式。


    バリデータエラーメッセージの存在自体は、WCAGの不一致の正式な基準ではないことに注意してください。 さらに、一部の投稿は、助言的であるか、潜在的なものとしてフラグが付けられています。 それらの決定は、文脈から決定されるべきです。







    逆もまた真です。すべての問題がバリデーターであるわけではありません。以下を含む手動テストが必要です。 スクリーンリーダーを使用する（以下を参照）。







  3. スクリーンリーダーをチェックインします。







    設定が最も簡単なのは、Windows + Firefox / IE + NVDAの組み合わせです。 JAWSも広く配布されています（プログラムは有料で高価ですが、40分間モードの試用版が付属しています）。 他のオペレーティングシステムのユーザーの場合、テスト環境はMicrosoftの仮想マシン（ https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/-以前のmodern.ie）で構成できます。 VM Windows 7。







    スクリーンアクセスプログラムは、それらに最初に遭遇した人に非常に固有のものですが、比較的早く慣れることができます。 すべてのフロントエンド開発者およびテスターに​​は、簡単な指示のレベルでプログラムを習得することをお勧めします（以下を参照）。 それほど時間はかかりません。











ワーツクを考慮する必要がある場合



  1. マークアップセマンティクスへの準拠。 特に、以下を区別できます（すべてがリストされているわけではありません）。







    • <ul>、<ol>、<li>タグまたは対応するロール属性によるリスト、アイテム列挙、ドキュメントフィードなどのマーキング。
    • <table>、<tr>、<th>、<td>タグまたは対応するロール属性を持つ表形式のデータマークアップ。 注ロール属性の要素をネストする規則は、タグの規則と完全に似ています。
    • <caption>および<summary>タグの使用
    • テーブルヘッダーの適切な使用。 セルヘッダーは、テーブル全体のすべての親<th>要素であることに注意してください。 Colspanヘッダーは、影響を受けるすべての列の各サブセルに適用されます。
    • 表示のみを目的として、テーブルまたはリストを複数に分割しないでください。
    • ボタンは、クリック可能な要素<button>、<a href... role="button">、<input type = "button">を使用して設計することをお勧めします。 フォーカス（tabindex）およびキーボードイベント（Enterを押すことによるキーダウン）を条件として、role = buttonでクリックできない要素を使用することもできます。


  2. ロール=メイン、ロール=ナビゲーション、ロール=コンテンツ情報、ロール=補完、ロール=バナーなどを使用してセマンティックエリアをマークアップする







    • ページ上のコンテンツはすべて、セマンティックゾーンに属している必要があります。
    • 1つのページにナビゲーションと同等の役割または補完的な役割を持つゾーンが複数回発生する場合、aria-label属性を通じてその目的を説明するテキストラベルを追加する必要があります。
    • 繰り返しブロックをスキップしてrole = "main"ブロックにジャンプするリンクを追加します。


    リンクは、ページ上の最初のフォーカス可能な要素である必要があります。 これは視覚障害者向けのリンクです。 ページを読み込んだ後、最初にTABを押してリンクにフォーカスを移動し、次にENTERを押してページをメインコンテンツの要素に固定する必要があります。







    http://webaim.org/のリファレンス実装。 ロード後、TABをクリックする必要があります-リンクは左上隅に表示され、ENTERになります。







  3. レベル1の見出しから始まる見出しの厳密な階層。







  4. キーボード制御：







    • すべてのコントロールと入力に焦点を合わせる必要があります。
    • フォーカス状態は区別可能でなければなりません


  5. 追加のテキスト情報の提供：







    • 属性「alt」： 装飾要素の場合は空、情報要素の場合は意味のあるテキスト。

    • 入力要素のラベルの提供：<label for = "...">、aria-label、aria-labelledbyを使用します。 テキストまたはテキストラベルのないコントロールまたは入力はありません。







      代替テキストの計算方法の詳細については、 https： //www.w3.org/TR/wai-aria/roles#textalternativecomputationを参照してください







      セマンティクスを持たない要素（たとえば、<span>）にaria-labelを追加しても意味がないことに注意してください。







      他の要素（リスト、フィールド<fieldset>などのグループ化、ランドマーク）の場合、aria-label属性も異なる方法で解釈されます。使用する場合、各要素の目的を理解する必要があります。







    • エラー表示：一般的なエラーメッセージ（ページのタイトル-ページのメインコンテンツのブロックの先頭にある、またはrole = "alert"またはaria-live = "assertive"を持つ要素のタイトル。
    • <caption>および<summary>タグを使用して、追加の情報が必要になる可能性のある以前のコンテキストまたはナビゲーションから目的が明確でないテーブルを記述します。
    • <abbr title>で略語を展開します（タグの内容の代わりに、titleの値が読み込まれます）： 


    <abbr title="  ">  .. </abbr>


    • ページ上の位置または外観、フォントスタイル、情報アイコンで表される取り消し線テキスト（ホテルの星空など）を考慮することによってのみ意味が明らかになる要素の場合、テキストの説明が必要です。画面の左端を超えて移動すると非表示になる場合があります。 


     .sr_only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); border: 0; }
      
      
    
        
        
        
      
    
    
        
        
        
      
      
    
        
        
        
      
    
    
     


     <span class="sr_only">     </span>


    • チャート、グラフ、インタラクティブFlash（ほとんどの場合）、SVG、Canvasなどの形式で提示される重要な情報は、テキスト形式でも提示する必要があります：個別の段落、表、場合によっては個別のページ、または目の不自由なユーザーからは非表示class = "sr_only"ブロックを使用します。







      注：ほとんどの場合、リストされた要素を視覚障害者が使用できるように技術的に調整することは可能ですが、人件費の観点から、視覚障害者のために別のインターフェースを作成する必要があります。 通常、ユーザーがデータをテキストで表現する方が簡単で、最も重要なことには、より便利です。









  6. 可能であれば、必要な機能（結合リスト（<select>）、フラグ（チェックボックス）、ラジオボタン、ボタン、入力フィールド）を満たす場合は、組み込みのブラウザコンポーネントを使用することをお勧めします。







    また、キーボードコントロールの複雑化を避け、同じ問題を解決する標準的なソリューションの存在下で新しいパターンのインタラクションを考案しないでください。障害のある人にとって既知でアクセス可能なコンポーネントとアプローチからインターフェースを構成しようとします。 「使用可能なインターフェイスの実装例」セクションおよび以下の基準4.1.2の説明を参照してください。







  7. 目の見えるユーザーには隠れているが、視覚障害者にはアクセス可能な要素を作成することが許可されています。 これは、画面の左端をはるかに超えて要素を移動する手法（上記のsr_onlyクラス）を使用して行われます。







  8. 通常のウィジェットにアクセスできるようにすることが困難な場合は、スクリーンリーダー用に別の代替インターフェイスを実装することもできます（インターフェイスのメインバージョンを非表示にします）。 同時に、目の見えるユーザーがキーボードから要素を操作できることを忘れてはなりません。







    この手法は慎重に使用してください。選択肢がある場合は、視覚障害のあるユーザーが使用できるように一般的なインターフェイスを調整することをお勧めします。







    カレンダーの代わりに日付を手動で入力する（ただし、カレンダーを使用することもできます）、国/都市を選択するためにマップの代わりにリストを使用するなど、視覚障害者のインターフェイスを大幅に簡素化する場合、別のインターフェイスを実装することは理にかなっています







    無理をしないことが重要です。実践では、視覚障害のあるユーザーは、一見視覚障害者にとって不快なインターフェースを使用するのに苦労しないことを示しています。









クイックチェック



  1. バリデーターは、一般的なHTMLの有効性についてサイトをチェックします： https : //validator.w3.org/ 。







    使用されるHTMLのバージョンの仕様への最大限の準拠はオプションですが、推奨されます（技術[G192] [g192]を参照）。 ただし、サイトの可用性にとって重要であり、拘束力のあるエラーがいくつかあります。 これらは、「WCAG AAコンプライアンスチェックの詳細」セクションの基準4.1.2の説明にリストされています。







  2. 専用のバリデーターでサイトを確認します。 検証ツールのセクションをご覧ください。







  3. スクリーンリーダーのないキーボードコントロール。







    クリック可能なものはないはずですが、キーボード要素からはアクセスできません（特別な代替手段がない限り）。 このような要素は、<a href=..> </a>、<button>タグを使用するか、role = button、role = linkおよびtabindex属性の組み合わせを使用して実装する必要があります。







    フォーカスは表示され、正しく移動する必要があります。要素にヒットしても「スタック」せず、ページのどの状態でもユーザーアクション中に失われることはありません。







  4. スタイルを適用したサイトを表示して、視覚障害者に見えるように近づけます。 スタイルはhttps://github.com/Harut/wai-aria.cssで見つけることができます 。 これにより、チェックリストの各項目をチェックせずに、ほとんどのエラーを「目で」見つけることができます。 この項目はオプションであり、置き換えられませんが、スクリーンリーダーでのページ表示に先行します。 まず、完全なビジュアルバージョンとスタイルが適用されたバージョンの不整合に注意することをお勧めします。







  5. スクリーンリーダーをチェックインします。 この段階では、以前のチェックで最も重大なエラーを検出して修正する必要があります。







    スクリーンリーダーによる表、非標準要素、ページ機能の使用の利便性、音声属性（主にロールとアリア*の正確さと完全性）の認識を確認する必要があります。







  6. スクリーンリーダーでフォームをチェックするには、特別な注意が必要です。 すべてのテキストラベル、エラー、指示の正確性を確認し、送信およびエラーが正常に行われたときのフォームの動作、フォーム入力モードでの情報の順序と完全性を確認する必要があります（ページ読み取りモードではなく、TABを使用してフィールドを切り替える場合）、フォーカスシフトを修正しますなど


利用可能なインターフェイスの実装例





WCAG AA詳細コンプライアンスチェック



このセクションでは、関連するWCAG基準に従ってグループ化された、AAレベルに準拠するためのチェックリストの形式でWCAGからの絞り込みを示します。 リストはhttp://webaim.org/standards/wcag/checklistからコンパイルされます 。 公式の推奨事項、手法、および一般的なエラーのリストは、 https ： //www.w3.org/WAI/WCAG20/quickref/にあります 。







サイトの開発とテストのすべての参加者は、開発段階でのミスをできる限り少なくしたり、初期段階で修正したりするために、このリストを注意深く研究し、マスターすることをお勧めします。 これにより、開発とテストで最小限の作業を行うことができ、重要な詳細のテストに集中することができますが、エラーの総数では見落とされる可能性があります。







1.1。 テキストバージョン：非テキストコンテンツのテキストバージョンを提供します







1.1.1。 非テキストコンテンツ（レベルA）









1.2。 メディアコンテンツ：期間限定のメディアコンテンツの代替バージョンを提供します







つまり、録音テキストのトランスクリプト、その内容または字幕のテキスト説明を提供する必要があります。 ビデオに音声で表されない視覚情報が含まれている場合は、音声による説明も提供する必要があります。







そのようなコンテンツがサイトに表示される場合は、WCAG標準またはWebaimの推奨事項などを参照する必要があります。







1.3。 適応性：データや構造を失うことなく、さまざまな形式で提示できるコンテンツを作成します







1.3.1。 情報と接続性（レベルA）









1.3.2。 重要な読み取りシーケンス（レベルA）









1.3.3。 感覚仕様（レベルA）







これが機能の不可欠で不可避な部分でない場合：









1.4。 選択性：コンテンツの視聴を簡素化し、重要な部分を小さな部分から分離します







1.4.1。 色の使用（レベルA）









1.4.2。 サウンドコントロール（レベルA）









1.4.3。 コントラスト（レベルAA）









1.4.4。 テキストのサイズ変更（レベルAA）









1.4.5。 画像上のテキスト（レベルAA）









2.1。 キーボードのアクセシビリティ







2.1.1。 キーボード（レベルA）









2.1.2。 フォーカストラップの欠如（レベルA）









2.2。 十分な時間：ユーザーがコンテンツに慣れ、作業するのに十分な時間を与える







2.2.1。 時間設定（レベルA）









2.2.2。 一時停止、停止、非表示。 （レベルa）









技術的な可能性がない場合、またはアニメーションまたは更新がページの機能にとって非常に重要であり、それらがなければページの意味または動作が変化する場合、標準はルールの例外を規定しています。 説明付きの例外の例は、基準の説明にあります 。







基準は非常に厳格であり、それを完全に順守するには、多くの開発時間が必要になることがあり、一般ユーザーのページの使用を損なう場合があります。 いずれの場合も、標準の厳密な正式な要件と現実の間で妥協点を見つける必要がありますが、同時に、これらのユーザーカテゴリごとに相互作用を検討する必要があります（「はじめに」を参照）。







2.3。 健康に有害であることが知られている設計要素を使用しないでください。







2.3.1。 1秒あたり3回以下のフラッシュの制限（レベルA）









2.4。 ナビゲーション：ナビゲーション、コンテンツ検索、およびサイト上の現在の位置の決定に関するヘルプとサポートをユーザーに提供します







2.4.1。 すべてのページで繰り返しブロックをスキップする（レベルA）









2.4.2。 ページタイトル（レベルA）









2.4.3。 フォーカス移動順序（レベルA）









2.4.4。 リンクインテント（コンテキスト内）（レベルA）









2.4.5。 さまざまな検索方法（レベルAA）









2.4.6. (Level AA)









2.4.7. (Level AA)









3.1. :







3.1.1. (Level A)









3.1.2. (Level AA)









3.2.







3.2.1。 (Level A)









3.2.2。 (Level A)









3.2.3. (Level AA)









3.2.4. (Level AA)









3.3。 :







3.3.1. (Level A)









3.3.2. (Level A)









3.3.3. (Level AA)









3.3.4. ( , ) (Level AA)







, , ( ), :









4.1. ,







4.1.1. (Level A)









4.1.2. , , , (Level A)









あとがき





More articles:


All Articles