この記事は最終更新日から1年以上経過しています。
【導入手順⑤】ウェブアクセシビリティ試験結果を公開する
公開日:
更新日:
こんにちはkanappleです。
ウェブアクセシビリティ導入の手順、前回の続きになります。
1. ウェブアクセシビリティ方針を決める
・目標する適合レベルを決める
・達成期限、担当部署を決める
2.ウェブアクセシビリティ方針を公開する
3.ウェブアクセシビリティ方針に基づいたウェブコンテンツ制作
・既存のサイトに導入する場合は現状を調査し対応していく
4.ウェブアクセシビリティの試験を行う
5.ウェブアクセシビリティ試験結果を公開する
今回の記事は「5.ウェブアクセシビリティ試験結果を公開する」です。
5.ウェブアクセシビリティ試験結果を公開する
達成基準チェックリストの結果を集計し、対応度を判定します。
対応の表記は「準拠」「一部準拠」「配慮」です。
全てのページで全ての達成基準に適合していれば「準拠」、どれか1つでも達成基準に適合していない場合は「一部準拠」となります。
例えば「レベルAAAに一部準拠」と表記する場合は、レベルAAに準拠していること、「レベルAAに一部準拠」と表記する場合は、レベルAに準拠が前提となります。
配慮は「準拠」「一部準拠」に至らない場合の対応度を示す際に用いる表記です。
ウェブコンテンツがJIS X 8341-3:2016を使用して制作されたことを示すために用いますが、試験の実施や結果は問いません。
目標とした適合レベルや参照した達成基準の一覧を表記します。
試験結果の表示
試験結果をまとめたら、ウェブサイトやマニュアルに公開します。
具体的には以下のようにの表記します。
ウェブアクセシビリティ試験結果
JIS X 8341-3:2016に基づいた試験を実施し、その結果を公表します。
本検証結果における「準拠」という対応度の表記は、情報通信アクセス協議会ウェブアクセシビリティ基盤委員会「ウェブコンテンツのJIS X 8341-3:2016 対応度表記ガイドライン – 2021年4月版」で定められた表記による。( https://waic.jp/docs/jis2016/compliance-guidelines/202104/ )
| 表明日 | 令和6年6月10日 |
|---|---|
| 規格の規格番号及び改正年 | JIS X 8341-3:2016 |
| 満たしている適合レベル | レベルAAに一部準拠 |
| 対象となるウェブページに関する簡潔な説明 | 株式会社○○○のウェブサイト(https://xxx.jp)以下の全てのページ |
| 依存したウェブコンテンツ技術のリスト | HTML、CSS、JavaScript、PDF |
| 試験に使用したチェックツール | Nu Html Checker、miChecker、axe DevTools |
| コンテンツを検証するのに用いたOS、ユーザーエージェント、支援技術 | Windows 10 / Google Chrome / NVDA、 Windows10 / Adobe Acrobat Reader /NVDA、 iOS17.4 / Safari / VoiceOver |
| 試験対象のウェブページを選択した方法 | ランダムサンプリングによって30ページ(ウェブページ:20ページ、PDF:10ファイル)、ウェブページ一式を代表するウェブページとして10ページおよびPDF1ファイルを選択 |
| 試験を行ったウェブページ | トップページ(https://xxx.jp)、会社概要(https://xxx.jp/xxx)・・・ |
| 達成基準チェックリスト | 達成基準チェックリスト(達成基準チェックリストを公開する) |
| 試験実施期間 | 2024年5月1日〜5月31日 |
| アクセシビリティを向上するために達成基準以上に追加で施した措置 | 2.4.8 現在位置の達成基準に関する措置として、パンくずリストを提供 |
| 今後の対応方針 | 一部ページにおいてバナーのコントラスト比を満たしていませんでした(1.4.3)、今後ページの改修時に改善に取り組んでまいります。 |
このような試験結果を作成したウェブアクセシビリティ方針と一緒に公開します。
目標とした達成基準を満たせていなくてもそのまま公開することが大切です。
情報システムやウェブサイトのウェブアクセシビリティは、コンテンツや機能が増えれば増えるだけ達成基準を満たすことが難しくなります。
また、情報システムもウェブサイトも常に更新し続けるものなので、試験結果が悪くなる場合もあります。
現状を隠さず公開し、改修する計画を立て、試験と改善を繰り返すことでウェブアクセシビリティのレベルを向上させることができます。
まとめ
・ウェブアクセシビリティの試験結果は、目標に達していいない場合でも現状をそのまま公開する
・検証や試験は継続的に行い、その都度問題点や対応について考える
・達成できていないものについては、今後の対応予定を公開し、対応度が向上していくよう努める
関連記事
この記事のハッシュタグ #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を基盤としつつ、私たちのハンドブックやブログも実装の一助になれば幸いです。
スタッフブログ