ナレッジ

市場横断のアクセシビリティ監査:各国のユーザーが実際に目にするものをテストする

米国のホームページの監査結果は、ドイツや日本のページについてはほとんど何も語らない。私たちは4カ国の23のサイトを監査したところ、4分の1がその市場固有の問題を抱えていた。

James Meadow

James Meadow

2026年10月4日 · 3 分で読める

多くのアクセシビリティテストは、サイトのある1つのバージョンに対してのみ行われる。それはチームが毎日作成し、確認しているバージョンで、たいてい英語でオフィスから見たものだ。しかし、十数の市場を抱えるサイトは、実質的には十数のサイトである。翻訳はテキストの長さや折り返しを変え、現地チームは独自のバナーやフォームを追加し、国によって異なるコンポーネントが表示され、ベルリンや東京の訪問者が実際に目にするバージョンは一度もテストされていないかもしれない。

この問題が実際にどれほど重要なのかを知りたかった。そこで、23の大規模なマルチマーケットウェブサイトを選び、それぞれの国の内側からアメリカ、ドイツ、フランス、日本向けのバージョンを読み込み、すべてに同じ自動アクセシビリティ監査を実行した。本ガイドでは、わかったこと、使用したコード、そして市場ごとの違いを意識したテストを自社のプロセスに組み込む方法を紹介する。

重要なポイント

  • テストしているバージョンは、全員が目にするバージョンとは限らない。安定した結果を示した20サイトのうち5サイトには、アメリカ版では一度も現れなかった種類のアクセシビリティ上の不具合が、ローカライズ版の少なくとも1種類に存在していた。
  • 違いは具体的だった。サインアップフォームにあるラベルのない誕生日フィールド、ラベルのない検索ボックス、テキスト代替のない画像、名前のないボタン、コントラストが不十分なテキストなどだ。
  • ページは訪問のたびに変化するため、まずはノイズを測定する必要がある。23サイトのうち3サイトでは、同じアメリカ版ページを数分間隔で2回読み込んだ結果が異なっていた。
  • 自動化されたルールは問題の一部しか捉えられない。市場ごとのリグレッションネットとして扱い、支援技術を使った手動テストも継続すべきだ。
  • EUでは、欧州アクセシビリティ法が2025年6月28日から多くの消費者向けサービス(eコマースを含む)に適用されており、これによりすべての市場版がコンプライアンス対象の範囲に含まれることになる。

1つのバージョンだけでは不十分な理由

市場間では、アクセシビリティに影響しうるいくつかの要素が変化する。

  • テキスト。 ドイツ語の単語は長く、日本語のテキストは異なるフォントと改行ルールを使用し、翻訳されたラベルが失われたり、重複したり、空のまま残ったりすることがある。
  • コンポーネント。 同意バナー、クッキーウォール、年齢確認ゲート、通貨・国選択セレクター、現地の決済ウィジェット、地域限定のプロモーションは、特定の市場にのみ表示されることが多い。
  • コンテンツ。 現地のマーケティングチームは、メインのデザインシステムの外で独自の画像やキャンペーンを公開することがあり、代替テキストは真っ先に欠落する要素だ。
  • 配信方法。 一部のサイトは、地域ごとに異なるビルド、ドメイン、コンテンツ管理システムのインスタンスを提供している。

これらのバージョンがどのように見えるかは、訪問者がどこにいるかによって決まる。アメリカのオフィスからドイツ版ページを読み込むテストでは、リダイレクトされたり、異なる同意フローが表示されたり、地域コンポーネントのアメリカ向けバリアントが表示されたりする可能性がある。ドイツのユーザーが実際に目にするものをテストするには、テスト自体がドイツからの訪問者として実行される必要がある。

テスト方法

アメリカ英語、ドイツ語、フランス語、日本語のホームページバージョンを公開している大規模ウェブサイトを選び、各サイト自身のhreflangアノテーションからURLを取得した。2026年10月4日、それぞれのバージョンを、該当する国のShifter出口経由でChromiumに読み込み、ブラウザの言語とタイムゾーンを一致させた(アメリカはニューヨーク、そしてベルリン、パリ、東京)。クライアント側のレンダリングと同意バナーの表示を待つため5秒間待機し、その後axe-core 4.13をWCAG 2のレベルAおよびAAのルールで実行した。

