WCAGとJIS X 8341-3:2016への弊社の見解と実施体制

Webサイトをつくるうえで、アクセシビリティへの対応はもはや当たり前の前提になっています。一方で、WCAGやJIS X 8341-3:2016という規格は、言葉だけが知られていて、中身が正確に理解されていない場面をよく見かけます。「JIS準拠」と書かれていても、それが何を指すのかが曖昧なまま使われていることも少なくありません。

本記事では、弊社がWCAGおよびJIS X 8341-3:2016をどう理解し、その理解をどのように実装と品質基準に落とし込んでいるのかを説明します。規格に対する見解、実装プロセス、そして社内の体制まで、順にお伝えします。

WCAGとJIS X 8341-3:2016の関係を整理します

ウェブアクセシビリティの議論では、WCAGとJIS X 8341-3:2016という二つの規格が並んで登場します。両者の関係を正確に理解していないと、話がかみ合わなくなります。最初にここを整理しておきます。

WCAGはW3Cが策定する国際的な達成基準

WCAGはWeb Content Accessibility Guidelinesの略で、ウェブ技術の国際標準化団体であるW3Cが策定しているウェブアクセシビリティのガイドラインです。2008年にWCAG 2.0が勧告され、その後WCAG 2.1（2018年）、WCAG 2.2（2023年）と改定が重ねられてきました。世界各国の法規制や調達基準において、WCAGは事実上の国際標準として参照されています。

JIS X 8341-3:2016はWCAG 2.0と一致した日本の規格

一方、日本国内では、JIS X 8341-3:2016という規格がウェブアクセシビリティの基準として定められています。この規格は、国際規格ISO/IEC 40500:2012、すなわちW3CのWCAG 2.0と一致した内容です。つまり、JIS X 8341-3:2016に準拠することは、WCAG 2.0に準拠することと実質的に同じ意味を持ちます。

WCAG 2.2が勧告された後も、JIS規格は2016年版のまま

ここでよく誤解されるのが、最新のWCAG 2.2に対応していれば自動的にJIS規格にも対応できる、という認識です。しかしJIS X 8341-3はWCAG 2.0に準拠して2016年に改定された後、WCAG 2.1やWCAG 2.2への追従改定はまだ行われていません。

つまり、「JIS X 8341-3:2016 適合レベルAA準拠」が求められる場合、対象となるのはWCAG 2.0レベルの達成基準であり、WCAG 2.2の追加基準は厳密には要求対象外です。ただし、より新しい達成基準にも対応しておく方が、運用フェーズで安心であることは言うまでもありません。

JIS X 8341-3の改正が、いま進んでいます

ただし、この「JISは2016年版のまま」という状況は、いままさに動いています。2025年9月、国際規格ISO/IEC 40500が改正され、WCAG 2.2と同じ内容になりました。これを受けて、JIS X 8341-3の原案作成団体であるウェブアクセシビリティ基盤委員会（WAIC）は、2025年10月に改正原案作成委員会を発足させました。改正JISは、ISO/IEC 40500:2025との一致規格、つまりWCAG 2.2と同等の内容とする方針で検討が進められていて、順調に進めば2026年中にも発行される見通しです。

総務省の「みんなの公共サイト運用ガイドライン（2024年版）」でも、この改正の見通しに触れたうえで、公的機関に対して準備を促しています。つまり、これから構築するサイトは、公開後にJIS改正を迎える可能性が高いということです。

弊社では、この改正動向を継続的に把握したうえで、実装方針に反映しています。具体的には、現行のJIS X 8341-3:2016 適合レベルAAを満たすことを基本に、改正後の基準となるWCAG 2.2の追加達成基準も見据えた実装を行います。この進め方であれば、構築したサイトが改正JISの発行を迎えても、手戻りを最小限に抑えられます。規格の節目をまたぐ時期だからこそ、目の前の基準と、その先の基準の両方を視野に入れた設計が大事だと考えています。

日本国内でJIS規格が基準として参照される理由

