アクセシビリティ対応の案件で、義務なのはどこまでか

📘 この記事でわかること
- 合理的配慮が義務化されたことと、ウェブアクセシビリティが「環境の整備」として努力義務に位置づけられていること
- 規格の対象がウェブサイトだけでなく業務システムにも及ぶことと、規格票のチェックリストだけではチェック内容が不完全になること
- 適合を表明するために必要な第三者試験や書類の手続きと、案件に参画する前に確かめておきたい3段の順序
案件情報や要件定義の書類で、「アクセシビリティ対応」という言葉を見かける機会が増えました。背景には2024年4月の法改正があります。ただし、法律が義務づけた範囲と、案件でエンジニアが担う作業の範囲は同じではありません。この記事では、デジタル庁のガイドブックに沿って、義務の線引きから規格の対象、試験や表記の考え方までを順に整理します。読み進めることで、案件の要件定義書や見積もりの前提を確認するときの判断材料が見つかります。
1. 義務化されたのは「合理的配慮」です
合理的配慮の義務化と、環境整備としての努力義務
2024年4月1日に改正障害者差別解消法が施行され、事業者による障害者への合理的配慮の提供が義務となりました1。案件の要件定義書に「アクセシビリティ対応」と書かれていると、この対応そのものが法律で義務づけられたように読めますが、義務の対象は合理的配慮であり、ウェブアクセシビリティへの取り組みそのものではありません。
デジタル庁のガイドブックでは、ウェブアクセシビリティへの取り組みは、合理的配慮を提供するための環境の整備として努力義務が課せられていると示されています2。合理的配慮は、求めがあったときに個別に応じるものです。ウェブアクセシビリティへの取り組みは、その求めが生まれる前の段階で、誰にとっても使いやすい状態を整えておく仕事だと捉えると、両者のつながりが見えてきます。
義務と努力義務という言葉の違いは小さく見えて、案件で何を約束できるかを左右します。義務であれば対応の有無そのものが問われますが、努力義務は体制づくりの度合いが問われる仕事です。案件に参画する前にこの線を確かめておくと、この先の章で扱う規格や試験の位置づけも見失わずに済みます。
官公庁や自治体が発注する案件では、要件定義書のなかで法改正に触れられることがあります。そこに「対応が必要」とだけ書かれていても、義務として求められているのか、環境整備の一環として求められているのかを読み分ける姿勢が欠かせません。読み違えたまま見積もりや作業範囲を固めてしまうと、着手後にクライアントとの認識がずれる原因になります。まずはこの土台を確かめてから、次の章で規格の対象範囲を見ていきます。
図の作成:Remogu編集部。合理的配慮とウェブアクセシビリティへの取り組みの関係を整理したもので、統計データではありません
ここまでの整理をふまえると、次に確かめたいのは規格そのものが何を対象にしているかです。ウェブサイトだけの話だと思われがちですが、実際の対象はもう少し広がっています。
2. 規格の対象は、ウェブサイトだけではありません
JIS X 8341-3が指す範囲
ウェブアクセシビリティの規格として広く知られているのがJIS X 8341-3です。正式名称は「高齢者・障害者等配慮設計指針-情報通信における機器,ソフトウェア及びサービス-第3部:ウェブコンテンツ」で、ウェブサイトのための規格と捉えられることが多いのですが、ブラウザを使うアプリケーションやシステムにも関係します3。
この広がりは、案件を選ぶときの見え方にも関わります。一般公開されているサイトだけでなく、社内向けの業務システムやブラウザで動くアプリケーションの案件でも、規格が関係する場面に出会う可能性があります。担当する範囲がどこまで規格の対象に含まれるのかは、案件ごとにクライアントと確認しておきたい点です。
規格を読み解くときは、対象がウェブページの見た目に限られないという前提を持っておくと、確認すべき範囲を取りこぼしにくくなります。フロントエンドの実装だけでなく、社内向け管理画面や業務システムの一部を担当する案件でも、同じ視点で確認する場面が出てきます。担当範囲がどこまで規格と関わるのかは、契約前の打ち合わせで確認しておきたい項目のひとつです。
ウェブサイトの外側にも広がる対象
規格が対象とする範囲を、案件でよく出会う場面に置き換えると次のように整理できます。一般公開されているウェブサイトに加えて、ブラウザを使うアプリケーションやシステムも対象に含まれるため3、社内向けの仕組みだからといって規格と無関係だとは言い切れません。ガイドブックの実践プロセスには、スマートフォンのアクセシビリティを扱う章も置かれています8。担当する案件がどの場面に当てはまるのかを、参画前に確認しておくと、後工程での認識のずれを防ぎやすくなります。
| 対象 | 規格との関係 | 案件で確認する視点 |
|---|---|---|
| ウェブサイト | JIS X 8341-3の呼び名の中心的な対象です | 閲覧環境や操作方法の想定を確認します |
| ブラウザで動く業務システムやアプリケーション | 規格の対象に含まれます3 | 社内向けであっても対象から外れないと考えます |
| スマートフォン向けの画面 | ガイドブックの実践プロセスに専用の章があります8 | 対応の範囲を事前にクライアントと確認します |
対象がウェブページの外側にも広がっていることを踏まえると、規格票を一読しただけで対応範囲を判断するのは早計です。案件に参画する前に、対象となる画面や機能の一覧をクライアントと共有しておくと、後になって想定外の範囲が見つかる事態を避けやすくなります。次の章では、規格票だけでは不足する理由を見ていきます。
3. チェックリストを埋める仕事ではありません
規格票の附属書と、達成基準・テクニックの理解
JIS X 8341-3の規格票には附属書としてチェックリストが用意されているため、これを埋めれば対応が完了すると誤解されやすい面があります。実際には、規格票だけでウェブアクセシビリティを確認すると不完全な確認になり、達成基準とテクニックへの理解を合わせて持つ必要があります4。
案件の現場に置き換えると、チェック欄を埋める作業というより、なぜその項目が必要なのかを理解したうえで実装を選ぶ仕事に近くなります。同じ「対応済み」という表記でも、理解の深さによって中身の確かさは変わります。
達成基準やテクニックを理解する土台があると、実装の選択肢で迷ったときに立ち戻る基準ができます。反対に、チェックリストの通過だけを目的にすると、形式は整っていても実際の使いやすさが伴わない対応になりかねません。案件のなかでは、なぜその対応が必要なのかを説明できる状態を目指すことが、結果としてクライアントからの信頼にもつながります。
図の作成:Remogu編集部。規格票と、達成基準・テクニックの理解の関係を整理したもので、統計データではありません
この深さの違いが、次の章で扱う「準拠」という言葉の重みにつながります。表面のチェックだけで準拠を語ると、後から確認を求められたときに根拠が薄くなります。
アクセシビリティ対応に関わるフロントエンド案件を見る →
4. 「準拠」と表明するには何が必要か
第三者による試験と供給者適合宣言書
JIS X 8341-3:2016は、規格に沿った試験と適合性の表明を行うことで適合要件を満たせます。ただし、それには第三者に試験を行ってもらったり、「供給者適合宣言書」と呼ばれる書類を作成したりする手続きが必要です5。工場で作られる製品の検査と違い、対象がウェブサイトである分、この手続きの位置づけを見誤りやすい面があります。
つまり、「準拠しました」という一言は、担当した範囲の見た目を整えただけでは成立しません。案件のなかで軽く使ってよい言葉ではなく、試験と書類という裏づけがあって初めて表明できるものだと捉えておく必要があります。
適合表明を支える2つの手続き
適合の表明を支える手続きは、大きく2つに分けられます。ひとつは第三者による試験で、外部の実施者が規格に沿って評価します。もうひとつは供給者適合宣言書で、試験の結果をもとに事業者が作成する書類です5。どちらか一方ではなく、両方がそろって初めて表明の裏づけになります。加えて、ウェブサイトは公開後も改修が続くため、一度そろえた裏づけがそのまま使い続けられるとは限りません。
| 必要なもの | 内容 | 位置づけ |
|---|---|---|
| 第三者による試験 | 外部の実施者が規格に沿って評価します5 | 自己判断だけでは適合の表明になりません |
| 供給者適合宣言書 | 試験結果をもとに事業者が作成する書類です5 | 表明の根拠として整えます |
| 継続的な確認 | 改修のたびに試験と書類を見直します | 一度の対応で終わらない前提で考えます |
第三者による試験と供給者適合宣言書は、それぞれ独立した手続きではなく、一連の流れとして扱われます。試験の結果が宣言書に記載する内容を裏づけるため、どちらか一方だけを整えても、適合の表明としては成立しません。案件のなかでこの手続きを担当する場合は、どちらの工程まで自分が関わるのかを早めに確認しておくと役割がはっきりします。
図の作成:Remogu編集部。適合表明に必要な手続きの関係を整理したもので、統計データではありません
ここで気になるのが、ウェブサイトは公開後も更新され続けるという事実です。工場で作られる製品と違い、試験のたびに構成が変わる可能性があります。次の章では、この現実にどう向き合っているかを見ていきます。
5. だから対応度の表記が使われています
日々の改修と、独自の表記
ウェブサイトや情報システムは日々改修と更新が行われ、そのたびに試験をやり直すのは現実的ではありません。この事情から、デジタル庁は対応度の表記に独自の表記を使う方針を採っています6。
案件のなかでこの表記に触れたときは、正式な適合の表明と同じ重みで受け取らないほうが安全です。表記が示しているのは、その時点での取り組みの状況であり、第三者試験を経た保証書ではありません。表記の更新頻度や見直しのタイミングは、クライアントと確認しておきたい点です。
対応度の表記を読むときの視点
対応度の表記を読むときは、3つの視点を分けて考えると整理しやすくなります。なぜ独自の表記が使われているのか、正式な適合表明とは何が違うのか、そして規格の正確な内容を確かめたいときはどこを見ればよいのかです。次の表に、それぞれの視点と案件での確認先をまとめます。
| 表記の視点 | 内容 | 案件での確認先 |
|---|---|---|
| なぜ独自表記なのか | ウェブサイトは日々改修されるためです6 | 表記の更新頻度をクライアントと確認します |
| 正式な適合表明との違い | 正式な適合には第三者試験と宣言書が必要です5 | どちらの体制を取るのか事前にすり合わせます |
| 規格の正確な内容の確認先 | ガイドブックは正確性や網羅性を担保していません7 | WAICの試験実施ガイドラインを参照します7 |
このガイドブックは基礎を理解しやすくすることを重視しており、記載の厳密な正確性や網羅性までは担保していません。規格の正確な内容や試験方法を確認したいときは、情報通信アクセス協議会ウェブアクセシビリティ基盤委員会(WAIC)が公開している試験実施ガイドラインを参照する必要があります7。個別の達成基準の判定は、この記事で扱う範囲を超えるため、案件のなかでは参照先の資料に沿って確認する流れになります。
対応度の表記を見かけたときは、その表記がいつの時点のものかと、次にいつ見直される予定かをあわせて確認しておくと、案件の途中で認識がずれにくくなります。表記だけを見て安心せず、根拠となる資料まで確認する姿勢が大切です。
6. 案件に入るときに確かめる順
義務の範囲→規格の版→試験と表記の順で確かめる
ここまでの内容を、案件に参画する前に確かめる順番として並べ直すと3段になります。まず、対応を求められているのが合理的配慮なのか、それとも環境整備としてのウェブアクセシビリティなのかという義務の範囲です。次に、JIS X 8341-3のどの版を基準にしているかという規格の版です。最後に、試験を経た表明なのか、それとも独自の表記による状況の共有なのかという試験と表記の位置づけです。
図の作成:Remogu編集部。案件参画前に確認する順序を整理したもので、統計データではありません
リモートで進める案件でも、この確認の順番は変わりません。Remoguでは、案件の90%以上がフルリモート可能です9。離れた場所からクライアントと協議する場面が増える分、この3段の確認を早い段階ですり合わせておくと、後工程での認識のずれを防ぎやすくなります。
この3段を確認する際は、口頭でのやり取りだけに頼らず、要件定義書や見積書に確認結果を残しておくと、後から振り返るときの手がかりになります。特に規格の版は途中で更新されることがあるため、案件の節目ごとに再確認しておくと安心です。3段のどこかで判断に迷ったときは、資料を読み込むよりも先に、クライアントへ確認する方が早く解決します。
規格対応の経験を活かせるフロントエンド案件をチェックする →
7. よくある質問
アクセシビリティ対応の案件では、どこまでの作業を担当しますか
担当する範囲は案件によって異なります。ウェブサイトのマークアップや表示の調整だけでなく、ブラウザを使う業務システムやアプリケーションが対象に含まれる案件もあります3。規格票のチェックリストを埋めるだけでは不足するため4、達成基準やテクニックの理解を前提にした実装を求められる場面が中心になります。案件によって作業範囲は異なるため、契約前に担当箇所を具体的にすり合わせておくと安心です。
案件資料に「準拠」と書かれていたら、そのまま受け取ってよいですか
正式な適合の表明には、第三者による試験と供給者適合宣言書が必要です5。資料に「準拠」とだけ書かれている場合は、どの段階の対応を指しているのかをクライアントに確認しておくと安心です。規格の正確な内容を確かめたいときは、WAICの試験実施ガイドラインが参照先になります7。担当する範囲が試験や書類の作成にまで及ぶのか、それとも実装のみなのかも、あわせて確認しておきたい点です。
業務システムやスマートフォンの案件でも関係しますか
関係します。JIS X 8341-3はウェブサイトのための規格と捉えられがちですが、ブラウザを使うアプリケーションやシステムにも関わります3。ガイドブックの実践プロセスにはスマートフォンのアクセシビリティを扱う章も置かれており8、対象はウェブページの外側にも広がっています。対象が広がっている分、規格票だけを確認して終わりにせず、担当する画面の種類ごとに確認しておくことが大切です。
この記事の内容だけで、達成基準の判定はできますか
できません。このガイドブックは基礎を理解しやすくすることを重視しており、記載の厳密な正確性や網羅性までは担保していません7。個別の達成基準を正確に判定するには、WAICが公開している試験実施ガイドラインなどを参照する必要があります7。案件のなかでは、この記事を土台にしつつ、参照先の資料やクライアントとの協議で詳細を詰める流れになります。
アクセシビリティ対応の内容は、今後変わる可能性がありますか
あります。ウェブサイトや情報システムは日々改修されるため、対応度の表記も見直しが前提になっています6。ガイドブック自体も改定が重ねられており、この記事で扱った内容も今後の改定によって更新される可能性があります。案件に参画する際は、参照している資料が最新のものかどうかをあわせて確認しておくと安心です。
義務と努力義務の線引きは、案件の説明資料を読むときの土台になります。規格の版や試験の有無がはっきりしないときは、資料を読み込むよりも先に、クライアントへ確認する一歩を踏み出してみましょう。
リモートワーク案件をお探しの方へ
Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。
求められる水準は案件ごとに違います。まずは条件を見比べるところから確かめられます。
会員登録無料 / 案件閲覧・相談は無料
※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。
出典・参考情報
*1 デジタル庁「ウェブアクセシビリティ導入ガイドブック」DS-671.2(2025年10月)
*2 デジタル庁「ウェブアクセシビリティ導入ガイドブック」DS-671.2(2025年10月)
*3 デジタル庁「ウェブアクセシビリティ導入ガイドブック」DS-671.2(2025年10月)
*4 デジタル庁「ウェブアクセシビリティ導入ガイドブック」DS-671.2(2025年10月)
*5 デジタル庁「ウェブアクセシビリティ導入ガイドブック」DS-671.2(2025年10月)
*6 デジタル庁「ウェブアクセシビリティ導入ガイドブック」DS-671.2(2025年10月)
*7 デジタル庁「ウェブアクセシビリティ導入ガイドブック」DS-671.2(2025年10月)
*8 デジタル庁「ウェブアクセシビリティ導入ガイドブック」DS-671.2(2025年10月)
*9 Remoguサイト公開情報(案件の90%以上がフルリモート可能)