ガイドライン 1.1 テキストによる代替

https://waic.jp/docs/WCAG21/Understanding/text-alternatives.html

すべての非テキストコンテンツには、拡大印刷、点字、音声、シンボル、平易な言葉などの利用者が必要とする形式に変換できるように、テキストによる代替を提供すること。

→画像とか、テキスト以外のコンテンツは、代わりにテキストで伝えられるようにしとく。
（そうすると、読み上げなどの支援技術が使えて助かるよ）

達成基準 1.1.1 非テキストコンテンツ（レベルA）

利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されている。ただし、次の場合は除く:

→テキスト以外のコンテンツは、代わりにテキストで伝えられるようにしとく。ただし例外はあるよ。
（例外はここでは省略するけど、要はテキストでは表せないものとか、テキストで表す意味がないものとか）

ガイドライン 1.2 時間依存メディア

時間依存メディアってのは、動画とか音声とか。

達成基準 1.2.1 音声のみ及び映像のみ (収録済) （レベルA）

先にこれ↓

時間依存メディアに対する代替コンテンツ (alternative for time-based media)
時間依存の視覚的及び聴覚的情報を正しい順序で説明したテキストを含み、あらゆる時間依存のインタラクションによる結果を得る手段を提供している文書。

「時間依存のインタラクションによる結果を得る手段」って何…？
→解説によると、「より多くの情報を知るためには、今、クリックしてください」みたいなものらしい。

収録済の音声しか含まないメディア及び収録済の映像しか含まないメディアは、次の事項を満たしている。ただし、その音声又は映像がメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされている場合は除く:
収録済の音声しか含まない
時間依存メディアに対する代替コンテンツによって、収録済の音声しか含まないコンテンツと同等の情報を提供している。
収録済の映像しか含まない
時間依存メディアに対する代替コンテンツ又は音声トラックによって、収録済の映像しか含まないコンテンツと同等の情報を提供している。

音声だけのコンテンツ（例えばラジオみたいなやつ）は、文字起こししよう。
映像だけのコンテンツ（例えばGIFアニメみたいなやつ）は、文字起こしか、音声で説明しておこう。
（ちなみに、その音声とか映像がそもそもテキストの代わりな場合は当然だけどいらないよ）

達成基準 1.2.2 キャプション (収録済) (レベル A)

収録済み（生放送ではない）の音声に、キャプション（字幕）がついている。

達成基準 1.2.3 音声解説、又はメディアに対する代替 (収録済) (レベル A)

収録済み（生放送ではない）の映像に、テキストによる代替か、音声解説がついている。

達成基準 1.2.4 キャプション (ライブ) (レベル AA)

1.2.2の強化版。
生放送の音声にも、キャプション（字幕）がついている。

テレビはやってますよね。
最近だと自動文字起こしで文字表示（その場合目的は英語への翻訳なことが多い）してるVTuberさんとかいる。

達成基準 1.2.5 音声解説 (収録済) (レベル AA)

収録済み（生放送ではない）の映像（動画）に、音声解説がついている。
1.2.3 との違いは、テキストの代替ではなく、音声解説のみなこと。

達成基準 1.2.6 手話 (収録済) (レベル AAA)

収録済みの音声に、手話通訳が提供されている。

達成基準 1.2.7 拡張音声解説 (収録済) (レベル AAA)

「拡張音声解説」ってなんやねーん。

音声解説は、映像に対して音声による説明を追加するものです。通常、映像の再生速度はそのままで、主音声の合間を使って説明のナレーションを提供します。そのため、ナレーションを入れる時間に制限があり、提供できる情報量には限りがあります。
拡張音声解説は、説明のナレーションを提供する際に映像の再生を一時停止するものです。映像を停止してナレーションを流すことで、時間的な制約がなくなり、詳しい情報を提供することができます。長い説明が必要になるたびに映像の再生を一時停止し、必要なナレーションを全て提供してから再開するということを繰り返します。
https://waic.jp/qa/extended-audio-description/

へ～～～

達成基準 1.2.8 メディアに対する代替 (収録済) (レベル AAA)

収録済みの映像に対して、テキストによる代替を用意する。

達成基準 1.2.9 音声のみ (ライブ) (レベル AAA)

