1. ウェブディレクターのための
Web A11Y 勉強会
#10 (2018-03-13)

2. 自己紹介
@caztcha
ウェブユーザビリティ / アクセシビリティ / 情報アーキテクチャ (IA)
HCD-Net 認定 人間中心設計専門家
ウェブアクセシビリティ基盤委員会 (WAIC) 翻訳 WG
https://website-usability.info

3. • ウェブアクセシビリティとは？
• ウェブアクセシビリティはなぜ必要なの？
• 支援技術を知ろう
• アクセシビリティ検証ツールいろいろ
• スクリーンリーダーを体験しよう!
• WCAG 2.0 の概略
• WCAG 2.0 (Level A) を読もう！
前回までのあらすじ

4. 今日のメニュー
• WCAG 2.0 (Level A) を読もう！
• 3.3.1 エラーの特定
• 3.3.2 ラベル又は説明
• 4.1.1 構文分析
• 4.1.2 名前 (name)、役割 (role) 及び値 (value)
• この勉強会のまとめ
「原則3 (理解可能)」の続きとして、
利用者の入力を支援することを学びま
す。最後に「原則4 (堅牢)」として、
コンテンツの堅牢性 (支援技術を含む
ユーザーエージェントとの互換性) に
ついて触れます。

5. WCAG 2.0 (Level A) を読もう！
(達成基準、解説書、達成方法集)

6. WCAG 2.0 の基本構成
おさらい
原則 (4)
ガイドライン (12)
達成基準 (61)
このうちレベル「A」のみが
本勉強会の対象です。
1. 知覚可能 (Perceivable)
2. 操作可能 (Operable)
3. 理解可能 (Understandable)
4. 堅牢 (Robust)

7. 原則 3. 理解可能 (Understandable)
情報及びユーザインタフェースの操作は理解可能でなければな
らない。
おさらい

8. ガイドライン 3.3 入力支援
利用者の間違いを防ぎ、修正を支援すること。

9. 達成基準 3.3.1
エラーの特定
入力エラーが自動的に検出された場合は、エラーとなっている箇所が特定さ
れ、そのエラーが利用者にテキストで説明される。 (レベル A)
達成基準 3.3.1 を理解する | WCAG 2.0解説書
https://waic.jp/docs/UNDERSTANDING-WCAG20/minimize-error-identified.html

10. [用語 ] 達成基準 3.3.1 エラーの特定
入力エラー
ユーザーが入力した情報で、システムが受け付けられないもの。

11. [まとめ] 達成基準 3.3.1 エラーの特定
ユーザーが情報を入力し、その入力をシステムが受け付けられない場合は、アクセシブルな形で
エラーメッセージを表示しましょう。
✓ エラーメッセージは、様々な障害者でも理解できるように、テキストで記述しましょう。
✓ エラーメッセージでは、エラー内容 (どんな不備があるのか？) と、エラー箇所 (どこに不備があるのか？) をわか
りやすく伝えましょう。
✓ WAI-ARIA を用いて、スクリーンリーダー利用者にもエラーが伝わりやすくしましょう。
● 全体的なエラーメッセージの要素に role=“alert” を記述しておくと、自ずと aria-live=“assertive” として機
能するので、エラーメッセージが表示されると同時にエラーメッセージをスクリーンリーダーが読み上げてく
れます。
● 個々のエラー箇所では、フォーム入力要素に aria-invalid=“true” を記述しておくと、その要素にフォーカス
が当たったときにスクリーンリーダーが「正しくない入力内容」などと読み上げてくれます。(ただし、より
具体的にメッセージを伝えるためには、別途エラーメッセージを生成し、フォーム入力要素と aria-
describedby で紐付けておくとよいでしょう。)

12. お名前 [必須]
メールアドレス [必須]
foo
……
送信
未記入の項目があるか、書式が適切でない項目があります。詳細は、各入力項目をご
確認ください。
未記入です。
不適切な書式です。
role=“alert”
aria-live=“assertive”
aria-describedby で紐付け
aria-invalid=“true”
aria-describedby で紐付け
aria-invalid=“true”

13. お名前を記入してください。
メールアドレスの書式が不適切です。
……
送信
お名前 [必須]
foo
覚えておかなければならない。
ここが要修正箇所だっけ？
ここが要修正箇所だっけ？
メールアドレス [必須]
一見親切だけど
地味に記憶負荷
が高い…

14. 達成基準 3.3.2
ラベル又は説明
コンテンツが利用者の入力を要求する場合は、ラベル又は説明文が提供さ
れている。 (レベル A)
達成基準 3.3.2 を理解する | WCAG 2.0解説書
https://waic.jp/docs/UNDERSTANDING-WCAG20/minimize-error-cues.html

15. [用語 ] 達成基準 3.3.2 ラベル又は説明
(特にありません )

