アクセシビリティ対応 Web サイトの構築に関するリソース

[アーティクル]
04/04/2023

Web には、HTML、CSS、JavaScript の組み合わせを使用して構築された動的で複雑な Web サイト、アプリケーション、およびユーザーインターフェイスが用意されています。ただし、アクセシビリティを念頭に置いて設計および構築する場合、これらの複雑な Web サイトは、支援技術に依存して Web を閲覧するユーザーが使用するのが困難です。

障穣のあるユーザーがアクセスできる Web サイトを構築するには、ユーザーインターフェイスに関するセマンティック情報が必要です。アクセシビリティ対応の Web サイトを使用すると、スクリーンリーダーなどの支援技術が、さまざまな能力を持つユーザーが Web サイトを使用するのに役立つ必要な情報を伝えることができるようになります。

Microsoft Edge でサポートされている新しい HTML5 機能については、 HTML5Accessibility に関するページを参照してください。

アクセシビリティのしくみ

支援技術は、コンピューターに通常はない機能を追加します。たとえば、視覚障碍のあるユーザーは、マウスや画面でブラウザーを直接使用するのではなく、スクリーンリーダーなどの支援技術と組み合わせてキーボードを使用できます。

Microsoft プラットフォームと Web 上のアプリケーションの場合、支援テクノロジは次の任意の組み合わせと対話します。

Microsoft UI オートメーション。
Microsoft Edge のドキュメントオブジェクトモデル (DOM) などのアプリケーション固有のオブジェクトモデル。

Web 開発者の場合、特定の HTML 要素は UI オートメーションオブジェクトにマップされるため、これらの HTML 要素を選択する際に、開発者はそれらの要素に組み込まれているアクセシビリティプロパティとイベントを使用できます。 Web サイトの開発中は、通常、アプリケーションにアクセスできるようにするために API が正しく書き込まれていること、または適切な要素が指定されていることを確認する必要があります。

詳細については、 Microsoft Edge の ARIA と UI オートメーションに関するページを参照してください。アクセシビリティユニバーサル Windows プラットフォーム (UWP) アプリについては、「Windows デベロッパーセンターのアクセシビリティ」を参照してください。

動的コンテンツに関するアクセシビリティに関する一般的な問題の多くは、適切なコーディングプラクティスによって対処できます。 WCAG 2.0 のドキュメントには、よりアクセシビリティの高い動的 Web アプリケーションを作成するのに役立つ多くの手法とベストプラクティスが含まれています。ただし、適切にコード化された場合でも、動的コンテンツに必ずしもアクセスできるとは限りません。アクセシビリティ対応のリッチインターネットアプリケーション (ARIA) は、この問題を解決するのに役立ちます。

Web アクセシビリティの詳細については、「Web アクセシビリティイニシアチブ (WAI) による Web アクセシビリティの概要」をチェック。

アリア

W3C の Web アクセシビリティイニシアチブによるアクセシビリティ対応リッチインターネットアプリケーション (ARIA) 仕様は、動的な Web コンテンツとカスタムユーザーインターフェイスをすべてのユーザーがアクセスできるようにする構文として定義されています。 ARIA は、カスタムセマンティクスを伝えるために設計された追加の属性 (ロール、プロパティ、および状態) を使用して HTML を拡張します。これらの属性は、コントロールの状態とロールをアクセシビリティ API に渡すためにブラウザーによって使用されます。

ロール、プロパティ、および状態

ARIA ロールは、 role 属性を使用して要素に設定され、要素に関する支援技術とアクセシビリティ API 情報を提供します。たとえば、次 <li> の要素は、メニュー内の項目であることを示すために割り当てられます role="menuitem" 。

<li role="menuitem">Home</li>

ARIA の状態とプロパティは、ロールの性質の定義を形成するのに役立つオブジェクトに関する特定の情報を提供する aria プレフィックス属性です。プロパティは、 aria-readonly や aria-haspopup など、オブジェクトの性質に不可欠な属性です。プロパティを変更すると、オブジェクトの意味に影響します。

次の例では、プロパティ aria-haspopup="true" がメニュー項目に <li> 設定され、ポップアップがあることを示しています。

<li role="menuitem" aria-haspopup="true">Open</li>

状態はオブジェクトの性質を変更しませんが、オブジェクトに関連付けられている情報や、 aria-hidden や aria-checked などのオブジェクトに対するユーザー操作を表します。たとえば、次の例の状態 aria-checked="false" は、選択されているのではなく、チェックボックスがオフになっていることを表します。

<div role="checkbox" aria-checked="false">Accept</div>

ロール、プロパティ、状態の完全な一覧を表示するには、W3C の [ロールモデル] に移動します。

支援技術の互換性テスト

構築している Web サイトが実際の支援技術と連携していることを確認することが、障穣のあるユーザーに良いエクスペリエンスを提供するための最良の方法です。多くの支援技術がキーボードを使用しているため、Web サイトのキーボードアクセシビリティのテストを開始するのに適しています。

