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

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 プロジェクト

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 アクセシビリティの観点: すべてのユーザーの影響と利点を調べる」を参照してください。