Yuisei-Maruyama
commented
2 years ago 対話型コンテンツ と 非対話型コンテンツ について
対話型コンテンツは、「ユーザーの操作のやり取りが期待されている要素」を指す。
非対話型コンテンツは、「ユーザーの操作を前提としない要素」を指す。
下記は「非対話型コンテンツ」として定義されている。
- a(href 属性があるもの）
- audio（controls 属性があるもの）
- button
- details
- embed
- iframe
- img（usemap 属性があるもの）
- input（hidden でないもの）
- label
- object（usemap 属性があるもの）
- select
- textarea
- video（controls 属性があるもの）
- tabindex="0"以上の全ての要素
対話型の中でも<button>や <a href="####"> が汎用的に使われる。
上記は、ブラウザ側で Enter キー（button の場合はスペースキーも含む）を押すと、click イベントを発火させる役割がある。
ブラウザの実装に則って統一された操作性を担保できるようにするために、
アクセシビリティとは？
「アクセシビリティ」という英語を直訳で表現すると「アクセスできるもの」ということになる。
日本語ではしばしば 「利用のしやすさ」 という表現をされていることが多い。
しかし、日本語には「ユーザビリティ」という言葉も存在する。
「ユーザビリティ」は直訳すると、「利用しやすさ」となる。
では、「アクセシビリティ」と「ユーザビリティ」はどういった違いがあるのかについて、下記で言及していく。
アクセシビリティとユーザビリティの違いについて
まず、「アクセシビリティ」と「ユーザビリティ」は影響範囲に違いがある。
具体的な例を用いると、
アクセシビリティ：「あらゆる状況」で「誰」にとっても、使えること
ユーザビリティ：「特定の状況」で「特定のユーザ」によって、使いやすさのメリットがあること
上記の例から、
アクセシビリティとは、状況を広く設定した中で、使いやすさには比重を置いていないこと
ユーザビリティとは、状況を狭く限定した中で、使いやすさを深く追求すること
と違いを表現できる。
Webアクセシビリティの誤解
上記のような認識は間違いである！！
例えば、「スマートフォンにおけるレスポンシブ対応 」を挙げてみる。
【目的】：あるWebサイトをスマートフォンに最適化した形で提供したい 【手段】：レスポンシブなレイアウトを提供すること
上記の目的を達成することで、こんなメリットがある！
など、アクセシビリティは 「あらゆる状況のあらゆる人達のもの」である！！
Webアクセシビリティの捉え方
Webアクセシビリティでよく意識されるもの
上記で書いたように、
Webアクセシビリティとは、
「あらゆる状況のあらゆる人達のもの」であること
を念頭においた上で特に意識されることは、
高齢者や多様性のある人のハンディキャップをどう改善できるのかと考えることである。
色盲のユーザであれば、赤や緑の区別が視覚的につきづらいと感じてしまうことがある。
WCAG Web Content Accessibility Guidelines 2.1
上記のような多様なハンディキャップを埋めるために下記のようなガイドラインがある！
https://waic.jp/docs/WCAG21/
達成基準には、「レベルA」から「レベルAAA」まである。
「レベルA」は達成しないと致命的な問題になることを示す。
組織ごとのWebアクセシビリティの取り組みについて
WCAGの文章は難しく、現場レベルに落とし込むのは困難である。 なので、下記のような企業が提案してくれているアクセシビリティ基準を参考にするのが良い！
Ameba：https://a11y-guidelines.ameba.design/ SmartHR：https://smarthr.design/accessibility/ freee：https://a11y-guidelines.freee.co.jp/
プルリクエストのレビューを出す時に、Lighthouse の計測結果を貼ることや機械的に計測できない項目を人間が行うなどを 行う必要がある！！
Webアクセシビリティ検証ツール
いずれのツールもエラーが出ないから完璧であるというわけではない！！！
法的な制約
欧米では、Webアクセシビリティ対応は義務になっている！！
エンジニアがWebアクセシビリティとどう向き合っていけば良いのか？
下記の2点を重視して開発に取り組む必要がある！！
エンジニアは最もサービスとの距離感が近い存在であるので、ガイドラインに沿って、アクセシビリティの改善サイクルを回しやすくする
Webアクセシビリティをパフォーマンスやコードの保守性と同じく非機能要件として扱う
できることから始めてみる