Webアプリケーションアクセシビリティ読書まとめ

アクセシビリティとは「利用可能な状況の幅広さ」を指す。

ユーザビリティとアクセシビリティは似ているが、
ユーザビリティ：特定ユーザが特定条件で使いやすいかどうか
アクセシビリティ：多様なユーザが多様な条件下で使えるかどうか

多くの状況でアクセスできるものはアクセシビリティが高く、
逆に特定条件でしかアクセスできないものはアクセシビリティが低い。

アクセシビリティは、「利用しやすさ」と翻訳されることもあり、この語感が「改善したほうが良いけど、使えないわけではないから優先度は高くない」という解釈に繋がり得る。

Webはアクセシビリティの為に存在するメディア。

Webにコンテンツを載せて公開するだけで堅牢・発見・携帯までがカバーできる。
Webはそもそもアクセシブル。

Webが出現する前は、オンラインで買い物、ニュースを読む、学習するということができなかった。
Web上にサービスやコンテンツを作るだけで世界をアクセシブルにすることに貢献している。

Webコンテンツは形を変えられる
文字の大きさ、表示状態などの使い方を変化させられる

Webの力は、ユニバーサル性にある。障害の有無に関わらず誰もがアクセスできることがWebの本質。

Webアクセシビリティと障害について
WCAG 2.1というものがあるが、
こうしたガイドラインを読み解く前提として、まず「どういった障害があり。ユーザがどうのように対処してWebにアクセスしているか」を制作側が理解しておく必要がある

同じ視覚以上でも
色覚異常と全盲とで取るべきアクセシビリティの対応が異なる

色覚異常

• 色の衝突が発生した場合でも見えるような対応

全盲

• スクリーンリーダーを用いた音声読み上げ対応
• 画面が見えない為、マウスが利用できない。スクリーンリーダー依存の入力対応

全盲、色覚異常の中で点字が読める率は全体の12.7%程。

聴覚異常

ろう者：先天的に聞こえない、音声言語を獲得する前に失聴
中途失聴者：音声言語を獲得したあとに失聴

音声コンテンツ系から情報を得るのが難しい

キャプション、書き起こし、手話などで対応

認知・学習障害

• 学習、コミュニケーション、読み書き、算数
• 新しい情報や複雑な情報を理解して技能を習得する能力、自立して対処する能力
• 記憶力、注意力、視覚的・言語的・数値的な思考力

短期記憶障害：パスワードやアクセスコードを思い出せない可能性

情報処理能力障害：デザインの関係性や情報を理解するために時間がかかる

言語障害：シンプルな言葉、指示が必要な場合がある。また、補助的なグラフィック、アイコン、見慣れたシンボルに依存する場合もある

社会的生姜、コミュニケーション障害：比喩、文字以外のテキスト、新しいアイコンが理解できない。文字通り明確な言葉を必要とする場合がある

数学的概念の理解への障害：非パーセンテージ、数値参照を理解できなかったり、混同したりする

集中力の維持・回復に課題がある場合：気が散ったり中断されたりが多いとタスクが出来ない

補助機能を使ったところで、もともと分かりにくものを分かりやすくすることは出来ない。
認知学習障害に対しては、本質的にはWebサイトやWebアプリケーションをシンプルで分かりやすく設計することが必要。

加齢に伴う能力の変化に対しては、少し障害とは異なるが、本質的なアプローチはシンプルな設計

Webアクセシビリティに取り組む時によく参照されるのがWCAG（Web Content Accessibility Guidelines）

４原則
知覚可能
操作可能
理解可能
堅牢

「そこに情報やUIがある」と近くできること
そのUIやナビゲーションが操作できること
ページ上の情報やUIの操作に関する情報が理解できること
標準仕様に則って実装することで、互換性を最大化すること

WCAG自体は技術が変わっても普遍的に対応できるように抽象化されて書かれているため、
実務で多くの人が利用するためには工夫が必要。
アクセシビリティへの取り組みをすすめる各社がWCAGをベースとしつつ分かりやすさ、読みやすさを改善した独自のガイドラインを公開

