アクセシビリティ

docs.scrimba.com

人々はさまざまな方法でウェブにアクセスします。スクリーンを見てマウスを動かす人もいれば、スクリーンが見えず、ページを声で聞く人もいます。マウスを一度も触らず、キーボード、音声、またはスイッチでページをナビゲートする人もいます。アクセシビリティとは、すべての人がページを使えるように作る実践であり、ほとんどはHTMLを本来あるべき形で書くことに帰着します。

アクセシビリティが重要な理由

**アクセシビリティ**とは、どのような環境にいる人でも、どうやってページを閲覧していても、誰もがページを使えるようにすることです。スクリーンが見えず、代わりにページを声で聞く人がいます。マウスを使わずキーボードでページをナビゲートする人もいます。より大きなテキストや強い色が必要な人もいます。

建物の脇に階段と一緒にスロープがある光景を想像してください。スロープは階段をのぼれない人を助け、のぼれる人には何も失わせません。アクセシブルなHTMLも同じ考え方です。ページを開放してより多くの人が使えるようにしても、誰のためにも悪くはなりません。

心強いことに、HTMLは最初からアクセシブルです。コンテンツの各部分に正しい要素を使うことで、ほとんどのところまで無料で到達します。

アクセシビリティはしばしば**a11y**（「a」、11文字、「y」）と短縮されます。これはページがウェブにアクセスするあらゆる方法で動作することについてです。ページを音声で読み上げるスクリーンリーダー、キーボードのみのナビゲーション、音声コントロール、スクリーン拡大、および色を減らしたり高コントラストの表示モードなどです。

最も役に立つ実用的なフレーミング：HTMLはアクセシビリティを最初の位置として提供し、最後に追加するものではありません。ほとんどの作業は正しい要素を選ぶことと、ブラウザが既にしていることを取り消さないことです。失敗は小さな原因から来る傾向があります。汎用要素から再構築されたカスタムウィジェット、ラベルなしのフォームフィールド、弱い色コントラスト、そしてマウスにのみ反応する動作です。

アクセシビリティは、支援技術（スクリーンを読み上げるスクリーンリーダー、クリックの代わりに押すスイッチデバイス、音声コントロールなど、コンピュータを操作するのを助けるソフトウェアまたはハードウェア）を使う人がページを知覚、操作、理解できるかどうかです。参考基準はWCAG、Web Content Accessibility Guidelinesで、4つの原則を中心に整理されています。コンテンツは知覚可能、操作可能、理解可能、そして堅牢であるべきです。

2つの結果は心に留めておく価値があります。まず、支援技術が依存する同じ整形された構造は、検索エンジンやその他のマシンがDOM（ブラウザのページのメモリ内モデル）から読み出すものでもあるため、アクセシビリティとSEOは競争するのではなく同じ方向に引き合います。次に、多くの場所でアクセシビリティは公開向けサイトの法的要件であり、いい選択肢ではありません。それすべての有用な考え方：アクセシブルなページはほとんど正しく構築されたものです。この章のほぼすべてが本来の目的で使用される標準HTMLです。

Junoアクセシビリティが重要な理由 アクセシビリティは、誰もがどうやってページに到着しようと、ページを使えることを意味します。いい部分はHTMLが仕事に適切な要素を選ぶ瞬間にほぼすべてを無料で与えることです。階段の脇のスロープを想像してください。より多くの人が入り、誰も悪くなりません。

Junoアクセシビリティが重要な理由 アクセシビリティはページがスクリーンリーダー、キーボード、拡大機、そしてその間のすべてで動作することです。HTMLはすぐに使えるようにアクセシブルなため、良い場所からスタートします。そのため、ほとんどの失敗はカスタムウィジェットと欠けたラベルでそれを取り消すことから生じます。正しい要素で構築すれば、既に大部分まで到達しています。

Junoアクセシビリティが重要な理由 基準はWCAGとその4つの原則です。知覚可能、操作可能、理解可能、堅牢。スクリーンリーダーを助ける同じ構造は検索クローラーがDOMを読むのを助けるため、これはあなたの時間に対する別の税ではありません。この章の残りを通常のHTMLとして扱いますが、それが本来あるべき使用方法だからです。

セマンティックHTMLを基盤として