生放送の音声に、テキストによる代替を用意する。

ガイドライン 1.3: 適応可能

情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。

この文の意味はよく理解できてない 🤔
「見た目に依存しない」と思っていれば近いか？

達成基準 1.3.1 情報及び関係性 (レベル A)

情報が、マシンリーダブルである。
もしくは、テキストで提供されている。

わかりやすいイメージは、「CSSがなくなっても意味が伝わるか？」ということ。

<div style="font-size: 3rem; font-weight: bold;">見出し</div>
<div>本文本文本文本文本文本文</div>

これは、見た目によってのみ見出しであるという情報を示してしまっている。

<h1>見出し</h1>
<p>本文本文本文本文本文本文</p>

タグによって役割を示すことで、マシンリーダブルになる。

達成基準 1.3.2 意味のある順序 (レベル A)

コンテンツの順序に意味がある場合は、正しい順序がマシンリーダブルである。

例えば、空白で文字の間隔を制御している、改行で縦書きを実現しているといった場合に、正しい読み方を示すことができない。
https://waic.jp/docs/WCAG21/Techniques/failures/F32

達成基準 1.3.3 感覚的な特徴 (レベル A)

コンテンツを理解し操作するための説明は、形、色、大きさ、視覚的な位置、方向、又は音のような、構成要素が持つ感覚的な特徴だけに依存していない。

「右にあるボタンを押してください」「四角は〇〇、三角は××を表します」のような説明をしない。

達成基準 1.3.4 表示の向き (レベル AA)

縦向き・横向きを制限しない。

達成基準 1.3.5 入力目的の特定 (レベル AA)

入力フィールドで、目的がマシンリーダブルである。

具体的な実装は、 autocomplete 属性を用いること。
https://a11y-guidelines.ameba.design/1/3/5/

達成基準 1.3.6 目的の特定 (レベル AAA)

UI（ボタンなど）、アイコン、領域（ランドマークロール）の目的がマシンリーダブルである。

ガイドライン 1.4: 判別可能

コンテンツを、利用者にとって見やすく、聞きやすいものにすること。

達成基準 1.4.1 色の使用 (レベル A)

色だけを情報にしない。

例えば「赤字はエラーです」とか、グラフで「赤い線が去年のデータ、青い線が今年のデータです」とか。
具体的に「エラー」という文字と合わせて示すとかする。
「色を使うな」と言っている訳ではないので、わかりやすくするために色を使っていくのはぜひやっていこう。

特に色覚特性の違いによって見分けにくいことがある。日本人男性の20人に1人は先天色覚異常である。
https://www.santen.co.jp/ja/healthcare/eye/library/color_deficiency/
色覚異常がない場合でも、色の違いがわかりにくいなーという状況はある。

達成基準 1.4.2 音声の制御 (レベル A)

音声が自動的に流れる場合、

• 停止できる
• （システム全体の音量を変更することなく）音量を調整できる

ようにする。

メリットはわりと直感的にわかるんじゃないだろうか。コンテンツを見たいだけなのに音が流され続けると困る。
特に、スクリーンリーダーを使っている場合、他の音声が流れていると読み上げ音声が聞き取りづらく鳴る。そのため、「流れた後に止められる」ではなく、「ユーザーの操作によって再生が始まる」ほうが望ましい。

1.4.3 コントラスト (最低限) (レベル AA)

（最低限）とあるのは、1.4.6で（高度）の基準もあるから。

テキスト及び文字画像の視覚的提示に、少なくとも 4.5:1 のコントラスト比がある。

はっきり読みやすい文字を配置しましょう、ということ。
文字画像も含まれるのはちょっとポイント。
次の場合は例外。

• 大きな文字: サイズの大きなテキスト及びサイズの大きな文字画像に、少なくとも 3:1 のコントラスト比がある。
• 付随的: テキスト又は文字画像において、次の場合はコントラストの要件はない。アクティブではないユーザインタフェース コンポーネントの一部である、純粋な装飾である、誰も視覚的に確認できない、又は重要な他の視覚的なコンテンツを含む写真の一部分である。
• ロゴタイプ: ロゴ又はブランド名の一部である文字には、最低限のコントラストの要件はない。