freeeアクセシビリティガイドライン（https://a11y-guidelines.freee.co.jp/）
Ameba Accessibility Guidelines（https://a11y-guidelines.ameba.design/）
ウェブアクセシビリティ簡易チェックリスト｜SmartHR Design System（https://smarthr.design/accessibility/check-list/）

WCAGにはレベルA, AA, AAAの3つの適合レベルがある。

WCAG レベルA
最低ライン。レベルAの基準を満たしていないと支援技術を用いても全くアクセスできなくなる場合がある。
「マシンリーダビリティ」つまり機械可読性という概念に紐づく。
マシンリーダビリティを実現する方法はシンプル。
テキストだけで分かるようにコンテンツやラベルを準備し、それを適切なHTMLとしてマークアップすれば良い。
SEOのセオリーと概ね一致する。
Googleのクローラが正しくコンテンツを解釈できるように、コンテンツをマシンリーダブルにする行為こそがSEOの初歩。
つまりSEOとは、Webが持つ「コンテンツをアクセシブルに届ける仕組み」を前提としたもの

Web上でUIを作るには、HTMLに定義されているフォームやボタンを組み合わせるしかなかった。
しかし、それらで表現できる範囲は限定的で、機能や見た目はデスクトップアプリケーションと比べ見劣りしていました。
そこでCSSやJSで高機能化。

しかし、HTMLには、メニューバー、タブ、ツールチップ、ツールバーなどデスクトップで当たり前のように使われるウィジェットを直接表現する言葉がない。
そのため、スクリーンリーダーでもどのような状態なのかが表現できない。

こうした状況に対処していくためにWAI-ARIA（ウェイアリア）がある。
ARIA = Accessible Rich Internet Applications でW3C仕様。

レベルAA ヒューマンリーダビリティ

支援技術なしでもユーザがアクセスできる

• サイトマップやサイト内検索のような複数のナビゲーションで情報到達可能
• 内容に対して適切な見出しを提供
• 入力エラーの修正方法を伝える
• 表示領域が狭くてもはみ出さず表示
• テキストやアイコン、画像のコントラスト比が基準値以上
• マウスオーバーやキーボードホーカスで表示されるものが不用意に消えない

支援技術を必要とする状況では、理解に時間がかかったり、操作に時間がかかったりするケースも多くある。
そうした時に試行回数が少なく情報にたどり着けば、ユーザーは目的を達成できる確率が上がる。
逆に言えば、分かりにくいものを提供してしまうと、ユーザーはサービスから離脱してい舞う可能性が高まる。

これはマシンリーダビリティの観点にもつながる。

レベルAAA
A, AAの強化版

• 操作の妨げになるものに対し、恥から採用しない、ユーザーが仕様を回避できる、ユーザー自身で調整を可能にするといったことを求める基準
• 読みやすさ、操作しやすさ、わかりやすさの担保を求める基準

コンテンツや機能によっては「例外なく達成」が難しかったり、操作の妨げになるものを排除すると機能自体が成立しなくなったりすることがあるため、通常はレベルAAAの適合を目標にはしません。

けれど、必ずしも達成が困難な基準ばかりでもないため、実現できそうであれば是非トライ。

なぜWebアプリケーションでアクセシビリティなのか

繰り返し利用することで生活や仕事が変化するから

共同利用のうえでは全員が使える必要があるから
複数人で利用するものを一部のユーザーが使えないと、コラボレーションは不完全。
全員が使えるものでなければ導入しづらい。

人事労務ソフトで言えば、入力した勤怠のチェックや給与明細の確認、年末調整の情報確認などを従業員が自力で行えない場合、その度に上長や労務担当者が個別に対処せねばなりません。

スクリーンリーダでUI操作を行う場合
コンテンツとそのセマンティクスを読み上げられる必要がある

セマンティクスには名前と役割がある。

名前があることで、対象を識別したり目的を理解できる
役割があることで、ユーザーは対象の振る舞い（ボタンであれば押せる等）を期待できます

ボタンをbuttonタグではなく、divなどで実装してしまうと、
div自体は特別な意味を持たない要素なので、セマンティクスが読み取れず、マシンリーダブルではなくなります。
マシンリーダブルにする為に、セマンティクス（名前と役割）を実装する必要があります。

