「調達仕様書にアクセシビリティ要件が入っているが、どのCMSなら対応できるのかわからない」という担当者向けに、WCAG 2.1・JIS X 8341-3の判断基準とCMS別の実装ポイントを解説します。

1. CMSのアクセシビリティ対応が問われるようになった背景

Webサイトのアクセシビリティは、長らく官公庁や自治体だけの課題として扱われてきました。しかし近年、民間企業のWebサイト制作においても、アクセシビリティ対応が要件定義の段階で議題に上がるケースが急増しています。その背景には、法制度の変化と調達実務の変化という二つの要因があります。

1-1. 2024年4月施行の障害者差別解消法改正がもたらした変化

2024年4月に施行された改正障害者差別解消法により、これまで努力義務とされていた民間事業者の「合理的配慮の提供」が法的義務となりました。合理的配慮とは、障害のある方から何らかの対応を求められた際に、過重な負担にならない範囲で個別に対応することを指します。

ここで注意が必要なのは、Webサイト全体をJIS規格に完全準拠させること自体は、民間事業者にとって現時点では努力義務にとどまるという点です。義務化されたのは、あくまで個別の申し出に対する合理的配慮の提供です。

ただし実務上は、この二つを切り離して考えることが難しくなっています。たとえば視覚障害のある方から「フォームが読み上げソフトで操作できない」という申し出があった場合、その都度個別に対応するよりも、サイト全体の実装をアクセシブルな状態に整えておくほうが、結果的に対応コストは小さくなります。事前的改善措置としてアクセシビリティ対応を進める企業が増えているのは、こうした合理性によるものです。

1-2. JIS X 8341-3の改正動向と対応の前倒し

日本国内のWebアクセシビリティ規格であるJIS X 8341-3は、2016年3月に改正公示された「JIS X 8341-3:2016」が現行版です。この規格は国際基準であるWCAG 2.0と一致した内容となっており、達成基準の適合レベルはA・AA・AAAの三段階で定義されています。

一方、W3Cが2023年10月にWCAG 2.2を勧告したことを受け、JIS X 8341-3についても改正に向けた作業が進行しています。WCAG 2.1とWCAG 2.2の追加基準を一度に取り込む形になるため、達成基準の項目数は大幅に増加する見込みです。改正版の発行時期については、ウェブアクセシビリティ基盤委員会（WAIC）の公式情報を随時確認することをおすすめします。

この改正動向は、CMS選定にも影響します。現時点でWCAG 2.1のAA水準に対応できる設計になっているCMSであれば、規格改正後の追加対応も比較的小さな修正で済みます。逆に、CMSが出力するHTMLの構造自体に問題がある場合、規格改正のたびにテンプレートの大規模な作り直しが必要になります。

1-3. 調達要件にアクセシビリティが明記されるケースの増加

官公庁・自治体・大学・独立行政法人の調達では、Webサイト制作の仕様書に「JIS X 8341-3:2016の適合レベルAAに準拠すること」という要件が明記されることが一般的になりました。総務省の「みんなの公共サイト運用ガイドライン」が公的機関にAA準拠を求めていることが、その根拠となっています。

さらに近年は、民間企業の大規模案件でもこの流れが波及しています。上場企業のコーポレートサイトリニューアルや、大手製造業のグローバルサイト統合案件では、RFP（提案依頼書）の非機能要件としてアクセシビリティ対応が記載されるケースが見られます。取引先の調達基準に自社が組み込まれている企業では、対応の有無が受注機会そのものに影響する可能性があります。

CMS選定の判断軸全体については、「CMSの種類と選び方 業種・規模別の選定基準と導入フローを解説」で体系的に解説しています。

2. WCAG 2.1とJIS X 8341-3の関係を正しく理解する

CMSのアクセシビリティ対応を検討する前提として、WCAGとJISという二つの基準の関係を整理しておく必要があります。ここを曖昧にしたまま制作会社と会話すると、要件の認識がずれる原因になります。

2-1. WCAGとJIS X 8341-3の対応関係

WCAG（Web Content Accessibility Guidelines）は、W3Cが策定した国際的なWebアクセシビリティ基準です。一方、JIS X 8341-3は日本産業規格として定められた国内規格で、正式名称を「高齢者・障害者等配慮設計指針－情報通信における機器，ソフトウェア及びサービス－第3部：ウェブコンテンツ」といいます。