16. [まとめ] 達成基準 3.3.2 ラベル又は説明
フォームの入力要素には、ラベルを付けましょう。
✓ ラベルは <label> 要素でマークアップし、for 属性で入力要素と紐付けましょう。入力要素にフォーカスが当たると同
時にラベルが読み上げられます。また、チェックボックスやラジオボタンの場合、<label> も含めてクリック可能領域
になります。
✓ 入力必須項目の場合は、ラベルの中に「必須」と明記しましょう。
✓ プレースホルダーをラベルの代替とするのは基本的に避けましょう。
ひとつの入力要素に複数のラベルが紐づく場合は、aria-labelledby で紐付けましょう。
✓ 「参加者 [ ] 名」のように、入力フィールドの前後にラベルがある場合
✓ テーブルのデータセルに入力要素があって、行/列の TH など複数の情報を組み合わせて理解する必要がある場
入力要素に入力フォーマットなどの説明文が紐づく場合は、aria-describedby で紐付けましょう。
ラジオボタンやチェックボックスのグルーピングをする場合は、<fieldset> 要素および <legend>
要素を用いましょう。

17. お名前 [必須]
電話番号
……
送信
参加人数
名様
<label> 要素でマークアップ
ハイフンなしで数字のみをご記入ください。(例 : 0312345678)
aria-describedby で紐付け
aria-labelledby で紐付け

18. 原則 4. 堅牢 (Robust)
コンテンツは、支援技術を含む様々なユーザエージェントが確実に
解釈できるように十分に堅牢 (robust) でなければならない。

19. ガイドライン 4.1 互換性
現在及び将来の、支援技術を含むユーザエージェントとの互換
性を最大化すること。

20. 達成基準 4.1.1
構文解析
マークアップ言語を用いて実装されているコンテンツにおいては、要素には完全
な開始タグ及び終了タグがあり、要素は仕様に準じて入れ子になっていて、要素
には重複した属性がなく、どの ID も一意的である。ただし、仕様で認められてい
るものを除く。 (レベル A)
達成基準 4.1.1 を理解する | WCAG 2.0解説書
https://waic.jp/docs/UNDERSTANDING-WCAG20/ensure-compat-parses.html

21. [用語] 達成基準 4.1.1 構文解析
(特にありません)

22. [まとめ] 達成基準 4.1.1 構文解析
HTML の仕様に準じて、適切にマークアップしましょう。
HTML のバリデーターでチェックするのも有効です。ただしアクセシビリティの観点で
は、必ずしも “valid” でなくてもよいケースがあります。
✓ HTML5 のセクション要素 (例 : <nav> 要素) 内のランドマークの併記 (例 : role=“navigation”) など。

23. 達成基準 4.1.2
名前 (name) ・役割 (role) 及び値 (value)
すべてのユーザインタフェース コンポーネント (フォームを構成する要素、リンク、ス
クリプトが生成するコンポーネントを含むがこれに限定されない) では、名前 (name)
及び役割 (role) は、プログラムによる解釈が可能である。又、状態、プロパティ、利用
者が設定可能な値はプログラムによる設定が可能である。そして、支援技術を含むユー
ザエージェントが、これらの項目に対する変更通知を利用できる。 (レベル A)
達成基準 4.1.2 を理解する | WCAG 2.0解説書
https://waic.jp/docs/UNDERSTANDING-WCAG20/ensure-compat-rsv.html

24. [用語] 達成基準 4.1.2 名前 (name) ・役割 (role) 及び値 (value)
プログラムによる解釈が可能
ウェブコンテンツが、様々なユーザーエージェント (ブラウザやスクリーンリーダー) によって処理/解釈されて、多
様なモダリティ (視覚情報、聴覚情報、触覚情報、など) で情報が提示できること。
プログラムによる設定が可能
支援技術を含むユーザーエージェントがサポートする手法を用いて、ソフトウェアによって設定が可能であること。
名前 (name)
ソフトウェアが、ウェブコンテンツのコンポーネントを利用者に識別させることができるテキスト。多くの場合、ラ
ベルと名前は同じ。
役割 (role)
ウェブコンテンツに含まれるコンポーネントの機能を、ソフトウェアが識別するために用いることができるテキスト
や数字。

25. [まとめ] 達成基準 4.1.2 名前 (name) ・役割 (role) 及び値 (value)
すべての UI 部品は、HTML のセマンティクスに則って、正しくマークアップしましょう。
HTML のセマンティクスでは、ユーザーに十分な情報を届けることができない場合は、必
要に応じて WAI-ARIA を適切に記述しましょう。

26. この勉強会のまとめ

27. (この勉強会の目標)
日々のウェブコンテンツ制作実務においてアクセシ
ビリティの担保を継続的に回せること。そのための
基礎作り。

28. (目指したいこと)
サイトオーナー (発注者) が意識せずとも自ずとア
クセシビリティが担保されている状態。

29. いかがでしたか？

30. まずは、いい基礎作りができたかな、と思います。

31. WCAG 2.0 を最後まで実際に読み解いた
ということ自体が、とてもすごいこと。

32. アクセシビリティを理解し実践できる
ことを、みなさんご自身の「強み」に！

33. (ウェブアクセシビリティに関するご相談は、いつでもお気軽にどうぞ！ )

34. おつかれさまでした。