大きい文字なら、多少コントラストが低くても読みやすいからいいということらしい。
（ただ実際には、大きく配置するような文字は目立たせる文字なので、大きい方の文字がコントラスト低いということはない気がする）
気になるのは、注釈の文言とかの表現として、あえてコントラスト弱めにしている部分だなあ。
#fff に対して4.5を確保すると、グレーならば #767676 が一番明るいライン。アルファ値で rgb(0,0,0,0.54) あたり。
背景が暗い色の場合にもコントラストを保つためにopacityでつけるといいってのも聞くなあ。

そこで、グレーを透過させることでこの課題を乗り越えることにしました。
https://developers.cyberagent.co.jp/blog/archives/26754/#chapter04

Vuetify だと、0.87, 0.6, 0.38（ライトモードの場合）を用意している。
0.38は基準を満たしてないように見えるが、これはDisabledを表すためのもので、
基準でも「アクティブではないユーザインタフェース コンポーネントの一部」は例外とされているので、disabledな要素に使うのであれば問題なさそう。

https://vuetifyjs.com/en/styles/text-and-typography/#opacity

1.4.4 テキストのサイズ変更 (レベル AA)

キャプション及び文字画像を除き、テキストは、コンテンツ又は機能を損なうことなく、支援技術なしで 200％ までサイズ変更できる。

（感想）具体的な数字まで決まってるんか。

わかりやすいところで言えば、ブラウザの文字拡大機能を使えるように実装しましょうね、ということ。
font-sizeにはpxではなくremを使おう。

目が見えづらい人や、文字が読みづらい人にとって、文字が大きくできると嬉しい。

1.4.5 文字画像 (レベル AA)

https://waic.jp/docs/UNDERSTANDING-WCAG20/visual-audio-contrast-text-presentation.html

文字は画像にせんといてくれ。
まあ、絶対画像にしなきゃいけない表現（ロゴとか）だとか、画像であっても拡大できるようにしてあるとかだったらいいけどね。

達成基準 1.4.6 コントラスト (高度) (レベル AAA)

1.4.3のレベルアップ版。
テキストと背景に、少なくとも 7:1 のコントラスト比（大きな文字の場合 4.5:1 のコントラスト比）がある。

かなり使用できる色の組み合わせが限られてくる。

達成基準 1.4.7 小さな背景音、又は背景音なし (レベル AAA)

収録済の音声しか含まないコンテンツ（ラジオのようなコンテンツ）の場合の話。

• 背景音（BGM）がない
• BGMを消せる
• BGM20dB以下

を満たす。
音声が聞きづらいユーザーが聞き取りやすくなる。

達成基準 1.4.8 視覚的提示 (レベル AAA)

テキストの表示について、次の機能を提供する。

• 利用者が、前景色と背景色を選択できる。
• 幅が 80 字を越えない (全角文字の場合は、40 字)。
• テキストが、均等割り付けされていない (両端揃えではない)。
• 段落中の行送りは、少なくとも 1.5 文字分ある。そして、段落の間隔は、その行送りの少なくとも 1.5 倍以上ある。
• テキストは、支援技術なしで 200％までサイズ変更でき、利用者が全画面表示にしたウィンドウで 1 行のテキストを読むときに横スクロールする必要がない。

達成基準 1.4.9 文字画像 (例外なし) (レベル AAA)

1.4.5のレベルアップ版。
（カスタマイズ可能な場合　の例外が削除されているということ？）

達成基準 1.4.10 リフロー (レベル AA)

（スマホの登場によって最近追加された基準っぽい）
以下のどちらかを満たす。

• 横幅320pxで表示して、縦スクロールのみ（横スクロールなし）で閲覧できる
• 高さ256pxで表示して、横スクロールのみ（縦スクロールなし）で閲覧できる

一般的なWebページなら、縦スクロールで閲覧するので、適用されるのは前者だろう。
body { min-width: 375px; } といった制限をかけることなく、320px幅での閲覧に対応する必要がある。

達成基準 1.4.11 非テキストのコントラスト (レベル AA)

UI （ボタンとか）や、グラフィック（画像）が隣接した色との間で少なくとも 3:1 のコントラスト比がある。