現行のJIS X 8341-3:2016は、WCAG 2.0と技術的に一致した内容として策定されています。つまり「JIS X 8341-3:2016のAA準拠」と「WCAG 2.0のAA適合」は、達成すべき基準としてほぼ同一です。

WCAG 2.1はWCAG 2.0に対して、モバイル端末での利用やロービジョン（弱視）への配慮を中心とした達成基準を追加したバージョンです。現行JISには含まれていない基準ですが、実務上はWCAG 2.1のAA水準を目標に設定するケースが増えています。規格改正を見据えた場合、この判断は合理的といえます。

2-2. 適合レベルA・AA・AAAの実務的な位置づけ

WCAG・JISともに、達成基準は三つのレベルに分類されています。それぞれの実務的な位置づけは次のとおりです。

• レベルA：最低限の水準。これを満たさない場合、特定の障害を持つユーザーがコンテンツを利用できない状態になります。画像の代替テキスト、キーボード操作への対応などが含まれます
• レベルAA：企業・公的機関のWebサイトが目標とすべき標準的な水準。文字色と背景色のコントラスト比、見出しやラベルの適切な記述などが含まれます
• レベルAAA：より高度な水準。すべてのコンテンツで満たすことは現実的でない基準も含まれるため、サイト全体での適合を目標とすることは推奨されていません

実務では、レベルAAを目標として設定するのが標準的です。調達仕様書に記載される要件も、ほとんどの場合AA準拠です。

2-3. 「準拠」と「配慮」の表記の違い

JIS X 8341-3:2016に関連して、Webサイトの対応度を示す表記には明確なルールがあります。ウェブアクセシビリティ基盤委員会が定める「対応度表記ガイドライン」では、次のように定義されています。

「準拠」は、目標とする適合レベルの達成基準をすべて満たし、試験結果を公開している状態を指します。一方「一部準拠」は、満たしていない達成基準が存在する状態です。また「配慮」は、試験を実施していないものの、アクセシビリティに配慮した制作を行っている状態を意味します。

この表記の違いは、調達要件を読み解くうえで重要です。「準拠」が求められている案件では、達成基準ごとの試験実施と結果の公開が必須となるため、制作フェーズに試験工数を組み込む必要があります。

3. CMSがアクセシブルなHTMLを出力できるかの判断基準

CMS選定において最も重要なのは、「そのCMSが出力するHTMLが、アクセシビリティ基準を満たせる構造になっているか」という点です。管理画面の使いやすさとは別の観点で評価する必要があります。

3-1. テンプレート側でHTML構造を完全に制御できるか

アクセシビリティ対応の可否を左右する最大の要因は、テンプレートでHTMLの出力を自由に制御できるかどうかです。CMSによっては、独自のタグや自動生成されるマークアップが、意図しない構造を出力してしまうことがあります。

確認すべき具体的な項目は次のとおりです。

• 見出しタグの階層をテンプレートで指定できるか：h1からh6の階層をスキップせずに出力できる設計になっているか
• ランドマークロールを設定できるか：header、nav、main、footerといったHTML5のセマンティック要素、またはARIAのランドマークロールをテンプレートに記述できるか
• 不要な装飾用マークアップが自動挿入されないか：スクリーンリーダーが読み上げる際にノイズとなる空要素やdivの入れ子が過剰に生成されないか
• lang属性を適切に出力できるか：ページの主要言語、および部分的に異なる言語が使われている箇所への指定が可能か

パッケージ型CMSであるMovable TypeやPowerCMSは、テンプレートで出力HTMLを一行単位まで制御できる設計になっており、この観点では有利です。

3-2. 編集者の入力が構造を壊さない仕組みがあるか

CMSのアクセシビリティ対応で見落とされがちなのが、公開後の運用フェーズです。制作時点でAA準拠を達成しても、担当者がコンテンツを追加するたびに構造が崩れていけば、水準は維持できません。

たとえば食品メーカーのコーポレートサイトで、広報担当者がニュースリリースを投稿する場面を考えてみます。エディタ上で「文字を大きくしたい」という理由から本来h3であるべき箇所にh1を使ってしまうと、見出し階層が破綻し、スクリーンリーダーでの読み上げ順序が意味をなさなくなります。

こうした事態を防ぐため、エディタ側で使用できる見出しレベルを制限したり、独自のブロックとして正しい構造を強制したりする仕組みが有効です。CMS選定時には、この「編集者による構造破壊を防げるか」という観点を必ず確認してください。