アクセシビリティのために実行できる最も効果的な単一の事柄は、汎用的な要素を使うのではなく、コンテンツの意味に一致する要素を使うことです。

**セマンティックHTML**とは、見た目のためではなく、コンテンツが何であるかのためにタグを選ぶことです。見出しは<h1>から<h6>を使います。ボタンは<button>を使います。リンクは<a>を使います。リストは<ul>または<ol>を使います。これらのそれぞれは既にスクリーンリーダーが発表できる意味を持っているため、聞き手は見えなくても「これはボタンです」または「これは見出しです」と知ります。

それは家を引っ越すときに箱にラベルを貼ることのようなものです。「キッチン」とマークされた箱は、それをパックした人だけでなく、それを運ぶ誰もを助けます。セマンティックタグは同じ方法であなたのコンテンツにラベルを付けるため、ブラウザと支援技術は各部分が何であるかを知ります。

実践では、これはボタンを見た目に似せたように見える<div>ではなく、ボタンが必要な場合に<button>に到達することを意味します。<div>は同じように見えるように作ることができますが、それが何であるかについて何も言いません。セマンティックHTMLの章はすべての集合を通ります。

セマンティック要素は既に動作と意味を備えてやってきます。<button>はフォーカス可能で、EnterとSpaceに反応し、ボタンとして発表されます。<nav>はナビゲーション領域をマークします。見出し<h1>から<h6>は、スクリーンリーダーユーザーが飛び越える輪郭を形成し、目の見える読者がセクションをスキムする方法のようなものです。

最も多くの困難を保存するルール：自分で構築する前にネイティブ要素を使用してください。<div role="button" tabindex="0">にクリックハンドラーを付けることで動作させることができますが、フォーカス、キーボードサポート、ロールを手で再実装しており、そのピースの1つは見落とされる傾向があります。実際の<button>はすべてを一度に与えます。ランドマーク要素（<header>、<nav>、<main>、<aside>、<footer>）はページスケールで同じ仕事をします。スクリーンリーダーユーザーはその上のすべてを聞く代わりにある領域に直接スキップできます。セマンティックHTMLの章は各要素を扱います。

セマンティックHTMLが基盤である理由は、ブラウザが各セマンティック要素を**アクセシビリティツリー**のロール（支援技術が読む、下のARIAセクションで完全に説明されたページのストリップダウンバージョン）にマップするからです。<button>はボタンロール、フォーカス動作、およびキーボードハンドリングを受け取ります。<div>から再構築し、そのどれも継承しません。あなたはフォーカス可能性、キーハンドリング、および発表されたロールを手で所有し、すべてのギャップは誰かの欠陥です。

2つの習慣はほとんどの重みを運びます。見出しレベルに実際の構造を与えます。ページの<h1>が1つ、その後<h2>と<h3>がレベルをスキップなくネストされます。スクリーンリーダーユーザーは見出しでナビゲートし、<h2>から<h4>へのジャンプはセクションが欠けているとして読まれます。ランドマーク要素（<main>、<nav>、<header>、<footer>、<aside>）を使用してページがナビゲート可能な領域を公開するようにします。認識するべき失敗モード「div soup」は、ほぼ完全に<div>と<span>から組み立てられたページです。完璧にレンダリングされ、支援技術にはほぼ何も公開しません。これらの2つの要素は全くロールを運ばないからです。

JunoセマンティックHTMLを基盤として 見た目のためではなく、コンテンツが何かのためにタグを選んでください。<button>はボタンのために、<h1>は見出しのために、<a>はリンクのために。それぞれはスクリーンリーダーに何であるかを既に伝えるため、無料で得ます。スタイル設定された<div>は同じように見えることができ、まだ何も言いません。

JunoセマンティックHTMLを基盤として ネイティブ要素はフォーカス、キーボードサポート、および音声ロールを既に備えてきます。そのため<button>は1つのようなふりをする<div>を打ち負かします。実際の要素を使う前に再構築し、人々がスキップして回れるようにナビゲーションなどのランドマークに寄りかかります。それでほぼ仕事の全部です。

JunoセマンティックHTMLを基盤として すべてのセマンティック要素はアクセシビリティツリー内のロールにマップされるため、<button>はロール、フォーカス、キーを一緒に与えます。一方<div>は3つすべての請求書を与えます。見出しを順序を保ってスキップなしで保ちます。人々はそれでナビゲートするからです。Div soupは素晴らしくレンダリングされ、支援技術に何も伝えません。それが問題全体です。

