Webアクセシビリティ：W3C標準がしばしば無視される理由

公開: 2022-03-11

du jourという用語は、 Webアクセシビリティです。私の意見では、Webデザインの最も頻繁に誤解され、適用が不十分な側面の1つです。 よくある誤解は、アクセシビリティは障害者専用に設計されているというものです。実際、誰もがアクセス可能なコンテンツの恩恵を受けており、さまざまなプラットフォームまたはさまざまな方法でアクセス可能なコンテンツにアクセスできるようになることで、視聴者が増えます。これは、コンテンツをより少ない制約で使用できるためです。

残念ながら、多くのWeb開発者はコンテンツにアクセスできるようにしておらず、Webアクセシビリティガイドラインに準拠していません。そのため、多くの人が自分のデザインを使ったり、コンテンツを楽しんだりするのに不必要な困難を経験しています。極端な場合、特定のユーザーグループはそのようなWebサイトをまったく効果的に使用できません。

アクセシブルなコンテンツを構築することは、開発者、デザイナー、またはコンテンツクリエーターにとって第二の性質である必要があります。これは、新しい建物を設計する建築家がランプ、階段、リフトを検討するのと同じです。

舞台裏の背景と、多くの開発者が正当な理由もなくWebアクセシビリティ標準を見落としているように見える理由を詳しく見てみましょう。

1.「アクセシブルデザイン」とはどういう意味ですか？

アクセス可能なコンテンツは、誰もが使用できるコンテンツです。ユーザーがコンテンツにアクセスする方法のすべての側面を把握しているわけではないため、事前にアクセシビリティを念頭に置いて設計する必要があります。

先に強調したように、これは障害を持つ人々には関係がなく、世界の人口の約15％を占めています。実際には、ユーザーは、開発中に想定したのとまったく同じ方法で、コンテンツを消費したり、デバイスを操作したりしないことになります。多くの法域では、法的な理由からアクセス可能なコンテンツも必要です。アクセシビリティコンプライアンスの詳細については、「組織のWebアクセシビリティビジネスケースを開発する際の法的およびポリシー要因」をお読みください。

次のようなユーザーがアクセスできるコンテンツについて考えるときは、次のシナリオを検討してください。

よく聞こえません。 世界中で3億6000万人が聴覚障害を持っています。オーディオコンテンツには文字起こしが必要であり、ビデオにはキャプションが含まれている必要があります。
よく見えません。 世界中で2億8500万人が視覚障害を持っていると推定されています。3900万人が視覚障害者で、246人が視力が低下しています。視覚障害のあるユーザーは、スクリーンリーダー（合成音声を使用してコンテンツを読み取る）、更新可能な点字ディスプレイ（画面コンテンツは点字ディスプレイに表示され、ユーザーはディスプレイのキーを使用してデバイスをナビゲートおよび操作できます）、または高-コントラストモード。
失読症の影響を受けます。 失読症の人は、コンテンツ、特に正当化されたテキストやすべて大文字などを読んだり理解したりするのが難しいと感じています。
物理的な制限に苦しんでいます。 すべての人がすべてのデバイスを使用できるわけではありません。たとえば、コンテンツ内のナビゲーションは、マウスユーザーだけでなく、マウスを使用できないユーザーも利用できる必要があります。
モバイルデバイスの使用。 コンテンツを小さな画面に適応させます。ユーザーがフォントサイズをズームまたは拡大できるようにします。

2.優れたWebアクセシビリティを確保する方法

人々は、コンテンツをナビゲートして消費するために非常に異なる方法を使用します。コンテンツへのアクセスを容易にする追加のソフトウェアツールによるサポートが必要なユーザーがいます。支援技術として知られるこれらのツールは、スクリーンリーダーからタッチスクリーンやヘッドポインターまで多岐にわたります。

ただし、アプリケーションと支援技術は相互に通信する必要があります。 HTMLで書かれているものすべてが、支援技術にとって完全に理解できるわけではありません。コンテンツを「技術言語」からより人間が読める言語に「翻訳」するのを支援するために、追加のアクセシビリティAPI標準が作成されました。

この基本的なWebアクセシビリティ図は、支援技術がどのように機能するかについてのより良いアイデアを提供するはずです。