3-3. 自動生成されるナビゲーション・パーツの品質

CMSは、パンくずリスト・ページネーション・カテゴリ一覧・検索フォームなどを自動生成する機能を備えています。これらの自動生成パーツが、アクセシビリティ基準を満たす形で出力されるかどうかも重要な確認事項です。

具体的には、ページネーションのリンクテキストが「1」「2」といった数字のみになっていないか、検索フォームの入力欄にラベルが関連付けられているか、パンくずリストがnav要素とaria-labelで適切にマークアップされているかといった点を確認します。自動生成部分をカスタマイズできないCMSでは、この時点で対応が頭打ちになります。

4. altテキストの必須入力設定と運用ルール

画像の代替テキスト（altテキスト）は、WCAG・JISの達成基準の中でも最も基本的かつ、運用で崩れやすい項目です。CMS側の設定で入力漏れを防ぐ仕組みを作ることが、対応の第一歩となります。

4-1. altテキストが必要な画像と不要な画像の区別

すべての画像に説明文を入れればよいというわけではありません。WCAGの達成基準では、画像の役割に応じて適切な代替テキストを設定することが求められています。

• 情報を伝える画像：写真・図解・グラフなど、内容の理解に必要な画像には、その情報を過不足なく伝える代替テキストを設定します
• 装飾目的の画像：背景装飾やスペーサーなど、内容に寄与しない画像はalt属性を空（alt=””）にし、支援技術が読み飛ばせるようにします
• リンクやボタンとして機能する画像：リンク先やボタンの動作を説明するテキストを設定します。画像の見た目ではなく機能を記述する点が重要です
• テキストを含む画像：画像内の文字情報をそのまま代替テキストに記述します

装飾画像に不要な説明を入れると、スクリーンリーダー利用者にとってはかえって理解の妨げになります。「入れればよい」ではなく「役割に応じて使い分ける」という考え方を、運用マニュアルに明記しておくことが重要です。

4-2. CMS別のalt必須入力設定の実装方法

主要CMSにおける代替テキストの入力制御は、それぞれ実装アプローチが異なります。

Movable Type・PowerCMSの場合：カスタムフィールドで画像項目を定義する際に、代替テキスト用のテキストフィールドを併設し、必須項目として設定する方法が確実です。テンプレート側では、そのフィールド値をimg要素のalt属性に出力する記述を行います。装飾画像用に「装飾画像として扱う」チェックボックスを併設し、チェック時はalt=””を出力する分岐をテンプレートに組み込むと、運用の柔軟性が高まります。

WordPressの場合：メディアライブラリに標準で代替テキストの入力欄が用意されていますが、初期状態では必須項目ではありません。入力を強制するには、投稿の保存前にバリデーションを実行するカスタム実装が必要です。ブロックエディタでの画像挿入時にも同様の制御を加えることで、入力漏れを構造的に防げます。

いずれのCMSでも、既存コンテンツの代替テキストを一括で点検する運用が併せて必要です。導入時点で数百枚の画像が存在するサイトでは、移行フェーズに点検工数を見込んでおきましょう。

4-3. 代替テキストの品質を維持する運用ルール

入力欄を必須にしても、内容が不適切であれば意味がありません。実際の現場では「画像1」「写真」といった無意味な文字列が入力されるケースが少なくありません。

品質を維持するためには、運用マニュアルに具体的な記述例を示すことが有効です。たとえば製造業のサイトであれば、製品写真には型番と外観の特徴を、工場設備の写真には設備名と用途を記述するといったルールを、実例つきで整理しておきます。CMSの入力欄にプレースホルダーやヘルプテキストを設定し、入力時点でルールが目に入る設計にすることも効果的です。

5. 見出し構造とキーボード操作への対応

見出し構造とキーボード操作は、スクリーンリーダー利用者・肢体不自由のあるユーザーにとって、コンテンツへの到達可否を直接左右する要素です。CMSの設計段階で対応方針を固めておく必要があります。

5-1. 見出し階層をCMS側で管理する方法

見出しは、ページの構造を伝える骨格です。スクリーンリーダー利用者の多くは、見出しを一覧表示して目的の箇所へジャンプする操作を行うため、階層が正しく設定されていないと、コンテンツ全体を順に読み進めるしかなくなります。