テキスト代替、ラベル、フォーカス、そしてキーボード

いくつかのコンテンツはそれ自体で話すことができません。画像はスクリーンリーダーが説明するまで見えません。フォームフィールドはラベルが付くまで推測です。そしてマウスにのみ反応するページは誰もがそれを使わない人を除外します。これら4つの領域は少しの注意が長い道のりに行く場所です。

信頼できる習慣の一握りはこのほとんどをカバーします。

• 画像にはalt属性が必要です。 alt属性は見えない誰にでも画像を説明します。画像が装飾的なだけの場合、空のalt=""はスクリーンリーダーにそれをスキップするよう指示します。

<img src="red-fox.jpg" alt="雪の中で眠っている赤いキツネ">

• フォームフィールドにはラベルが必要です。 <label>は訪問者とスクリーンリーダーの両方にフィールドに入力するものを指示します。

<label for="email">メールアドレス</label>
<input id="email" type="email">

• ボタンとリンクは明確なテキストが必要です。 コンテキストから外れて読まれた場合、「もっと読む」は不明確です。「チケット価格についてもっと読む」は単独で意味があります。
• キーボード順序は読む順序に一致する必要があります。 Tabキーを押す誰かがHTMLの要素が現れる順序でページを通り抜けるため、その順序を合理的に保ちます。

画像とメディアとフォームと入力の章はalt属性テキストとラベルについてさらに深く掘り下げます。

すべてのフォームコントロールを<label>に関連付けます。信頼できる方法はラベルのfor属性をinputのidに一致させることです。

<label for="postcode">郵便番号</label>
<input id="postcode" type="text" name="postcode">

これでラベルをクリックするとフィールドがフォーカスされ、スクリーンリーダーはフィールドがフォーカスを得たときにラベルを発表します。フォームと入力の章は変更をカバーしています。

**alt属性テキスト**については、ピクセルではなく目的を説明してください。alt="会社ロゴ"は色と形のリストより優れており、装飾的な画像は空のalt=""を取ります。そのため、ファイル名として読まれるのではなく、スキップされます。

フォーカス順序はDOMの要素の順序に従うため、ソース順序を視覚的な読む順序に一致させたままにします。肯定的なtabindex値（tabindex="1"以上）を避けます。それらは正しく保つのが難しい別のタブシーケンスを発明します。tabindex="0"を使用してカスタムコントロールを自然な順序に追加し、tabindex="-1"を使用してスクリプトによってフォーカス可能だがTabキーでフォーカス可能でないようにします。

キーボード操作性の場合、ルールは短いです。マウスでできることはすべてキーボードで動作する必要があります。クリックがメニューを開く場合、Enterも開くべきです。キーボードユーザーが自分がどこにいるかを見ることができるよう、目に見えるフォーカスアウトラインを保ちます。ここで色のコントラストが重要です。WCAGは通常のテキストとその背景の間で少なくとも4.5:1のコントラスト比を要求し、色だけに意味を持たせないでください。すべての人が同じ色を区別するわけではないからです。

これら4つの領域はすべてDOMが視覚的なレイアウトが見ている目のマウスユーザーのために運ぶ意味を運ばなければならない場所です。

ラベル。 for/idによってコントロールに結び付けられた<label>、またはinputをラップすることで、そのコントロールにアクセシブル名（支援技術が要素のために発表するテキスト）を与えます。ラベルがない場合、スクリーンリーダーはフィールドのタイプを読むだけでその目的については何も読みません。プレースホルダーテキストはラベルではありません。入力時に消え、一貫性なく発表されます。

テキスト代替。 altは<img>のアクセシブル名です。外観ではなく目的で書いてください。装飾的な画像はalt=""（空、存在しますが空白）を取ります。そのため、アクセシビリティツリーから削除されます。altを完全に省略することは異なり、いくつかのスクリーンリーダーはファイル名を読むことにフォールバックします。誰も助けません。