日本国内でウェブアクセシビリティの水準を示すときに参照されるのは、WCAGそのものではなくJIS X 8341-3:2016です。デジタル庁や総務省が公開しているガイドブックも、JIS X 8341-3:2016を基準として記述しています。案件によって求められる水準は異なりますが、基準として引かれるのはこのJISであることが一般的です。このため、弊社では国際標準であるWCAGの動向を継続的に見ながら、実装の基準としてはJIS X 8341-3:2016を中心に据えています。

適合レベルA・AA・AAAと「準拠」表記の正しい理解

続いて、その規格の中身についてお伝えします。WCAGおよびJIS X 8341-3:2016には、達成基準の難易度に応じて適合レベルA・AA・AAAという三段階があります。この三段階の意味と、どこまでを満たすべきなのかを押さえておくと、規格の理解が正確になります。

標準的に求められるのは適合レベルAA

適合レベルAは最低限満たすべき基準、AAはそれに加えて満たすべき標準的な基準、AAAはさらに高度な基準です。多くのガイドラインや調達では、適合レベルAAが基準として示されています。つまり、AだけでもAAAでもなく、AAを満たすことが標準的な要求になります。弊社が実装の目安にしているのも、この適合レベルAAです。

「準拠」と「対応」「配慮」は意味が異なる

ここで大事なのは、表記の正確さです。制作実績では「アクセシビリティに対応」「アクセシビリティに配慮」といった表現をよく見かけます。しかし、これらの言葉そのものには厳密な定義がありません。WAIC（ウェブアクセシビリティ基盤委員会）が公開している「JIS X 8341-3:2016 対応度表記ガイドライン」では、「準拠」「一部準拠」「配慮」という用語が区別されています。

「準拠」は、対象範囲のすべてのページが目標とした適合レベルの達成基準を満たし、試験を実施したうえで表記できるものです。「一部準拠」は、試験の結果、一部の達成基準を満たせていない場合に、今後の対応方針を示したうえで用いる表記です。「配慮」は、ウェブアクセシビリティ方針で目標とする適合レベルを示したうえで、その達成基準に沿って制作したことを示す表記で、試験を前提としません。

「対応しています」という曖昧な言葉と、試験を経た「準拠」とでは、裏付けの重みが変わってきます。弊社では、この対応度表記ガイドラインに沿って、案件の目的や求められる仕様に応じて、これらの表記を使い分けています。すべての案件を一律に「準拠」とするわけではありません。日頃からアクセシビリティに配慮した制作を基本としつつ、準拠が求められる案件では、試験を実施したうえで「準拠」と表記できる状態まで対応します。

AAAは全体で目指すものではなく、適用できる箇所で満たす

適合レベルAAAについても触れておきます。AAAはすべての達成基準を満たすことが現実的でない場合があるため、サイト全体での達成は想定されていません。WCAG自身も、すべてのコンテンツでAAAへの適合を求めることは推奨していません。大事なのは、AAAを全体目標に掲げることではなく、適用できる箇所を選んで個別に満たしていく姿勢です。弊社では、AAを土台にしながら、無理なく適用できるAAAの基準を案件ごとに見極めて取り入れています。

2024年4月の法改正の正確な理解

さて、ここからは法律の話に移ります。アクセシビリティを語るうえで、2024年4月の法改正は避けて通れません。ただ、この改正については誤解されやすいので、正確に整理してお伝えします。

義務化されたのは「合理的配慮の提供」

2024年4月1日、改正障害者差別解消法が施行され、これまで努力義務だった民間事業者による合理的配慮の提供が、法的な義務になりました。公的機関についてはすでに義務化されていたものが、民間事業者にも広がった形です。合理的配慮とは、障害のある方から配慮を求める意思の表明があった場合に、過重な負担にならない範囲でその障壁を取り除く対応を指します。

ウェブアクセシビリティが直接義務化されたわけではない

ここで理解いただきたいのは、この改正によってウェブアクセシビリティそのものが法的に義務化されたわけではない、という点です。改正に合わせて「義務化」という言葉が前面に出ることがありますが、法律が義務づけたのは合理的配慮の提供であって、ウェブサイトを特定の規格に準拠させること自体を直接命じる条文ではありません。

ウェブアクセシビリティの確保は、2016年の施行時から環境の整備として努力義務に位置づけられていて、この点は2024年の改正後も変わっていません。正直なところ、ここを曖昧にしたまま「義務化」だけを強調して、不安をあおる情報には、疑問を感じます。

