ウェブページを企画・設計・制作・保守する方達のアクセシビリティ配慮を助け、共に考えるサイトです
2025年11月、当社の検査部メンバーが、アクセシビリティの国際資格であるCPACC試験を受験し、2026年1月に合格しました。
今回公開する報告書は、その受験経験をもとに、CPACC試験の概要、受験上の配慮、学習方法、実際に役立った試験対策などをまとめたものです。試験に関する情報がまだ多いとはいえない中で、これから受験を考える方にとって、実践的な手がかりになる内容だと思います。
アクセシビリティに関わる仕事をする私たちにとって、こうした学びを一人の経験にとどめず、社会に共有していくことには大きな意味があります。当社のメンバーが、自身の経験を丁寧に整理し、次に続く人のための報告書としてまとめてくれたことを、とても嬉しく思っています。
日本からも、CPACCに挑戦する人がもっと増えていくことを願い、この報告書を紹介します。
CPACC試験受験報告書_2026-6-24.pdf（PDF/1.1M）
弊社をご指名いただく形でお仕事をいただくことがあります。毎年継続してご依頼いただいているから、ということもあると思いますが、どなたかから紹介を受けてお問い合わせくださるお客様も少なくありません。
もちろん、当社の指摘が「重箱の隅をつつくようだ」、あるいは「少し過剰ではないか」と感じられて、次からは声をかけていただけなくなるお客様もいらっしゃるようです。それでも、繰り返しご相談くださるお客様の中には、単に規格に対応するためではなく、純粋にアクセシビリティを高めたいと考えてくださっている方がいらっしゃいます。私たちにとって、それは何より嬉しいことです。
そうしたお客様には、完璧を目指すことだけにエネルギーを使うよりも、継続して取り組むことが大切だとお伝えするようにしています。制作会社様であれば、クライアント様にどのように説明すればご理解いただきやすいか。企業や官公庁のお客様であれば、組織の中でどのように説明し、関係者を巻き込んでいけばよいか。そうしたことも、できる限り一緒に考えるようにしています。
なぜなら、アクセシビリティとは、一度の改修で終わる「ゴール」ではなく、サイトを運用し続ける限り続いていく「プロセス」だからです。最初から完璧な100点満点を目指して息切れしてしまうよりも、まずはできるところから始める。そして、それを50点、60点と維持し、少しずつアップデートしていく。その方が、結果として多くの人に長く使われるサイトに育っていくのだと思います。
当社の指摘が、ときに「重箱の隅をつつくよう」に見えてしまうのも、実はこの「運用フェーズで崩れないための頑丈な土台」を、お客様と一緒に作りたいという思いがあるからです。規格を満たすためのチェックリストを消化して終わりなしたくないのです。小さな綻びがやがて大きな綻びへと変わる様子は何度も見ています。
私たちはこれからも、お客様が無理なくアクセシビリティを継続できるよう、実践的なノウハウと熱量をもって伴走していきたいと考えています。
「適合」の表示より大切にしたいこと
ウェブアクセシビリティの検査証明書については、「それにどのような意味があるのか」と問われることがあります。
たしかに、ウェブアクセシビリティ試験は、実施した時点での状況を確認するものであり、将来までを含めた万能の保証ではありません。証明書が絶対的な「お墨付き」のように受け取られるとすれば、それは適切ではないでしょう。
しかし私たちは、それでもなお、検査証明書には果たすべき役割があると考えています。
それは、単に結果を飾るためではなく、ウェブアクセシビリティに向き合い、きちんと確認し、その状況を社会に対して示そうとする姿勢を形にすることです。
検査証明書は、ある時点で、ある対象に対して、一定の方法で確認を行ったことを示す文書です。
公開後の更新や運用の変化によって、アクセシビリティの状況は変わり得ます。したがって、証明書そのものが将来にわたる品質保証になるわけではありません。
私たちも、証明書を過大に語るべきではないと考えています。
証明書があるからそれで十分、ということではありません。
ウェブアクセシビリティは、本来、その時々の状況を見つめ、必要な改善を重ねながら支えていくものだからです。
それでも、証明書には意味があると私たちは考えています。
その意味は、「適合」という文字を並べることではなく、ウェブアクセシビリティ対応に取り組み、第三者の立場で状況確認を行い、その結果を示していることにあります。
私たちは2014年よりJAB認定検査機関として、アクセシビリティ検査証明書を発行してきました。
だからこそ、証明書は結果を飾るためのものではなく、検査を行った事実と、その背景にある体制や手順を示すものだと考えています。
言い換えれば、証明書の価値は、完璧さを演出することではなく、きちんと確認したことを明らかにするところにあります。それは、ウェブアクセシビリティへの取り組みを、曖昧な印象ではなく、確かな行動として示すための一つの手段です。
お客様の中には、検査証明書の中に「適合」という文字が並ぶことを期待される方もおられます。
もちろん、適合していることは望ましいことです。
しかし私たちは、ウェブアクセシビリティにおいて本当に重要なのは、適合という表示そのものよりも、現在位置を把握し、その状況に向き合い、改善を継続するためのプロセスと体制だと考えています。
そのため、不適合の項目が残っていたとしても、それだけで取り組みの価値が失われるわけではありません。むしろ、不適合を把握したうえで対応を放棄せず、改善に向けて進んでいることを示すことにこそ、意味があります。私たちは、その姿勢こそが、ウェブアクセシビリティに本気で取り組んでいることの表れだと考えています。
この考え方は、私たちが公表している「Webアクセシビリティ指数・プログレスレポート 2025年」にも通じています。私たちは、アクセシビリティを「適合して終わり」のものではなく、現在位置を確認しながら継続的に改善していく取り組みだと考えています。
検査証明書もまた、その継続の中に位置づけられるものです。
適合という言葉だけを追うのではなく、課題を把握し、向き合い、改善を重ね、その過程をきちんと示していくこと。
私たちはこれからも、そうした営みを大切にしていきたいと考えています。
総務省「みんなのアクセシビリティ評価ツール：miChecker（エムアイチェッカー）」のVer.3.0公開から早2ヶ月が経とうとしています。皆様、もうお使いでしょうか？
総務省｜みんなのアクセシビリティ評価ツール：miChecker (エムアイチェッカー)Ver.3.0
今後は令和5年度中を新バージョンへの移行期間とし、旧バージョンについては公開終了を予定しているとのことです。
初めてお使いの方、旧バージョンからの乗り換えに重い腰を上げた方、ぜひ一緒にmiChecker Ver.3.0を導入してみましょう。（所要時間：15分程度）
「問題の可能性大」として検出される項目です。
DOCTYPE宣言がない場合に問題が指摘されます。
現在、DOCTYPE宣言がなくて誤動作するスクリーンリーダーは無いかもしれません。しかし、バリデータが誤った検証結果を返もしてしまったり、文書が仕様に準拠するかどうか判定できない可能性がありますので、対応するようにしてください。
公開識別子が知られたものでない場合は、「問題の可能性大」ではなく、「要判断箇所」として『文書のDOCTYPE宣言で指定された公開識別子はよく知られたものではないようです。そのため、バリデータが誤った検証結果を返す可能性があります。また、文書が仕様に準拠するかどうか判定できない可能性があります。』が指摘がされます。
DOCTYPE宣言を追加してください。
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
「問題あり」として検出される項目です。
同じid値を持つものが2つ以上ある場合に問題が指摘されます。
idは、仕様上では1ページの中でユニークなものであることが求められています。同じ値を持つ物を複数設定してはいけません。広く利用されている汎用的なブラウザでは、恐らく、何も問題は起きません。そのため、製作者もidに重複があるに気がつかないことが多くあります。しかし、スクリーンリーダーなど、利用者数が決して多くない支援技術などでは、ちょっとした文法エラーでもうまく処理できずに、おかしな動作をしてしまう可能性があります。
PC用とスマートフォン用のコード、例えば検索用のコードなどを1つのページに入れてある場合に、同じidが使われていることがよくあります。動作に問題はないとしても、支援技術が混乱しないように、異なるidを設定してください。
アクセシビリティのエラーにはなりませんが、idの先頭を数字にすることは正しくありません。必ず、先頭文字は英字にしてください。
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
::after疑似要素を用いてコンテンツが挿入されている場合「問題の可能性大」として指摘される項目です。
実際、これが問題であることは多く、検出された場合は注意して確認し、必要に応じて対処する必要があります。
例えば次のように指定されていたとします。
p.good:before { content: "大正解: " }
p.bad:before { content: "不正解: " }
これを次のようにして用いたとします。
コードの例 <p class="good"> <q>::before疑似要素を使って追加されたコンテンツはスクリーンリーダーの読み上げ対象にならない場合があるので注意が必要である。</q> </p> <p class="bad"> <q>::before疑似要素を使って追加されたコンテンツはスクリーンリーダーの読み上げ対象になるので、何の配慮もなく使用して構わない。</q> </p>
これで、それぞれの文章の前に「大正解:」と「不正解:」が表示されますが、スクリーンリーダーはこれを読み上げ無い可能性があります。
この手法によるコンテンツの追加は大変便利ですが、スクリーンリーダーによっては対応していないと考えて下さい。つまり、期待しているような表示はされず、音声化されることもありません。
残念ながら根本的な修正方法はありません。これを重要な項目には利用しないことしかできません。
例えば、隠しテキストで対処する方法が考えられますが、それであれば、疑似要素は使わずに普通に表示すれば良いことになります。よって、疑似要素は、視覚的に見て操作しているに向けて、補助的なものとして何か情報を提供するときに使用は限るようにしてください。あるいは、装飾的なものに限ってください。
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
::before疑似要素を用いてコンテンツが挿入されている場合「問題の可能性大」として指摘される項目です。
実際、これが問題であることは多く、検出された場合は注意して確認し、必要に応じて対処する必要があります。
例えば次のように指定されていたとします。
p.good:before { content: "大正解: " }
p.bad:before { content: "不正解: " }
これを次のようにして用いたとします。
コードの例 <p class="good"> <q>::before疑似要素を使って追加されたコンテンツはスクリーンリーダーの読み上げ対象にならない場合があるので注意が必要である。</q> </p> <p class="bad"> <q>::before疑似要素を使って追加されたコンテンツはスクリーンリーダーの読み上げ対象になるので、何の配慮もなく使用して構わない。</q> </p>
これで、それぞれの文章の前に「大正解:」と「不正解:」が表示されますが、スクリーンリーダーはこれを読み上げ無い可能性があります。
この手法によるコンテンツの追加は大変便利ですが、スクリーンリーダーによっては対応していないと考えて下さい。つまり、期待しているような表示はされず、音声化されることもありません。
残念ながら根本的な修正方法はありません。これを重要な項目には利用しないことしかできません。
例えば、隠しテキストで対処する方法が考えられますが、それであれば、疑似要素は使わずに普通に表示すれば良いことになります。よって、疑似要素は、視覚的に見て操作しているに向けて、補助的なものとして何か情報を提供するときに使用は限るようにしてください。あるいは、装飾的なものに限ってください。
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
「問題あり」として検出される項目です。
a要素の開始タグと終了タグの間に何もテキストの情報が提供されていない場合に、この項目が検出されます。
よく見かけるのはリンク画像を提供し、その代替テキストが空になっている場合です。あるいは、スタイルシートでリンクと分かるような画像を表示させている場合なども該当します。
<!-- リンク画像に代替テキストが設定されていないケース --> <a href="/news/"><img src="newsicon.png" alt="" /></a> <!-- スタイルシートでアイコンを表示しているケース --> <a href="/news/" class="newsicon"></a>
この問題はスクリーンリーダーの利用者にとっては致命的です。もし検出されていたら、いま直ぐに修正すべきです。目で見て操作している人の状況に例えるならば、肝心のリンクが黒塗りされているか、切り取られて存在しない状態になっているのと同じ状態です。利用者には大変失礼であり、最悪の状態にあると思ってください。
しかし、残念ながらこの問題が検出されるウェブページは少なくありません。リンクが失われることは大きな問題になりますから、このような場合、スクリーンリーダーは読み上げるべき情報がないことを伝えたり、あるいは飛び先として指定されているURLを読み上げるなど工夫します。あるいは、そのページのタイトルを読み上げるような場合もあります。
URLなど読み上げて、たまたま内容が理解できれば良いですが、大抵はそのような情報は製作者の為のものであって、利用者に提供するものではないため、利用者においてはますます混乱してしまいます。
リンク画像の場合は画像にしっかりとalt属性を入れれば問題は解決します。
cssで画像を表示している場合は少し対処は難しくなります。たまに、cssのcontentプロパティに情報を入れている場合がありますが、それでは不十分です。実は、スクリーンリーダーによってはcontentプロパティを読み上げてくれたりもしますが、読み上げない場合もありますし、htmlの定義から考えれば、cssにそのような役割をさせるべきではありません。このような場合は、非表示のテキストを追加するのがもっとも容易です。
<!-- リンク画像に代替テキストが設定されていないケース --> <a href="/news/"><img src="newsicon.png" alt="ニュース" /></a> <!-- スタイルシートでアイコンを表示しているケース --> <a href="/news/" class="newsicon"><span class="visually-hidden">ニュース</sapn></a>
なお、a要素にtitle属性を用いる方法では適合にはなりません。title属性は補足情報を提供するものであって、主となる情報提供に用いることはできません。
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
「問題の可能性大」として検出される項目です。しかし、実際にはほとんどの場合が「問題あり」になります。
ページ内リンクにおいて、a要素の開始タグと終了タグの間に何もテキストの情報が提供されておらず、a要素にtitle属性が使用されている場合に、この項目が検出されます。
よく見かけるのはリンク画像を提供し、その代替テキストが空になっている場合です。あるいは、スタイルシートでリンクと分かるような画像を表示させている場合なども該当します。
<!-- リンク画像に代替テキストが設定されていないケース --> <a href="#news" title="ニュース一覧"><img src="newsicon.png" alt="" /></a> <!-- スタイルシートでアイコンを表示しているケース --> <a href="#news" class="newsicon" title="ニュース一覧"></a>
この問題はスクリーンリーダーの利用者にとっては致命的です。もし検出されていたら、いま直ぐに修正すべきです。title属性はアクセシビリティのための対策とはなりません。
目で見て操作している人にとっては、ツールチップが現れて便利かもしれません。（この場合でも、リンクの目的を示すようなものをそこに表示させているわけではなく、補助的な情報であることに注意が必要です） しかし、スクリーンリーダーで利用している人にとっては、依然、肝心のリンクが黒塗りされているか、切り取られて存在しない状態になっているようなものです。利用者には大変失礼であり、最悪の状態にあると思ってください。
リンクが失われることは大きな問題になりますから、このような場合、スクリーンリーダーは読み上げるべき情報がないことを伝えたり、あるいは飛び先として指定されているURLを読み上げるなど工夫します。あるいは、そのページのタイトルを読み上げるような場合もあります。
URLなど読み上げて、たまたま内容が理解できれば良いですが、大抵はそのような情報は製作者の為のものであって、利用者に提供するものではないため、利用者においてはますます混乱してしまいます。
リンク画像の場合は画像にしっかりとalt属性を入れれば問題は解決します。title属性を消す必要はありません。ただし、alt属性とtitle属性を同一にすることはおかしなことです。title属性には、例え、それが誰にも伝わらなかったとしても、問題の無い補足的な情報を入れるに留めてください。
cssで画像を表示している場合は少し対処は難しくなります。たまに、cssのcontentプロパティに情報を入れている場合がありますが、それでは不十分です。実は、スクリーンリーダーによってはcontentプロパティを読み上げてくれたりもしますが、読み上げない場合もありますし、htmlの定義から考えれば、cssにそのような役割をさせるべきではありません。このような場合は、非表示のテキストを追加するのがもっとも容易です。
<!-- リンク画像に代替テキストが設定されていないケース --> <a href="#news" title="ニュース最新情報"><img src="newsicon.png" alt="ニュース" /></a> <!-- スタイルシートでアイコンを表示しているケース --> <a href="#news" class="newsicon" title="ニュース最新情報"><span class="visually-hidden">ニュース</sapn></a>
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)