フォーカス。 フォーカス順序はオーバーライドしない限りDOM順序です。肯定的なtabindexはほぼ常に誤りです。あなたが視覚的なレイアウトに対して保つ必要がある第二のタブシーケンスを構築するからです。tabindex="0"を使用してカスタムコントロールを自然な順序に折り込み、tabindex="-1"を使用してスクリプトのみでフォーカス可能にします。これはアクションの後にフォーカスを移動するときに必要です。目に見えるフォーカスインジケーターを保ちます。置き換えることなくoutline: noneを設定しないでください。またはキーボードユーザーは位置を追跡を失います。またキーボードトラップ（キーボードユーザーが進むことはできるが抜けられないフォーカス）に注意してください。WCAGはこれを具体的に指摘しています。

キーボードとコントラスト。 すべての操作はキーボードで到達可能で操作可能である必要があり、論理的な順序で。コントラストについて、WCAG AAは本文テキストで4.5:1、大規模テキストとコントロールの視覚境界で3:1を要求し、意味は色だけに乗るべきではありません。必要なフィールドが赤でのみマークされている場合、その差を知覚しない誰にも見えません。テキストまたはアイコンと組み合わせてください。

Junoテキスト代替、ラベル、フォーカス、そしてキーボード 4つの小さな習慣がこのほとんどを運びます。画像にaltを与え、フォームフィールドに<label>を与え、単独で意味のあるボタンとリンクテキストを書き、タブ順序を読む順序と一致させます。そのどれも長い時間がかかりません。装飾的な画像は空のalt=""を得ます。そのためスキップされます。

Junoテキスト代替、ラベル、フォーカス、そしてキーボード 一致するforとidで<label>にすべてのinputを配線します。目的でaltを書き、装飾的に空にします。フォーカス順序をDOM順序に保ち、肯定的なtabindexをスキップします。覚えておくべき線：マウスができることはすべてキーボードもしなければならず、あなたのコントラストが4.5:1に達することを確認します。

Junoテキスト代替、ラベル、フォーカス、そしてキーボード ラベルとaltは要素のアクセシブル名を設定するため、プレースホルダーはラベルではなく、欠けたaltは空いているわけではありません。フォーカスをDOM順序に保ち、肯定的なtabindexを避け、置き換えることなくフォーカスアウトラインを削除しないでください。テキストで4.5:1に達し、赤だけで必要なマーカーが赤を見られない誰にも届くため、色だけが信号になることを決してさせません。

ARIA、そして最初にそれに到達しない理由

特にアクセシビリティのために作られた一組のHTML属性があります。それはARIAと呼ばれます。それは正しい場所で有用であり、それはプラットフォームで最も誤用される部分の1つであるため、それが何をするか、いつそれをそのままにしておくかの両方を理解する価値があります。

**ARIA**はAccessible Rich Internet Applicationsの略です。それは要素に追加できる余分な属性の一組で、支援技術についてそれについて詳しく指示します。名前はそれが最初に到達するツールのように聞こえます。そして通常は最後です。

理由は単純です。ARIAが説明できるほとんどは、HTMLは既にそれ自体で言っています。<button>は既にボタンとして発表されます。それにrole="button"を追加することは何も変わりません。あなたが要素が何であるかを説明するためにARIAを追加してしまう場合、それは通常それが既に言う平文HTML要素に交換する兆候です。

粘着ノートが移動ボックスに追加される光景を想像してください。ボックスが既に「キッチン」と印刷されている場合、「キッチン」を読む粘着ノートはただ混乱を追加します。ラベルを持たない独自のボックスのためにノートを保存します。ARIAはHTMLが要素を持たないページの部分のためです。それは聞こえるより稀です。

ARIAは要素に3種類の情報を追加します。roles（role="dialog"のようにそれが何であるか）、states（aria-expanded="false"のようなそれの現在の状態）、およびproperties（aria-describedbyのようなヘルプテキストを指す追加の関係）。スクリーンリーダーはこれらを使用してカスタムウィジェット（タブパネルやスライダーなど、ネイティブHTMLと同等のもの）を発表します。