それでも、求められる水準は上がっている

しかし、だからアクセシビリティに取り組まなくてよい、という話ではありません。内閣府の対応指針でも、アクセシビリティの確保は、合理的配慮を的確に行うための環境の整備として推奨されています。アクセシブルなサイトを用意しておくことは、個別の合理的配慮の負担を減らすことにもつながります。法律上の義務と、社会的に求められる実質的な水準は、分けて考える必要があります。後者は、改正を経て上がってきているという面があります。だからこそ弊社は、不安をあおる形ではなく、規格に基づいた対応をお客様に提供しています。

公開して終わりにしないために

続いて、サイトを公開したあとの話をお伝えします。アクセシビリティ対応は、公開した時点で完成するものではありません。ここでは、公開後に何が求められるのかを整理します。

公開時の試験だけでは足りない

よくあるのが、アクセシビリティ対応を「公開して終わり」と捉えてしまうケースです。しかし、サイトは公開後も日々更新されます。新しいページが追加され、資料が掲載され、お知らせが投稿されます。公開時にどれだけ整えても、運用のなかで基準が崩れていけば、準拠の状態は保てません。公開時の確認に加えて、運用フェーズでも継続的に品質を維持していくことが大事になってきます。

運用担当者が自走できる引き継ぎ

ここで大事になってくるのが、サイトを運用するお客様の担当者が、自分たちでアクセシビリティを維持できる状態を引き継ぐことです。日々の更新で代替テキストの付け方や見出しの構造が崩れてしまえば、せっかくの品質は続きません。担当者が更新作業のなかで迷わず参照できる運用ガイドラインを用意しておくことが、長く品質を保つための条件になります。

「準拠」と表記するための試験

もう一つ整理しておきたいのが、試験の位置づけです。「準拠」と表記するためには、決められた方法で試験を実施し、その結果を示す必要があります。JIS X 8341-3:2016には、附属書JB（参考）として試験方法が示されていて、WAICはこれを具体化した試験実施ガイドラインを公開しています。そこでは、試験の対象とするページの選び方や、ランダムに選ぶページを含めた目安の枚数、検証の手順などが定められています。つまり、「準拠」という言葉は、決まった手続きを経て初めて使えるものです。実際のところ、ここまでの手続きを踏まえて「準拠」と表記している例ばかりではありません。

弊社のアクセシビリティ実装プロセス

さて、ここからは、こうした考え方を弊社が実際にどう実装に落とし込んでいるのかを説明します。企画から運用まで、各フェーズでの作業をお伝えします。

企画段階での要件定義

最初に行うのが、仕様や要件の読み込みと整理です。案件で求められる適合レベル、対象範囲、試験の要件を読み解いて、満たすべきアクセシビリティ要件を定義します。この段階で、達成基準ごとにどう実装するかをまとめたガイドラインを作成して、プロジェクトの土台にします。

デザインフェーズでの確認項目

デザインを進める段階では、視覚に関わる達成基準を確認します。文字色と背景色のコントラスト比が基準を満たしているか、フォーカスの状態が視認できるか、ボタンやリンクのタッチターゲットのサイズが操作しやすい大きさになっているかを、デザインデータの段階でチェックします。実装に入ってから手戻りが起きないよう、設計の早い段階で基準を織り込みます。

実装フェーズでのコーディング

実装フェーズでは、マークアップの品質を重視します。見出しやリスト、ランドマークを適切に使い分けたセマンティックなHTMLを基本にして、必要な箇所では適切なARIA属性を付与します。これらの実装はコーディング規約に組み込んでいるので、担当者によって品質が変わることがありません。レスポンシブデザインでも、画面幅を狭めた状態で操作性と読みやすさが保たれるよう配慮しています。

公開前の試験

実装が完了したら、公開前にJIS X 8341-3:2016 附属書JBに基づく試験を実施します。機械的に検出できる項目は、総務省が公開しているmiChecker（みんなのアクセシビリティ評価ツール）などで確認します。ただし、機械的なチェックで判定できるのは達成基準の一部です。キーボードだけで操作できるか、読み上げ環境で内容が正しく伝わるかといった項目は、人の目と手で検証します。機械と人の両面から確認することで、試験の精度を保っています。