達成基準 1.4.12 テキストの間隔 (レベル AA)

以下のようにCSSを上書きされても、コンテンツが読めて、機能が使えるようにする。

• 行の間隔 (行送り) をフォントサイズの少なくとも 1.5 倍に設定する
• 段落に続く間隔をフォントサイズの少なくとも 2 倍に設定する
• 文字の間隔 (字送り) をフォントサイズの少なくとも 0.12 倍に設定する
• 単語の間隔をフォントサイズの少なくとも 0.16 倍に設定する

例えば、ある要素の高さを固定していて、行間を1.5に広げるとテキストがはみ出て読めなくなってしまうといった例はこれに適合しない。
「上記を設定しろ」ということではなく、「上書きされても問題ないか」である。

達成基準 1.4.13 ホバー又はフォーカスで表示されるコンテンツ (レベル AA)

ポインタホバー又はキーボードフォーカス表示させるもの（ホバーで説明が出てくるツールチップのようなもの）は、以下の要件を 全て 満たす:

• ホバーやフォーカスを外すことなく、非表示にすることができる
• 表示されたコンテンツ上でポインタを動かせる（ポインタを動かした途端消える、ということがない）
• ホバーやフォーカスが外されるか、ユーザーが非表示にするまでは、表示され続ける

「ホバーやフォーカスを外すことなく、非表示にすることができる」はEscキーで解除できるような実装を指す。
ホバーで何かを表示するような機能は結構ありますが、「ホバーやフォーカスを外すことなく、非表示にすることができる」のは意識してないとわざわざ対応しないですね・・・。

ガイドライン 2.1: キーボード操作可能

すべての機能をキーボードから利用できるようにする。

キーボード操作ができるなら、
音声操作でも（音声によってキーボード入力をして）
マウスでも（オンスクリーンキーボードを使って）
使えることになる。

達成基準 2.1.1 キーボード (レベル A)

すべての機能をキーボードから利用できるようにする。

達成基準 2.1.2 キーボードトラップなし (レベル A)

キーボードのフォーカス移動がトラップ（その場から抜け出せない状態）されない。

キーボードで操作する場合、Tabキーによってフォーカスの移動ができる。
モーダルウィンドウを開いたときなど、一時的にフォーカスをトラップする（モーダルウィンドウ内だけでフォーカスが移動するようにする）ことがある。
ただし、このまま抜け出せなくなってしまうと、一生他の場所を見ることができない。（進行不能バグみたいなもの）
閉じるボタンを押す（Enter）すると抜け出せるとか、Escキーで抜け出せるとかの方法を用意する。

達成基準 2.1.3 キーボード (例外なし) (レベル AAA)

すべての機能をキーボードから利用できるようにする。

2.1.1と同じじゃんと思うかもしれないが、「例外なし」とあるように、
2.1.3で除外されていた例外

ただし、その根本的な機能が利用者の動作による始点から終点まで続く一連の軌跡に依存して実現されている場合は除く。

を含む。
・・・？

手書き入力のようなものが「一連の軌跡に依存」する機能。

これは、終点だけでなく利用者の動作の軌跡に依存する入力が、基本機能に必要なコンテンツ (つまり、達成基準 2.1.1 では例外とされていたコンテンツ) にキーボードでアクセシブルにする必要があることを意味しない。逆に、そういった軌跡に依存した入力を用いるコンテンツは、この達成基準に適合することができないため、ガイドライン 2.1 にレベル AAA で適合することはできないということである。

ということなので、軌跡に依存する機能をなくせ、ということか…？？

達成基準 2.1.4 文字キーのショートカット (レベル A)

キーボードショートカットがある場合、

• ショートカットを解除できる
• 別のキーに割り当てることができる
• フォーカスを受け取っているときのみ有効になっている

のどれかならOK。

この達成基準の意図は、キーボードショートカットの誤った動作を減らすこと

ガイドライン 2.2: 十分な時間

利用者がコンテンツを読み、使用するために十分な時間を提供すること。

達成基準 2.2.1 タイミング調整可能 (レベル A)

コンテンツに制限時間があるような場合、制限時間を

• 解除できる
• 調整できる
• 延長できる

