スクリーン・リーダー・プレビュー
HTMLを貼り付けて、スクリーンリーダーがどのように線形化してアナウンスするかを確認します。alt テキスト、見出し、ARIA属性を確認します。
スクリーンリーダー出力
📚 科学的根拠と情報源
このツールが対象とする人
スクリーンリーダーは、視覚障害者または重大な視覚障害のある人々のための重要な支援技術です。WHOのWorld Vision Report(2019年)によると、世界中で少なくとも22億人が視覚障害を抱えており、そのうち約4300万人が失明しています。WebAIM Screen Reader Survey(2024年)は、スクリーンリーダーユーザーの大多数が障害のある個人であり、失明が最も一般的な理由であることを一貫して発見しています。開発者、デザイナー、コンテンツクリエイターは、このツールを使用して、HTMLが支援技術によってどのように解釈されるかをプレビューします, エンドユーザーが遭遇する前に、欠落しているalt テキスト、不正な見出し構造、アクセシブルな名前のないボタンとフィールド、ARIAの誤用を発見するのに役立ちます。
このツールの仕組み
このツールはブラウザのネイティブDOMParserを介してHTMLを解析し(データはデバイスを離れません)、アクセシビリティツリーをトラバースして線形化された読み取り順序を構築します。画像のalt テキストの存在、見出しレベルの一貫性、アクセシブルな名前のないリンクとボタン、ARIAロールとラベル、関連付けられたラベルのないフォームフィールドをチェックします。
科学的参考文献
- WebAIM(2024年)。「Screen Reader User Survey #10 Results。」 webaim.org · スクリーンリーダーの使用パターン、ブラウザの組み合わせ、アクセシビリティの障害に関する最大の継続的な調査。見出しとランドマークが、ユーザーの主要なナビゲーション戦略であることを一貫して発見しています。
- 世界保健機関(2019年)。 World Vision Report。 · 世界中で少なくとも22億人が近視または遠視の障害を抱えており、そのうち約4300万人が失明していると報告しています。
- Power, C., Freire, A., Petrie, H. & Swallow, D.(2012年)。「Guidelines are only half of the story: Accessibility problems encountered by blind users on the web。」 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems(CHI '12)。 · 視覚障害ユーザーが遭遇するアクセシビリティ問題のかなりの部分がWCAG単独ではカバーされていないことを発見し、手動レビューとスクリーンリーダーテストの必要性を強調しました。
- Lazar, J., Allen, A., Kleinman, J. & Malarkey, C.(2007年)。「What frustrates screen reader users on the web: A study of 100 blind users。」 International Journal of Human-Computer Interaction, 22(3), 247–269。 · 欠落しているalt テキスト、ラベル付けされていないフォームフィールド、誤解を招くリンクラベルが、視覚障害ユーザーが報告する主要な不満事項として特定されました。
- W3C WAI(2023年)。「WAI-ARIA Authoring Practices 1.2。」 · 動的コンテンツを支援技術にアクセシブルにするためにロール、状態、プロパティをどのように使用すべきかを定義しています。
免責事項
このツールは、HTMLアクセシビリティツリーに基づくスクリーンリーダー出力の簡略化された近似を提供します。実際のスクリーンリーダー(NVDA、JAWS、VoiceOver、TalkBack)は、コンテンツのアナウンス、ARIA属性の処理、動的ウィジェットとの相互作用の方法が異なります。このプレビューは、実際のスクリーンリーダーと実際のユーザーでのテストに代わるものではありません。執筆プロセスの早い段階で一般的な問題を検出することを目的としています。
ウェブアクセシビリティ標準の短い歴史
ウェブ上のアクセシビリティは、W3C Web Accessibility Initiative(WAI)からの小さな標準のスタックと、それらを参照する国家法によって統治されています。WCAG 1.0は1999年5月に公開され、ウェブコンテンツをアクセス可能にする最初の正式なガイダンスでした。それは主にHTML中心で、すぐに時代遅れになりました。WCAG 2.0(2008年12月)は、4つの原則(知覚可能、操作可能、理解可能、堅牢)と3つの適合性レベル(A、AA、AAA)を中心に組織された大規模な書き直しでした。それは2012年にISO規格(ISO/IEC 40500)になり、ほとんどの法律がまだ参照する適合性目標です。WCAG 2.1(2018年6月)はモバイル、ロービジョン、認知障害をカバーする17の新しい成功基準を追加しました。WCAG 2.2(2023年10月)はさらに9つを追加し、特に2.4.11 フォーカスが隠されないと3.3.8 アクセシブル認証。WAI-ARIA 1.0は2014年3月に最終化されました;1.2は2023年6月に現在の勧告です。法的側面では、米国の第508条更新(2018年1月)がWCAG 2.0 AAを米国連邦調達に組み込みました。欧州アクセシビリティ法(指令2019/882)は2025年6月28日に発効し、EUのほとんどの消費者向けデジタル製品にアクセシビリティ標準を満たすことを要求しています。ほとんどの国がWCAGを参照するので、WCAG 2.2 AAに向けて構築することは、今日のあらゆるグローバル製品の実用的な目標です。
今日のスクリーンリーダーの状況
WebAIM Screen Reader User Survey #10(2024)は、人々が実際にどのスクリーンリーダーを使用しているかについての正典的なソースです。5つの製品がデスクトップ、モバイル、ChromeOSを支配しています。
- JAWS(Freedom Scientific、1989年初版)はWindowsでの長年の商業的リーダーです。約$1000+のコスト。WebAIM 2024は調査回答者の約40%の主要スクリーンリーダーとして見ており、NVDAをわずかに下回ります。
- NVDA(NV Access、2006年初版、Pythonで書かれている)はWindowsのオープンソース代替品です。無料。WebAIM 2024は最も使用されている主要スクリーンリーダーとして報告しており、回答者の約47%。NVDAがニッチツールから市場リーダーになるまでの15年の成長は、支援技術における偉大なオープンソースの成功物語の一つです。
- VoiceOver(Apple、2005年macOS、2009年iOS)は、すべてのMac、iPhone、iPad、Apple Watch、Apple TVに組み込まれて出荷されています。最も使用されているモバイルスクリーンリーダーです。Safariとナビゲーション用のiOSローターと緊密に統合されています。
- TalkBack(Google、2009年Android)はAndroidの対応物です。Android 4以来オープンソース。ジェスチャーとナビゲーションメニューを使用します。
- ChromeVox(Google、2012)とNarrator(Microsoft、2000、Windows 10で近代化)が状況を完成させます。それぞれが小さいが忠実なユーザーベースを持っています。
1つのページは各製品によって異なる方法で発表される可能性があります。堅牢なページは少なくとも2つでクリーンにテストされます:通常はNVDA + FirefoxまたはChrome、そしてVoiceOver + Safari。
このツールに手を伸ばす時
- ローンチ前監査。主要なページ(ホームページ、サインアップフォーム、チェックアウト)を貼り付け、線形化された出力を声に出して読みます。それがあなたにとって意味をなさないなら、スクリーンリーダーユーザーにとっても意味をなしません。
- コードレビュー。重要なマークアップ変更があるPRをマージする前に、レンダリングされたHTMLを貼り付け、ヘッディング、ランドマーク、altテキストが無傷で残っていることを確認します。
- デザインのハンドオフ検証。デザイナーは最終的なHTMLを貼り付けて、視覚的階層が意味的階層に一致することを確認できます。見出しのように見えるページは、DOMでもそうあるべきです。
- アクセシビリティを教える。クラスやチームに、スクリーンリーダーが実際に受け取るものを見せます。視覚的レイアウトと線形化された出力の間のギャップは、しばしば障害のない開発者がなぜセマンティックHTMLが重要なのかを初めて理解する時です。
- WCAGに対するコンプライアンスチェック。最も違反される4つの基準のクイックスポットチェック:1.1.1 非テキストコンテンツ(altテキスト)、1.3.1 情報と関係性(意味的構造)、2.4.4 リンクの目的、4.1.2 名前、役割、値。
- CMS / ノーコードサイトチェック。ビジュアルエディタは、見出しの代わりにdivや、テキストのないリンクをしばしば生成します。公開されたHTMLを貼り付け、何が滑り抜けたかを見ます。
- メールテンプレートのアクセシビリティ。HTMLメールはアクセシブルにすることで悪名高く困難です。プレビューを使用して、すべての画像のaltテキスト、適切な見出し順序、読みやすい読み流れを検証します。
スクリーンリーダーが暴露する一般的なミス
- 欠落または無用なaltテキスト。
alt="image"、alt="photo"、alt="logo"は何もないよりわずかにましです。Lazar et al.(2007)は、欠落したaltテキストを盲目のウェブユーザーのトップフラストレーションとして特定しました。周囲の文脈における画像の目的を伝えるaltテキストを書くか、純粋に装飾的な画像にはalt=""を使用してスクリーンリーダーがスキップするようにします。 - スキップまたは再開する見出しレベル。
h2をスキップしてh1からh3に行くのはナビゲーションを混乱させます。同じページで複数のh1要素を使用することは(コンポーネント駆動設計でかなり一般的なパターン)、スクリーンリーダーユーザーがナビゲートするドキュメントアウトラインを壊します。WebAIM 2024は、見出しがスクリーンリーダーユーザーにとって最も一般的なナビゲーション戦略であることを発見しました。 - Divitis。
<button>または<a>を使用する代わりに、クリックハンドラ付きの<div>でクリック可能なテキストをラップすることは、キーボードサポートなし、フォーカスリングなし、役割アナウンスなしを意味します。常にセマンティックHTMLから始め、ネイティブ要素が合わない場合にのみARIAを追加します。 - HTMLで十分なところでARIAを使用。 ARIAの第一規則(W3C WAI-ARIA Authoring Practicesによる):「ネイティブHTML要素を使用できるなら...そうしなさい」。
<button role="button">は冗長です;<div role="button">は代わりに本物のボタンを使用すべきというサインです。 - ARIAが間違って使用される。フォーカス可能な要素に
aria-hidden="true"を使うと、スクリーンリーダーには見えなくなりますが、キーボードからはフォーカス可能なままで、混乱を招くタブオーダーのレシピです。tabindex="0"とキーボードハンドラなしのrole="button"は何も役に立つことをしません。 - ラベルのないフォーム入力。関連付けられた
<label>、aria-label、またはaria-labelledbyのない<input>は、コンテキストなしで「edit, blank」として発表されます。プレースホルダーテキストは代替ではなく、フォーカス時に消え、しばしばコントラストに失敗します。 - 「ここをクリック」と「もっと読む」リンク。スクリーンリーダーユーザーは、しばしばページ上のすべてのリンクのリストをプルアップしてナビゲートします。「ここをクリック」だけでは何も伝えません。リンクテキストに目的地を説明させます:「2024 WebAIM調査を読む」が「ここでもっと読む」に勝ちます。
- フォーカススタイルを削除する。代替フォーカスインジケータなしの
outline: noneは最も違反されるWCAG基準の一つです(2.4.7 フォーカス可視)。多くのスクリーンリーダーユーザーを含むキーボードユーザーは、フォーカスがどこにあるかを見る必要があります。
ARIAを一目で:各種類の役割が何をするか
- ランドマークの役割(
banner、navigation、main、complementary、contentinfo、search)は、スクリーンリーダーユーザーが間でジャンプできるリージョンにページを分割します。ほとんどがネイティブHTMLの同等物を持っています(<header>、<nav>、<main>、<aside>、<footer>)。最初にネイティブ要素を使用します。 - ウィジェットの役割(
button、checkbox、combobox、menu、tabpanelなど)はインタラクティブコントロールを記述します。ウィジェットの役割は、W3C ARIA Authoring Practices Guide(APG)が詳細に文書化しているキーボード相互作用パターンを暗示します。APG仕様を正確に一致させることができない場合は、ネイティブHTMLを優先します。 - ドキュメント構造の役割(
article、list、listitem、row、cellなど)は、非インタラクティブなコンテンツを記述します。ほとんどがネイティブHTMLの同等物も持っています。ネイティブ要素が利用できない場合(例:<table>が合わないカスタムデータグリッドの構築)のみそれらを使用します。 - ライブリージョン(
aria-live="polite"、aria-live="assertive"、role="status"、role="alert")は、フォーカスを移動せずに動的更新をアナウンスするようスクリーンリーダーに伝えます。チャットメッセージ、フォームエラー、ロード状態に使用されます。過剰使用は通知疲労を引き起こします;エラー状態のような真の緊急事態のためにassertiveを予約します。
その他のよくある質問
このプレビューはNVDA / JAWS / VoiceOverが実際に言うことと一致しますか?
近似します。このツールはブラウザのアクセシビリティツリー(スクリーンリーダーが使用するのと同じ構造)を読み取り、発表されるであろうものの線形化されたバージョンを生成します。実際のスクリーンリーダーは製品固有の動作を追加します:フォーカス変更のアナウンス、テーブルナビゲーション、テーブルヘッダー、リストアイテム数、ARIA-live丁寧さ処理、カスタム冗長性設定。プレビューを最初のサニティチェックとして扱います;本番ローンチの場合、聴衆が使用するオペレーティングシステムで少なくとも1つの実際のスクリーンリーダーでテストします。
WCAGとARIAの違いは何ですか?
WCAG(Web Content Accessibility Guidelines)は要件のリストです:「すべての非テキストコンテンツにはテキストの代替が必要」。何を達成するかは伝えますが、必ずしもどのようにかではありません。ARIA(Accessible Rich Internet Applications)はWCAGを満たすためのツールの一つです:ネイティブHTMLが不十分なときに支援技術にセマンティクスを公開するHTML属性(役割、状態、プロパティ)のセット。HTMLが十分にセマンティックなら、ARIAなしでWCAGを満たすことができます。ARIAはそうでない場合のためのものです。
良いaltテキストをどう書きますか?
W3CのAn alt Decision Treeからの3つのルール:(1)画像が純粋に装飾的な場合、スクリーンリーダーが完全にスキップするようにalt=""を使用します。(2)画像が周囲のテキストにすでにない情報を伝える場合、その情報を簡潔に説明します(通常125文字以下)。(3)画像が機能的な場合(例:ホームにリンクするロゴ、またはアイコンボタン)、外観ではなくアクションを説明します。「検索」は「虫眼鏡アイコン」に勝ちます。「画像の...」、「写真の...」を避け、スクリーンリーダーはすでに要素が画像であることを発表します。
私のサイトはdivをどこでも使っています。どこから始めますか?
5つのランドマーク要素を追加することから始めます:<header>、<nav>、<main>、<aside>、<footer>。次に、クリック可能なdivを<button>(アクション用)または<a>(ナビゲーション用)に置き換えます。次に見出しを監査します:各ページには1つの<h1>とネストされた順序の残りがあるべきです。これら3つのステップは、典型的なdiv重視のサイトのアクセシビリティ問題のおそらく70%を修正します。ARIAとJavaScriptフォーカス管理は、セマンティック基盤が整った後に来ます。
ここに貼り付けるHTMLはどこかに送信されますか?
いいえ。解析はブラウザの組み込みDOMParserを使用し、解析は完全にクライアント側で実行されます。DevToolsでネットワークタブを開いて分析をクリックすると、線形化中にゼロのアウトバウンドリクエストが見えます。内部テンプレート、未リリースのページ、または顧客データを含むHTMLに対して安全です。