ECの改善を考えるとき、アクセス数や購入率は細かく見ていても、「操作できずに離脱した人」はなかなか数字に表れません。

商品をカートに入れたあと、ボタンを押し間違えた。キーボードで操作していたら、いまどこを選択しているのか分からなくなった。認証画面で何度もやり直しを求められ、そのまま閉じた。

ここで離脱したのは、まだ迷っていた人ではありません。買おうとしていた人です。

ウェブアクセシビリティという言葉から、「一部の人に向けた特別対応」を思い浮かべる方もいるでしょう。ただ、ECの現場で考えると、これは購入を妨げている原因を見つけ、取り除く話です。当然、売上ともつながっています。

JISの正式改正を待つと、手戻りが増える

国内のウェブアクセシビリティ規格として、現在参照されているのが「JIS X 8341-3:2016」です。現行規格はWCAG 2.0をもとにつくられていますが、国際的にはすでにWCAG 2.2が勧告され、JISも改正に向けて動き始めています。

規格の話が始まると、途端に数字が並びます。

現行JISで対象となるレベルA・AAの達成基準は38項目。WCAG 2.2では55項目まで増えています。数字だけを見れば17項目の差ですが、ECにとって大事なのは、その中身です。

スマートフォンでの操作、キーボードフォーカス、ドラッグ操作、同じ情報を何度も入力させる設計、認証時の負担。いずれも、いまのECで普通に起きている問題です。

たとえば、タップやクリックの対象には、原則24×24 CSSピクセル以上という基準があります。ただし、対象同士の間隔が確保されている場合などは例外です。「すべてのボタンを24ピクセル以上にすれば終了」という単純な話ではありません。

キーボードで選択している項目が、固定ヘッダーやポップアップに完全に隠れないか。ドラッグを使わなくても操作できるか。ログイン時に記憶やパズルだけを強制せず、別の認証方法や入力を助ける仕組みがあるか。

これをECに置き換えると、数量変更、絞り込み、クーポン入力、会員登録、ログイン、決済といった場所が、そのまま確認対象になります。

法律上の義務とJIS適合は、同じ話ではない

2024年4月の改正障害者差別解消法施行により、民間事業者にも、過重な負担にならない範囲で合理的配慮を提供することが義務づけられました。

ただし、すべての民間サイトに、JISへの適合が一律で義務づけられたわけではありません。障害者差別解消法とJISは、同じものではないからです。

では、JISやWCAGは何のためにあるのか。

実際に利用できない人から申し出があったとき、何を基準に改善するのか。その判断を具体的にするためです。「使いやすくしましょう」だけでは、直す場所も完了の基準も決まりません。

罰則があるかどうかだけで対応時期を決めると、判断を誤ります。問い合わせや苦情が届いてから動けば、原因の調査、改修方法の検討、社内説明が一度に発生します。購入フローに手を入れるなら、決済や会員基盤との結合テストまで必要になることもあります。

問題が起きてから個別に対応するより、普段の品質基準にアクセシビリティを含めておく。その方が、改修範囲も費用も判断しやすくなります。

まず見るべきは、全ページではなく「買う工程」

数千ページあるECを、最初からすべて検査しようとすると、対象が大きすぎて動けなくなります。

まず見たいのは、売上に直結する次の工程です。

• 商品検索と絞り込み
• 商品詳細からカート投入
• カート内の数量変更と削除
• 会員登録とログイン
• 配送先・支払方法の入力
• エラー表示と修正
• 注文内容の確認と確定

キーボードだけで最後まで購入できるか。画面を拡大しても、入力欄やボタンが欠けないか。エラーの場所と直し方が読み上げられるか。ダイアログを閉じたあと、操作していた場所へ戻れるか。

自動検査ツールも役に立ちます。ただし、分かるのは機械が見つけられる問題までです。色のコントラストや代替テキストの有無など、一部の問題は拾えても、この購入フローを最後まで使い切れるかまでは判断してくれません。

最後に注文を完了できるかどうかは、人が実際に操作して確かめる必要があります。

ヘッドレスを選ぶ理由は、改善の回数に表れる

タップ領域、フォーカス表示、入力フォーム。こうした改善の多くは、ユーザーが触れるフロントエンドに現れます。