CMS側で見出し階層を担保する具体的な方法は次のとおりです。

• テンプレートでh1を固定する：ページタイトルをh1として出力し、本文エリアではh1を使用できないようエディタ側を制限します
• エディタの選択肢を絞る：ブロックエディタやリッチテキストエディタで選択できる見出しレベルを、h2からh4程度に限定します
• カスタムフィールドで構造を規定する：セクション単位のカスタムフィールドを定義し、見出しレベルをテンプレート側で自動付与する設計にします
• 公開前チェックの仕組みを設ける：見出しレベルのスキップを検知して警告を表示するチェック機能を、承認フローに組み込みます

特に複数部門が更新に関わる大学や自治体のサイトでは、三つ目のカスタムフィールドによる構造規定が有効です。編集者が構造を意識しなくても、テンプレートが正しい階層を出力する設計にできます。

5-2. キーボード操作対応で確認すべき実装ポイント

マウスを使用できないユーザーは、Tabキーとカーソルキーだけでサイトを操作します。すべての機能がキーボードで操作できることは、レベルAの達成基準に含まれる必須要件です。

確認すべき実装ポイントは次のとおりです。

• フォーカスの可視化：現在どの要素が選択されているかが視覚的に判別できること。CSSでoutlineを一律に消す実装は、この基準に違反します
• フォーカス順序の論理性：Tabキーで移動する順序が、視覚的なレイアウトと一致していること
• キーボードトラップの排除：モーダルウィンドウやドロップダウンメニューに入った後、キーボード操作だけで抜け出せること
• スキップリンクの設置：ページ冒頭に「本文へ移動」リンクを設け、ナビゲーションを読み飛ばせるようにすること

これらの多くは、CMSそのものではなくテンプレート実装とJavaScriptの記述に依存します。CMSを選定する際は、製品の機能一覧を確認するだけでなく、実装を担う制作会社にキーボード操作対応の実績があるかを確認することが重要です。

5-3. プラグイン・拡張機能がもたらすリスク

WordPressのようにプラグインで機能を追加するCMSでは、導入したプラグインが出力するHTMLがアクセシビリティ基準を満たしていないケースがあります。スライダー・アコーディオン・モーダルウィンドウなどのUI部品を提供するプラグインは、特に注意が必要です。

たとえばカルーセルスライダーのプラグインでは、自動再生の停止手段が用意されていない、スライド切り替えボタンがキーボードで操作できないといった問題が生じやすくなります。プラグインを導入する前に、出力されるHTMLと操作性を実機で検証する工程を、制作フローに組み込んでおきましょう。

6. 色コントラスト比とデザイン面の実装ポイント

色に関する達成基準は、デザインフェーズで決定される要素が多く、後戻りのコストが大きい領域です。CMSのテンプレート設計と並行して、デザインガイドラインの段階で基準を織り込むことが求められます。

6-1. コントラスト比の基準値と測定方法

WCAG・JISのレベルAAでは、文字色と背景色のコントラスト比について明確な数値基準が定められています。

• 通常サイズのテキスト：4.5:1以上のコントラスト比が必要です
• 大きいテキスト：18ポイント以上、または14ポイント以上の太字については3:1以上で許容されます
• UI部品・グラフィックオブジェクト：ボタンの境界線やアイコンなど、識別に必要な視覚情報についても3:1以上が求められます（WCAG 2.1で追加された基準）

コントラスト比は、専用の測定ツールで数値を確認できます。デザインカンプの段階で全パターンを測定し、基準を満たさない配色は修正しておくことで、実装後の手戻りを防げます。

6-2. 色だけに依存しない情報伝達

色覚特性のあるユーザーに配慮するため、情報を色だけで伝えない設計が求められます。これはレベルAの達成基準に含まれる要件です。

具体的には、フォームのエラー表示を赤文字のみで示すのではなくエラーアイコンとテキストを併記する、グラフの凡例を色分けだけでなくパターンやラベルで区別する、リンクを色の違いだけでなく下線でも示すといった対応が該当します。

医療機関のサイトで診療科ごとに色分けを行うようなケースでは、色に加えてアイコンや文字ラベルを併用する設計にしておくことで、この基準を満たせます。

6-3. CMSのテンプレートに配色ルールを組み込む

デザインで定めた配色ルールを運用フェーズで維持するには、CMS側で編集者が任意の色を指定できない設計にすることが有効です。