当初対象とした25サイトのうち2サイトは、すべての市場でブロックページを返したため除外し、23サイトが残った。ノイズを測定するため、すべてのアメリカ版ページを2回ずつ監査した。23サイトのうち3サイトでは、この2回のアメリカ版実行の間で結果が異なっており、これはたいていローテーションするバナーやランダムに読み込まれるコンテンツが原因だったため、市場間比較ではこの3サイトを除外した。

わかったこと

指標アメリカ(1回目)アメリカ(2回目)ドイツフランス日本
23サイト全体での不具合発生件数158165174168161
不具合が検出されなかったサイト数65335
ページあたりの不具合種類の平均数1.61.71.81.81.7

ローカライズ版はすべての指標でわずかに悪い結果だったが、このレベルの差は実行ごとのノイズに近い。より明確なシグナルは、どの問題がどこで現れたかにある。アメリカ版の結果が安定していた20サイトのうち5サイトでは、どちらのアメリカ版実行にも現れなかった種類の不具合が、ローカライズ版の少なくとも1つに存在していた。

サイトの種類アメリカ版以外でのみ見つかった不具合対象市場
ゲームプラットフォームサインアップの誕生日フィールド(日、月、年)にアクセシブルな名前がないドイツ、フランス、日本
ウェブサイトビルダーメインの検索フィールドにラベルがないドイツ、フランス、日本
セキュリティソフトウェアベンダー通貨セレクターに無効なARIA属性、テキスト代替のないプロモーション画像、名前のない動画再生ボタンドイツ、フランス、日本
eコマースプラットフォームアクセシブルな名前のないボタンドイツ、フランス
オープンソースプロジェクトサイト色のコントラストが不十分なフッターテキストドイツ、フランス、日本

これらの不具合の中には、件数以上に重要な意味を持つものがいくつかある。スクリーンリーダーの利用者は、日付フィールドに名前がないサインアップフォームを完了できず、「editテキスト」としてしか読み上げられない検索ボックスを使うこともできない。これは、アメリカ版ページしかテストしないチームには見えないままになる種類の不具合だ。

92件の監査全体で最も多かった不具合は色のコントラストで、43ページで見つかり、次いでアクセシブルな名前のないボタン、テキスト代替のない画像が続いた。

コード

以下のモジュールは、ある市場の訪問者が実際に見る形でページを監査し、意図したページと取り違えないよう、ブロックページやエラーページにフラグを立てる。Playwrightとaxe-coreが必要になる。

import { readFileSync } from 'node:fs';
import { createRequire } from 'node:module';

const require = createRequire(import.meta.url);
const AXE_SOURCE = readFileSync(require.resolve('axe-core/axe.min.js'), 'utf8');

// Audit one page as a visitor in one market would see it: the browser's locale and time zone match the
// market, and the browser itself runs through an exit in that country.
export async function auditPage(browser, url, { locale, timezoneId }) {
  const context = await browser.newContext({ locale, timezoneId });
  const page = await context.newPage();
  try {
    const response = await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 60000 });
    await page.waitForTimeout(5000); // let client-side rendering and consent banners appear
    await page.evaluate(AXE_SOURCE); // evaluate, not a script tag, so the page's CSP cannot block it
    const result = await page.evaluate(() =>
      window.axe.run(document, { runOnly: ['wcag2a', 'wcag2aa'], resultTypes: ['violations'] }));
    const lang = await page.evaluate(() => document.documentElement.getAttribute('lang'));
    const status = response ? response.status() : null;
    return {
      url,
      finalUrl: page.url(),
      status,
      blocked: status === null || status >= 400, // a block or error page, not the page you meant to audit
      title: await page.title(),
      lang,
      violations: result.violations.map((v) => ({ id: v.id, impact: v.impact, nodes: v.nodes.length })),
    };
  } finally {
    await context.close();
  }
}

そして、ある市場向けにこれを実行する際は、ブラウザをその国の出口経由でルーティングする。

