こんな課題はありませんか。
- アクセシビリティチェックをしたいが、何から確認すればよいか分からない。
- JIS X 8341-3:2016の資料はあるが、自社サイトにどう当てはめればよいか分からない。
- ツールだけで確認してよいのか、人の操作確認まで必要なのか判断しにくい。
あなたのサイトでアクセシビリティチェックを行う際に、何から着手し、どこまで確認し、どのように結果を公開すればよいかがわかります。
Web担当者の発注前のお困りごと解決します。
このページは、アクセシビリティチェックの進め方や結果公開の方法を知りたいWeb担当者向けの記事です。
()
公式サイトのウェブアクセシビリティ試験結果(2026年度)を2026年6月1日に公開しました。その時のアクセシビリティチェックの準備から対応、結果公開までの一連の業務をこのページで紹介します。

あなたのサイトでアクセシビリティチェックを行う際に、何から着手し、どこまで確認し、どのように結果を公開すればよいかがわかります。
アクセシビリティチェックでは、WAICの「JIS X 8341-3:2016 試験実施ガイドライン」を参照しました。このガイドラインは、JIS X 8341-3:2016の試験方法をどう理解し、実施するかが書かれています。
同ページでは、実装チェックリストについて「実情に合わせてカスタマイズ」を行った上で使用する必要があるとされています。
最初に、アクセシビリティチェックを行う対象ページを確定しました。今回はK2公式サイト全体を対象とし、重複ページや不要なURLを除外したうえで、最終的に82ページを確認対象としました。
対象ページはサイトマップや管理画面だけでなく、公開中のページを実際に巡回しながら確認しています。チェック対象を先に確定しておくことで、確認漏れを防ぎ、公開する試験結果との整合性も取りやすくなります。
WAICの「JIS X 8341-3:2016 試験実施ガイドライン」を参考に、今回の確認方法を決めました。
参考ページの「3.1.1 実装チェックリストの例」に実装チェックリストの例があるため、それをダウンロードしてカスタマイズしました。参考ページには確認者が実装者に相談しながら進める旨の記述がありますが、今回の試験では実装者と確認者が同一人物だったため、確認はスムーズに進められました。
まず、ダウンロードしたシートから明らかに該当しない項目を削除しました。また、HTML構造がテンプレート化されているページはあらかじめグルーピングし、対象グループの代表ページを確認した結果を、同じグループの他ページにも当てはめることで、チェック作業を効率化しました。
チェックの事前準備として、実装チェックリストのカスタマイズに加え、Lighthouse、axe DevTools、WAVE、Color Tester、NVDA などツールの選定及び、TAB操作、200%拡大表示、フォーム操作確認など実際の確認方法も確定させておきます。
今回のアクセシビリティ対応では、確認と改修を並行して進めました。確認で見つかった問題はその場で修正し、修正後に再度確認を行う流れです。実装者と確認者が同一人物だったため、問題の発見から原因調査、改修、再確認までを一連の作業として進めることができました。
また、ページごとの確認結果だけでなく、共通テンプレートや共通UIに関す修正内容は同じ構造を持つページへまとめて反映しています。
HTML構造は、アクセシビリティ対応の土台になる部分です。見た目に問題がなくても、HTML構造が適切でなければ支援技術が正しく情報を取得できません。
今回は見出し構造、画像の代替テキスト、フォーム部品のラベル設定、テーブルの見出し設定、リンクテキストなどを中心に確認しました。また、aria属性やrole属性についても、不要な指定や不適切な利用がないかを確認しています。
HTML構造に問題が見つかった場合は修正を行い、修正後に再度確認を実施しました。特に問題の出やすい、ページ内リンクやタブUIによる表示切替、レスポンシブデザインにおけるハンバーガーメニューの処理などは最初につぶしておくと後の確認がしやすくなります。
アクセシビリティチェックでは、Lighthouse、axe DevTools、Color Testerを使用し、機械的に確認できる項目を洗い出しました。LighthouseではAccessibility項目、axe DevToolsではWCAG観点の自動検出、Color Testerでは文字色と背景色のコントラスト比を確認しています。
ツールの結果はスコアだけで判断せず、指摘内容を確認したうえで、必要に応じてHTMLやCSSを修正しました。修正後は再度確認し、チェック表に結果を記録しました。今回使用したアクセシビリティチェックシートは、確認項目や記録方法の参考としてダウンロードできるようにしています。
ツールで確認できる項目に加え、実際の操作や表示状態も確認しました。
キーボード操作では、TABキーでページ内のリンクやフォーム部品へ順番に移動できるか、フォーカス位置が見えるか、メニューやボタンをキーボードだけで操作できるかを確認しました。表示確認では、200%拡大時のレイアウト崩れや、レスポンシブ表示でのメニュー操作、フォーム入力、ページ内リンクの挙動などを確認しています。問題が見つかった場合は修正し、再確認を行いました。
また、スクリーンリーダーによる読み上げを確認し、見出し構造やリンクテキスト、フォーム項目などが適切に読み上げられるかを確認しています。
実装者と確認者が別の場合は、チェック結果だけでなく、該当ページ、該当箇所、確認方法、想定される原因、修正後の再確認結果を共有できる形にしておく必要があります。
指摘内容だけを渡すと、実装側で原因を特定しにくくなるため、チェックシートには確認結果と修正メモをあわせて残しておくと進めやすくなります。
ウェブアクセシビリティ試験結果ページは、「確認概要」「対象URL一覧 / 確認結果」「確認方法」「備考」の4つで構成しました。確認概要で全体の前提を示し、対象URL一覧で確認対象と判定結果を掲載する形にしました。
確認方法には、Lighthouse、axe DevTools、Color Tester、HTML構造確認、TAB操作、200%拡大表示確認、フォーム確認など、実際に行った確認内容を掲載しました。
ダウンロード資料の備考には、ケイツー・インタラクティブが診断機関ではなく、Web制作・UI設計・実装の立場から確認を行ったことを記載しました。
ウェブアクセシビリティ試験結果ページに加え、対象URL一覧PDF、アクセシビリティチェックシート、チェックフローなどの資料も作成しました。確認結果とあわせて、確認対象や確認手順を参照できるようにしています。
今回は、K2公式サイト82ページで実施したアクセシビリティチェックをもとに、準備から確認、改修、結果公開までの流れを紹介しました。
アクセシビリティチェックはツールを実行するだけでは完了しません。対象ページの整理、確認方法の決定、HTML構造の確認、キーボード操作や読み上げ確認、修正後の再確認までを含めて進めることで、公開できる試験結果につながります。
これからアクセシビリティチェックを行う方の参考になれば幸いです。
アクセシビリティ対応の具体的な進め方は、アクセシビリティ対応をご覧ください。
※本情報はページ公開時のものです。情報は常に更新され掲載内容と異なる場合がございます。
Webサイトの更新、導線、解析、フォーム、アクセシビリティに加え、現在の制作会社や改善方針についてのセカンドオピニオンも月額で相談できます。
継続相談の目安:月額25,000円(税別)
※最低契約期間は3か月です。
更新は
SNSnoteでお知らせしています。