WordPressのブロックエディタでは、テーマ設定でカラーパレットを定義し、カスタムカラーの使用を無効化できます。これにより、編集者が選択できる色を基準を満たす組み合わせに限定できます。Movable TypeやPowerCMSでは、カスタムフィールドの選択肢としてあらかじめ定義した配色クラスのみを提示する設計にすることで、同様の制御が可能です。

編集者の自由度は下がりますが、公開後にコントラスト比が基準を下回るリスクを構造的に排除できるという利点があります。運用体制と要求水準のバランスを見て判断してください。

7. CMS別に見るアクセシビリティ対応の適性

ここまでの実装ポイントを踏まえ、主要CMSごとのアクセシビリティ対応における特性を整理します。製品としての優劣ではなく、要求水準と運用体制に対する適性という観点でご確認ください。

7-1. Movable Typeのアクセシビリティ対応特性

Movable Typeは、テンプレートで出力HTMLを完全に制御できる設計であり、アクセシビリティ要件が厳格な案件との相性に優れています。官公庁・自治体・大学での採用実績が多いのは、この特性が調達要件と合致するためです。

静的HTMLを生成する仕組みであることも、アクセシビリティ試験の観点では有利に働きます。出力されたHTMLファイルをそのまま検証ツールにかけられるため、試験結果の再現性が高く、「準拠」表記に必要な試験工数を圧縮できます。

一方で、テンプレート実装の自由度が高いということは、実装者の知識水準がそのまま品質に反映されるということでもあります。製品を導入すれば自動的にAA準拠になるわけではない点は、正しく理解しておく必要があります。

7-2. PowerCMSのアクセシビリティ対応特性

PowerCMSは、Movable Typeをベースに開発された国産商用CMSで、アクセシビリティ関連の機能が製品として組み込まれている点が特徴です。開発元がアクセシビリティ分野に注力しており、関連する支援機能やチェック機能が提供されています。

多段階のワークフロー機能と組み合わせることで、公開前の承認プロセスにアクセシビリティチェックを組み込む運用が構築しやすい点も強みです。複数部門が分散して更新する大学・大企業グループのサイトでは、この仕組みが品質維持に直結します。

導入にあたっては、ライセンス費用と構築費用が発生します。求められる水準と運用規模に見合うかどうかを、総所有コストの観点で判断してください。

7-3. WordPressのアクセシビリティ対応特性

WordPressは、コア開発チームがアクセシビリティ対応方針を掲げており、管理画面自体もアクセシビリティを意識した設計が進められています。適切なテーマを選定し、テンプレートを丁寧に実装すれば、AA準拠を達成することは十分に可能です。

課題となるのは、テーマとプラグインの品質にばらつきがある点です。配布されているテーマの多くはアクセシビリティ試験を経ておらず、既製テーマをそのまま使用した場合、達成基準を満たさないマークアップが含まれる可能性があります。厳格な要件がある案件では、オリジナルテーマを設計・実装する前提でコストを見積もることが現実的です。

また、動的にHTMLを生成する仕組みであるため、ページの状態によって出力が変化する箇所の試験には、静的出力型より工数がかかる傾向があります。

7-4. 選定時に制作会社へ確認すべき事項

CMS製品の特性は選定の一要素にすぎません。実際の対応品質は、構築を担う制作会社の実績と体制に大きく左右されます。提案依頼の段階で、次の項目を確認しておくことをおすすめします。

• JIS X 8341-3に基づく試験の実施実績：達成基準ごとの試験を実施し、試験結果を公開した案件の有無
• 試験工数の見積もりへの計上：アクセシビリティ試験と改修の工数が、見積書に明示されているか
• 公開後の運用支援体制：コンテンツ追加時のチェック体制や、定期的な再診断の提供可否
• 支援技術での検証環境：スクリーンリーダーなどの支援技術を用いた実機検証を行っているか

8. アクセシビリティ診断と改善の進め方

CMSを選定・構築した後は、実際に基準を満たしているかを検証する工程が必要です。診断と改善を体系的に進めるための考え方を整理します。

8-1. 自動チェックツールと手動検証の役割分担

アクセシビリティの検証には、自動チェックツールによる機械的な検査と、人による手動検証の両方が必要です。