ただし、オークションなど、リアルタイムのイベントで、制限時間をつけるしかないような場合は例外。

達成基準 2.2.2 一時停止、停止、非表示 (レベル A)

自動再生のコンテンツは、停止できる仕組みがある。

達成基準 2.2.3 タイミング非依存 (レベル AAA)

操作がタイミングに依存しない。

達成基準 2.2.4 割り込み (レベル AAA)

緊急を要する場合を除いて、割り込み（自動的な更新など）を抑制できる。

達成基準 2.2.5 再認証 (レベル AAA)

認証済のセッションが切れた場合は、再認証後でもデータを失うことなく利用者が操作を継続できる。

達成基準 2.2.6 タイムアウト (レベル AAA)

データの損失を引き起こす恐れのある利用者の無操作の残り時間が警告される。ただし、利用者が 20 時間以上何もしなくてもデータが保持される場合は、この限りではない。

ガイドライン 2.3: 発作と身体的反応

発作や身体的反応を引き起こすようなコンテンツを設計しないこと。

達成基準 2.3.1 3 回の閃光、又は閾値以下 (レベル A)

ポリゴンショックで知られる問題。

ウェブページには、どの 1 秒間においても 3 回を超える閃光を放つものがない、又は閃光が一般閃光閾値及び赤色閃光閾値を下回っている。

達成基準 2.3.2 3 回の閃光 (レベル AAA)

2.3.1のレベルアップ版

ウェブページには、どの 1 秒間においても 3 回を超える閃光を放つものがない。

達成基準 2.3.3 インタラクションによるアニメーション (レベル AAA)

アニメーションが、機能又は伝達されている情報に必要不可欠でない限り、インタラクションによって引き起こされるモーションアニメーションを無効にできる。

「ないこと」ではなく、「無効にできること」。

よくある例は、パララックス。

ガイドライン 2.4: ナビゲーション可能

利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。

達成基準 2.4.1 ブロックスキップ (レベル A)

複数のウェブページ上で繰り返されているコンテンツのブロックをスキップするメカニズムが利用できる。

わかりやすい例が、スキップリンク。Googleでも実装されている。

達成基準 2.4.2 ページタイトル (レベル A)

ウェブページには、主題又は目的を説明したタイトルがある。

HTML では、title タグを入れること。

達成基準 2.4.3 フォーカス順序 (レベル A)

ウェブページが順を追ってナビゲートできて、そのナビゲーション順が意味又は操作に影響を及ぼす場合、フォーカス可能なコンポーネントは、意味及び操作性を損なわない順序でフォーカスを受け取る。

達成基準 2.4.4 リンクの目的 (コンテキスト内) (レベル A)

それぞれのリンクの目的が、リンクのテキスト単独で、又はリンクのテキストとプログラムによる解釈が可能なリンクのコンテキストから判断できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。

「もっと見る」リンクや「こちら」リンクが悪い例。
https://a11y-guidelines.ameba.design/2/4/4/

達成基準 2.4.5 複数の手段 (レベル AA)

ウェブサイトの中で、あるページを見つけるための手段が複数ある。
例えば、「トップページからのリンク」「サイトマップ」「グローバルナビゲーション」「検索」などのうちから2つ以上。

ただし、「フォームの送信完了画面」のような、操作の1ステップ or 結果のページは別。

達成基準 2.4.6 見出し及びラベル (レベル AA)

見出し及びラベルは、主題又は目的を説明している。

達成基準 2.4.7 フォーカスの可視化 (レベル AA)

Web制作においては、見た目上の問題から、フォーカスリングが削除されることがある。
しかし、キーボード操作時にフォーカス位置がわからなくなってしまうため、少なくともキーボード操作時にはフォーカスリングを表示すべきである。
方法としては、what-inputを使用して、マウス操作時のみフォーカスリングを打ち消すという妥協策がある。
https://www.npmjs.com/package/what-input

達成基準 2.4.8 現在位置 (レベル AAA)

ウェブページ一式の中での利用者の位置に関する情報が利用できる。

パンくずなど。

達成基準 2.4.9 リンクの目的 (リンクのみ) (レベル AAA)

それぞれのリンクの目的を、リンクのテキスト単独で特定できるメカニズムが利用できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。