それがどのように機能するかを説明するために、簡単なコード例を見てみましょう。

 <a href="#” class=”button”>Delete</a>

スクリーンリーダーを使用する人にとって、この単純なコードはあまり意味がありません。それは誤解を招くことさえあり、「削除」というテキストのリンクとしてのみ読み取られます。アクションの実行に使用されるメソッドの種類をユーザーが理解できるようにするために、 ARIA （Assistive Rich Internet Applications）属性（https://www.w3.org/TR/wai-aria/で指定）を使用して、元の役割をオーバーライドします。属性role="button"を追加することにより、ボタンへのリンクの意味を変更します。このようにして、スクリーンリーダーはリンクではなくボタンとして読み上げます。どちらがより適切です。

要するに、属性ARIA：

非セマンティック要素または他のセマンティック要素のセマンティクスを提供または強化し、
動的（ライブ）コンテンツに引き続きアクセスできるようにします。
定義されたウィジェットのタイプ（メニュー、ツリー項目、スライダー、進行状況メーターなど）を説明する役割を提供します。
Webページの構造（見出し、領域、および表）を説明する役割を提供します。
ウィジェットの状態を提供します（チェック済み、ポップアップありなど）。
ドラッグソースとドロップターゲットを説明するドラッグアンドドロップのプロパティを提供します。

Webデザインのアクセシビリティとは何ですか？

コンテンツをデザインするときはいつでも、コンテンツがどのように認識され、どのように操作できるかという2つのことを考えてください。 Webデザインのアクセシビリティを説明するためにいくつかの例を調べてみましょう。

カスタム選択ドロップダウン要素を設計するとします。要素を設計する際に考慮すべき点は次のとおりです。

さまざまな状態をマークします：有効、無効、読み取り専用。
フォーカス/ホバー状態になったときに要素をマークします。
フォーカス/ホバー状態になったときにすべてのオプション要素をマークします。
テキストのみが200％レベルに拡大された場合でも、コンテンツが読みやすいことを確認してください。
テキストとその背景の間に十分なコントラストがあることを確認してください。適度に視力の弱い人や、直射日光にさらされたり、明るさが低いディスプレイなど、極端な照明条件のデバイスを使用している人がコンテンツを読むのに役立ちます。

別の例として、状態を表す色を選択することができます。ユーザーが色を選択できるセクションを設計する際に考慮すべき点は次のとおりです。

特定の色を区別するのが難しい人がいます。したがって、緑はすべての訪問者にとって緑を意味するわけではありません。これを修正するには、目的を説明するすべての色の説明を追加します。
フォーカス/ホバー状態になったら、各要素にマークを付けます。
ビューポートが小さいデバイスなどですべての要素を簡単にアクティブ化できるように、要素間に十分なスペースがあることを確認してください。

3.アクセシビリティテスト：どこから始めればよいですか？

Webコンテンツに完全にアクセスできることを確認する方法は1つではありません。アクセシビリティの問題を検証して修正するには、複数の手法を使用する必要があります。問題、解決策、および優先順位を定義することから始めることができます。

問題の定義

アクセシビリティの問題に取り組んでいる間は、常に明確なタイトルで問題ごとに1つのチケットを作成するようにしてください。これにより、問題の理解が簡単になり、優先順位を定義するのに役立ちます。

悪い例：ユーザーはページのキーボードを使用できません。

良い例：メインメニューでキーボードナビゲーションを使用できません。

悪い例は、短時間で閉じるのが非常に難しいケースにつながります。チケットのタイトルが一般的すぎるため、複数のトピックに関するディスカッションがコメントセクションから始まる場合もあります。

良い例は、問題を正確に示しており、メインメニューのキーボードナビゲーションという1つのことにのみ焦点を当てています。

Webアクセシビリティの問題に優先順位を付ける

優先順位は、どの問題を最初に修正する必要があるかを定義するため、重要です。たとえば、WCAGはA、AA、AAAの3つの適合レベルで分割されます。これは、最小レベルAから開始する必要があることを意味しますが、AAおよびAAAレベルが単に「必要」であることを自動的に意味するわけではありません。すべてのレベルが重要であり、レベルAだけで十分であると想定して優先順位を付けないことが重要です。