商品・在庫・受注などを担うバックエンドと画面側が密接に結びついたECでは、表示や操作を変えるたびに、システム全体への影響を確認しなければなりません。ボタンひとつを直したいだけなのに、影響調査や改修範囲が広がることもあります。

そこで選択肢になるのが、バックエンドとフロントエンドを分離するヘッドレスコマースです。商品や受注の仕組みを維持しながら、画面側を継続的に改善しやすくなります。

とはいえ、すべてのECをヘッドレスにすればよいわけではありません。

ひとつのブランドを単一のサイトで運営し、購入導線も大きく変わらないのであれば、既存のECパッケージやテンプレートの改善で足りる場合があります。分離したことで開発や検証の対象が増えては、本末転倒です。

一方、次のようなECでは、ヘッドレスの強みが出やすくなります。

• 複数のブランドやサイトで商品・在庫情報を共用したい
• ウェブサイト、アプリ、店頭端末など複数の売り場を展開したい
• バックエンドの更新周期に縛られず、UIを改善したい
• 新しいデバイスや基準の変化へ継続的に対応したい
• 共通部品を使いながら、ブランドごとに異なる体験をつくりたい

もちろん、ヘッドレスにしただけでアクセシブルになるわけではありません。

フォームやボタン、ダイアログをアクセシブルな共通部品として管理できるか。ひとつの改善を各画面へ展開できるか。公開前の検証を開発工程の中に入れられるか。自由度を生かせるかどうかは、こうした運用まで設計できるかで決まります。

ヘッドレスを採用するかどうかは、流行や自由度だけで決めるものではありません。

これから何回、どの範囲を変える可能性があるのか。その変化に、現在のEC基盤が無理なく対応できるのか。構築時の機能だけでなく、公開後の改善まで見て判断する必要があります。

RFPには「準拠」だけでなく、検証方法まで書く

これから新規構築やリニューアルを行うなら、RFPに「JIS X 8341-3に配慮する」と一行書くだけでは足りません。

「配慮」の中身は、人によって変わります。発注者は当然含まれると思っていた。制作会社は要件にないと判断した。このすれ違いを公開直前に見つければ、手戻りは避けられません。

少なくとも、次の項目は先に決めておきたいところです。

• 目標とする基準と適合レベル
• 対象範囲と対象外にする範囲
• 購入フローなど、必ず検証する画面
• 自動検査と人による操作検証の分担
• 公開前の試験方法と判定者
• 公開後の更新・再検証ルール
• 外部サービスや決済画面の扱い

現時点で構築するなら、現行JISだけに固定せず、WCAG 2.2の適合レベルAAを視野に入れた要件を併記する方法があります。W3Cも、WCAGの最新版を使うことを推奨しています。

規格名だけを最新版にしても、品質は決まりません。誰が、どこを、どう確かめるのか。そこまで決めて、ようやく実装と検証へ進めます。

「売れる」と「使える」を別々に設計しない

アクセシビリティ対応は、売上施策を終えたあとに追加する作業ではありません。

購入ボタンを押しやすくする。入力ミスの理由を分かるようにする。認証で行き止まりをつくらない。
どれも、購入率を改善するときに確認する内容です。

アクセシビリティとコンバージョン改善は、同じ購入導線を異なる視点から確かめています。

JIS改正の正式な発行を待つ必要はありません。まずは自社ECの購入工程を、キーボード、画面拡大、スマートフォン、読み上げという複数の条件で通してみる。

そこで購入できない場所が見つかったなら、将来の基準に備えるためだけの問題ではありません。いま、このECを使っている人が直面している問題です。

「売れるサイト」と「使えるサイト」を別々に考えず、同じ購入体験として設計する。
今回のJIS改正は、その設計を見直すきっかけとして捉えるのがよいと思います。

※参照
ウェブ・コンテンツ・アクセシビリティ・ガイドライン（WCAG）2.2｜W3C
WCAG 2の各バージョンと最新版の利用について｜W3C
JIS X 8341-3改正原案作成委員会 発足のお知らせ｜ウェブアクセシビリティ基盤委員会
JIS X 8341-3:2016関連ガイドライン｜ウェブアクセシビリティ基盤委員会
障害を理由とする差別の解消の推進｜内閣府

※関連リンク：「GMOクラウドEC」公式サイト