エッセンスで学ぶwebアクセシビリティ

## この記事について
こんにちは！この記事では、私が現在勉強中のwebアクセシビリティについてまとめていきます。

調べてみると、本格的にwebアクセシビリティへの配慮が行き届いていることに自信を持つには、w3c勧告のWeb Content Accessibility Guidelines2.1(WCAG2.1)で定められているAAA、AA、Aというランクを目指して指定されたチェックリストを満たすという方法があるんだな〜、WCAG2.1自体を読んで実施するのは疲れるからより噛み砕かれたfreeeさんのチェックリストを使ったりするんだな〜、ということが分かったりします。

しかし、freeeさんのチェックリストでも140ある項目を案件ごとに確認し直すのは大変だと思います。この記事では、そういった本気のアクセシビリティ施策をしないまでも、普段から気をつけられるアクセシビリティをご紹介します。

## この記事が目指すゴール
この記事が目指すのは、WCAG2.1のチェック項目を覚えていなくても普段からアクセシビリティを考慮したフロントエンド実装ができるよう、webアクセシビリティに必要なエッセンスを感じ取っていただくことです。そのため、WCAG2.1で定められているwebアクセシビリティの四大原則をみていきましょう。四大原則と、よくあるアンチパターンとの対応を確認することで四大原則のイメージを立体的にできればと思っています。

アンチパターンを覚えつつ、それ以外でも原則に従っているかどうか、脳裏で考えながら実装を行っていただければと思います。また、気分でWCAG 2.1 達成方法集の該当する失敗例へのリンクも載せちゃいました。併せて御覧ください。

## WCAG2.1の四大原則
まず、私は次のように解釈しています。
- 知覚可能: webページから情報を得るために使う五感を選べる・コンテンツが意図せず隠れたりしないようにする
- 操作可能: webページを操作する手段(マウス、キーボード、スマホなど)や状況(身体的特徴やなんか調子が悪いとか)によって不公平が生じないようにする
- 理解可能: ユーザーにとってあらゆる挙動が予測できるようにする・予測の難しい挙動(エラーなど)は原因を理解できるように説明する
- 堅牢: 支援技術(読み上げソフトなど)を介してユーザーが不利益なくコンテンツを利用できるようにする

改めて見ると当たり前なことが書いてある気もしてきませんか？
かなりガッツリ引用すると、実際の定義の日本語訳は以下の通りです。気が向いたら読んでみて下さい。

*ウェブを利用したい誰もが、コンテンツに求めるのは次のことである:*
*知覚可能 － 情報及びユーザインタフェースコンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
これは、利用者が提示されている情報を知覚できなければならないことを意味する (利用者の感覚すべてに対して知覚できないものであってはならない)。*

*操作可能 － ユーザインタフェースコンポーネント及びナビゲーションは操作可能でなければならない。*
*これは、利用者がインタフェースを操作できなければならないことを意味する (インタフェースが、利用者の実行できないインタラクションを要求してはならない)。*

*理解可能 － 情報及びユーザインタフェースの操作は理解可能でなければならない。*
*これは、利用者がユーザインタフェースの操作と情報とを理解できなければならないことを意味する (コンテンツ又は操作が、理解できないものであってはならない)。*

*堅牢 (robust) - コンテンツは、支援技術を含む様々なユーザエージェントが確実に解釈できるように十分に堅牢でなければならない。*
*これは、利用者が技術の進歩に応じてコンテンツにアクセスできなければならないことを意味する (技術やユーザエージェントの進化していったとしても、コンテンツはアクセシブルなままであるべきである)。*
※[WCAG2.1解説書イントロダクション](https://waic.jp/docs/WCAG21/Understanding/intro#understanding-the-four-principles-of-accessibility)より抜粋。原文から和訳されたもので、翻訳上の誤りを含む可能性があるとのことです。

### Perceivable (知覚可能)
*情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。*

#### よくあるアンチパターン
##### alt属性がない
【問題】
伝えたい文字情報は極力画像にするべきではありません。画像は選択できる五感が制限されるため視覚に頼れず、また画像の読み込みに失敗してもPerceivableでなくなります。
【解決】
仕方なく文字を含む画像を使う場合は、alt属性を指定しましょう。background-imageには代替テキストをあてられないのでimgタグを使うようにしましょう。

[WCAG 2.1 達成方法集による失敗例はこちら](https://waic.jp/docs/WCAG21/Techniques/failures/F3)

##### 視覚に頼った方法でコンテンツを指定する
【問題】
色の感じ方が違ったり、形や位置が認識できない場合にPerceivableでなくなるものの指し方です。
次に示す画像について考えます。
![今回問題にしている画像です。3つのボタンが並んでいて左から「"Qiitaの記事へ"という黒字にQiitaのブランドカラーの背景の角丸のボタン」、「twitterの水色の公式アイコン」、「facebookの公式アイコン」です](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2530676/540e3238-a947-3ef3-43ee-659bf0888d7a.png)
例えば、「私のQiitaの記事はQiita色のボタンから、twitterアカウントへは鳥の形をしたアイコンから、facebookアカウントへはその右のアイコンから」といったような誘導ではそれぞれを判別できない場合があります。それぞれ、色、形、位置に頼った指定の仕方をしているためです。

【解決】
上の例なら、twitterとfacebookのアイコンにalt属性などでtwitterアイコンとfacebookアイコンであることを示した上で、それぞれ「"Qiitaの記事へ"と書かれたボタン」、「twitterアイコン」、「facebookアイコン」と示すことで視覚に頼らない指定ができます。
[WCAG 2.1 達成方法集による形状や位置についての失敗例はこちら](https://waic.jp/docs/WCAG21/Techniques/failures/F14)
[WCAG 2.1 達成方法集による色についての失敗例はこちら](https://waic.jp/docs/WCAG21/Techniques/failures/F13)

###### 文字と背景のコントラスト比が低く見にくい
【問題】
見えにくい文字は視覚に頼るユーザーにとってPerceivableではありません。
【解決】
WCAG2.1では大きい文字では3:1、普通のテキストでは4.5:1のコントラスト比を求めています。実装の際は、開発者ツールのインスペクター機能を使って簡単に調べられるので、このチェックが通っていることを確認するようにしましょう。
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2530676/196a00f4-8234-51fe-9c01-8499aee45f50.png)

[WCAG 2.1 達成方法集による失敗例はこちら](https://waic.jp/docs/WCAG21/Techniques/failures/F83)

##### まとめ
Perceivableはひとまず、出力として視覚と聴覚の2つの方法が確保されていること、ただ情報を与えるだけでなく十分な視認性や可聴性を確保すること、そして、入力としてキーボードとマウス、スマホによる操作に不自由がないことを担保するのが第一歩のような気がしました。実際、この説明だけで今回ご紹介しなかったPerceivableに関する他の項目をある程度説明できます。興味があったら是非、[WCAG2.1](https://waic.jp/docs/WCAG21/#perceivable)を見て対応関係を確認してみて下さい。

## さいごに
ここまで読んでくださりありがとうございました。四大原則を紹介しきれなかったのですが、文章ばかりの割に長くなってしまったので、 ~~書き疲れ~~ 読み疲れると思い一旦ここで区切ります。続編をお待ち下さい。抽象的な内容が主なので腑に落ちないところもあるかもしれませんが、四大原則の単語だけでも覚えて意識していただければと思います！一緒に、コツコツやっていきましょう