ただし、WCAGレベル（またはその他のガイドライン）を理解するのは非常に難しい場合があり、少し単純化するために、次の優先度の定義を検討することもできます。

重大–ユーザーがアプリケーションを使用できないようにする問題。利用可能な回避策はありません。
メジャー–アプリケーションの使用を困難にしたり、方向を乱したりするが、ユーザーが操作を完了する能力を妨げない問題。
軽微–煩わしいが使用を妨げない問題、またはアプリケーションに加えられる可能性のある機能強化。
情報–ベストプラクティスに準拠していません。改善のための一般的な推奨事項。

ソリューション

ガイドライン（つまり、WCAG、セクション508、またはADA）のいずれも、特定の問題を修正する方法に関する技術コードの観点から、直接的な解決策を提供するものではありません。それらは期待される動作を定義するだけです。ただし、WCAGはさらに、問題の再現方法を理解するのに役立つテスト手順を定義しており、自動および半自動のWebアクセシビリティテストの信頼できるルールの開発に焦点を当てたW3Cコミュニティである自動WCAGモニタリングコミュニティグループがあります。

WCAGテクニックG4の例（「コンテンツを一時停止し、一時停止した場所から再開できるようにする」）：

テスト手順

コンテンツを移動またはスクロールするページでは、

Webページまたはユーザーエージェントが提供するメカニズムを使用して、コンテンツの移動またはスクロールを一時停止します。
移動またはスクロールが停止し、自動的に再起動しないことを確認します。
提供されているメカニズムを使用して、移動するコンテンツを再開します。
停止したところから移動やスクロールが再開されていることを確認してください。

予想された結果

2番と4番は本当です。

ご覧のとおり、技術的な解決策はありませんが、予想される動作を定義しています。 Web開発者がそれをどのように実装するかは彼ら次第です。

WebアクセシビリティガイドラインとW3C標準

次の基本的なWeb標準を出発点にする必要があります。

最も一般的なのは、WCAGとして知られるWebコンテンツアクセシビリティガイドラインです。 WCAG 2.0は、「安定した、参照可能な技術標準です。 知覚可能、操作可能、理解可能、堅牢という4つの原則に基づいて編成された12のガイドラインがあります。 ガイドラインごとに、A、AA、AAAの3つのレベルでテスト可能な成功基準があります。」
WCAG 2.0のテクニックは、Webコンテンツ作成者向けの包括的なガイドです。
W3Cメディアアクセシビリティユーザー要件—このドキュメントは、Web上のオーディオとビデオに関して障害を持つユーザーが持つアクセシビリティ要件を示しています。
21世紀の通信およびビデオアクセシビリティ法—CVAAは2つの大きなタイトルまたはセクションに分かれています。タイトルIは、障害を持つ人々がブロードバンドを使用して製品やサービスに完全にアクセスできるようにするための通信アクセスについて説明しています。アクセシビリティ法のタイトルIIは、障害を持つ人々がテレビやインターネットでビデオ番組を視聴しやすくするための新境地を開拓します。
セクション508—電子および情報技術を開発、調達、維持、または使用するときにすべての連邦機関に適用される情報通信技術（ICT）のアクセシビリティ要件。
障害を持つアメリカ人法（ADA）のタイトルIIに基づくウェブサイトのアクセシビリティ—そこで、ADAのタイトルIIの無差別要件が州および地方自治体のウェブサイトにどのように適用されるかを学びます。

Webアクセシビリティテスト：コンテンツがアクセス可能かどうかを確認するにはどうすればよいですか？

ステップ1からWebコンテンツにアクセスしやすくするために役立つ基本的なチェックポイントを次に示します。