リード的なガイダンスはARIAの最初のルールです。ネイティブ要素が既に仕事をしている場合、ARIAを使用しないでください。ネイティブ<button>は毎回<div role="button">を打ち負かします。ネイティブ要素は動作をもたらし、ARIA属性はラベルだけをもたらすため。さらに悪いことに、間違った、または古いARIA属性は無いより悪いです。ブラウザは別のものを言っているからです。aria-hidden="true"を間違った要素に置くと、スクリーンで見える本当のコンテンツを隠しながらスクリーンリーダーユーザーに見える状態が隠されます。HTMLが要素を持たないウィジェットを構築する場合にARIAに到達し、その後、属性を発明するのではなく確立されたパターンに従ってください。

ARIAが編集するもので始めます。アクセシビリティツリーはブラウザがDOMと一緒に構築する並列構造です。各要素のため、それはroleを記録します（要素が何であるか。ボタン、リンク、見出し）、そのstates と properties（条件と関係。aria-expanded、aria-checked、またはdisabledのような）、およびアクセシブル名と説明（発表されるテキスト）。支援技術はこのツリーを読み、あなたのCSSや生のHTMLではありません。

ARIAはそのツリーを直接編集するための語彙です。roles（role="tablist"）、時間とともに変わるstates（aria-selected="true"）、およびより安定した関係を説明するproperties（aria-labelledby、aria-controls）。**ARIAの最初のルール**は、ネイティブHTML要素または属性が既にあなたが必要なロール、状態、またはプロパティを与える場合、それを使用し、ARIAを追加しないことです。理由はARIAがアクセシビリティツリーのみを変更し、それ自体で動作を追加しないことです。<div>に対するrole="button"はスクリーンリーダーにそれをボタンと呼ぶように与えますが、フォーカス可能性、EnterまたはSpaceハンドリング、そして無効化サポートを与えません。あなたはそれらのそれぞれを自分で追加するでしょう。そしてあなたが1つを忘れた日、あなたはボタンとして発表しますがボタンのように機能しないコントロールを持っています。これは正直な<div>より悪いです。

いくつかのルールは害をもたらすことを意図したARIAを防ぎます。ネイティブ要素を好みます。ネイティブセマンティクスをオーバーライドしないでください（<button>にrole="heading"はありません）。aria-hidden="true"とマークされたサブツリーの内側に対話型要素を配置しないでください。スクリーンリーダーが見られないフォーカス可能なコントロールを作ります。そしてあなたのJavaScriptで状態を同期してください。古いaria-expandedはユーザーに嘘をついているからです。ARIAが必要な場合、WAI-ARIA Authoring Practicesから構築します。これは一般的なウィジェットの公開されたパターンです。スクラッチから属性を構成するのではなく。これのいずれかをテストするために、ブラウザのアクセシビリティインスペクターは与えられた要素のための計算されたロール、名前、および状態を示します。これはまさに支援技術が受け取るものです。

JunoARIA、そして最初にそれに到達しない理由 ARIAは支援技術に要素を説明する余分な属性の一組です。それが到達する最初のものに聞こえます。そしてそれは通常最後です。本当の<button>は既にそれがボタンであることを言います。HTMLが要素を持たないページの稀な部分のためにARIAを保存し、他のすべてを平文に保ちます。

JunoARIA、そして最初にそれに到達しない理由 ARIAはカスタムウィジェットのためにロール、状態、およびプロパティを追加します。HTMLが要素を持たないもの。ARIAの最初のルールはネイティブ要素が既に仕事をしているときにそれをスキップすることです。間違った、または古い属性は無いより悪いからです。もしあなたが<button>をボタンとしてラベル付けしているなら、止めて、ボタンを使用してください。

JunoARIA、そして最初にそれに到達しない理由 ARIAはアクセシビリティツリーを編集します。ロール、状態、およびプロパティ、そして何もほか。それが全く理由なので、ARIAの最初のルールは<div>でなので、role="button"はキーまたはフォーカスまでボタンを発表します。自分を構築します。JavaScriptで状態を同期してください。そしてあなたが属性を発明するのではなくウィジェットが必要な場合、公開されたパターンをコピーします。

簡単な自己監査

最も一般的な問題をキャッチするために、専門家用ソフトウェアは必要ありません。機械に既にあるツールを使った数個のチェックはそれらのほとんどを見つけ、そしてそれらは実行するのにわずか2分かかります。

あなたが任意のページで実行できる短いチェックリストは次の通りです。