例えばチェックボックスなどもspanタグなどでゼロから見た目を作成したくなりますが、
これだとマシンリーダブルでなくなる為、<input type="checkbox" />を用いてセマンティクスを実装する必要があります。

HTMLの語彙は、アプリケーション独特のセマンティクスが不足しています。例えばタブなどのインタラクションを含む役割や要素が展開されているかどうかという状態です。

これらのセマンティクスを補完するのがWAI-ARIA（ウェイ アリア）という仕様です。
主に役割を保管するWAI-ARIAロールと状態やプロパティを補完するWAI-ARIAステート及びプロパティがあります。

HTMLはデフォルトのユーザースタイルシートを持っているため、独自のスタイルでの上書きに手間がかかります。
そこでスタイルを作りやすいdiv要素のみを用いて、セマンティクスはWAIARIAで付与するという考えもあるでしょうが、それはおすすめできません。
なぜなら、WAI-ARIAはあくまで補完するもので、振る舞いまでは再現してくれないため。
例えば、divにrole="button"を付与してもキーボードで操作できるようにはなりません。

スクリーンリーダーなどの支援技術に対し、
アクセシビリティAPI（Windows：Microsofy Active Accessibility, Windows Automation API、MacOS：NSAccessibility）を介してOS上のアプリケーションとやりとりします。
OS上のアプリケーションはアプリケーションのウィンドウをルートノードとしたアクセシビリティオブジェクトモデルを生成します。
支援技術は、このアクセシビリティオブジェクトモデルを読み取り、操作することで、アプリケーションを操作します。

アクセシビリティオブジェクトモデルは、様々なプロパティを持ちます。
WAI-ARIAにはAOMのプロパティに対応した語彙がある。

Name

• aria-label
• aria-labelledby

Role

• role

Description

• aria-description

Expanded

• aria-expanded

アクセシビリティオブジェクトモデルは、
WAI-ARIA > CSS > HTMLという順で優先される。

<table style="display: contents" role="table"></table>

roleプロパティがtableになる。

Chrom dev toolのアクセシビリティの項目で確認可能。

アクセシブルでないUIを後からアクセシブルにするには、最初からアクセシブルに作るよりも高いコストが必要になる

フォーカスインジケーター
大きな理由がなければ、ブラウザのデフォルトのフォーカスインジケーターをそのまま表示すると良い。

フォーカス以外の状態（マウスオーバー、アクティブ、選択状態など）とスタイルを区別することも重要。
例えばフォーカスとマウスオーバーで同じスタイルが適用されていると、ユーザーがフォーカスを見失ってしまったり、マウスオーバーやフォーカスしている箇所を誤解してしまう可能性があります。

出し分けは:focus-visibleという擬似クラスで可能

マシンリーダブルであることで、様々な方法でアクセスできるようになる。

• 音声読む上げ
• VUI（Voice User Interface）
• 点字ディスプレイ
  などにも変換可能

マシンリーダブルに作ることは、まだこの世に生まれていない未知の技術との親和性も高くする
文章要約するAIに対してもマシンリーダブルであることが前提

Webアプリケーションを構築するのは、テキストのみではなく、
データを視覚表現する為のグラフやチャート、理解を促進するための画像、アイコン、
入力の為のUIなどもテキストではないコンテンツ。

これら非テキストコンテンツに対して、代替テキストを付与することで、アプリケーション全体をマシンリーダブルにし、アクセシブルにすることが出来る。

非テキストコンテンツへの対応方法

画像
マシンリーダブルの代表的な課題は、画像や図形に代替テキストが付与されていないこと。

• img要素のalt属性に代替テキストを記述
• svg要素であれば、title要素を追加もしくは、aria-label属性を追加

<img src="..." alt="◯◯">

<svg role="img">
  <title>◯◯</title>
  <path ...>
</svg>

<svg role="img" aria-label="◯◯">
  <path ...>
</svg>