2.4.4の強化版。
コンテキスト（前後の文脈）によらず、リンクのテキスト単体で理解できるようにする。

達成基準 2.4.10 セクション見出し (レベル AAA)

セクション見出しを用いて、コンテンツが整理されている。

わりと当たり前のことだな。

ガイドライン 2.5: 入力モダリティ

マウスやタッチで使いやすくしましょうねのコーナー。

ユーザーがキーボード以外の様々な入力を通じて機能を操作しやすくすること。

すべての機能を、マウスでも、タッチでも使えるようにする。
ここでキーボードを入れていないのは、2.1に「キーボード操作可能」が定義されているため。

達成基準 2.5.1 ポインタのジェスチャ (レベル A)

「マルチポイント又は軌跡ベースのジェスチャ」が必要な機能は、すべてジェスチャなしのポインタ操作が可能であるようにする。
「軌跡ベースのジェスチャ」というのは、いわゆるマウスジェスチャであるとか、ドラッグアンドドロップとか。「マルチポイントのジェスチャ」はピンチイン・ピンチアウトなど。

拡大操作をピンチインのみでできるようにするのではなく、「+」「-」ボタンを用意することなどが具体的な解決策。
https://a11y-guidelines.ameba.design/2/5/1/

達成基準 2.5.2 ポインタのキャンセル (レベル A)

「クリック」「タップ」で実行される機能が、押し始めた後にキャンセルできるようにする。

解説すると、クリックのイベントには「押し始めた (ダウンイベント、mousedown)」と「離した (アップイベント、mouseup)」がある。
機能を実装するとき、ダウンイベントで実行するのではなく、アップイベントで実行するようにすると、間違ってボタンを押し始めたとしても、別の場所にカーソルを移動させて離すことで、やっぱやめたができる。

達成基準 2.5.3 名前 (name) のラベル (レベル A)

UI（リンクやボタン）にテキスト（文字画像も）を含むラベルがあるとき、視覚的に見えるテキストを「名前（機械的に読み取れる名前）」に含める。
単に機械的にも読めるようにしましょう、ではなく、見えるものと合わせることが必要。

含めることなので、必ずしも一致させる必要はなく、

<button aria-label="Search for a value">Search</button>

もアリ。

達成基準 2.5.4 動きによる起動 (レベル A)

デバイスを振ったり、傾けたりして使う機能がある場合、動き以外でも使えるようにして、かつ動きでの起動を止められるようにする。

動けない状況で使うかもしれないし、逆に揺れている場所で間違って動かしてしまう、なんてこともあるかも。
また、振戦といった体が震えてしまう病気も存在する。

達成基準 2.5.5 ターゲットのサイズ (レベル AAA)

ボタンなど、クリック・タッチする対象のサイズを 44 × 44 CSS ピクセル以上にする。
（テキストリンクは例外）

特にタッチ操作の場合などは、指の太さによって精度が低くなるので、大きいと押しやすいよね。

（感想）
レベルAAAであるからといって、それ以外を目指す場合に気にしなくていいかというとそうではないと思う。
44 x 44を完全にクリアするのは難しくても、可能な限り大きい方が使いやすい。

達成基準 2.5.6 入力メカニズム非依存 (レベル AAA)

入力方法を制限しない。途中で変えることもできるようにする。
キーボードでも、マウスでも、タッチでも、いろんな方法で使えると便利だよね。

具体的には、多くの場合パソコンにはキーボードとマウスがどちらもつながっているし、
タブレットPCの場合はそれに加えてタッチディスプレイもある。
また、スマートフォンでも、Bluetoothでマウスやキーボードをつなぐことだってできる。

ガイドライン 3.1: 読みやすさ

テキストのコンテンツを読みやすく理解可能にすること。

達成基準 3.1.1 ページの言語 (レベル A)

ページのデフォルトの自然言語（日本語、英語、、、）がプログラムで理解できるようになっている。
htmlタグにlang="ja" をつける。

(複数の言語が同じ割合で使われている場合、最初に使われている言語をデフォルトの自然言語として選択する必要がある。)

へー

3.1.2 一部分の言語 (レベル AA)

