この記事は最終更新日から1年以上経過しています。
ウェブアクセシビリティのガイドラインと規格
公開日:
更新日:
こんにちはkanappleです!
前回の記事でウェブアクセシビリティの必要性が理解できたので、今回はガイドラインを規格についてです。
ウェブアクセシビリティには主に3つのガイドラインがあります。
WCAG(Web Content Accessibility Guidelines)
ウェブ技術の標準化を行う世界的な非営利団体W3C(World Wide Web Consortium)が定める規格で、世界で標準に使われいるガイドラインです。
現在はWCAG2.2というバージョンが勧告されています。
ISO/IEC 40500:2012
国際標準化機構(ISO)と国際電気標準会議(IEC)が定める国際規格で、WACAG2.0をそのまま採用して発表されました。
この動きによっててWCAGを規格として使うことができるようになりました。
JIS X 8341-3
日本工業規格(JIS)が定める国内規格で、正式名称を「高齢者・障害者等配慮設計指針-情報通信における機器,ソフトウェア及びサービス-第3部:ウェブコンテンツ」といいます。
ウェブサイトだけではなく、ブラウザを使うアプリケーションやシステムにも関係しています。
「知覚可能」「操作可能」「理解可能」「堅牢(robust)」の4つの原則と、ウェブアクセシビリティを向上させるための12のガイドラインで構成されおり、さらに、ガイドラインを細分化した61の達成基準があります。
達成基準は適合レベル(A・AA・AAA)が定義されていて、これについては今後の記事で詳しく書いていこうと思います。
JIS X 8341-3はWCAG 2.0と一致規格のため、WCAG 2.0のチェックツールを使うことができたり、海外の情報が豊富なことが特徴ですが、注意点もあります。
1点目はJIS X 8341-3:2016は単体で完結していない点。
JIS X 8341-3:2016には達成基準の解説や達成方法は含まれていない為、ウェブアクセシビリティがJIS X 8341-3:2016に準拠していることを確認するためには、必ずWCAG 2.0の達成基準と達成方法を理解する必要があります。
2点目は、独自の対応度の表記を使う点です。
JIS X 8341-3:2016は、JIS規格に従った試験と適合性の表明をすることで適合要件を満たすことができますが、それを行うためには第三者に試験を行ってもらったり、「供給者適合宣言書」といわれる書類を作成したりする必要があります。
しかしウェブサイトや情報システムは日々改修と更新が行われいる為、その都度試験を行う必要があり現実的ではありません。
そこでJIS X 8341-3:2016 の「附属書JB(参考) 試験方法」とあわせて、ウェブアクセシビリティ基盤委員会(WAIC)が作成した「試験実施ガイドライン」を参照することで妥当な工数で試験を行うことができます。
日本でウェブアクセシビリティ対応の証明をするには一般的にこのJIS X 8341-3:2016を基準に対応します。
まとめ
・WCAGとは、W3Cが作成したウェブアクセシビリティのガイドライン(最新はWCAG2.2)
・ISO/IEC40500:2012とは、WCAG2.0をそのまま採用した国際規格
・JISX 8341-3:2016とは、日本工業規格が定める国内規格
・WCAG2.0とISO/IEC40500:2012とJISX8341-3:2016は同じ内容である
・ウェブアクセシビリティの対応の証明は、JIS X 8341-3:2016を基準に対応する
・JIS X 8341-3:2016の試験は「附属書JB(参考) 試験方法」と合わせてウェブアクセシビリティ基盤委員会(WAIC)が作成した「試験実施ガイドライン」を参照して行うとよい
次回はウェブアクセシビリティ対応の証明方法について書きます。
関連記事
この記事のハッシュタグ #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を基盤としつつ、私たちのハンドブックやブログも実装の一助になれば幸いです。
スタッフブログ