名前のないUI
アイコンで作成されたボタンは、スクリーンリーダには単なるボタンであることしか伝わらず、
ユーザが操作できない状態になる
ボタンだけでなく、入力欄にもアクセシブルな名前が必要。
アクセシブルな名前がないと視覚で情報を得られないユーザーは何を入力すればよいのか分からない

• button, img or svgのみのボタンに、テキストを内包させる
• buttonタグに利用されているimgやsvgにalt属性やaria-labelを適用する
• input要素をlabelで囲いテキストを付与する

装飾の為の視覚表現がテキスト情報をもっている
コンテンツではなく、装飾のための表現がテキストデータを持っている場合、ユーザーにはノイズとなる可能性がある。プラス、マイナス記号など
機械からは無視できるようになっていることが望ましい

• 背景を用いて画像を装飾する
• alt属性を空にする
• aria-hidde＝"true"で隠す

自分メモ

画像を利用する場合、imgを利用するかbackground-imageを利用する問題について、
アクセシブル観点だと、結構明確な答えが出た気がする。

• imgタグを利用する場合、クローラーやスクリーンリーダーなどのマシンから画像要素として認識される

  • imgであれば、alt属性を利用し、テキストを情報で補完できる
  • svgであれば、title要素かaria-label属性を利用し、テキストを情報で補完できる
  • ただし、装飾としてのみ利用されている画像やアイコンの場合、アクセシブル観点では削除しないと行けないが、その分の余計な対応が必要
    • alt属性を空とする
    • aria-hidden属性をtrueとする

• background-imageを利用する場合、ローラーやスクリーンリーダーなどのマシンから画像要素として認識されない

  • imgやsvgを利用した場合と真逆で、画像として認識されない
  • 画像として、マシンに認識させる場合、background-imageは不向き
  • 逆に背景やUIに対して画像を利用する場合、マシンには画像を認識させなくても良い為、background-imageが向いている

コンテンツとコンテンツの間の関係性=構造も情報で、これにアクセスできないといけない
構造の例：表、見出し、キャプション、セルなど

構造が持つ情報にアクセスできることは情報を正しく知覚、理解することに必要不可欠

↓我々はこういった構造も意味のある情報として捉える
列の見出しセルが、グレー背景に太字
行ごとに水平方向の線がある
見出しは他のテキストよりも大きく太字

これらの構造がマシンリーダブルでない場合、視覚で情報を得られないユーザーは情報の保つ意味を正しく理解できない。

こういった構造も正しくHTMLを用いた記述でなければ、マシンリーダブルでなくなり、アクセシブルでなくなる。

反対に、見出しではないのに、視覚的には見出しのような大きな文字や装飾を持った文を見出し要素でマークアップしてもいけません。

情報の関係性で頻出するのは、key-value形式
ある情報（Value）に対して、メタな情報（Key）が与えられる

下記の様な構造を組むと、スクリーンリーダーは基本的にHTMLの記述順に読み上げるので、「姓　名　テキストを編集　テキストを編集」となり、どちらの入力欄に姓名を入力するかの確信が持てなくなる。

<p>
  <span>姓</span>
  <span>名</span>
</p>
<p>
  <input />
  <input />
</p>

実際のデータ構造をマークアプ腕示せていない場合、データ構造を機会が読み取れず、アクセシブルではなくなる。

HTMLには、table要素の様な視覚表現を伴う要素が多くあり、
これらはあくまで基本的にはセマンティクスを表現する為。
間違っても視覚的表現の為だけにHTML要素を使ってしまうと、セマンティクスを利用しているユーザに間違った情報（構造）が伝わってしまう。

フォームの改善

ラベルと説明について

• プレースホルダーをラベル代わりに使わない
• ラベルと説明がどのフォームコントロール・グループに関係しているか分かりやすく配置する
• 必須入力であることをテキストで説明する（*のみで済ますなどはだめ、記号は使わない）

inputタグに対してtitle属性、alia-label属性でも対応可能
fieldsetタグでグループ化
legendタグでグループ内の説明
legendはdivで囲わない

よくある課題

• 1つのフォームコントロールに多くの入力を求めすぎる
• 1つの入力値のみのフォームコントロールに分割する（フォームではない）
  • 姓名を分ける
  • メールアドレスの@以降の分割
    など