運用フェーズの継続支援

公開後は、運用フェーズの支援に移ります。運用ガイドラインをお渡ししたうえで、サイトの更新に伴うアクセシビリティの維持を継続的に確認します。ページの追加やリニューアルのタイミングでは、改めて達成基準を満たしているかを点検し、必要な修正を反映します。

弊社の社内研修体制

続いて、この実装プロセスを支えている社内の体制についてお伝えします。規格の理解は、特定の担当者だけが持っていても、サイト全体の品質にはつながりません。関わる全員が同じ基準を共有して初めて、品質として安定します。

半期ごとの勉強会

弊社では、半期に一度、アクセシビリティに関する勉強会を実施しています。WCAGの改定動向、JIS規格をめぐる議論、各種ガイドラインの更新など、最新の情報を全員で共有する場です。規格は少しずつ動いていくので、知識を更新し続ける機会を定期的に設けています。

チェックリストの運用

属人化を防ぐために、アクセシビリティのチェックリストを整備して、すべての案件で運用しています。デザイン、実装、試験の各フェーズで確認すべき項目をリストにしているので、担当者が変わっても確認の抜け漏れが起きにくくなります。

コーディング規約への組み込み

セマンティックHTMLやARIA属性の扱いは、弊社のコーディング規約に組み込んでいます。アクセシビリティを「追加で気をつけること」ではなく、日々のコーディングの標準的な動作として根づかせています。

新しいメンバーへの研修と案件開始時の確認

新しく加わったメンバーや協力パートナーには、最初の研修でアクセシビリティの基本方針を共有します。また、案件を始める前に、その案件で満たすべきアクセシビリティ要件をチーム全員で確認します。こうした積み重ねを通じて、規格の理解は個人の知識にとどまらず、弊社の品質基準として全員で共有されています。

私たちのアクセシビリティに対する見解

さて、ここからは、私自身がアクセシビリティをどう捉えているのかをお話しします。

規格への適合は、目的ではありません。それは出発点だと私は考えています。適合レベルAAを満たすことは、お客様の先にいる利用者に当たり前に使えるサイトを届けるための条件であって、そこを満たして初めて、本当の意味での使いやすさを考えられます。

Webサイトには、年齢や障害の有無にかかわらず、あらゆる人がアクセスします。誰か一人でもその情報に届かないとすれば、それは届けたい相手に情報やサービスが届いていないことになります。「誰一人取り残さない」という言葉を、理念として掲げるだけでなく、実装に責任を負う制作会社の側が引き受けるべきだと私は思っています。

今までの経験から実感しているのは、アクセシビリティ対応が地味で、手間のかかる作業の積み重ねだということです。華やかさはありません。それでも、この一つひとつの作業が、画面の向こうにいる人が情報に届くかどうかを左右します。だからこそ私たちは、この作業を軽んじません。

弊社は「デジタルを通じて、すべての人を幸せに」という理念を掲げています。すべての人、という言葉のなかには、見えにくい方も、聞こえにくい方も、操作が難しい方も含まれます。アクセシビリティへの取り組みは、この理念を言葉だけで終わらせないための、具体的な手段だと考えています。

まとめ

本記事では、WCAGとJIS X 8341-3:2016の関係から、いま進んでいるJIS改正の動向、適合レベルと「準拠」表記の正しい理解、2024年の法改正の解釈、公開後の運用で大事になること、そして弊社の実装プロセスと社内の体制までをお伝えしてきました。

弊社では、ここで説明した規格の理解を社内で共有し、それを品質基準の土台として日々の制作に反映しています。アクセシビリティは、規格を満たすことと、それを運用のなかで維持し続けることの両方が問われます。規格そのものが新しくなろうとしているいまは、なおさらです。その両方に責任を持って取り組んでいます。

アクセシビリティ対応について、規格の読み解きや試験の進め方、運用体制の引き継ぎなど、気になることがありましたら、お気軽にご相談ください。弊社のお問い合わせ窓口より承ります。この記事が、参考になれば嬉しいです。