一部が別の言語で書かれている場合、そこがプログラムでわかるようにする。
lang属性をつける。

達成基準 3.1.3 一般的ではない用語 (レベル AAA)

専門用語などを使うときは、説明を加える。
その場で説明する、用語集を用意する、など。

達成基準 3.1.4 略語 (レベル AAA)

（ほぼ3.1.3と同じじゃない？）
略語に説明を加える。
HTMLでは abbr も使える。

達成基準 3.1.5 読解レベル (レベル AAA)

固有名詞や題名を取り除いた状態で、テキストが前期中等教育レベルを超えた読解力を必要とする場合は、補足コンテンツ又は前期中等教育レベルを超えた読解力を必要としない版が利用できる。

めちゃムズいこと言ってるように見えて、
「中学生でもわかるように書こう」ということ。

達成基準 3.1.6 発音 (レベル AAA)

発音が違うと違う意味になってしまうような場合、読み方を提供する。
カッコ書きで書くことでよい。

ruby要素で提供する、とも書いてあるが、rubyが正しく読まれるのかは不明・・・。

ガイドライン 3.2: 予測可能

ウェブページの表示や挙動を予測可能にすること。

びっくりさせない、混乱させない。

達成基準 3.2.1 フォーカス時 (レベル A)

フォーカスしただけでコンテキストの変化（モーダルを開いたり、ページを移動したり）をさせない。
びっくりしちゃう。

クリックやEnterなどで実行させる。

達成基準 3.2.2 入力時 (レベル A)

UI要素の状態を変える（チェックボックスをチェックした、文字を入力したなど）ときにコンテキストの変化を起こさない。
びっくりしちゃう。

達成基準 3.2.3 一貫したナビゲーション (レベル AA)

サイト内で出てくるナビゲーションは、ページが変わっても同じ場所（「相対的に同じ順序」）に表示されるようにする。
追加削除はあってもいい。例えば、下層ページに入るとより詳細なメニューが表示されたりするのはいい。すでに登場した項目が逆順になったりしなければいい。

達成基準 3.2.4 一貫した識別性 (レベル AA)

サイト内に出てくる同じ機能を持つ要素を、同じように識別できるようにする。
機能が同じなら、同じ名前（ラベル）をつけるようにする。

達成基準 3.2.5 要求による変化: (レベル AAA)

コンテキストの変化（モーダルを開いたり、ウィンドウを開いたり）は、利用者が実行した場合にのみ限定する。
もしくは、止められる仕組みをつくる。
（3.2.1, 3.2.2とはどう違うんだ？）
→クライアント側のリダイレクトとかか。

ガイドライン 3.3: 入力支援

利用者の間違いを防ぎ、修正を支援すること。

誰でもミスをすることがある。
https://waic.jp/docs/WCAG21/Understanding/input-assistance.html

ほんまそれ

しかし、ある種の障害のある人は、エラーを起こさずに入力するのがより困難である。

さらにはこういう状況もある。

達成基準 3.3.1 エラーの特定 (レベル A)

入力がエラーになっている場合は、エラーの箇所がユーザーに伝わるようにする。

実装例としては aria-invalid など。

達成基準 3.3.2 ラベル又は説明 (レベル A)

入力させる場合、何をどんなふうに入力すべきか説明する。

達成基準 3.3.3 エラー修正の提案: (レベル AA)

エラーが検出できて、修正が提案できるなら、提供する。

達成基準 3.3.4 エラー回避 (法的、金融、データ) (レベル AA)

重要な操作をするページ（法律行為、金融取引、ストレージ上のデータの変更、試験の解答など）は、以下のどれかをできるようにする

• 操作の取り消し
• データのチェック
• 送信前の確認（修正）

重要な操作ミスったら困るよね。

達成基準 3.3.5 ヘルプ (レベル AAA)

そのとき実行している機能に関して、ヘルプを提供する。

達成基準 3.3.6 エラー回避 (すべて) (レベル AAA)

3.3.4の強化版。
情報を送信するページならどんなページでも、以下のどれかをできるようにする

• 操作の取り消し
• データのチェック
• 送信前の確認（修正）

ガイドライン 4.1: 互換性

