この記事は最終更新日から1年以上経過しています。
【導入手順①②】ウェブアクセシビリティ方針の策定と公開
公開日:
更新日:
こんにちはkanappleです!
前回までにウェブアクセシビリティの規格や対応の証明について書いたので、これから実際どのようにウェブアクセシビリティを導入していくかについて具体的に書いていこうと思います。
ウェブアクセシビリティを導入するには段階を踏んで対応していく必要があり、以下の流れが推奨されています。
1. ウェブアクセシビリティ方針を決める
・目標する適合レベルを決める
・達成期限、担当部署を決める
2.ウェブアクセシビリティ方針を公開する
3.アクセシビリティ方針に基づいたウェブコンテンツ制作
・既存のサイトに導入する場合は現状を調査し対応していく
4.ウェブアクセシビリティの試験を行う
5.ウェブアクセシビリティ試験結果を公開する
今回の記事は「1.ウェブアクセシビリティ方針を決める」と「2.ウェブアクセシビリティ方針を公開する」についてです。
1. ウェブアクセシビリティ方針を決める
JIS X 8341-3の対応度を表記するためにはウェブアクセシビリティ方針を作成しなければなりません。
・対象範囲を決める
まず、ウェブサイトのどこを対象範囲にするかを決めます。ドメイン名かサブドメイン名を単位とするのが一般的です。
ウェブサイトの一部を対象から外す場合には、対象外となるページのURLやサブドメイン等を示した一覧を掲載するなどが必要です。
・目標とする適合レベルを決める
三つの適合レベル(レベルA、レベルAA、レベルAAA)のうち、どの適合レベルを目標を定めます。
JIS X 8341-3:2016への適合の表明が難しい場合は、「準拠・一部準拠・配慮」のどの対応度を目標とするかを決めます。
前回の記事でも書きましたが、レベルAAに準拠させることを最終目標としましょう。
・達成期限、担当部署を決める
目標を達成する期限や、担当部署、問い合わせ先を決めます。
また、目標とする対応度が一部準拠の場合、満たすことのでいない達成基準、追加で目標とする達成基準を決めます。
こちらはJIS X 8341-3:2016の要件ではありませんが、明記するとよいでしょう。
2.ウェブアクセシビリティ方針を公開する
決定したウェブアクセシビリティ方針をサイト上やマニュアルで公開します。
具体的な書き方は以下になります。
ウェブアクセシビリティ方針
株式会社○○○のウェブサイトでは、アクセシビリティの確保・維持・向上を実現するため「JIS X 8341-3:2016 高齢者・障害者等配慮設計指針-情報通信における機器,ソフトウェア及びサービス-第3部:ウェブコンテンツ」への対応に取り組んでいます。
・対象範囲
株式会社○○○のウェブサイト(https://xxx.jp)全体
・目標とする適合レベル及び対応度
JIS X 8341-3:2016の適合レベルAAに準拠します。
本方針における「準拠」という対応度の表記は、情報通信アクセス協議会ウェブアクセシビリティ基盤委員会「ウェブコンテンツのJIS X 8341-3:2016 対応度表記ガイドライン – 2021年4月版」で定められた表記によるものです。
詳しくは「ウェブコンテンツの JIS X 8341-3:2016 対応度表記ガイドライン(外部サイト)」をご覧ください。
・目標を達成する期限
2024年6月30日
・担当部署
○○チーム
ウェブアクセシビリティ対応は原則としてウェブページ一式全体を対象としていますが、対応や試験にはとても時間がかかります。
そこで、対象とする範囲を段階的に広げていく場合や、現状対象外のページを作る場合はその旨を明記します。
例1:対象範囲を段階的に広げていく場合
・対象範囲
株式会社○○○のウェブサイト(https://xxx.jp)
ただし、2024年度は■■コーナー(https://xxx.jp/hoge/ 以下)のみを対象とし、それ以外のウェブページは2025年度以降の対応とします。
例2:現時点では特定のディレクトリを対象外とする場合
・対象範囲
株式会社○○○のウェブサイト(https://xxx.jp)
ただし、2024年度は■■コーナー(https://xxx.jp/hoge/ 以下)を対象から除外し、■■コーナーのウェブページは2025年度以降の対応とします。
例3:新規ページのみを対象とする場合
・対象範囲
株式会社○○○のウェブサイト(https://xxx.jp)
ただし、ウェブページに明記した公開日または最終更新日が2024年5月1日以降の日付であるウェブページのみを対象とします。それ以外のウェブページは、2025年度以降の対応とします。
まとめ
・ウェブアクセシビリティを導入するには、まずウェブアクセシビリティ方針の策定が必要
・ウェブアクセシビリティ導入にはそれなりの期間がかかる為、段階的に対応しても良い。その場合はその旨を方針に明記する。
・作成したウェブアクセシビリティ方針は、サイト上やマニュアルで公開する
次回は「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を基盤としつつ、私たちのハンドブックやブログも実装の一助になれば幸いです。
スタッフブログ