import { chromium } from 'playwright';
import { auditPage } from './audit.mjs';

// One browser per market, running through an exit in that country.
const browser = await chromium.launch({
  proxy: {
    server: 'http://p.shifter.io:443',
    username: `${process.env.SHIFTER_PROXY_USER}-country-de`,
    password: process.env.SHIFTER_PROXY_PASS,
  },
});
const result = await auditPage(browser, 'https://shifter.io/de', { locale: 'de-DE', timezoneId: 'Europe/Berlin' });
console.log(result.status, result.blocked, result.lang, result.violations);
await browser.close();

自社のドイツ語版ホームページに対して実行したところ、不具合は検出されなかった。

これを作る過程で得た教訓が2つ、コードに組み込まれている。blockedフラグが存在するのは、最初の実行でブロックページを監査してしまったためだ。2つのサイトがすべての出口を拒否し、そのブロックページはもっともらしく見える結果を生成した。その中には、アメリカ英語として宣言されていたページが、一瞬ラベル付けミスのドイツ語ページだと思わせられた例も含まれる。また、axeはscriptタグではなくevaluateで注入されている。これは、一部のサイトの厳格なContent Security Policyが注入スクリプトを拒否するためだ。

プロセスへの組み込み方

  • 販売しているすべての市場を、その市場から監査する。 プロキシの地理・タイムゾーン・ロケールの一致で説明されているように、各国の出口を使い、言語とタイムゾーンを一致させることで、監査が現地の訪問者と同じ同意フロー、リダイレクト、地域コンポーネントを目にするようにする。
  • バージョンはサイト自身から見つける。 hreflangアノテーションにはすべての市場版が一覧されているため、市場が追加されても監査対象リストは漏れなく維持される。
  • 差分を信頼する前に、まずノイズを測定する。 同じページを2回監査し、同一実行間でも現れる変化はノイズとして扱う。
  • 正しいページを監査できたか確認する。 ステータス、タイトル、最終的なURLを記録し、ブロックページ、エラーページ、別の市場へのリダイレクトは破棄する。アンチボットスタックの調べ方では、ステータスコードだけでは誤解を招く理由を説明している。
  • メインバージョンとの差分を取る。 ある市場版には存在するが、チームがテストしているバージョンには存在しない不具合を報告する。これらは誰も目にしていない不具合だからだ。
  • 定期的に実行する。 現地のキャンペーンやバナーは毎週変わる。大規模な変化検知の原則はアクセシビリティにも当てはまる。
  • 人間を関与させ続ける。 W3Cは、ツールがすべてのアクセシビリティ要件をチェックできるわけではなく、人間の判断が必要であることを明言している。自動監査はリグレッションを見つけるものであり、サイトがアクセシブルであることを証明するものではない。

今これが重要な理由

アクセシビリティは、多くの国で公共部門のウェブサイトに対する法的要件として長く存在してきた。EUでは、欧州アクセシビリティ法が2025年6月28日から、eコマースを含む定められた消費者向け製品・サービスの一群に適用されており、それを満たすために使われる整合欧州規格はWCAGに基づいている。ヨーロッパ全域で販売する企業にとって、サイトの各国版はそれらの要件を満たすべき対象の一部であり、開発者が見ているバージョンだけではない。これは一般的な情報であり、法的助言ではない。自社の各市場に適用されるルールについては、法律専門家に確認してほしい。

結論

アクセシビリティは通常、1つの場所でテストされ、多くの場所に出荷される。23のマルチマーケットサイトに対する監査では、安定した結果を示したサイトのうち4分の1に、アメリカ版以外にしか存在しない不具合があった。ラベルのないサインアップフィールドから、テキスト代替のない画像まで様々だった。

各市場版を現地の訪問者が見る形でテストし、本当の違いをノイズから切り分け、チームがすでに確認しているバージョンと差分を取ること。市場ごとに数分の自動化コストで済み、そこのユーザーがずっと遭遇し続けてきた問題を見つけ出せる。

出典と参考文献

始める準備はできていますか?

Shifterのレジデンシャルプロキシをお試しください。IP 205M+件、195+カ国、$0.10/GBから。

始める