アクセシビリティ、ウェブアクセシビリティとは

概要

一般にアクセシビリティとは、アクセスのしやすさを意味します。転じて、製品やサービスの利用しやすさという意味でも使われます。

似た意味をもつ言葉にユーザビリティがありますが、アクセシビリティはユーザビリティより幅広い利用状況、多様な利用者を前提とします。

ウェブのアクセシビリティを言い表す言葉がウェブアクセシビリティです。ウェブコンテンツ、より具体的にはウェブページにある情報や機能の利用しやすさを意味します。

さまざまな利用者が、さまざまなデバイスを使い、さまざまな状況でウェブを使うようになった今、あらゆるウェブコンテンツにとって、ウェブアクセシビリティは必要不可欠な品質と言えます。

以上、https://waic.jp/knowledge/accessibility/ よりコピペ

アクセシビリティとは直訳するとアクセスのしやすさ、サービスの利用しやすさのことを言います。

視覚障害者や聴覚障害者でも使いやすいように、という文脈で使われることが多いですが、あらゆるひと（この言い方を嫌う人もいるかも知れませんが健常者ももちろん含め）が使いやすいことを言います。バリアフリーとの違いはそこですね。バリアフリーは「バリア」があってそれを取り除くの意ですが、アクセシビリティはただ単に「access＋-ible＋-ty」＝「アクセスのしやすさ」という意味の単語です。

WCAG

このウェブアクセシビリティについて基準を定めているところがあります。ウェブサイトに関する多くの仕様を決めているWorld Wide Web Consortium略してW3Cより、Web Content Accessibility Guidelines 2.0略してWCAG 2.0というものが発行されています。対応度に応じてレベルA、AA、AAAは存在し、Aは最低限、AAを目指し、AAAは余裕があればやるぐらいのレベルとされています。

というわけで、具体的にウェブアクセシビリティを大事にするというのはどういうことなのかまとめていきます。
以下はW3C勧告のWCAG(Web Content Accessibility Guidelines) 2.0（日本語訳）の中から

当たり前過ぎて誰でも守るようなもの
AAAクラスと、一部AAクラス
その他一部の内容

を除いたものを軽くまとめてあります。()内に書かれた番号は、対応するWCAGの章段番号です。

WAI-ARIAについて

WAI-ARIAとは、ウェブアクセシビリティを高めるために定められた属性郡です。詳しくはMDNのWAI-ARIAのページへどうぞ。
role属性とaria-***属性はこのWAI-ARIAで定められたものです。説明はMDNに任せ、この記事では名前に触れるにとどめます。

ウェブアクセシビリティ

非テキストコンテンツ

非テキストコンテンツには原則全てテキストによる代替が必要です。(1.1.1)

画像

img要素にはaltという属性があります。ここには、画像の代わりとして使われるテキストを指定します。
例えば、第70回駒場祭のテーマページは、文字が全て画像になっています。そこで、alt属性には書かれている文章を指定します。¹

<img alt="のぞきこむと…第70回駒場祭　七変華" />

他にも、写真を掲載した場合は「〜の様子」などとalt属性を設定すると良いでしょう（一部例外あり、下のよくありそうな間違い参照）。「〜様子」などの名詞ではなく、文章を設定するのも有効な場合もあるでしょう。

alt属性はその名の通り「alternate＝代用」となるものです。その画像をその文字列に置き換えて意味が通るかどうかよく確認してください。

よくありそうな間違いを下に記載します。

駒場祭のロゴのalt属性に「第70回駒場祭ロゴ」とする。
- alternateとは言えません。ロゴだけならばalt=""にすべきです。ただし、ロゴを紹介している文脈では適切な場合もあります。
三角形に「三角形」とする。
- やはりalternateとは言えません。次へ移動するボタンなら「次へ移動」など、ただのデザインならalt=""を指定するようにしましょう。
画像の上や下などに画像の説明がすでにテキストにかかれているにも関わらずalt属性に似たような説明を書く。
- これもalternateとは言えません。テキストのみで画像を説明できている場合はaltは空白を指定しましょう。ただし、aria-labelledby属性を代わりに付けましょう

ちなみにalt未指定とalt=""を指定するのでは意味が異なります。音声読み上げソフトでは、alt=""だと何も読み上げませんが、alt未指定だとファイル名など余計なことを読み上げます。必ずalt=""を指定しましょう。実際にVoiceOverなどでデバッグするのが良いでしょう。

フォーム

フォーム部品を扱う場合は、それが何の入力フォームなのかを「構造的に」はっきり示さないといけません。
構造的にとは

label要素を使いフォーム部品とテキストを結びつける。
placeholderに説明や入力例を示す。
aria-label属性に説明を入れる

等が入ります。(3.3.2)

動画と音声

動画と音声もテキストの代替があることが望まれます(1.1.1、1.3)が、まあ出来たらでいいでしょう。YouTubeをつかえばそんな機能が使えた気がします。

構造化(1.3.1)

構造化要素

p、h1〜h6、ul、li、article、abbr等、「div(span)+文章上の意味」を持つ要素を積極的に使いましょう。

buttonなどを使ってタブを作ったり、やむを得ずdivタグでボタンを作ったりする場合はrole属性を使いましょう。

構造化マークアップ

schema.orgというやつです。検索されるときとかに見やすくなるかもしれません
。

リンクテキストについて

リンクテキストは、そのリンクだけで内容がわかるようにしましょう。(2.4.4)

【悪い例】　会場へのアクセスはこちら

【良い例】　会場へのアクセスは交通アクセスページへ

色

文字と背景の間にコントラスト比がある

WCAGではコントラスト比は最低限4.5:1あるべきだとし、7:1あることを推奨しています。(1.4.3、1.4.6)

色が唯一の情報識別手段になっていない

色のみで情報の区別をすることはせず、記号の形を変えたり、文字の場合は太字にすることで強調したりするようにしましょう。(1.4.1)

ところで、この世にはCUDとか言うものがありますが、あれ3型2色覚とか1色覚のことはあまり考えてないので、まあCUDを守るのも良いですが、色だけで区別しないことに重点を置くべきでしょう。結局色覚多様性の中でもマイノリティがカバー出来ないので、それに固執するのはあまり好きではありません。

キーボード操作

ウェブサイトで行えることは全てキーボードから行えるようにする(2.1)

まずそもそもa要素のリンクやフォーム部品はTabキーで選択、移動できることを知っておきましょう。
というわけで基本はキーボード操作で全部できるようになっているはずです。

ボタンをdivタグなどで実装するとフォーカス出来なくなってしまいます。基本aタグやbuttonタグなど適した要素で作りましょう。
どうしてもという場合はtabindex="0"という属性を使うとフォーカスできるようになります。が、別途実装が必要になったりするのでやはり控えたほうがいいでしょう。

フォーカス順をちゃんとする(2.4.3)

CSSを使うなどしてソースコードに出てくる順番と視覚的に出てくる順番が違うようにならないようにしましょう。

どうしてもという場合はtabindexという属性に適切な値を入れると順番を制御できます。

その他

フォーカスで大きく表示が切り替わる実装をしない(3.2.1)

動作はクリックなどで起きるようにしましょう。マウスカーソルを乗せるなどで動く実装はあまり良くはありません。

本当はそもそも画像にしないで文字で配置したほうがいいです。 ↩