この記事は最終更新日から1年以上経過しています。
【導入手順④】ウェブアクセシビリティの試験を行う
公開日:
更新日:
こんにちはkanappleです。
ウェブアクセシビリティ導入の手順、前回の続きになります。
1. ウェブアクセシビリティ方針を決める
・目標する適合レベルを決める
・達成期限、担当部署を決める
2.ウェブアクセシビリティ方針を公開する
3.ウェブアクセシビリティ方針に基づいたウェブコンテンツ制作
・既存のサイトに導入する場合は現状を調査し対応していく
4.ウェブアクセシビリティの試験を行う
5.ウェブアクセシビリティ試験結果を公開する
今回の記事は「4.ウェブアクセシビリティの試験を行う」です。
4.ウェブアクセシビリティの試験を行う
ウェブアクセシビリティ試験を実施する人に決まりはなく、ウェブサイト運営者や制作会社等の第三者に試験の実施を依頼することもできます。
試験は達成基準に含まれる「達成方法」と「失敗例」を使って判断する方法が推奨されており、達成方法はWCAG 2.0 解説書で確認できます。
・WCAG 2.0 解説書
また、freeeアクセシビリティ・ガイドラインではアクセシビリティチェック項目一覧ページがあり、チェック項目について動画で解説してある項目もあるので活用すると良いでしょう。
・freeeアクセシビリティ・ガイドライン
・freee アクセシビリティチェック項目一覧
試験にはWAICが公開している実装チェックリストをカスタマイズして使うと効率的に作業を進められます。
・JIS X 8341-3:2016 試験実施ガイドライン
ウェブアクセシビリティ試験に使用できるツール
・HTMLのバリテータ:The Nu Html Checker
・コントラスト比のチェック:Google Chromeの開発者ツールを開き「Lighthouse」タブからチェックする。またはChromeの拡張でaxe DevToolsを使う
・スクリーンリーダー: NVDA、macOSのVoiceOver(最終的なチェックにはNVDAを用いる)、iOSのVoiceOver、Android TalkBack
・アクセシビリティチェックツール:axe DevTools
・アクセシビリティ評価ツール:miChecker(エムアイチェッカー)
試験対象ページについて
ウェブサイト単位で試験を行う場合は、次のいずれかの方法を用いて、試験対象のページを選択して試験を実施します。
a) 全てのウェブページを選択する場合
b) ランダムに選択する場合
c) ウェブページ一式を代表するウェブページを選択する場合
d) ウェブページ一式を代表するウェブページとランダムに選択したウェブページとを併せて選択する場合
ウェブサイトの総ページが100ページを超える場合は、方法dを用いることが推奨されています。
試験対象ページの目安については、WAICの試験実施ガイドラインに詳しく掲載されています。
実装チェックリストのカスタマイズ方法
ここでは先ほど紹介したWAICの実装チェックリスト(実装チェックリスト2020年12月版)について説明します。
ダウンロードした実装チェックリストを、作成したウェブアクセシビリティ方針に沿ってカスタマイズします。
1.適合レベルに合わせた達成方法の選択
目指す適合レベルを確認し、必要な達成基準を選択します。
目標が適合レベルがAの場合は、実装チェックリストのシート「レベルA」を、適合レベルがAAの場合は、実装チェックリストのシート「レベルA」と「レベルAA」の両方を使用します。
2.試験環境の決定
想定するウェブブラウザ、支援技術などの使用環境(試験環境)を決定します。
ウェブアクセシビリティ方針がある場合は、方針に書かれている試験環境を使用します。
3.達成方法の除外
試験に使用しない達成方法を除外します。
しかしチェックリストから項目を削除してしまうと、試験を行なっていないのか試験が必要ないのか不明確になる為、削除せずに除外する項目の適用欄に「除外」と記入し、除外の利用を「注記」欄に記入しましょう。
4.達成方法の追加
現在公開されている実装チェックリスト2020年12月版は、レベルA、レベルAAに対応になっています。
レベルAAAで試験を行う場合は、実装チェックリストに追加しましょう。
5.達成方法の修正
複数の達成方法を一度に判断する場合には、複数の項目を一つの項目に統合できます。
試験の実施と実装チェックリストの記入方法
カスタマイズした実装チェックリストで検証を行い、試験結果を記入します。
1.「適用」欄に、試験対象の有無を記入する
試験対象がウェブページに含まれていれば適用ありとなり、適用欄に「○」と記入、含まれていない場合は「適用」欄に「-」と記入します。
例えば、画像がないページで画像に関する検証は適用なしとなります。
また、別の項目で達成基準を満たしているために、試験の必要が無い場合にも適用欄に「-」と記入し、詳細を備考欄に記入します。
2.適用ありの試験項目について試験を行い、その結果を「適合」欄に記入する
適合であれば「○」、不適合であれば「×」と記入します。
適用なしの場合は、その項目に関してアクセシビリティの問題は生じません。
達成基準チェックリストを作成する
実装チェックリストに記入した試験結果を元に、達成基準チェックリストを作成します。
達成基準チェックリストには以下を記入します。
・達成基準
・適合レベル
・適用
・結果
・注記
こちらも、実装チェックリストを同じく、達成基準が適用なしの場合は適用欄に「ー」を記入し、一つでも適用がある場合は「○」を記入します。
達成基準に対応する達成方法が全て適合であれば、適合欄に「○」と記入します。
WAICでは達成基準チェックリストの例が公開されているので、参考にしましょう。
ウェブアクセシビリティ試験には時間がかかる為、事前準備を行い効率よく試験を実施します。
実際は対象とした範囲すべてで適合の結果を得ることは難しいものです。
必ず達成させることを目的にせず、問題箇所の把握と解決策の検討をし、次の試験で達成度を高めることを目指しましょう。
気を付けること
すべての適合結果を得ることは難しいと書きましたが、非干渉については必ず改修する必要があります。
非干渉に適合できていない場合は、コンテンツにアクセスできない利用者がいる状態である可能性があるためです。
まとめ
・ウェブアクセシビリティ試験に必要なツールを活用し試験を行う
・ウェブサイト単位で試験を行う場合は、ウェブページ数によって試験方法を考える
・必要に応じカスタマイズした実装チェックリストに、適用と適合を記入していく
・試験を元に達成基準チェックリストを作成する
・全てに適合は難しいが、非干渉の達成基準は必ず適合してリリースする
次回は「5.ウェブアクセシビリティ試験結果を公開する」についてです。
関連記事
この記事のハッシュタグ #Accessibility から関連する記事を表示しています。
タブのアクセシビリティ実装テクニック
タブはなぜ難しい?ウェブでよく使われるUIのひとつが「タブ」。見た目はシンプルですが、実際にアクセシビリティ対応を行うと「ロールや属性の付与」「選択状態の管理」「キーボード操作」など考えることが多く、実装難度は意外と高めです。タブをUIとして選択しないという手段もありますが、必要なケースもあります。よくある惜しい実装例キーボード操作できない現在地が伝わらないすべてtabindex="0"こうした実装を避けるため、ここでは APG(ARIA Authoring Practices Guide) をベースにしつつ、利用シーンに合わせて調整できる実装方法を紹介します。https://www.w3.org/WAI/ARIA/apg/patterns/1) ロールと要素を正しく関連付けるタブUIの基本は 「どことどこが結びついているか」を明示することです。tablist・tab・tabpanel のロールを付与し、aria-controls・aria-labelledby で相互参照を作ります。参照IDは一意であることが必須です。2) ロービングタブインデックスを理解Tabキーで移動したときに、選択中のタブだけがフォーカス可能にするのが「ロービングタブインデックス」です。aria-selected とセットで更新するのがポイントです。これにより、矢印キーやTabキーでの移動が直感的かつスムーズになります。3) キーボード操作(矢印+Home/End)タブは キーボード操作のしやすさが大事です。横型なら ←/→、縦型なら ↑/↓ を割り当て、Home/End で先頭・末尾に移動できるようにします。循環移動(最後の次は最初へ)も実装すると操作性が上がります。また、aria-orientationで 向きを明示することも大切です。これにより、縦型タブでもスクリーンリーダー・キーボード操作の両方に正しく伝わります。タブとスクリーンリーダー対応について主要な支援技術での挙動は以下の通りです。特に PC-Talker ユーザーにとっては「タブUIそのものが見えない」課題が残ります。NVDA(Windows):○ タブを認識するVoiceOver(iOS / Mac):○ タブを認識するTalkBack(Android):○ タブを認識するPC-Talker(Windows):△ タブを認識しないPC-Talker向け改善案他のスクリーンリーダーでは少し冗長になりますが、補助的にスクリーンリーダー用テキストなど用意することで改善できる場合があります。「現在は〇〇のタブを表示中です」といった短い一言を補足的に伝えるイメージです。プロジェクトの性質や利用者層に応じて、採用してみてください。まとめタブのアクセシビリティ実装は難しく見えますが、ポイントを押さえればシンプルです。ロールや要素で関係を作る選択中だけtabindex=0とaria-selected="true"矢印キー操作を入れる向きをaria-orientationで伝えるこの4つを押さえるだけで、支援技術ユーザーにとってぐっと快適になります。告知2025年10月3日(金)21:00 - 26:00 オンライン開催の「#朝までマークアップ 3(JS編)」に出演いたします。当日は、アクセシビリティを考慮したUIの話をします。この記事にご興味を持っていただけましたら、ぜひご参加ください!
スタッフブログ
動きのあるウェブアクセシビリティ対応はどうやって対応するの?
モーダルやタブ、アコーディオンなど「動き」のあるUIは、デザイン性や利便性を高める一方で、支援技術ユーザーにとっては操作や理解が難しくなることがあります。そのため、動きを伴うコンポーネントを実装する際は「アクセシビリティ対応」が欠かせません。参考ガイドラインW3C が公開している ARIA Authoring Practices Guide (APG) では、実際のUIパターンごとに「ロールや属性の付け方」「キーボード操作の仕様」などが整理されています。タブ、モーダル、ツリー、メニューなど、多くのケースで 実装コード例 が紹介されており、開発者が迷わず対応できるようになっています。ARIA Authoring Practices Guide (APG)このガイドを参考にすることで、動きのあるUIをアクセシブルに作るための基本を把握することができます。実際にどう活かすか実務では、APGが全て正解として見るだけでなく、実装しているUIが 想定された操作と一致しているかロービングタブインデックスやaria属性の相互参照が抜けていないかスクリーンリーダーで操作が伝わるかスクリーンリーダー読み上げに無理はないかキーボード操作で操作できるかといった観点でチェックするのも大事なポイントです。自社の取り組み:ハンドブックとブログ私たち、ましじめでも、社内外の方に役立つよう「ウェブアクセシビリティハンドブック」と「アクセシビリティ連載ブログ」を公開しています。日本語で考え方もまとめていますので、ぜひ参考にしてみてください。ウェブアクセシビリティハンドブックブログ:アクセシビリティ連載おわりに「動きのあるUI」をアクセシブルにすることは、単に基準に適合させるためだけではなく、誰にとっても「自然に使いやすい」体験につながります。APGを基盤としつつ、私たちのハンドブックやブログも実装の一助になれば幸いです。
スタッフブログ