キーボード互換性テストでは、ユーザーがマウスを必要とせずにすべての対話型コントロールにアクセスできるかどうかを検証します。 Microsoft Accessibility Insights for Web は、Microsoft Edge と Chrome のブラウザー拡張機能であり、ガイドとしていくつかの一般的な問題を明らかにします。

Web サイトがキーボードで正常に動作することを確信できたら、スクリーンリーダーなどの他の支援技術で試してみてください。このテストでは、次の問題が明らかになります。

HTML、ARIA、CSS。
機能または手法に対する支援技術のサポートレベル。

ブラウザーによって、Microsoft Edge がマップするのとは異なる方法で、プラットフォームアクセシビリティ API に要素がマップされる場合があります。インターフェイスを構築する際には、それぞれの違いを考慮することが重要です。

WebAIM は、テストする支援テクノロジとブラウザーを決定するのに役立つスクリーンリーダーとロービジョンユーザーを対象に調査を実施します。

テスト方法を学習する

支援技術は高度なツールです。支援技術を使用してすぐにテストを開始できると想定しないでください。その仕組みについて最初に学習する必要はありません。スクリーンリーダーでテストする学習には、特に急な学習曲線があります。スクリーンリーダーの初心者ユーザーは、スクリーンリーダーにバグがあると考える場合があります。一方、問題は実際にはスクリーンリーダーを使用する際にエラーになる可能性があります。

WebAIM でのスクリーンリーダーによるテストでは、支援技術を使用したテストの学習に関する詳細情報が提供されます。

ローカルでのテスト

ほとんどのデバイスには、OS に組み込まれている支援技術が含まれています。 Microsoft Windows には、 Windows ナレータースクリーンリーダーと Windows 拡大鏡が含まれています。 NVDA、FreedomscientificSoftwareJaws、ZoomText などのサードパーティの支援技術をダウンロードできます。 Apple macOS には、VoiceOver スクリーンリーダーが含まれています。 iOS、Android、Linux はすべて、さまざまな支援技術をサポートしています。

仮想マシンとエミュレーターでのテスト

macOS では、Windows ナレーターや NVDA など、Windows でのみ使用できる支援技術を使用してテストする場合は、Windows 仮想マシンを作成します。

Android Studio には、 Android Accessibility Suite で支援技術をテストするためのエミュレーターが含まれています。手順に従って仮想デバイスを設定し、エミュレーターを起動し、GooglePlay ストアから Android Accessibility Suite をインストールします。

注

現在、iOS シミュレーターには VoiceOver は含まれていません。

クラウドベースのテストツール

OS で支援技術を利用できない場合、または仮想マシンまたはエミュレーターにインストールできない場合は、クラウドベースの支援技術テストツールが次に最適です。

Assistiv Labs (商用製品) を使用すると、最新の Web ブラウザーを使用して支援技術を手動でテストできます。支援技術とブラウザーを選択すると、操作できる仮想マシン、エミュレーター、または実際のデバイスに接続されます。

「クラウドベースのエミュレーターとシミュレーター」も参照してください。

アクセシビリティの基本に関するリソース

これらは、アクセシビリティのためのプロジェクトとイニシアチブです。

A11Y プロジェクトは、Web アクセシビリティを容易にするコミュニティ主導の取り組みです。 A11Y プロジェクトサイトを参照して、アクセシビリティの基本原則、アクセシビリティパターンとウィジェットライブラリ、アクセシビリティソフトウェア、ブログ、書籍、ツールに関するリソースについて説明します。

Web アクセシビリティイニシアチブ (WAI)

W3C Web アクセシビリティイニシアチブ (WAI) は、Web のアクセシビリティの向上に役立つ取り組みです。これらのサイトには、Web アクセシビリティ、インクルージョンの設計、チュートリアルとプレゼンテーションなど、はじめにに関するさまざまなリソースが用意されています。

アクセシビリティに関するブログ

これらはアクセシビリティに関するブログです。

TPGi、LLC

TPGi、LLC は、クライアントが政府や国際基準を満たしながら、効果的かつ効率的にすべての聴衆に到達することを保証するために、世界中の組織にコンサルティングと技術ソリューションを提供しています。ブログでは、Web アクセシビリティのベストプラクティス、アクセシビリティツール、アクセシビリティの傾向などのトピックについて説明します。

レベルアクセス

Level Access は、アクセシビリティ対応の製品やサービスの開発と展開をクライアントにサポートするデジタルアクセシビリティ企業です。ブログでは、ARIA のベストプラクティス、アクセシビリティの傾向、ウェビナーなどのトピックに取り組んでいます。

アクセシビリティ対応の例

これらは、アクセシビリティのライブラリと例です。

ally.js - チュートリアル

アクセシビリティをよりシンプルにすることで、アクセシビリティに関する問題を伴う最新の Web アプリケーションを支援する JavaScript ライブラリ。詳細については、「 ally.js - チュートリアル」を参照してください。

OpenAjax の例

OpenAjax Alliance の Web サイトは、WAI-ARIA の規則を検証するための優れたリソースであり、WAI-ARIA の実装の例を多数提供しています。

