アクセシビリティ
はじめに
Webは変化し続けています。Siri、Alexa、Cortanaなどの音声アシスタントは、スクリーンリーダー技術を使用してWebページから読み上げることで回答を提供することがよくあります。同様の方法はパーソナルコンピューティングの初期から存在していました。キャプション（字幕と呼ばれることもある）は聴覚障害者のために作成されましたが、現在では利便性のために皆に使用されるようになっており、スマートフォンのバイブレーションモードは今や標準機能です。キャプションを楽しんで使用する他のグループには、集中力を維持するためにキャプションを使用するADHDの人々、言語理解を向上させるために依存する非ネイティブスピーカー、音声コンテンツが聞き取りにくい騒音環境にいる人々が含まれます。
現代のデバイスとプラットフォームは、アクセシビリティのための多くのオプションを提供しています。これらは、障害者だけでなく一般の人々のユーザー体験をパーソナライズするのに役立ちます。しかし、多くの人はアクセシビリティメニューを開いて試してみることはありません。
優れたアクセシビリティは、障害者だけでなく、すべての人に有益です。これはユニバーサルデザインの基本原則です。ティム・バーナーズ＝リーが述べたように：“Webの力はその普遍性にあります。障害に関係なく、すべての人がアクセスできることが本質的な側面です。” COVID-19パンデミックは、デジタルインターフェースのアクセシビリティの向上がもはやオプションとして認識されるべきではないことを明確にしました。仮想世界への信頼できるアクセスなしに現実世界をナビゲートすることはますます困難になっています。
Microsoftのインクルーシブデザインガイドラインは、永続的な障害シナリオを超えて、一時的または状況的制限まで拡張しています。人間の能力は様々です。人が腕を失った（永続的）場合でも、事故のためにギプスをしている（一時的）場合でも、赤ちゃんを抱いている（状況的制限）場合でも、片手や音声操作でコンピューターや電話を使用できることは彼らに恩恵をもたらします。
この画像とアプローチは彼らのインクルーシブ101ガイドブックの提供によるものです。
世界中の政府は、デジタルアクセシビリティが道徳的義務であるだけでなく、多くの場合法的に要求されることを認識しています。アクセシビリティは商業と民主主義にも優れています。たとえば、欧州連合（EU）は、2025年6月までに、幅広い分野のWebサイトがWeb Content Accessibility Guidelines（WCAG）原則（EN 301 549標準を通じて）に準拠することを義務付けています。これにより最終的に、より多くの人々がEUでサービスを売買できるようになります。他の国々も同様の法律を可決しており、組織により仮想的なオファリングをよりアクセシブルにするよう圧力を高めています。
EN 301 549やSection 508などの立法で参照される標準は、Web Content Accessibility Guidelinesに基づいており、このレポートで使用される自動アクセシビリティテストはガイドラインの一部に対してのみテストできます。私たちのテストは、オープンソースツールであるGoogle Lighthouseを活用しており、これはDequeのオープンソースaxe-coreを使用しています。
過去のレポートには更新された多くの情報があります。時間の経過とともに変化を追跡し、変化が起こる場所を記録することは有用です。私たちはまた、異なる分野とWebアクセシビリティについての新しいセクションを紹介したいと思いました。私たちの分析を通じて、CMS、JavaScriptフレームワークを追跡し、異なる技術の平均アクセシビリティを評価できます。異なる国と政府のアクセシビリティを比較し、時間の経過とともにそれがどのように変化するかを追跡することもできます。
継続的な課題にもかかわらず、Webアクセシビリティには顕著な改善が見られました。Lighthouseアクセシビリティオーディットのメジアンスコアは、過去2年間で84%に上昇しました。WCAG 2.2では、4.1.1成功基準が削除されました。したがって、Dequeはaxeからduplicate-idとduplicate-id-activeオーディットを削除しましたので、これは私たちのスキャンにもう含まれていませんでした。これらの非推奨のaxeルールは、2022年のレポートで調査された数百万のサイトに影響を与えました。また、2.2で追加された新しい成功基準もあり、対応するテストがaxe-coreに追加されました。
アクセシビリティスコアは重要なツールですが、グッドハートの法則に精通している人は、測定がターゲットになることの危険性を知っているでしょう。自動テストはWCAG成功基準の一部のみに対処できることも認めなければなりません。また、完璧なスコアがアクセシブルなサイトを保証するものではないことも認めなければなりません。
同様に、評価されたページの割合が増加したページランクごとのメジアンLighthouseスコアの増加も見ることができます。これは2020年から2021年の間ほどの改善ではなく、2023年のWeb Almanacは作成されなかったため、2年間で1%の増加です。しかし、Lighthouseスコアはaxeを活用しており、WCAG 2.2により合致するようにテストを増やしていることも注目に値します。
もっとも改善されたLighthouseテストを使用してもっとも一般的なエラーを見ると、Lighthouseオーディットのどの部分がもっとも改善されたかを確認できます。完璧からは程遠いものの、前進が見られます。
aria-allowed-attrは2022年にサイトの82%、2024年に95%で合格。aria-input-field-nameは2022年にサイトの14%、2024年に21%で合格。aria-progressbar-nameは2022年にサイトの3%、2024年に14%で合格。color-contrastは2022年にサイトの23%、2024年に29%で合格。frame-titleは2022年にサイトの36%、2024年に51%で合格。Google Lighthouseには現在、スコアリングに使用される57の異なるオーディットテストが含まれています。これらはすべて、さまざまなアクセシビリティ製品やサービスで広く採用されているDequeのオープンソースaxe-coreに基づいています。7つのオーディット（aria-meter-name、aria-toggle-field-name、aria-tooltip-name、document-title、duplicate-id-active、html-lang-valid、object-alt）を除いて、全体的に改善が見られました。object-altとaria-tooltip-nameの両方が2022年の改善で言及されましたが、残念ながらこの改善は2024年には繰り返されませんでした。
この章を通じて、読者が自分のアクセシビリティイニシアティブで適用し、フォローできる実用的なリンクとソリューションを含めました。一貫性のため、「障害者」というアイデンティティファーストの用語も広く使用されていることを認識していますが、章全体を通じて人中心言語の「障害を持つ人々」を使用することにしました。私たちの用語選択は、どちらの用語がより適切かを示唆することを意図したものではありません。
読みやすさ
Webでの情報やコンテンツの読みやすさは重要です。Webサイトのコンテンツの読みやすさに貢献するさまざまな要因があります。これらの側面を考慮することで、インターネット上のすべての人がコンテンツを簡単に消費できるようになります。このレポートでは測定可能なもの内容をカバーしており、平易な言語は読みやすさにとって重要ですが、測定するのは簡単ではありません。Flesch–Kincaidのような比較的単純な数学的読みやすさスコアがあります。一部の人々はそれを英語の読みやすさを決定するために使用していますが、Webはグローバルです。言語は難しく、もっとも人気のある言語間でも適用できる自動平易言語テストについて合意された標準はありません。
カラーコントラスト
カラーコントラストとは、ユーザーがコンテンツを見ることができるように、ページの要素の前景色と背景色の違いを指します。WCAGがコントラストガイドラインに準拠する方法を非常に明確にしているにもかかわらず、Webサイトがテキストやアイコンなどの重要な要素で不十分なコントラストを持つことは非常に一般的です。
通常サイズのテキスト（24pxまで、または太字の場合は18px）についてWCAGで定義された最小コントラスト要件は、AA適合性では4.5:1、AAA適合性では7:1です。ただし、より大きなフォントサイズの場合、より低いコントラストでも大きなテキストは読みやすさが向上するため、コントラスト要件は3:1のみです。
Google Lighthouseは、ほとんどのカラーコントラスト問題を簡単にテストできますが、すべてではありません。誰もがワークフローに簡単に組み込むことができる色の組み合わせをチェックするためのオープンソースツールが幅広くあります。一般的なコントラスト感度を持っている場合、十分なコントラストの自分の認識に依存することはできないため、これらのツールの使用が必要であることに注意することが重要です。
Lighthouseテストでは、モバイルサイトの29%とデスクトップサイトの28%が十分なテキストのカラーコントラストを持っていることが判明しました。これは過去数年間と比較して中程度の改善ですが、基本的な読みやすさに必要なレベルをまだはるかに下回っています。
カラーコントラストは年齢を重ねるにつれてより重要になります。また、人々が眼鏡を持っていない場合や屋外でコンテンツを読む必要がある場合など、一時的な障害や状況的制限にとって定期的に問題となるものでもあります。ブラウザーやオペレーティングシステムがライト、ダーク、ハイコントラストモードのサポートを実装しているため、適切なコントラストを達成することはより困難になっています。これらはブラウザーやオペレーティングシステムによってよくサポートされていますが、まだほとんどのWebサイトではよくサポートされていません。サイトがユーザーの設定した好みに従うことへの需要が高まっており、複数のタイプの障害がユーザーにこのコントロールを与えることから恩恵を受けることができます。詳細については、以下のユーザー設定セクションを参照してください。
ズームとスケーリング
これまで以上に、ユーザーは超ワイドな曲面スクリーンからモバイルフォン、さらには時計まで、さまざまな技術でWebサイトと関わっています。スケーリングを無効にすることは、何が自分にとって最適に機能するかを定義するユーザーエージェンシーを奪います。WCAGでは、Webサイトのテキストは、コンテンツや機能の損失なしに少なくとも200%まで拡大できる必要があると要求しています。
多くの人々がズーム機能を無効にする理由を完全に理解していないため、ズーム機能を無効にしないことの重要性を強調するために、2022年に以前にハイライトしたAdrian Roselliの投稿を再訪しています。
ズームとスケーリングを無効にしているサイトの減少が見られることを嬉しく思います。2022年のモバイルユーザーのデータと比較すると、スケーリングを無効にしたサイトが2%少なく、最大スケール1を無効にしたサイトが4%少なくなっています。デスクトップの平均は、前回のレポートと比較して両方とも2%下がりました。ユーザーはブラウザーを設定してこの設定をオーバーライドできますが、一部のデフォルトは依然として作成者の好みを尊重します。
サイトがズームを無効または制限しているかを確認するには、ページのソースを確認し、<meta name="viewport">を検索します。maximum-scale、minimum-scale、user-scalable=no、またはuser-scalable=0でタグ付けされている場合。理想的には、コンテンツのサイズ変更に制限はないはずですが、WCAGは200%拡大の必要性のみを指定しています。
<number>は両方で2%、最後にptはデスクトップで15%、モバイルで14%です。フォントサイズの定義方法も読みやすさに影響し、ピクセルは他の単位ほど柔軟ではありません。ピクセル（px）の使用はデスクトップで65%、モバイルで66%です。emの使用は2022年の6%から9%に増加しました。remは2022年には6%でしたが、現在は4%に減少しています。2022年以降、emやremの使用に大幅な増加はありませんが、ユーザーがブラウザー設定でフォントサイズを増減する場合、しばしばユーザーにより良い体験を提供します。
言語識別
lang属性で言語を識別することは、スクリーンリーダーのサポートを向上させ、自動ブラウザー翻訳を促進します。この機能はすべてのユーザーに恩恵をもたらします。たとえば、lang属性がない場合、Chromeの自動翻訳機能は不正確な翻訳を生成する可能性があります。Manuel Matuzovićは、不足しているlang属性が翻訳エラーにつながる可能性の例を提供しています。lang属性は、Chen Hui-Jingが指摘するように、異なる言語と読み方向のWebページをスタイリングする際にも役立ちます。
2022年には、モバイルWebサイトの83%がlang属性を含んでいましたが、2年後には86%になっているのは有望です。ただし、これはWCAGの下でレベルA適合性の問題であるため、まだ改善の余地があります。この基準を満たすには、lang属性を認識されたプライマリ言語タグとともに<html>タグに追加する必要があります。言語を適切に定義することは重要です。テンプレートが新しいWebサイトを作成するためにコピーされる場合、コンテンツの言語とコードの言語属性（lang=”en”）の間に不一致が生じることがあります。
また、ページ言語がありますが、ページには多くの場合複数の言語が含まれていることを覚えておいてください。ページに複数の言語が含まれている場合、lang属性を他のタグにも適用できます。W3Cには言語の部分への対処方法についての良いドキュメントがあります。
ユーザー設定
現代のCSSにはレベル5メディアクエリが含まれており、これにはユーザー設定メディアクエリが含まれます。ユーザー設定メディアクエリは、ユーザーが自分に合った設定を選択できるようにすることで、アクセシビリティを向上させます。これには、ダークモードなどの個人の好みに合ったカラースキームやコントラストモードの選択が含まれます。ユーザーは、前庭障害のあるユーザーに有益な、ページのアニメーションを最小化することも選択できます。
prefers-reduced-motionメディアクエリを使用し、12%のサイトがprefers-color-schemeを使用し、prefers-contrastはデスクトップとモバイルサイトの1%未満で使用されていることを示す棒グラフ。モバイルサイトの50%以上がprefers-reduced-motionメディアクエリを含んでいることがわかりました。これは2022年の34%から増加しています。これは重要です。なぜなら、デジタルアニメーションは前庭障害のある人に害を与える可能性があるからです。このクエリを使用することで、そのようなアニメーションを適応または削除してアクセシビリティを向上させることができます。Mozillaの開発者コミュニティには、モーションセンシティブなサイトの構築に関する優れたリソースがあります。
サステナビリティの章には、アニメーションの使用の増加とデジタルサステナビリティへの影響について素晴らしい統計があります。
コントラストについては、デスクトップとモバイルWebサイトの12%のみがprefers-color-schemeメディアクエリを利用しており、これは2022年の8%から増加しています。コンテンツの読みやすさを向上させるために、ユーザーが表示モードを調整できるようにすることは良い慣行です。prefers-color-schemeクエリは、ブラウザーがユーザーの好みのカラースキームを検出し、ライトモードとダークモードをサポートできるようにします。prefers-contrastクエリは、ハイコントラストモードを有効にすることで、視力の低いユーザーや光過敏症のユーザーにとって価値があります。
forced-contrastのサポートは、2024年にデスクトップで約4%増加して14%になりました。強制色モードは、色のコントラストの向上を通じてテキストの読みやすさを向上させるために設計されたアクセシビリティ機能です。有効になると、ユーザーのオペレーティングシステムがほとんどの色関連のスタイルを制御し、Webサイトの色設定をオーバーライドします。このモードは、より予測可能なテキストと背景のコントラストを確保するために、背景画像などの一般的なパターンを無効にします。
もっともよく知られた実装は、現在コントラストテーマと呼ばれるWindowsのハイコントラストモードです。これらのテーマは、低コントラストと高コントラストのオプションを持つ代替カラーパレットを提供し、ユーザーがシステムカラーを好みに合わせてカスタマイズできるようにします。-ms-high-contrastの使用は2024年にわずかに減少し、約23%になりました。これはEdgeやChromeでエミュレートできるため、テストが簡単になりました。
ナビゲーション
Webサイトのナビゲーションについて話すとき、ユーザーがさまざまな方法と入力デバイスを使用する可能性があることを認識することが重要です。マウスを使ってスクロールする人もいれば、キーボード、スイッチコントロールデバイス、またはスクリーンリーダーを使って見出しを通ってナビゲートする人もいます。Webサイトを設計するとき、使用するデバイスや支援技術に関係なく、すべてのユーザーにとって効果的に機能することを確保することが重要です。ワイドスクリーンテレビと音声インターフェース（SiriやAmazon Alexaなど）の両方が、ナビゲーションの設計方法に課題をもたらします。サイトに優れたセマンティック構造を構築することは、スクリーンリーダーユーザーがサイトをナビゲートするのに役立ちますが、他の多くのタイプの技術のユーザーにも役立ちます。
フォーカス表示
フォーカス表示は、主にキーボードやその他の代替ナビゲーションデバイスを使ってWebサイトをナビゲートするユーザーにとって重要です。WebAimには、運動能力が限られた人のための支援技術について優れたリソースがあります。これらのデバイスは、制御できるものを最大化するためにユーザーによってカスタマイズされています。これらのデバイスでは、可視的なフォーカススタイルとフォーカス順序の管理方法に多くの類似点がありますが、キーボードのみのユーザーとは異なる場合があります。
ほとんどの自動テストは、フォーカス順序やキーボードトラップをテストしません。Lighthouseは、サイトがキーボードナビゲーション可能であることを伝えることはできません。それができることは、サイトがキーボードナビゲーション可能でない場合に、必要不可欠ないくつかの基本的なテストに失敗したことを伝えることだけです。Lighthouseは、Equesのaxeルールを使用してベストプラクティスを評価しています。フォーカス表示で完璧なスコアを持っていても、ページを手動でテストする必要があります。Lighthouseは以下をテストすることを推奨しています：
Accessibility Insightsは、Dequeのaxeを活用する優れたオープンソースツールです。このChrome/Edge拡張機能は、キーボードのみのテストを支援し、開発者が他のテストを通じてガイドできます。Tab Stops機能は、キーボードのみのユーザーがWebサイトを通じて進歩する優れた視覚的指標です。
フォーカススタイル
WCAGは、ページを移動する際に現在フォーカスされている要素をユーザーが識別できるようにするため、すべてのインタラクティブコンテンツに可視的なフォーカスインジケータを義務付けています。
Webサイトの53%が:focus {outline: 0}を適用していることがわかりました（2022年には86%でした）。これは、フォーカスされたインタラクティブ要素のブラウザーが提供するデフォルトのアウトラインを削除します。一部のWebサイトはこれをオーバーライドするためにカスタムスタイルを実装していますが、必ずしもそうではなく、ユーザーが現在フォーカスされている要素を識別するのが困難になり、ナビゲーションを妨げます。Sara SoueidanはWCAG準拠のフォーカスインジケータの設計について貴重なガイダンスを提供しています。ポジティブな点として、Webサイトの12%が現在:focus-visibleを使用しており（2022年の9%、2021年の0.6%から増加）、これはフォーカスインジケータを表示するタイミングを決定するためにブラウザーヒューリスティクスを使用する疑似クラスです。これは、アクセシビリティプラクティスの大幅な改善です。
tabindex
一般的に、HTMLはtabindexを設定しなくてもフォーカス順序が設定されます。CSSとJavaScriptは、DOMでの表示方法に変更を引き起こすことがよくあります。tabindex属性は、要素がフォーカスを受け取ることができるかどうかを制御し、キーボードフォーカスまたは”tab”順序での位置を決定します。
分析によると、モバイルWebサイトの63%とデスクトップWebサイトの64%がtabindexを利用しています（それぞれ60%と62%から増加）。この属性は、アクセシビリティに影響を与える可能性があるいくつかの目的に役立ちます：
tabindex="0"は、要素をシーケンシャルキーボードフォーカス順序に配置します。カスタムインタラクティブ要素とウィジェットは、フォーカスシーケンスに含まれることを確保するためにtabindex="0"を持つ必要があります。tabindex="-1"は、キーボードフォーカス順序から要素を削除しますが、JavaScriptを介してプログラマティックにフォーカスできるようにします。- 正のtabindex値は、デフォルトのキーボードフォーカス順序をオーバーライドし、しばしばWCAG 2.4.3 - フォーカス順序の問題につながります。
非インタラクティブ要素をキーボードフォーカス順序に配置することは避けることが重要です。これは、見ることができるスクリーンリーダーユーザーや代替ナビゲーションユーザーにとって混乱を招く可能性があります。
tabindex属性を使用するすべてのWebサイトのうち、4%が正の値を使用しています（2022年の7%から減少）。正のtabindex値を使用することは、自然なタブ順序を破壊するため、一般的に悪い慣行と考えられています。Karl Grovesはこのトピックについて洞察的な記事を提供しています。
ランドマーク
ランドマークは、Webページを異なるテーマ領域に構造化するのに役立ち、支援技術のユーザーがより簡単にナビゲートできるようにします。たとえば、ローターメニューは異なるページランドマーク間をナビゲートするのに役立ち、スキップリンクは<main>などの特定のランドマークにユーザーを誘導できます。ランドマークは、さまざまなHTML5要素を使用して定義できます。このセマンティック構造は、Web Accessibility Initiative – Accessible Rich Internet Applications（ARIA）のランドマークロールでも適用できます。ただし、ARIAの第一のルールに従って、可能な限りネイティブHTML5要素を使用することが最良です。
ARIAランドマークは伝統的にスクリーンリーダーユーザーにのみ表示されていましたが、一部のサイトでは、見出しとランドマークをページ固有の目次に集約するこのオープンソースSkipToスクリプトなどのツールを使用し始めています。ドキュメント構造をユーザーに公開することは、すべての人の理解を助けます。SkipToは、本来基本的なブラウザー機能であるべきものを提供します。これは、後のセクションで議論されるスキップリンクを超えるものです。
| 要素タイプ | % 要素 | % ロール | % 両方 |
|---|---|---|---|
main |
37% | 17% | 44% |
header |
65% | 12% | 66% |
nav |
66% | 19% | 70% |
footer |
65% | 10% | 67% |
roleの使用（デスクトップ）。
ほとんどのWebページでもっとも一般的に期待されるランドマークには、<main>、<header>、<nav>、<footer>が含まれます。私たちの調査結果は以下のことを明らかにしています：
- すべてのページの37%のみがネイティブHTML
<main>要素を使用している - すべてのページの17%が
role="main"を持つ要素を持っている - 43%がそれらのいずれかを使用している（2021年の35%から増加）
Scott O’Haraのランドマークに関する記事は、アクセシビリティを向上させるための貴重な洞察を提供しています。
見出し階層
見出しは、支援技術を使用する人々を含むすべてのユーザーにとって、Webサイトをナビゲートするのに役立つため重要です。支援技術は、ユーザーが興味のある特定のセクションにジャンプできるようにします。Marcy Suttonの見出しとセマンティック構造に関する記事で強調されているように、見出しは目次のように機能し、ユーザーと検索エンジンが特定のコンテンツ領域に効率的にナビゲートできるようにします。
残念ながら、見出し階層は過去2年間で悪化しています。Lighthouseは適切に順序付けられた見出しを追跡し、1%をわずかに上回る下落をしました：
見出しレベルは異なるフォントサイズと関連付けられており、コンテンツを構造化するのではなく、Webサイトを視覚的にスタイルするために頻繁に誤用されています。この誤用は、ユーザー体験とアクセシビリティツール、そして検索エンジンの両方に悪影響を与えます。CSSは要素をスタイルするために使用すべきであり、見出しタグではありません。
WCAGは、成功基準2.4.5：複数の方法で概説されているように、ヘッダーのプライマリメニューを超えて複数のナビゲーションオプションをWebサイトが提供することを義務付けています。たとえば、認知障害を持つ人を含む多くのユーザーは、大きなWebサイトでページを見つけるために検索機能を好みます。
現在、モバイルWebサイトの21%とデスクトップWebサイトの22%が検索入力を含んでいます（それぞれ2022年の23%と24%から減少）。これは良いトレンドではありません。
スキップリンク
スキップリンクは、キーボード、スイッチコントロールデバイス、またはその他の代替ナビゲーションツールに依存するユーザーが、フォーカス可能な要素をすべてナビゲートすることなく、Webページのさまざまなセクションをバイパスできるようにします。一般的な使用は、プライマリナビゲーションをスキップして<main>コンテンツに直接移動することです。とくに、広範囲なインタラクティブナビゲーションメニューを持つサイトでは、これは一部のユーザーにとってユーザー体験を劇的に改善できます。
デスクトップとモバイルページの24%がスキップリンクを含んでいる可能性があることがわかりました。これにより、ユーザーはページの不要な部分を避けることができます。私たちの分析は、ページの上部付近に配置されたスキップリンク（ナビゲーションをバイパスするものなど）のみを検出するため、この割合は実際にはより高い可能性があります。スキップリンクは、上記のSkipToスクリプトで説明したように、ページの他のセクションをスキップするためにも使用できます。
ドキュメントタイトル
説明的なページタイトルは、ページ、タブ、ウィンドウ間をナビゲートするために重要です。スクリーンリーダーなどの支援技術は、これらのタイトルを声に出して読み、ユーザーが自分の場所を把握するのに役立ちます。
<title>要素を使用し、それらのタイトルの69%が4つ以上の単語を持ち、デスクトップの7%とモバイルの6%のタイトルがレンダリング時に変更されることを示す棒グラフ。モバイルWebサイトの97%がドキュメントタイトルを含んでいますが、4つ以上の単語を持つタイトルを持っているのは69%のみです。私たちの分析は、ホームページと2次ページに限定されているため、内部ページについての洞察は限られています。2次ページは、4つ以上の単語の説明的なタイトルを持つ可能性が8%高いことがわかりました（2024年の平均で78%）。理想的には、タイトルには、ナビゲーションを向上させるためのページのコンテンツの簡潔な説明とWebサイトの名前の両方が含まれるべきです。
レンダリング時に変更されたタイトル値は、初期HTMLタイトルとJavaScriptが読み込まれた後のページの最終値の比較から導出されます。データは、スキャンされたデスクトップサイトの7%がタイトルのコンテンツを動的に変更していることを示しています。2次ページは、ホームページよりもタイトルを変更する可能性がわずかに低くなっています。
テーブル
テーブルは、2つの次元を使用してデータと関係を提示します。アクセシビリティのために、テーブルは、支援技術を使用するユーザーがデータを理解してナビゲートするのに役立つために、キャプションやヘッダーセルなどの要素を持つよく構造化された形式が必要です。<caption>要素を使用するキャプションは、スクリーンリーダーのコンテキストを提供するためとくに重要です。現在、デスクトップサイトの1.6%が<caption>を使用しており（2022年の1.3から微増）、これはテーブルをよりアクセシブルにするための重要な側面です。
| テーブルサイト | すべてのサイト | |||
|---|---|---|---|---|
| デスクトップ | モバイル | デスクトップ | モバイル | |
| キャプション付きテーブル | 5.5% | 4.8% | 1.6% | 1.5% |
| プレゼンテーションテーブル | 4.4% | 5.0% | 3.1% | 4.2% |
CSS FlexboxとGridのおかげで、テーブルをページレイアウトに使用する必要はありません。必要に応じて、テーブルはrole="presentation"を使用してセマンティクスを明示的に削除し、レイアウトの目的で使用されるときの混乱を避けることができます。モバイルテーブルの4%がこの回避策を使用していることがわかります（2022年の1%と比較）。
フォーム
フォームは、ログインや購入などのユーザーインタラクションに不可欠です。障害を持つユーザーにとって、アクセシブルなフォームは、タスクを完了し、同等の機能を実現するために重要です。フォームは、静的なHTMLページよりも開発者が構築するのがはるかに複雑であることも多いです。
<label> 要素
<label>要素は、入力フィールドをアクセシブルな名前とリンクするための推奨される方法です。for属性を使用して入力のidとマッチさせることで、適切なプログラム的関連付けが保証され、フォームの使いやすさが向上します。さらに、label要素が適切に使用されると、ユーザーはラベルをクリックまたはタップしてフォームフィールドにフォーカスできます。
たとえば：
<label for="emailaddress">メール</label>
<input type="email" id="emailaddress">
label要素からアクセシブルな名前を取得。デスクトップ入力の24%とモバイルの25%がplaceholder属性からアクセシブルな名前を取得。aria-labelが9%を担当。value属性が3%を貢献。title属性がデスクトップの3%とモバイルの2%の調査サイトに貢献。残念ながら、モバイル入力の13%がアクセシブルな名前を欠いています（2022年の38%から大幅に改善）。モバイルサイトの15%のみが<label>を使用しており（2022年の19%から減少）、これはスクリーンリーダーや音声テキストツールに依存するユーザーを妨げる可能性があります。アクセシブルな名前は常に使用する必要があり、サイトは、アクセシブルな名前が入力の表示ラベルと一致することを確保することで、スクリーンリーダーを超えた支援技術をサポートする必要があります。WCAG 2.1は、音声コントロールなどの技術がより良くサポートされることを確保するために、2.5.3 Label in Name（レベルA）を追加しました。aria-labelとaria-labelledbyの使用は、HTML <label>が使用できない場合にのみ使用する必要があります。
placeholder 属性
placeholder属性は、入力形式の例を提供します。アクセシブルな名前を提供する方法として<label>を置き換えるべきではありません。プレースホルダーが表示ラベルを提供する唯一の方法である場合、ユーザーが入力を開始するとその参照点が消えます。ブラウザーがデフォルトでプレースホルダーテキストにWCAGを満たすのに十分なコントラストを提供しないことは新しい懸念ではありません。さらに、それらは常にスクリーンリーダーでサポートされているわけではありません。より良い解決策は、入力の下または横に入力形式の例を表示し、aria-describedbyを使用してプログラム的に入力に接続することです。
モバイルサイトの57%とデスクトップサイトの55%がプレースホルダーのみを使用しており、これはアクセシビリティの問題につながる可能性があります。HTML5ガイドラインによると、プレースホルダーはアクセシビリティのためにラベルを置き換えるべきではありません。
アクセシビリティと制御の使いやすさを低下させるため、ラベルの代替としてのplaceholder属性の使用は、高齢者ユーザーや認知、運動、細かい運動技能、または視覚障害を含むさまざまなユーザーにとって有害です。
必須情報
フォームで必須フィールドを示すことは重要です。HTML5以前は、アスタリスク（*）が一般的に使用されていましたが、これは視覚的な手がかりのみであり、エラー検証を提供しません。さらに、HTML5のrequired属性とaria-required属性は、必須フィールドを示すためのセマンティクスを改善できます。
aria-requiredが41%と40%で使用され、アスタリスクが20%と19%で使用され、これら3つのうち2つが実装されているのが14%と13%、すべて3つが使用されているのがデスクトップで2%、モバイルで1%であることを示す棒グラフ。現在、
- モバイルサイトの65%がrequired属性を使用している（2022年の67%から減少）
- 40%が
aria-requiredを使用している（2022年の32%から増加） - 19%が依然としてアスタリスクのみに依存している（2022年の22%から減少）
これは、requiredとaria-requiredで補完されない限り避けるべきです。
キャプチャ
WebサイトはしばしばCAPTCHAを使用して、訪問者が人間であり、ボットではないことを確認します。CAPTCHAは「Completely Automated Public Turing Test to Tell Computers and Humans Apart」の略で、悪意のあるソフトウェアを防ぐために一般的に使用されています。
これらのテストは、とくに低視力や読み障害のある人にとって、すべての人にとって困難な場合があります。W3Cは、探索する価値のある視覚的CAPTCHAの代替案を提案しています。
Webでのメディア
メディアのアクセシビリティは重要です。障害を持つ人々は、メディアコンテンツを理解し、相互作用するための代替手段を必要としています。たとえば、盲目のユーザーは画像や動画の音声説明を必要とし、耳の聞こえないまたは難聴のユーザーは手話やキャプションを必要とします。
音声のみおよび動画のみのコンテンツには、トランスクリプトが必要です。画像などの非テキストコンテンツには、同等の代替案が必要であり、それらが単に装飾的な場合は、セマンティック的にそのようにマークされる必要があります。
メディアプレーヤーは、ユーザーが音声または動画コンテンツを直接インラインで再生できるようにするために、しばしばページに埋め込まれます。この場合、オープンソースのAble Playerなどのアクセシブルなプレーヤーを使用することが重要です。
画像
画像は、スクリーンリーダーにテキスト説明を提供するalt属性を持つことができます。画像の69%がGoogle Lighthouseのalt テキストを持つ画像のオーディットに合格しました（2022年の59%から上昇）。これは注目すべき増加であり、とくに数値が2021年から2022年にかけてわずか1%しか増加しなかったためです。
alt テキストは、画像のコンテキストを反映する必要があります。装飾的な画像の場合はalt=""が適切で、意味のある画像には情報的な説明が必要です。ファイル名をalt テキストとして使用することは避けることも重要です。これはほとんど関連する情報を提供しないためです。現在、モバイルの7.5%とデスクトップの7.2%のサイトがこれを行っています。
alt テキスト値でもっとも一般的に見つかるファイル拡張子（空でないalt属性を持つサイトの場合）は、jpg（およびjpeg）、png、ico、svgです。これは、CMSまたはその他のコンテンツ管理システムがalt テキストを自動生成するか、コンテンツエディターに提供を要求していることを示している可能性があります。しかし、CMSが単に画像ファイル名をalt属性に含めるだけの場合、通常はユーザーに利益をもたらしません。したがって、意味のあるテキスト説明を使用することが重要です。
alt 属性の長さ。
alt テキストのない画像は現在15%でわずかに減少しており、2022年の値から3%減少しています。デスクトップとモバイルの両サイトでalt テキスト属性の30%が空であることがわかりました。これは2022年の27%から増加しています。空のalt属性は、純粋に装飾的で、スクリーンリーダーやその他の支援技術によって説明される必要のない画像にのみ使用されるべきです。ほとんどの画像はページコンテンツに貢献するため、一般的に意味のある説明を含めるべきです。
残念ながら、alt属性の17%が10文字以下を含んでおり、これは2022年から1%減少しています。これらの異常に短い説明は、画像を適切に説明するための不十分な情報を示唆しています。これらの一部はリンクのラベル付けに使用される場合があり、これは受け入れられますが、多くは十分な説明的コンテンツを欠いています。
これらの統計を変更するために、確実にもっと多くのことが行えます。オーサリングツールアクセシビリティガイドライン（ATAG）2.0で提案されているように、より良いドキュメントと検証を通じて作成者をサポートするコンテンツツールは非常に少ないです。ますます多くの人々が、通常はクライアント側でalt テキストを作成するために人工知能（AI）を検討しています。Brian TeemanはAI生成Alt テキストについて興味深い批評を書きました。
有望なアプローチの1つは、AIDmiでCKEditorにAIを組み込んだDrupalのMike Ferandaからのものです。alt テキストがどのようなものであるかの例を作成者に示すことで、彼らが伝えようとしていることを反映するようにそれを編集する可能性が高くなります。このアプローチは他の編集ツールにも適用できます。
音声と動画
<track>要素は、キャプションや説明など、<audio>および<video>要素にタイムテキストを提供するために使用されます。これは、聴覚障害や視覚障害のあるユーザーがコンテンツを理解するのに役立ちます。
<audio>要素を持つサイトが<track>要素を含む。
<video>要素の場合、数値はデスクトップとモバイルサイトの両方で0.5%、モバイルサイトで0.65%とわずかに高くなっています。これらの統計は、第三者サービスがテキスト代替を提供する可能性が低い<iframe>を介して埋め込まれた音声または動画をカバーしていません。私たちの業界はもっと多くのことができます。
ARIAによる支援技術
Accessible Rich Internet Applications（ARIA）は、障害を持つ個人のWebアクセシビリティを向上させるために設計されたHTML5要素の属性セットを提供します。しかし、ARIA属性の過度な使用は、時として解決する以上の問題を引き起こすことがあります。ARIAは、ネイティブHTML5要素が完全にアクセシブルな体験を確保するのに不適切な場合にのみ使用されるべきであり、必要以上に置き換えたり使用したりするべきではありません。
ARIAロール
支援技術が要素と相互作用する際、要素のロールはユーザーがそのコンテンツとどのように関わるかを伝えるのに役立ちます。
たとえば、タブ式インターフェースは、その構造を正確に表現するために、しばしば特定のARIAロールを必要とします。WAI-ARIAオーサリングプラクティスデザインパターンは、ネイティブHTMLに相当するものがないため、コンテナ要素にtablistロールを割り当てることを提案して、アクセシブルなタブ式インターフェースの作成方法を概説しています。
HTML5は、組み込みのセマンティクスとロールを持つ多数のネイティブ要素を導入しました。たとえば、<nav>要素は本質的にrole="navigation"を持っているため、ARIAでこのロールを明示的に追加する必要がありません。
モバイルサイトの50%以上が、少なくとも1つの要素にrole="button"が割り当てられたホームページを持っていることがわかりました（2022年の33%、2021年の29%、2020年の25%から上昇）。この増加は懸念されます。なぜなら、Webサイトがカスタムボタンとして<div>または<span>要素を使用しているか、<button>要素に冗長にロールを適用している可能性があることを示唆しているからです。どちらの慣行も問題があり、可能な限り<button>などのネイティブHTML要素を使用するというARIAの基本原則に違反しています。
role="button"を持つWebサイト。
Webサイトの18%がrole="button"を持つ少なくとも1つのリンクを持っています（2022年の21%からわずかに減少）。ARIAロールを追加することで支援技術に要素の目的を知らせることができますが、その要素をネイティブの対応要素のように機能させることはできません。リンクとボタンは異なる動作をするため、この不一致はキーボードナビゲーションの問題につながる可能性があります。たとえば、リンクはスペースキーでアクティブ化されませんが、ボタンはアクティブ化されます。
presentation ロールの使用
要素にrole="presentation"が割り当てられると、その要素は、必要な子要素のセマンティクス（たとえば、<ul>内のリスト項目、またはテーブル内の行とセル）とともに、固有のセマンティクスを失います。たとえば、親の<table>または<ul>要素にrole="presentation"を適用すると、このロールが子要素に伝播し、テーブルまたはリストのセマンティクスが失われます。
role="presentation"でセマンティクスを削除することは、要素が視覚的な存在のみを持ち、その構造が支援技術によって認識されないことを意味します。要素のコンテンツはスクリーンリーダーによって読み上げられますが、セマンティクスに関する情報は提供されません。
role="presentation"を持っています。
これは懸念されます。なぜなら、2022年にはすでにデスクトップサイトの25%とモバイルサイトの24%で高い値だったからです。
同様に、role="none"を使用することも要素のセマンティクスを削除します。今年、サイトの5%がrole="none"を使用しており、2022年の11%から減少しています。<table>が純粋にレイアウトに使用される場合など、まれなケースでは有用かもしれませんが、一般的にはアクセシビリティに有害である可能性があるため、慎重に使用する必要があります。
ほとんどのブラウザーは、リンクや入力、またはtabindex属性を持つ要素を含むフォーカス可能な要素のアクセシビリティツリーでロールを公開する際に、role="presentation"とrole="none"を無視します。同様に、これらのロールを持つ要素が（aria-describedbyなどの）グローバルARIA状態またはプロパティを含む場合、presentationとnoneロールは無視される可能性があります。
ARIAによる要素のラベリング
DOMに加えて、ブラウザーにはアクセシビリティツリーがあり、アクセシブルな名前、説明、ロール、状態などのHTML要素の詳細が含まれています。この情報は、アクセシビリティAPIを通じて支援技術に伝達されます。
要素のアクセシブルな名前は、そのコンテンツ（たとえば、ボタンのテキスト）、属性（たとえば、画像のalt属性）、または関連する要素（たとえば、フォームコントロールにリンクされたラベル）から取得できます。複数のソースが利用可能な場合、アクセシブルな名前のソースを決定するために使用される階層があります。アクセシブルな名前についてさらに読むには、Léonie Watsonの記事“アクセシブルな名前とは何か？”が貴重なリソースです。
aria-labelがサイトの65%で使用され、aria-hiddenが63%、aria-expandedが35%と34%、aria-liveが29%と28%、aria-controlsが29%と28%、aria-labelledbyが27%と26%、aria-currentが25%と26%、aria-haspopupが25%と23%、aria-describedbyが18%と16%、最後にaria-atomicが15%と14%で使用されていることを示す棒グラフ。アクセシブルな名前の割り当てを支援する2つのARIA属性は、aria-labelとaria-labelledbyです。これらの属性は、ネイティブに導出されたアクセシブルな名前よりも優先され、控えめに、必要な場合にのみ使用されるべきです。スクリーンリーダーでアクセシブルな名前をテストし、障害を持つ個人を関与させることは、名前が役立ち、アクセシビリティを妨げないことを確保するために重要です。
私たちは、評価されたページのほぼ66%がaria-label属性を持つ少なくとも1つの要素を特徴としていることを観察しました（2022年のデスクトップの58%とモバイルの57%から増加）。これにより、アクセシブルな名前のためのもっとも頻繁に使用されるARIA属性となっています。さらに、デスクトップページの27%とモバイルページの25%がaria-labelledby属性を持つ少なくとも1つの要素を持っていました（両方とも2022年のデータから2%増加）。この傾向は、より多くの要素がアクセシブルな名前を割り当てられている一方で、視覚的ラベルを欠く要素の増加も示している可能性があります。これは、認知障害のあるユーザーや音声入力ユーザーにとって困難となる可能性があります。
aria-label属性が24%で使用され、10%と12%でアクセシブルな名前がなく、value属性が6%と5%で使用され、title属性が両方で1%使用されていることを示す棒グラフ。ボタンは通常、コンテンツまたはARIA属性からアクセシブルな名前を受け取ります。ARIAガイドラインによると、可能であれば要素がARIA属性よりもコンテンツからアクセシブルな名前を導出することが好ましいです。私たちは、デスクトップのボタンの59%がテキストコンテンツからアクセシブルな名前を取得していることを発見しました。これは2022年の61%からわずかに減少しています。aria-label属性の使用は、デスクトップで23.9%にわずかに増加しており（2022年の20%から）、より多くのサイトがアクセシブルな名前にaria-label属性を使用していることを意味します。
一部のケースでは、複数のボタンが同じコンテンツを持っているが異なる機能を持つ場合や、ボタンが画像やアイコンのみを含む場合など、aria-labelが有用です。
コンテンツの隠蔽
時として、視覚的インターフェースには支援技術のユーザーにとって有益でない冗長な要素が含まれています。このような場合、aria-hidden="true"を使用してスクリーンリーダーから要素を隠すことができます。ただし、要素を削除することで、視覚的に提示されているものと比較してスクリーンリーダーユーザーにとって情報が少なくなる場合、このアプローチは使用すべきではありません。支援技術からコンテンツを隠すことは、アクセシブルにすることが困難なコンテンツを回避する方法であってはなりません。
aria-hidden属性を持つ少なくとも1つの要素を持つ。
この属性を使ってセマンティックコンテンツを隠したり表示したりすることは、アクセシビリティAPIにコンテンツがいつ隠されているかを示すために、現代のインターフェースでよく行われる慣行です。この例として、見出しのリストの下にあるコンテンツが隠されており、ユーザーが見出しの1つを選択して関連するコンテンツを表示するまで隠される、アコーディオンコンポーネントがあります。
ARIAはアクセシビリティに大きな影響を与える可能性があり、慎重に使用する必要があります。適切なメッセージを伝えるためにARIAを正しく適用することが重要です。
たとえば、開示ウィジェットは、要素が展開または折りたたみによって表示または非表示になったときに支援技術に合図するために、aria-expanded属性を使用する必要があります。私たちの観測によると、モバイルページの34%が少なくとも1つのaria-expanded属性を持つ要素を持っており、これは2022年から約5%増加しています。
スクリーンリーダー専用テキスト
開発者がスクリーンリーダーユーザーに追加情報を提供するために使用する一般的なアプローチは、スクリーンリーダーからはアクセス可能に保ちながら、CSSでテキストを視覚的に隠すことです。このCSS技術により、テキストがアクセシビリティツリーに含まれながら、視覚的には隠されたままになることが保証されます。
sr-onlyとvisually-hiddenクラス名は、開発者とUIフレームワークによって、スクリーンリーダーのみがアクセス可能なテキストを作成するために頻繁に使用されます。たとえば、BootstrapとTailwindはこの目的でsr-onlyクラスを含んでいます。私たちは、デスクトップページの16%とモバイルページの15%がこれらのCSSクラスの一方または両方を使用していることを発見しました（それぞれ2022年から1ポイント増加）。すべてのスクリーンリーダーユーザーが視覚障害を持っているわけではないため、スクリーンリーダー専用のソリューションに過度に依存することは避けるべきであることに注意することが重要です。この技術がインタラクティブ要素のアクセシブルな名前で使用される場合、コンピューターを音声で制御する人にとって、要素と相互作用するためにどのコマンドを与えるべきかを知ることが困難になる可能性があります。
動的レンダリングコンテンツ
時として、DOMの新しいまたは更新されたコンテンツについてスクリーンリーダーに通知することが必要です。たとえば、フォーム検証エラーは伝達されるべきですが、遅延読み込み画像はアナウンスする必要がないかもしれません。DOMの更新は、非破壊的な方法で行われるべきです。
aria-liveを使用するライブリージョンを持つデスクトップページ。
ARIAライブリージョンは、スクリーンリーダーがDOMの変更をアナウンスできるようにします。私たちは、デスクトップページの29%がaria-live属性を持つライブリージョンを使用しており（2022年の23%から増加）、モバイルページの28%がaria-liveを使用していること（2022年の22%から増加）を発見しました。さらに、ページは暗黙のaria-live値を持つARIAライブリージョンロールを使用しています：
| ロール | デスクトップ | モバイル | 暗黙のaria-live値 |
|---|---|---|---|
status |
9.2% | 8.7% | polite |
alert |
6.9% | 6.7% | assertive |
timer |
0.8% | 0.8% | off |
log |
0.6% | 0.6% | polite |
marquee |
0.1% | 0.1% | off |
aria-live値。
ライブリージョンのバリエーションとその使用法について詳しくは、MDNライブリージョンドキュメントをチェックするか、このDequeによるライブデモを試してみてください。
ユーザーパーソナライゼーションウィジェットとオーバーレイ修復
ユーザーは、Webサイトでアクセシビリティウィジェットを見ることにますます慣れています。これらにより、彼らの体験を向上させるアクセシビリティ機能にアクセスできます。アクセシビリティオーバーレイはこれらの1つのタイプであり、通常2つのタイプの技術を含みます：パーソナライゼーションウィジェットとJavaScriptオーバーレイです。オーバーレイは汎用またはカスタムのいずれかです：
- ユーザーパーソナライゼーション：サイト訪問者がサイト内メニューを介してサイトの外観を変更できるようにするツール — フォントやカラーコントラストの調整などの変更
- 自動オーバーレイ修復：複雑なアルゴリズムや人工知能を使用して、ユーザーインターフェースに影響を与える多くの一般的なWCAG問題を自動的にスキャンし、修復を試みる汎用技術
- カスタムオーバーレイ修復：特定の適合性ニーズに対処するためにエキスパート開発者によって書かれたサイト固有のコードで、支援技術との衝突を避けるために、コンテキスト内でアクセシビリティエキスパートによって検証されたもの
ブラウザーはパーソナライゼーションのための優れた組み込みツールを持っていますが、多くのユーザーはそれらについて知りません。一部のサイトは、カスタマイゼーションを簡単にするためにさまざまなアクセシビリティ機能を提供する パーソナライゼーションウィジェット を追加しています。多くの場合、これにはブラウザーに含まれているフォントサイズ、間隔、コントラストが含まれます。これには、Edgeに含まれているテキスト読み上げなどのツールも含まれる場合があります。これはさまざまなユーザーに有用ですが、とくにその環境で自分の支援技術を利用できない人にとって有用です。これらのウィジェットは、支援技術を積極的に使用していないユーザーや、ブラウザーの組み込みアクセシビリティ機能をすでに最大限に活用しているユーザーにとって役立ちます。
使用する場合、これらのツールが支援技術ユーザーを含むユーザー体験（UX）を妨げないことが重要です。そのため、欧州障害フォーラム（EDF）は、アクセシビリティオーバーレイは欧州法との適合性を保証しないと明確に述べたレポートを発表しました：
「支援技術のユーザーは、すでに自分のデバイスとブラウザーを好みの設定に構成しています。オーバーレイ技術は、ユーザーの支援技術と干渉し、ユーザー設定を上書きして、代わりにオーバーレイを使用することを人々に強制する可能性があります。これにより、一部のユーザーグループにとってWebサイトのアクセシビリティが低下し、コンテンツへのアクセスが妨げられる可能性があります。」
オーバーレイ修復 は、オーバーレイ製品でよく見られる2つめのタイプの技術です。自動オーバーレイ修復は、ページがブラウザーでレンダリングされる際に、一般的なWCAG問題を継続的に見つけて対処しようとします。カスタムオーバーレイ修復も、アクセシビリティの障壁を克服するためにJavaScriptで書くことができ、とくにもはや更新できないレガシーコードがある場合に有効です。障害を持つユーザーとのテストを含む適切な手動テストにより、カスタムオーバーレイは効果的なソリューションになり得ます。
人気のある自動オーバーレイが一部のユーザーにとって製品のアクセシビリティを低下させるという文書化された報告が多数あります。
この技術は一部のユーザーの一般的な障壁に対処し、サイトをよりアクセシブルにすることができます。自動オーバーレイは、開発チームがデザインやソースコードに対処することでのみ解決できるより複雑な問題に集中できるようにすることで、組織のアクセシビリティの進歩とコンプライアンスへの道筋を前進させることもできます。
残念ながら、多くのチームはオーバーレイに投資した後、単にアクセシビリティへの投資を停止します。
この技術は、優れたアクセシビリティ実践の必要性を置き換えるものではありません。アクセシビリティは製品ライフサイクルのすべての段階に含まれる必要があります。オーバーレイは、ソースでエラーを修正するよりも常に多くのユーザビリティ、セキュリティ、パフォーマンスの問題を抱えることになります。自動ツールはWebサイトを完全にアクセシブルにしたり、WCAG準拠にしたりできないことを覚えておくことが重要です。
2024年には、デスクトップWebサイトのほぼ2%が既知のアクセシビリティアプリを利用していることを観察しました。これらの製品すべてがアクセシビリティオーバーレイではありませんが、検出可能なオーバーレイは同様の成長傾向を示しています。
UserWayは私たちのデータセットで最も広く使用されているオーバーレイです。
これらのソリューションは、一般的に高トラフィックのWebサイトではあまり使用されません。訪問数でトップ1,000にランクされたサイトでは、わずか0.2%のみがオーバーレイを使用しています。
オーバーレイに関する混乱
国際アクセシビリティプロフェッショナル協会（IAAP）は、アクセシビリティオーバーレイのポジションと推奨事項を概説した論文を発表しました。その中で、IAAPはオーバーレイ技術がユーザーのアクセスを妨げてはならないことを強調しています。さらに、IAAPメンバーは、Webサイトやアプリケーションがオーバーレイ技術で完全にアクセシブルになるという含意の主張をサポートしてはならないと述べています。
多くのオーバーレイプロバイダーによる虚偽の広告宣伝は、アクセシビリティ擁護者からの抗議を促しました：Adrian Roselliの#accessiBe Will Get You Suedは2020年に最初に公開されましたが、ケースが進展するにつれて積極的に更新されています；Lainey Feingoldのアメリカの法的観点。
アクセシビリティを前進させるために使用されるツールや技術の能力と制限を明確に理解することが重要です。企業の能力に関する虚偽の主張は、多くのクライアントを混乱させています。組織は、適用可能なアクセシビリティ要件を満たし、訪問者に最高の体験を提供することを確保するために、適切な調査を行う責任があります。
EU委員会も米国司法省（DOJ）も、Webアクセシビリティ標準がどのように満たされるべきかを述べていません — ただ、それらが満たされなければならないということだけです。DOJ ADA Title IIルール制定から、ルールは「公的機関がこのルールの下で技術標準に適合するために実装する可能性のある内部ポリシーや手順については対処していない」とあります。
一部の事例では、オーバーレイと手動の専門知識の組み合わせがアクセシビリティの改善を加速する可能性があります。
セクターとアクセシビリティ
今年は一連の新しいデータ比較を提供しています。異なるコミュニティがアクセシビリティをどのように扱ってきたかには、認識できる違いがあることを強調したいと思います。良いガバナンスまたは良いデフォルトに基づいているかにかかわらず、重要なアクセシビリティの違いを見ることが可能です。このセクションの著者の希望は、これがさまざまなコミュニティがアクセシビリティをどのように扱うかのレビューを促すことです。
また、このセクションでは、オープンソースツールであるGoogle Lighthouseを使用してWebサイトのアクセシビリティも評価しました。
国別
国情報を特定する方法は2つあります。まずサーバーのGeoIDによる方法、そして第二にトップレベルドメインによる方法です。異なる国でのホスティングの価格のため、一部の国は他の国よりもGeoIDでよく表現されています。同様に、.aiや.ioドメインのように多くのドメインが国とは独立して動作できることを考えると、すべての.ca、.es、または.fiドメインがカナダ、スペイン、またはフィンランドに位置していると仮定することはできません。
アメリカで運営されている多くのサイトがアクセシビリティに関するSection 508ガイドラインの対象となっていることは注目に値します。組織は、アクセシブルなWebサイトを持たないことでADA Title IIIの下でアメリカで訴訟を起こされています。アメリカがもっともアクセシブルな国であることは驚くことではありません。他の管轄区域も、自分たちの地域内で販売したり市民に販売したりする企業を処罰し始めています。ますます多くの人々が欧州アクセシビリティ法を見て、2025年に導入される新しい要件に備えています。
以下のマップは、国別トップレベルドメイン（TLD）によるデスクトップアクセシビリティスコアの平均を示しています。
しかし、TLDをランク付けして非国家コードも含めて見ると、少し理解しやすくなります。
前のチャートと同様に、.eduと.govドメインがもっともアクセシブルです。Section 508とSection 504の下での米国政府は、20年以上にわたってこれを義務の一部としてきました。初期のアクセシビリティ法制と活発な訴訟が、米国でのアクセシビリティの採用を推進してきました。米国外の国々は、WCAG適合のための法制化と執行措置の提供を後から開始しました。Lainey Feingoldはグローバルな法律とポリシーの素晴らしいリストを維持しています。
政府
すべての政府ドメインが一貫したアクセシビリティルールに従っているわけではありませんが、多くの国の政府サイトを分離することができました。一部の国では政府サイトの命名に一貫性がないため、カバーされない例外があります。私たちは世界中のほとんどの政府機関の平均を収集しました。
ほとんどの現代の政府は、WCAG 2.0 AAまたはWCAG 2.1 AAのいずれかにコミットしています。これらのポリシーの実装が等しく提供されていないことは明らかです。これは欧州連合内のアクセシビリティを調べる際にとくに重要で、各加盟国はWebアクセシビリティ指令に基づく法制を実装する必要があります。3年間のEU加盟国レポートを、ここで提供された値や将来のWeb Almanacと比較することが可能であるべきです。米国の平均が87%であることは注目に値します。
オランダ（98%）が確実にトップで、ルクセンブルク（96%）とフィンランド（94%）が続きます。イギリスとオランダはどちらもアクセシビリティを優先する標準化されたデザインシステムを持っています。ルクセンブルクとフィンランドの成功に何が貢献しているのでしょうか？ほとんどのアクセシビリティコンテンツが英語でのみ利用可能であることを考慮すると、これが一部の政府による採用を減少させているのでしょうか？
政府ドメインは主にドメイン名パターンマッチングに基づいて発見されました。政府がドメイン名を使用する方法には多くの不整合がありますが、ここには比較を提供するのに十分な情報があります。.govは米国政府のすべてのレベルをカバーしているため、州固有のレポートを除いて、それらの州固有のサブドメインを除外しようとしたことは注目に値します。このレポートでは、市や地域の.govサイトを除外することができませんでした。上記のTLD .govドメインチャートを見ると、平均は87%でした。
さまざまな州のアクセシビリティも確認できます。
再び、コロラドとバーモントは他の州よりもはるかに進んでいます。コロラドは、州全体インターネットポータル機構（SIPA）を中央集権化し、新しいアクセシビリティ法制とともに、現在平均96%を達成しています。ジョージア州は中央機関を通じて管理される中央Drupalインストールを持っていますが、これが上位5位に入る理由を説明しているのでしょうか？ペンシルベニア州の州平均は82%とはるかに低いですが、2023年に設立された新しいデジタルエクスペリエンスチームもあります。
今年初めに、米国司法省は障害者のアメリカ人法（ADA）タイトルIIの規制を更新しました。米国の州政府と地方政府は今後すべて、WCAG 2.1 AAに完全に準拠することが要求されます。コンプライアンス日は人口の規模によって異なりますが、2026年4月または2027年4月のいずれかになります。米国の州がこの新しい規制にどのように準拠するかを測定することが重要です。これらの数値の改善が見られるでしょう。
コンテンツマネジメントシステム（CMS）
WebAim Million調査はCMSデータをレビューしており、私たちはWeb Almanacを通じて同等の結果を提供できます。Web Almanacは、オープンソースだった時代のWappalyzerのフォークのカスタマイズ版を使用しています。これにより、レポートはどのCMSが使用されているかを特定し、結果を比較できます。Typo3がGoogle Lighthouseデータを使用する場合よりもWebAimでより良い結果を得ていたことは明らかです。両方の調査は、CMSの選択がアクセシビリティに影響を与えることを明確に示しました。
ほとんどの人がCMSについて考える時、ダウンロードして自分でインストールできるものを思い浮かべます。これは主にオープンソースツールで構成されていますが、排他的ではありません。Adobe Experience Manager（AEM）、Contentful、Sitecoreがこのトップ10リストでもっともアクセシブルな3つでした。この可能な説明は、AEMのようなクローズドソースソフトウェアは、アクセシビリティ問題に対処するためのより多くのリソースを持つ大企業によって使用される可能性が高いことです。さらに、オープンソースソフトウェアはWebサイト所有者に多くの自由を与えますが、場合によってはより悪いアクセシビリティにつながる可能性があります。
これらの従来型CMSの監査を見ると、上位4つのLighthouse問題には非常に一貫性があります。カラーコントラスト、リンク名、見出し順序、alt属性は、これらのCMS全体で定期的に発生する問題であり、これらの問題は主にユーザーに関連しています。なぜなら、CMSは選択された色やリンクの命名に責任を持つことができないからです。
| 従来型CMS | もっとも多い | 2番目に多い | 3番目に多い | 4番目に多い |
|---|---|---|---|---|
| Adobe Experience Manager | color-contrast |
link-name |
heading-order |
label-content-name-mismatch |
| Contentful | color-contrast |
link-name |
heading-order |
image-alt |
| Sitecore | color-contrast |
link-name |
heading-order |
image-alt |
| WordPress | color-contrast |
link-name |
heading-order |
target-size |
| Craft CMS | color-contrast |
link-name |
heading-order |
image-alt |
異なるCMSは、それらが持つトップエラーに多くの共通点があります。それらはほとんどコンテンツ問題に関係しており、これはATAG 2.0が支援するために書かれたものです。ATAGのベストプラクティスがWCAG 3.0に持ち込まれることが期待されています。このスキャンは公開されているWebサイトのみを対象としているため、オーサリングインターフェースは評価されていません。作成者には障害があることに注目する価値があり、作成者はアクセシブルなインターフェースを期待できるべきです。作成者はアクセシブルなコンテンツを作成するためのサポートも必要です。オーサリングツールへのより大きな焦点を促進するために、W3CはATAGレポートツールを作成しました。
作成者がページのアクセシビリティを評価するのに役立つ多くのツールがあります。スタッフのブラウザー設定を制御する機関は、すべてのブラウザーにオープンソースのAccessibility Insightsブラウザープラグインを単純にインストールすることを選択できます。これにより、エラーが管理者にとってはるかに見やすくなります。ただし、上記のCMSの多くにとって、最良のソリューションは、作成者を支援することを目的としたSa11yやEditoria11yのようなツールをインストールすることかもしれません。Joomlaバージョン4.1以降ではSa11yがデフォルトで含まれていますので、すべての作成者が恩恵を受けます。
Webサイトプラットフォームは一般的に従来型CMSよりも良いパフォーマンスを示し、Wix、Squarespace、Google Sitesが大幅に優れています。
これらのCMSプラットフォームの監査を見ると、上位4つのLighthouse問題は問題の頻度において一貫性が低いですが、依然として多くの類似点があります。代替テキスト、リンク名、見出し順序、カラーコントラストはすべて依然として問題ですが、発生率が異なるだけです。
| プラットフォームCMS | もっとも多い | 2番目に多い | 3番目に多い | 4番目に多い |
|---|---|---|---|---|
| Wix | heading-order |
link-name |
button-name |
color-contrast |
| Google Sites | image-alt |
link-name |
aria-allowed-attr |
heading-order |
| Duda | link-name |
color-contrast |
image-alt |
heading-order |
| HubSpot CMS | color-contrast |
heading-order |
link-name |
target-size |
| Pixnet | heading-order |
link-name |
color-contrast |
frame-title |
異なるCMSプラットフォームには、さまざまな強みと弱みがあります。たとえば、ARIAコンポーネントにはアクセシブルな名前が必要であることは明らかですが、GoDaddy Website Builderで構築されたWebサイトの36%がこのテストに失敗しています。一方、私たちのデータセットで100,000以上の出現を持つすべてのCMSプラットフォームの中央値失敗率はわずか1%です。GoDaddyはダイアログ名の分野でも異常値で、テストの14%が失敗しており、平均失敗率の1.3%と比較して高いです。
ポジティブな側面では、Dudaはボタン名で際立っており、そのWebサイトの3%のみがテストに失敗しており、中央値の13%と比較して優秀です。さらに印象的なのはWixで、WixのWebサイトの20%のみがカラーコントラストのLighthouseテストに失敗しており、もっとも使用されているCMSプラットフォーム間の中央値失敗率は70%です。同様に、Wixは画像の代替テキストに関して例外的に良い成績を示しており、失敗率はわずか1%で、中央値の34%と比較して優秀です。
これらの違いは、作成者がコンテンツをアクセシブルにするための最後のステップを取る必要がある場合でも、CMSがアクセシビリティに影響を与えることが可能であることを示しています。
JavaScriptフロントエンドフレームワーク
WebAim Millionは、JavaScriptフレームワークとライブラリの影響も調べています。使用されるライブラリに基づいてデータのパターンを見ることが再び可能です。私たちはState of JavaScript 2023の定義を使用して作業しました。
Stimulus、Remix、Qwikは、React、Svelte、Ember.jsよりも平均で数パーセントアクセシブルです。
RedwoodJSが明らかにもっともアクセシブルで、Remix、Astroがそれに続きます。
結論
私たちの分析は、Webアクセシビリティに大きな変化がないことを示しています。いくつかの改善はありましたが、多くの簡単な問題が未解決のままです。カラーコントラストの改善と画像のalt属性の使用は、対処されれば大きな影響を与える可能性があります。CMSシステムとJavaScriptフレームワークには大きな責任があり、例はそれらがアクセシビリティに真の正の影響を与えることができることを証明しています。
私たちはしばしば、アクセシビリティを向上させることを意図した機能が、実際にはユーザー体験を悪化させながら、時として改善の誤った感覚を作り出すことを観察します。これらのアクセシビリティ問題の多くは、デザイナーと開発者がアクセシビリティ配慮を後付けとして扱うのではなく、最初から統合すれば避けることができるでしょう。組織は、よりアクセシブルなユーザー体験の開発を可能にするために、アクセシビリティトレーニング、運用、予算を優先する必要があります。一部の政府は、そのアプローチがいかに効果的であるかを実証しています。
Webコミュニティは、Webサイトがすべての人に対応する場合にのみ優れた顧客体験を提供することを理解する必要があります。2024年において、使用されるデバイス、ブラウザー、支援技術に基づいて人々を差別すべきではありません。私たちは対処が簡単な重要な指標に焦点を当てており、2025年により多くの改善が見られることを期待しています。