HTMLを検証します。 支援技術ではページコンテンツの解釈に問題が発生する可能性があるため、HTML構造にエラーがないことを確認してください。
キーボードだけでテストします。 キーボードのみを使用して、すべてのアクション可能な要素にアクセスできることを確認してください。また、フォームの送信など、キーボードを使用してすべてのアクションを実行できる必要があります。
アクセシビリティテストツールとバリデーターを使用してテストします。 潜在的なアクセシビリティエラーをスキャンして検証するツールを使用します。
動的コンテンツ。 検索結果が変更された場合など、動的な変更についてスクリーンリーダーのユーザーに通知します。
意味を説明するために色に頼らないでください。 説明とともに色を使用します（例：[黄色のボックス]警告）。
フォーカスのあるアウトラインを削除しないでください。 これは、CSSプロパティのoutline: 0; キーボードユーザーはページの向きを失うため、これを行わないでください。キーボード以外のユーザーにはフォーカスのアウトラインを削除することを検討できますが、キーボードのユーザーには常にフォーカスのアウトラインを提供してください。
エラーメッセージ。 エラーを修正する方法を常にユーザーに伝えてください。データが無効であるとだけ述べないでください。
タブの順序。 タブベースのナビゲーションが、グラフィカルユーザーインターフェイスで確立された規則に従っていることを確認してください。少なくとも、アプリケーションのデフォルト言語の読み取り方向に従う必要があります。たとえば、英語では、読み上げ順序は上から下、左から右です。アラビア語では、上から下、右から左です。
ズーム。 テキストを最大200％ズームしている間、ページのコンテンツが引き続き読み取り可能であることを確認してください。
画像をオフにします。 あなたはまだ快適な方法でページを使うことができますか？すべての画像に代替テキストはありますか？
スクリーンリーダー。 少なくとも1つのスクリーンリーダー（VoiceOver、Windowsナレーター、NVDAなど）を使用してコンテンツを読み、ナビゲートできるかどうかをテストします。
ハイコントラストモード。 ハイコントラストモードに切り替えている間、コンテンツがまだ読み取り可能かどうかを確認します。
フォントサイズ。 ページのフォントサイズが10px以上であることを確認してください。

4.Webアクセシビリティの一般的な間違い

最も一般的な間違いは、開発前にアクセシビリティ要件を特定できないことです。残念ながら、後のアクセシビリティは開発の一部となり、ソリューションの実装は難しくなります。

これは、アクセシビリティを実装する際に開発者が犯す最も一般的な間違いのいくつかのリストです。

キーボードのみを使用してコンテンツをナビゲートする機能はありません。
CSSアウトラインプロパティの誤用。 ほとんどの場合、 outline: 0; が使用されます。これは、各アクション可能な要素の周囲のアウトラインが表示されなくなることを意味します。 outline: 0; またはoutline: 0 !important; 。ユーザーは、コンテンツ内を移動しているときに現在フォーカスされている要素を表示できなくなります。ただし、 border CSSプロパティを使用するなど、他に代替手段がない場合は除きます。
DOM操作やblur()メソッドの使用などにより、現在の要素からフォーカスが失われます。これは、シングルページアプリケーションでよく発生します。
XMLHttpRequest APIを使用してコンテンツがダウンロードされ、UIに新しい変更が加えられたなど、何かが変更されたというスクリーンリーダーユーザーへの通知はありませんが、ユーザーには通知されていません。これは、シングルページアプリケーションでよく発生します。
アクセスできない日付ピッカー。 多くの場合、アクセスできない日付ピッカーが使用されます。ユーザーは、キーボードを使用してカレンダーオプションをナビゲートすることはできません。
アクセシビリティの問題を自動的に修正すると主張する拡張機能を使用する。それらを注意深く使用し、結果を確認してください。それらを誤用すると、解決策よりも多くの問題が発生する可能性があります。
インデックス番号が0より大きい要素tabindex属性に追加します。インデックスが0より大きいtabindexを使用する目的は、主にナビゲーションパスを「修正」することです。ただし、ナビゲーションの自然なパスを取得するために、HTML構造を変更することを検討してください。 tabindexを使用して操作すると、メンテナンスの問題や予測できないナビゲーションパスが発生する可能性があります。
見出しの階層が間違っています。 残念ながら、それはまだかなり頻繁に見られますが、ヘッダー階層は適切に構築されていません（例： <h1> 、 <h5> 、 <h2> 。スクリーンリーダーのユーザーはヘッダーを使用してセクションをナビゲートしており、コンテキストを理解するのが難しいため、不適切な構造は混乱を招きます。
ハイコントラストのサポートがありません。 ソフトウェアをハイコントラストモードで使用している人がいます。あなたのコンテンツがまだ知覚可能であることを確認してください。
アクセスできないCAPTCHAソリューションを使用します。 残念ながら、私が知っているすべてのCAPTCHAは、アクセスできないか、非常に使いにくいものです。
アニメーションが多すぎる、および/または一時停止できない。 ビデオ、広告、または画像カルーセルの自動再生は非常に気が散ります。
テキストの大きな塊。 スペース、コンマ、またはドットを含まない、非常に大きな単一のブロックに凝縮されたテキスト。非常に読みにくい。より小さなチャンク、より多くの段落、および小見出しに分割すると、テキストコンテンツをより適切に整理するのに役立ちます。
ズームの問題。 最大200％にズームしたときに、コンテンツが引き続き読み取り可能でナビゲート可能であることを確認してください。
色に依存しています。 非常に多くの場合、要素の状態は色でのみマークされます。たとえば、警告状態は黄色の箇条書きでのみマークされます。この色は、色覚異常の人には同じように認識されません。
クリック可能/タップ可能な小さなターゲット。 クリック可能/タップ可能な領域は小さすぎることがよくあります。大きくすると、ユーザーはそれらをより簡単にアクティブ化できます。

