この記事は最終更新日から1年以上経過しています。
ウェブアクセシビリティ対応の証明
公開日：
更新日：
こんにちは！kanappleです。
今回は、前回の記事で紹介したウェブアクセシビリティの国内規格である「JIS X 8341-3:2016」の対応の証明についてです。
JIS X 8341-3:2016は日本工業規格（JIS）が定める国内規格ですが、JISマーク表示制度の対象規格ではない為、証明としてJISマークを付けることはできません。
そこで、JISマークの代わりに証明する方法として「供給者適合宣言を作成する」または「ウェブアクセシビリティ基盤委員会のガイドラインの基準を満たす」があります。
前回の記事で書いた通り、供給者適合宣言を作成して証明するのは対応が困難な場合が多い為、ここではウェブアクセシビリティ基盤委員会（WAIC）が作成した「ウェブコンテンツのJIS X 8341-3:2016 対応度表記ガイドライン」を使用した証明について書きます。
JIS X 8341-3:2016の達成基準
JIS X 8341-3:2016達成には基準が定められており、レベルA、レベルAA、レベルAAAという3つの適合レベルがあります。
・レベル A （25の達成基準）：サイトのアクセシビリティ確保に最低限必要なレベル
・レベルAA（13の達成基準）：推奨されている理想的なレベル
・レベルAAA（23の達成基準）：サイトのアクセシビリティが非常に高いレベル。
A→AA→AAA の順により高いレベルとなり、全部で61の達成基準があります。
国や地方公共団体はAA、民間企業はA〜AAを目指すことが推奨されています。
JIS X 8341-3:2016の対応度
JIS X 8341-3:2016の対応度として、前述した基準をどれだけ達成しているかを表記する方法が3つあります。
これはJIS規格に基づいた表記方法ではなく、WAICが独自に定義した表記方法です。
準拠
試験を行って達成基準のすべてを満たしている場合に使えます。
公開する時には試験結果も合わせて公開します。
一部準拠
達成基準の一部を満たしている場合に使えます。
一部準拠の場合は追加で今後の対応方針を記載します
配慮
試験の実施や結果は問いません。
配慮の場合は、目標とした適合レベルか参照した達成基準一覧を記載します。
以上の適合レベルと対応度を使い、ウェブアクセシビリティへの対応状況を証明することができます。
目指したいのは「レベルAAに準拠」ですが、いきなり達成するのは難しいです。
まずは「レベルAに準拠」をクリアすることから始めましょう。
まとめ
・JIS X 8341-3:2016対応を証明としてJISマークを付けることはできないため、ウェブアクセシビリティ基盤委員会（WAIC）が作成した「ウェブコンテンツのJIS X 8341-3:2016 対応度表記ガイドライン」を使用して証明する
・JIS X 8341-3:2016にはレベルA、レベルAA、レベルAAAの達成基準が定められており、レベルAAに適合させることが推奨されている
・JIS X 8341-3:2016の対応度として、準拠、一部準拠、配慮の3つ表記がある
・レベルAAに準拠を目標としウェブサイトを制作しましょう
関連記事
この記事のハッシュタグ #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を基盤としつつ、私たちのハンドブックやブログも実装の一助になれば幸いです。
スタッフブログ