限定的な環境（Chromeだけ、とか）で使えるだけじゃなくて、様々な環境（他のブラウザや、読み上げソフトなど）で使えるようにしましょうね。
また、今動くだけじゃなく、将来も壊れないようにしましょう。

4.1.1 構文解析 (レベル A)

https://waic.jp/docs/WCAG21/Understanding/parsing.html

HTMLの書き方の話。要は正しいHTMLを書きましょう！という話。
具体的には以下を守りましょう！

• 完全な 開始タグと終了タグがある
  • 山カッコ（>）が欠けていたりとか、引用符（"）が対応していなかったりすると、「完全な」ではなくなる。
• 仕様に準拠した入れ子になっている
• 一つの要素に重複した属性を設定しない
• ページ内でidを一意にする

※ただし仕様で認められてるものを除く

「ちょっとくらい間違ってても、ブラウザで表示できたんだったらいいじゃん！」と思うかもしれないけど、
ブラウザは正しくない書き方をされたHTML（たとえば、必要な閉じタグが抜けてるとか）も「まあこういうことだろうな」と「修復」して表示している。
この修復方法はブラウザによって違うので、あるブラウザで正しく表示できたからと言って、他のブラウザでも表示できるとは限らない。

だから、どんなブラウザ（正しくはユーザーエージェント）でも正しく表示される「丈夫さ」のために、正しいHTMLを書きましょう。

4.1.2 名前 (name)・役割 (role) 及び値 (value) (レベル A)

https://waic.jp/docs/WCAG21/Understanding/name-role-value.html

ウェブアプリとかを作る場合の話っぽい。

名前：ラベルとほぼ同義
役割：「これはボタン」とか「これはリンク」とか。
値：たぶん、inputの中に入れるテキストとか、チェックボックスがチェックされているか否か、とか

この達成基準は、主に独自のユーザインタフェース コンポーネントを開発、又はスクリプトで実装するコンテンツ制作者に向けたものである。例えば、標準的な HTML のコントロールを仕様に沿って使用していれば、既にこの達成基準を満たしていることになる。

HTMLのinputで作ってる限りは気にしなくていいらしい。

ユーザインタフェース コンポーネント (user interface component)
コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。

ただのテキストとかじゃなくて、操作する部分、と思っておけばいいかな。

4.1.3 ステータスメッセージ (レベル AA)

ステータスメッセージってなんぞ？

1. メッセージはアクションの成功又は結果、アプリケーションの待機状態、プロセスの進捗、又はエラーの存在に関する情報を利用者に提供する
2. メッセージはコンテキストの変更によって配信されない

1はまあわかる、2はなんのこと？？

動的にコンテンツを表示する場合でも、検索結果のリストはステータスの更新とはみなされない。

「検索結果が表示される」は、コンテキストの変化に関する情報
https://a11y-guidelines.ameba.design/4/1/3/

らしい。

むしろ「コンテキスト」ってなんだ？？

コンテキストの変化 (changes of context)
ウェブページのコンテンツにおける大きな変化で、利用者が気づかないと、ウェブページ全体を一度に見ることのできない利用者を混乱させる恐れのあるもの。
https://waic.jp/docs/WCAG21/Understanding/status-messages.html#dfn-change-of-context

？？

1. ユーザエージェント
2. ビューポート
3. フォーカス
4. ウェブページの意味を変えるコンテンツ

ふむ。

コンテンツの変化が、必ずコンテキストの変化になるとはかぎらない。アウトラインの展開、動的なメニュー、又はタブの切替などのコンテンツの変化は、それが上記のいずれか (例: フォーカス) を変更しないかぎり、状況を変化させるとは限らない。

内容を変えること、ではなくて、混乱させうる変化かどうかなのか。
アラートダイアログがフォーカスを受け取るなども、コンテキストの変更の例。

で、ステータステキストがなんだったかというと、
コンテキストの変更ではないもの。
つまり、あえて伝えるための処理を行う必要がある。

「エラーが発生しましたよ！」とか、「処理が終わりましたよ！」とか、状態が変わったことを伝える。

aria-live=assertive や role=alert を使うらしい。具体的な実装については作ることになった場合に調べることにしよう。
https://waic.jp/docs/WCAG21/Techniques/aria/ARIA19