しかし、どうすればWebアクセシビリティを改善できますか？

問題を定義することは1つのことです。それを修正することはまったく別のことであり、見た目ほど簡単ではないことがよくあります。これは、アクセシビリティAPIの実装に一貫性がなく、回避策を見つけたり、問題を修正しようとしたときに何かがまったく機能しないという事実を受け入れる必要がある場合があるためです。

ツールに関しては、考えられるすべての組み合わせをチェックできる単一のツールはありませんが、良いスタートとして、これらのツールが役立つはずです。

W3C Markup Validation Service —HTMLコンテンツにエラーがないことを確認するためだけに。 HTML構造にエラーがある場合、出力は予測不可能であり、特にさまざまな支援技術によって適切に処理できません。
https://www.w3.org/WAI/ER/tools/ —Webコンテンツがアクセシビリティガイドラインを満たしているかどうかを判断するのに役立つプログラムまたはオンラインサービスのリスト。
そして、私のツールであるASLint https://www.aslint.org/は、アクセシビリティの問題を見つけるのに役立ちます。

すべてのシナリオを完全にまたは完全に自動化できるわけではないため、アクセシビリティツールが手動テストに取って代わることはできないことを常に念頭に置いてください。たとえば、 position: fixed; 。

アプリケーションの使用を妨げる問題に焦点を当てます。たとえば、ユーザーがキーボードを使用してメニューをナビゲートできない場合などです。

コンテンツをアクセシブルにすることが重要な理由

誰もが自分のコンテンツをできるだけ広く広めたいと思っています。アクセシビリティは、より多くのユーザーにリーチすることから、すべてのユーザーのユーザーエクスペリエンスを向上させることまで、さまざまなレベルでその分野で役立ちます。さらに、アクセシビリティは、あなたが伝統的に障害者と考えるかもしれないものだけのものではありません。高齢化してそれに伴う身体的変化を経験している個人、電話で自動コントラスト調整が必要な晴れた日にジョギングしている人、またはアクセス可能な音声でテキストメッセージを送信したい買い物袋でいっぱいの手を持つ親であるかどうかテクノロジーは、すべてのユーザーが時々使用できるテクノロジーです。

追加のボーナスとして、WCAG 2.0基準を完全に満たすアクセス可能なコンテンツは、検索エンジンによるクロールと理解が容易であり、サイトのランク付けに大きな影響を与える可能性があるというプラスの効果があります。したがって、アクセシブルなデザインは、Webサイトへの追加のトラフィックを促進する可能性があります。

最後に、考慮する必要のある統計を次に示します。

世界中で10億人以上が何らかの障害を経験しています。
人口の高齢化。 2015年から2030年の間に、世界の高齢者（60歳以上）の数は、9億100万人から14億人以上へと56％増加すると予測されています。
ユニバーサルデザインがカギです。 ユニバーサルデザインとは、あらゆる能力の人々が本質的にアクセス可能で使用可能なサービス、製品、および環境を生み出すための幅広いアイデアと実践を指します。
障害の種類：視覚、可動性、発話、認知、聴覚など、障害には5つの大きなカテゴリーがあります。

私たちは皆、質の高いサービスを必要としています。 それらもお届けしましょう。