パターン

A11Y プロジェクトには、メニュー、ボタン、ヒントなどのアクセス可能なウィジェットとパターンのライブラリが用意されています。詳細については、「パターン」を参照してください。

アクセシビリティの手法とツール

これらは、アクセシビリティを向上させる手法とツールです。

アクセシビリティ: Microsoft Edge のアクセシビリティ対応拡張機能アイコンを作成する

Microsoft Edge 用のアクセシビリティ対応拡張機能アイコンの作成に関するガイダンスを取得します。詳細については、「アクセシビリティ: Microsoft Edge のアクセシビリティ対応拡張機能アイコンの作成」を参照してください。

アクセシビリティ対応の名前と説明: 計算とマッピング 1.1

この W3C マッピングドキュメントでは、ブラウザーが Web コンテンツ言語からアクセス可能なオブジェクトの名前と説明を決定し、それらをアクセシビリティ API で公開する方法について説明します。詳細については、「アクセシビリティ対応の名前と説明: 計算とマッピング 1.1」を参照してください。

アクセシビリティ評価リソース

アクセシビリティ評価リソースは、アクセシビリティの Web サイトを評価するためのさまざまなアプローチの概要を示す W3C によるマルチページリソースです。詳細については、「アクセシビリティ評価リソース」を参照してください。

支援技術互換性テスト

スクリーンリーダーなどの支援技術 (AT) で、さまざまなコンテンツタイプと標準がどのように動作するかを示すテスト結果。詳細については、支援技術互換性テストに関するページを参照してください。

アクセシビリティの高い Web サイトの構築がはるかに簡単になりました

この .NET Web 開発とツールのブログ投稿では、Visual Studio 拡張機能の Web アクセシビリティチェッカーについて説明します。詳細については、「アクセシビリティの高い Web サイトの構築がはるかに簡単になりました」を参照してください。

コアアクセシビリティ API マッピング 1.1

この W3C マッピングドキュメントでは、Web コンテンツ言語のセマンティクスをアクセシビリティ API に公開する方法について説明します。詳細については、「 Core Accessibility API Mappings 1.1」を参照してください。

簡単なチェック - Web アクセシビリティの最初のレビュー

Web ページのアクセシビリティを評価するのに役立つ WAI による一連のクイックチェック。詳細については、「 Easy Checks – A First Review of Web Accessibility」を参照してください。

WCAG 2.0 を満たす方法

Web コンテンツアクセシビリティガイドライン (WCAG) 2.0 の要件 (成功基準) と手法に関するクイックリファレンス。詳細については、 WCAG 2.0 を満たす方法に関するページを参照してください。

HTML アクセシビリティ API マッピング 1.0

この W3C マッピングドキュメントでは、HTML5.1 要素と属性がプラットフォームアクセシビリティ API にどのようにマップされるかについて説明します。詳細については、「 HTML アクセシビリティ API マッピング 1.0」を参照してください。

クイックヒント

A11Y プロジェクトによるアクセシビリティに関するクイック Web 開発のヒントの一覧。詳細については、「クイックヒント」を参照してください。

サイトスキャン

Microsoft Edge Dev センターのサイトスキャンツールでは、古いライブラリ、レイアウトの問題、アクセシビリティの問題がチェックされます。詳細については、「サイトスキャン」を参照してください。

WCAG 2.0 の手法

Web コンテンツアクセシビリティガイドライン (WCAG) 2.0 の成功基準を満たす Web 開発者向けのガイダンスを提供する W3C の手法。詳細については、「 WCAG 2.0 の手法」を参照してください。

Web アクセシビリティの開発に関するヒント

障穣者がよりアクセスしやすい Web コンテンツの開発に関する W3C からのヒント。詳細については、「 Web アクセシビリティの開発に関するヒント」を参照してください。

WAI-ARIA オーサリングプラクティス 1.1

W3C によるドキュメント。このドキュメントは、WAI-ARIA 1.1 の使用方法について読者に理解を提供し、WAI-ARIA のロール、状態、およびプロパティを使用してウィジェット、ナビゲーション、および動作にアクセスできるようにする方法を推奨しています。詳細については、「 WAI-ARIA オーサリングプラクティス 1.1」を参照してください。

WAI のガイドラインと手法

WAI によって開発された一連の Web アクセシビリティガイドラインと標準。詳細については、「 WAI ガイドラインとテクニック」を参照してください。

Web アクセシビリティ評価ツールの一覧

Web サイトがアクセシビリティガイドラインを満たしているかどうかを判断するのに役立つ Web アクセシビリティ評価ツールの一覧。詳細については、「 Web アクセシビリティ評価ツールの一覧」を参照してください。

Web アクセシビリティの観点: すべてのユーザーの影響と利点を調べる

アクセシビリティの影響とすべてのユーザーの利点に関する W3C による一連の短い状況ビデオ。詳細については、「 Web アクセシビリティの観点: すべてのユーザーの影響と利点を調べる」を参照してください。