はじめに

2016/05/16に「第一回 社内エンジニア勉強会」が開催されました ヾ(。・∀・)ノ
システム、フロント、マークアップエンジニアが一同に揃って執り行う盛大な勉強会!

そんな勉強会で、アクセシビリティについてお話する機会をいただくことができました!!
5分の LT … 案外短いもので、時間足らずだったのでとても悔しい(´ω`*)…
口頭でだーーーーっとお話したものも含めて、こちらにまとめたいと思います。

目次

アクセシビリティとは?

アクセシビリティとは、使いやすさ、アクセスのしやすさ、利用しやすさのことです。

参考:
アクセシビリティ – Wikipedia
https://ja.wikipedia.org/wiki/アクセシビリティ

Web におけるアクセシビリティは、高齢者や障害者、さまざまな情報端末やソフトウェアにおいて、特殊な技術に依存せず、情報を取得、あるいは発信できる柔軟性に優れていることを意味します。

高齢者や障害者においては、言語障害など、視力、聴力、発声といったコミュニケーション上の障害や、運動障害による情報格差を軽減できることで、これまでになかったさまざまなコミュニケーションが可能になります。

情報端末やソフトウェアにおいては、Google などのクローラに効率的に解析させたり、ソフトウェアが情報を判別するのに役に立ちます。

障害者差別解消法

参考:
障害を理由とする差別の解消の推進 – 内閣府
http://www8.cao.go.jp/shougai/suishin/sabekai.html

内閣府の方で先月の4月1日に、障害者差別解消法が執行された影響もあって、アクセシビリティに対する関心がますます高まってきています。

障害者差別解消法とはなんぞやといいますと、障害を理由にしたサービス提供の拒否/制限を禁ずる法律です。
正式名称は、「障害を理由とする差別の解消の促進に関する法律」です。

この法律は、アクセシビリティを、社会的障壁を取り除くための「環境整備」として位置付けています。
アクセシビリティに違反しても直接的に罰則は受けません。
あくまでも「努力義務」として、行政機関や事業者による自主的な取り組みを促しています。

多くのWebサイトは非常に視覚的で、ラベルのないグラフやラベルのないボタンがあります。これこそ World Wide Web Consortium(W3C)がインターネットのグローバルな標準規格を設定した理由です。私たちはすべてのインターネットユーザーやサイトの持ち主に、標準規格に則ったサイトを作って欲しいと願っています。そうすれば、視覚障害者も同じ土俵に立つことができるのです。
― Ron McCallum

全部が全部、案件でアクセシビリティに対応できるかというとそうではなく…
はっきり言って、予算や工数の兼ね合いで厳しいというのが現実です。
しかしながら、意識しながらやるってことは大切だよね~というお話です。

標準規格

WCAG2.0(日本工業規格「JIS X 8341-3:2016」)
WAI-ARIA

参考:
Web Content Accessibility Guidelines (WCAG) 2.0
http://waic.jp/docs/WCAG20/Overview.html
Accessible Rich Internet Applications (WAI-ARIA) 1.1 日本語訳
http://momdo.github.io/wai-aria-1.1/

アクセシビリティに関する標準規格は、この2種類があります。
WCAG2.0 を日本工業規格としたものが「JIS X 8341-3:2016」です。
どちらもアクセシビリティに関するリソースですが、いくつかはっきりとした違いがあります。

2つを兄弟で例えると…
同じ環境で育って、基本的な価値観は同じですが、性格はそれぞれ異なる感じです。

WCAG2.0 は、家が火事にならないよう守る用心深いマイホーム主義者であるのに対して

WAI-ARIA は、もっと積極的でアクセシビリティを新しい領域に築こうという志を持っています。
今回は、この WAI-ARIA について話をしていきます。

WAI-ARIA = WAI + ARIA

WAI-ARIA とは、WAI と ARIA を組み合わせたものです。

WAI は 「Web Accessibility Initiative」 の略で、「W3C 内でアクセシビリティ関連のガイドライン策定等を担当する組織」のことです。

ARIA は 「Accessible Rich Internet Applications」 の略で、「リッチなインターネットアプリケーションをアクセシブルにするための仕様」 ということです。

対応してみる

では… アクセシビリティに対応するとは具体的にどうすればいいのか、フォームを例にご紹介します!!

元々 W3C の使命は Web をアクセシブルにすることであったため、Web にはたくさんのアクセシビリティの機能が組み込まれています。

デモページ:
Practical ARIA Examples
http://heydonworks.com/practical_aria_examples/#input-tooltip

for 属性と id 属性に注目してください。
それぞれ、入力項目とラベルの関係性を表しています。

入力項目がフォーカスされた時に、ラベルが読み上げられるようにできます。
これによって、ユーザーは自分が入力しようとしている項目を知ることができます。

入力項目とラベルを関連付けることで選択できる領域が広がって、ユーザーが入力項目を選択しやすくなります。

大抵のスクリーンリーダーは、ラベルテキストの前に <legend> 要素のテキストを読み上げます。
ですので、2つの情報を組み合わせて読み上げられた時に意味が通るように注意しないといけません。

あとは、ヒントとなる要素をマークアップをして、入力項目と適切に関連付ければ完成です。

先ほどのコードに aria-describedby 属性と、それに対応する要素が加わりました。

aria-describedby 属性は、id 属性を使って要素を関連付けることができます。
今回の例では、<input> 要素と、そのヒントである <div> 要素を関連付けています。
支援技術にブラウザを通じて、入力項目が説明されているというのを伝えています。

role=”tooltip” は、支援技術にブラウザを通じて、ヒントをツールチップとして扱うように伝えています。

ユーザー名もパスワードも、どちらの場合もヒントの要素は <input> 要素に隣接している要素となっているので、CSS の隣接セレクタを使って、入力項目がフォーカスを受け取った時に簡単に表示したり隠したりできます。

focus 類似クラスを使うと、キーボードのユーザーが Tab キーを使って、入力項目にフォーカスを合わせたときに、ヒントが表示されます。

まとめると…

ユーザー名の <input> にフォーカスを移すと、最初に <legend> が読み上げられます。

続いて 、<input> に関連付けられたラベルが読み上げられて aria-describedby の値によって
<input>id 属性に関連付けされたヒントの要素が読み上げられます。

HTML、CSS、ちょっとした WAI-ARIA だけで、こういったアクセシブルなフォームを作ることができます!

書籍紹介

続いて、Web アクセシビリティに関する書籍の紹介をしたいと思います。

コーディングWebアクセシビリティ
WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション
http://www.amazon.co.jp/dp/4862462669/

こちらは、初心者でもわかるように解説している本です。
コード例も多いので、手を動かしながら読めるタイプの本です。
文字も大きくイラストの解説も多いのでとっつきやすいと思います。

そして、まとめて読んでおきたいのが…

デザイニングWebアクセシビリティ
アクセシブルな設計やコンテンツ制作のアプローチ
(一般財団法人 国際ユニヴァーサルデザイン協議会主催「IAUD アウォード2015 銀賞・ウェブデザイン部門」受賞)
http://www.amazon.co.jp/dp/4862462650/

先ほどのと同じシリーズですね。
書籍の評価は、こちらのほうが高いようです。
なんらかの賞もいただいているようです。

これらのシリーズの Facebook ページが存在しているようです。
いいねをして更新を見張っておくと、幸せになれるかもしれません。

Facebook:
https://www.facebook.com/a11ybooks

参考サイト

最後に、今回紹介した参考ページも含めて、まとめてどーんとのっけます。
興味をもたれた方は、是非ご覧になってみてください(*´Д`)!!

あわせて読みたい記事