• マウスを脇に置き、Tabキーを押します。すべてのリンクとボタンに到達できますか。理にかなった順序で。それらをEnterで活性化できますか。
• すべての画像にalt属性がありますか。
• すべてのフォームフィールドに<label>がありますか。
• あなたのボタンとリンクは単独で読まれるとき、まだ意味がありますか。
• テキストはその背景に対して読みやすいですか。

あなた自身のページでこれらを実行することは迅速です。そしてそれは人々が最も多く達成するもの問題をキャッチします。Tabキーがどこかに引っかかるか、画像にaltがない場合、あなたは修正する価値があるものを見つけました。

ワークフローに繰り返し可能なパスを構築します。

1. キーボード。 ページ全体をTabします。すべての対話型要素は到達可能である必要があります。合理的な順序で。目に見えるフォーカスインジケーターで。そしてEnterまたはSpaceで操作可能。フォーカスが消えるか引っかかるなら、他の何かの前に修正します。
2. 見出しとランドマーク。 <h1>が1つあることを確認し、見出しはレベルをスキップしません。そして、主な領域は<main>、<nav>、およびその他のランドマークを使用します。
3. 名前。 すべての画像にaltがあり、すべてのコントロールにラベルがあり、すべてのリンクとボタンはコンテキストの外で明確に読みます。
4. コントラスト。 ブラウザの開発ツールでテキストをその背景に対してチェックします。これはその比率を報告し、失敗するものをフラグします。

LighthouseパネルChromeの開発ツール、またはaxeブラウザ拡張機能などの自動チェッカーはうまくいく問題の共有をキャッチします。しかし、ただ共有です。彼らはalt属性が有意義であるか、タブ順序が理にかなっているかを判断することはできないため、手動キーボードパスは本質的なままです。

働く監査は自動化と手動パスを組み合わせます。オートメーションはただ地面の一部をカバーするため。ツールは確実に欠けたalt、欠けたラベル、およびコントラスト失敗（約WCAGの基準の3分の1）を見つけます。そしてそれはalt属性テキストが正確であるか、タブ順序が論理的であるかを判断することはできません。

• 自動化。 機械的な失敗を掃除するために最初にaxeまたはLighthouseを実行します。
• キーボード。 マウスを脇に置き、Tabして、到達可能性、論理的な順序、見える焦点環、完全な操作可能性、そしてフォーカスが抜けられない場所を確認します。このパスだけはほとんどのカスタムウィジェット欠陥をサーフェスします。
• スクリーンリーダー。 1つを有効にします（VoiceOverはmacOS Cmd+F5で付属、NVDAはWindows上の無料ダウンロード、TalkBackはAndroidに組み込まれています）そして少しの主な流れを聞き通すります。あなたは名前が発表されていること、ロールが正しいこと、そして状態変化が実際に話されることを確認しています。
• アクセシビリティツリー。 ブラウザの開発ツールはあらゆる要素のための計算されたロール、名前、および状態を示します。これはあなたに支援技術が本当に受け取るもの、要素がどのように見えるかは独立して、教えます。

自動化されたツールが緑を報告していても、キーボードとスクリーンリーダーパスを実行します。チェックを実行しないことはページを使用する本当の人がもっとも影響するものです。

Juno簡単な自己監査 マウスを脇に置き、ページをTabします。合理的な順序ですべてに到達して使用できますか。その後、すべての画像にaltがあること、すべてのフィールドに<label>があること、そしてテキストがその背景に対して明確に読むことを確認します。この数分でページを使用する人が最も達成するもの問題をキャッチします。

Juno簡単な自己監査 ルーティンにします。到達可能性と順序のためにTabして、1つの<h1>とスキップなしの見出しを確認し、画像とコントロールの名前を確認し、開発ツールでコントラストを読みます。axeとLighthouseのような自動化されたツールは役立ちます。しかし、それらはそれの一部だけをキャッチします。そのため、手でキーボードパスを続けて行ってください。

Juno簡単な自己監査 オートメーションは欠けたalt、欠けたラベル、およびコントラストを見つけます。WCAGの約3分の1です。そしてそれは意味や順序について何も判断します。そのため、キーボードパス、スクリーンリーダーを聞き通すこと、およびアクセシビリティインスペクターでの計算されたロール名への見かけと組み合わせます。ツールが実行できないチェックは最も重要なもの。そのため、レポートが緑でも自分で実行してください。