自動チェックツールは、alt属性の欠落・コントラスト比の不足・見出し階層のスキップ・フォームラベルの欠落といった、機械的に判定できる項目を短時間で検出できます。サイト全体を横断的に点検する用途に適しています。

一方、代替テキストの内容が適切か、フォーカス順序が論理的か、キーボードだけで全機能を操作できるかといった項目は、人による判断が不可欠です。自動ツールで検出できる問題は全体の一部にとどまるため、ツールの結果だけで「対応完了」と判断することはできません。

8-2. 試験対象ページの選定と実施手順

JIS X 8341-3に基づく試験を実施する際は、サイト内のすべてのページを対象とすることが理想ですが、規模が大きい場合は現実的ではありません。ウェブアクセシビリティ基盤委員会が示す試験方法では、ランダムに選択したページとサイトを代表するページを組み合わせて、一定数のページを試験対象とする手順が示されています。

試験対象には、トップページ・主要な下層ページ・フォームページ・検索結果ページなど、機能や構造が異なるページをバランスよく含めることが重要です。CMSで生成されるページはテンプレート単位で構造が共通するため、テンプレートごとに代表ページを選ぶ考え方が実務的です。

8-3. 改修の優先順位づけ

診断で多数の問題が検出された場合、すべてを一度に改修することは困難です。次の観点で優先順位をつけることをおすすめします。

• レベルAの不適合を最優先：コンテンツの利用自体を妨げる問題から着手します
• サイト全体に影響する箇所を優先：共通ヘッダー・フッター・ナビゲーションの問題は、一箇所の修正で全ページに効果が及びます
• アクセス数の多いページを優先：影響を受けるユーザー数が多い箇所から改善します
• フォーム・申込導線を優先：利用できないことによる不利益が大きい機能から対応します

改修は一度で完了するものではなく、公開後も継続的に維持する取り組みです。コンテンツを追加するたびにチェックを行う運用フローを、CMS導入時に併せて設計しておきましょう。

8-4. アクセシビリティ方針の策定と公開

JIS X 8341-3への対応度を対外的に示すには、「ウェブアクセシビリティ方針」を策定してWebサイト上に公開する必要があります。方針には、対象範囲・目標とする適合レベル・目標達成の期限を記載します。

方針を公開したうえで試験を実施し、その結果を「試験結果」として併せて公開することで、「準拠」という対応度を表記できるようになります。調達要件に「準拠」が求められている場合、この一連のプロセスを制作スケジュールに組み込む必要があるため、要件定義の段階で工数を確保しておくことが重要です。

9. まとめ

CMSのアクセシビリティ対応は、製品を導入すれば自動的に達成されるものではありません。テンプレートでHTML構造を制御できるか、編集者の入力が構造を壊さない仕組みがあるか、自動生成されるパーツの品質が担保されているかという観点で、CMSを評価することが出発点となります。

本記事で解説したポイントを改めて整理すると、以下のとおりです。

• 民間事業者に義務化されたのは合理的配慮の提供であり、規格への完全準拠は現時点で努力義務にとどまる
• JIS X 8341-3は改正に向けた作業が進行中であり、WCAG 2.1のAA水準を目標に設定しておくと将来の追加対応が小さく済む
• 代替テキストは必須入力設定と運用ルールの両輪で品質を維持する
• 見出し階層はエディタ側の制限とカスタムフィールドによる構造規定で担保する
• コントラスト比はデザインフェーズで基準を織り込み、CMSのカラーパレット制限で運用時の逸脱を防ぐ
• 自動チェックツールで検出できる問題は一部であり、手動検証との組み合わせが不可欠

アクセシビリティ診断は、達成基準の解釈と支援技術を用いた検証の両方に専門知識が求められる領域です。自社での判断が難しい場合や、調達要件として「準拠」表記が求められている場合は、実績のある専門会社への相談が確実な選択肢となります。

フォー・クオリアは、Webサイト制作実績20,000件以上を有し、Movable TypeのProNet認定パートナーとして、Movable Type・PowerCMS・WordPressをはじめとする各種CMSの構築に対応しています。官公庁・大学・金融・製造業など、アクセシビリティ要件が厳格な業種での構築経験をもとに、CMS選定のご提案からアクセシビリティ診断・改善実装・公開後の運用支援まで一貫してサポートいたします。CMSのアクセシビリティ対応でお困りの際は、まずはお気軽にご相談ください。

 まずはお気軽に
ご相談ください