(CV:三上枝織)
はい、『ゆるゆり』は全く関係ないね。
『ARIA』も『緋弾のアリア』も関係ないね。ごめんね。
しかし、WAI(わぁい)といい、ARIA(アリア)といい、オタク心をくすぐるネーミングだぜ……
という冗談はさておき。
WAI-ARIAとは、Web Accessibility Initiative - Accessible Rich Internet Applications の略で(長い……)、Webにおけるアクセシビリティの向上を目的に制定された規格だ。
Web開発者にとっても聞き慣れない言葉かもしれない。
そんなの見たこともないって人も多いだろう。
何しろ、はっきりいって、これを使わなくても一般人は全く困らない。
俺も、たぶんあなたも。
しかし、俺たちは五体満足に生まれたことに感謝しつつも、「アクセシビリティ」という概念に思いを馳せるってのもたまにはいいかもよ?
※ WAI-ARIAの仕様や書き方に関する詳しい解説は、今回はしないよ。
アクセシビリティって?
アクセシビリティ(accessibility)とは、日本語でいえば「アクセス可能性」……横文字入ってるし。
つまり「どんな人、端末、環境でもアクセスしやすい(アクセシブル)こと」を意味する。
例えば、ブラウザ Internet Explorer でしかまともに閲覧できないWebサイトは、アクセシビリティの欠片もない。
まあ、とりあえずWeb標準に従っておけば、ほぼすべての端末、ブラウザから閲覧できるわけだけど、特別な配慮が必要な場合もある。
例えば、目が見えない人。
え、目が見えないのにWebサイトを読む人がいるの? と思ったあなた、「スクリーンリーダー」とか「点字ディスプレイ」でググってきなさい。
視覚障害者の9割以上がWebサイトを利用しているとのデータもある。
HTMLのいいところは、テキストベースであり文書が構造化されているため、単純な機械(ソフトウェア)でもその内容を理解できる点だ。
つまり、人間だけでなくスクリーンリーダー(読み上げソフト)にも効果的に読み上げさせることができる。
視覚障害者にとってのスクリーンリーダーのような、アクセシビリティを支援するソフト、装置などを「支援技術」と呼ぶ。
アクセシビリティは視覚障害者のためだけではない。
例えば、体が不自由でマウスが使えない人のために、キーボードや各種コントローラーだけでサイトを利用可能にすることもアクセシビリティの向上に寄与する。
マシン・リーダブル
HTMLがいかに構造化ドキュメントのための言語といえども、スクリーンリーダーのような機械が本当に内容や意味を正確に理解できるかといえば、それは困難だ。
例えば、コメントフォームなどの部品に適切にラベルなどをつけてマークアップすれば、機械でもそれがコメントを送信するためのフォームであることを理解できる。
しかし、一般に「見ればわかる」ような実装でも、機械から「見て」わかるとは限らない(機械はレンダリングされた結果の画像としてのWebページを「見る」わけではない)。
マシン・リーダブルとは「機械が理解できる」という意味だが、ハンデのある人にとっては機械が理解しやすいことと自分が利用しやすいことはイコールに近くなる。
なぜなら、ハンデのある人が利用するのは機械を用いた支援技術だからだ。
よって、アクセシビリティを追求することはマシン・リーダブルを追求することに等しい、と言っても過言ではない。
現在のHTMLはマシン・リーダブルをより推し進め、フォーマットとしてアクセシビリティの向上に努めているので、アクセシブルなサイトを作るためにはまずWeb標準を遵守し、論理的で構造的なマークアップを心掛けるのが第一となる。
ところで、Webページにおいて機械の代表格であるスクリーンリーダーがどこまで理解でき、どこから理解できなくなるかを、簡単な例を挙げて説明する。
- HTMLで完結するような要素(文書構造や、意味付けのタグが用意された要素)は、スクリーンリーダーにもほぼ完全に理解できる。
<h1>
は見出し、<nav>
はナビゲーション、<input type="text">
は単一行テキスト入力ボックス、など。- 文書の構造がわかれば、操作によって節見出しに移動、リンクを順に読み上げ、などが可能。スクリーンリーダーは単にページを片っ端から読み上げるだけではない。
- HTMLの画像
<img>
タグのalt
属性により設定された代替テキストを、スクリーンリーダーは読み上げる。- 読み上げる必要のない画像には、空の
alt
属性を指定するべき。
- 読み上げる必要のない画像には、空の
- HTMLだけでなく、CSSやJavaScriptもある程度解釈する、というより、スクリーンリーダーは通常のブラウザを使用して解釈した文書を読み上げる。
- CSSの
display: none;
やvisibility: hidden;
により非表示にされた要素を、スクリーンリーダーは読み上げない。 - CSSの擬似要素
::before
や::after
のcontent
プロパティにより生成されたテキストを、スクリーンリーダーは読み上げる。 - JavaScriptによりクリック可能とされた要素を、スクリーンリーダーはクリック可能と認識する。ただし、それがどのような効果をもたらすかを、スクリーンリーダーは事前に(多くの場合、事後にも)認識できない。
- 「クリックできるよ、でもどうなるかはわからないよ」ということ。
- CSSにより単に不可視とされただけの要素を、スクリーンリーダーは読み上げてしまう。すべてのユーザーから隠すことを意図していた場合、意図しない動作となる。
- 画面外に描画させたもの。
- 文字の色を透明または背景色と同じにしたもの。
- Webフォントを使ったアイコンなど、読み上げる必要がない要素を、スクリーンリーダーは読み上げようとする。
- リンクのタイトルや略語の元になった言葉などを表すのに使われる
title
属性を設定しても、多くのスクリーンリーダーはこれを利用しない。
主に、不可視の要素の扱いと、JavaScriptを利用したアクションに関する問題があることがわかる。
それらは「見ればわかる」ことなのかもしれないが、上述の通り、マシン・リーダブルでなければアクセシブルでないのだ。
これらの問題を解決するために定められたのが、Webの標準規格のひとつである「WAI-ARIA」だ。
わぁい 記述例
WAI-ARIAも調べてみると奥が深く、ここではすべてを紹介できないが、よく使いそうな記述例をいくつか紹介する。
要素が非表示であることを示す
要素の現在の状態を表す属性はステート属性と呼ばれ、状態が変われば属性値も変更しなければならない。
要素が非表示であることを示すには、 aria-hidden
属性を使う。これは true
で非表示を表し、既定値は false
(表示)である。
<div id="box1" aria-hidden="true">非表示の要素</div>
また、要素が展開・折りたたみされる場合、 aria-expanded
属性を使う。 true
で展開、 false
で折りたたみ状態を表し、既定値は undefined
(展開・折りたたみされない)である。
なお、ステート属性の属性値を変更するにはJavaScriptなどを使う。
要素によりコントロールする対象を示す
要素を識別したり定義したりする属性はプロパティ属性と呼ばれる。
たとえばある要素をクリックしたときに別の要素を操作する場合、 aria-controls
属性を使い、操作対象の id
属性値を指定する。
<input id="toggle-button" type="button" value="クリックで開閉" aria-controls="toggle-box" />
<div id="toggle-box" aria-expanded="false">折りたたまれた要素</div>
要素の役割を示す
要素に役割がある場合、それを示すためにロール属性 role
を使用する。
従来、HTMLにおける文書構造を定義するのに、 <div>
要素はもともと意味をもたないため、開発者自身がわかりやすいように id
や class
属性などによって要素に名前を付けていたが、これだけでは機械から見て構造を理解することができなかった。
以下は role
属性を使用したシンプルなWebページのマークアップの一例である。
<body>
<div id="header" role="banner">
<div id="header-img" role="img">トップ画像など</div>
<div id="global-nav" role="navigation">グローバルナビゲーション</div>
<form id="search" role="search">検索フォーム</form>
</div>
<div id="main" role="main">
<div class="article" role="article">
<h1 class="title" role="heading">記事見出し</h1>
<div class="section" role="section">セクション1</div>
<div class="section" role="section">セクション2</div>
……
</div>
<div class="article" role="article">
……
</div>
</div>
<div id="sidebar" role="complementary">サイドバー</div>
<div id="footer" role="contentinfo">フッター</div>
</body>
HTML5においては、文書構造を示す要素がいくつか定義されているので、一部はWAI-ARIAのロール属性と重複するが、以下のように併用することも可能である。
<body>
<header role="banner">
<div id="header-img" role="img">トップ画像など</div>
<nav id="global-nav" role="navigation">グローバルナビゲーション</nav>
<form id="search" role="search">検索フォーム</form>
</header>
<main role="main">
<article role="article">
<h1 class="title" role="heading">記事見出し</h1>
<section role="section">セクション1</section>
<section role="section">セクション2</section>
……
</article>
<article role="article">
……
</article>
</main>
<aside role="complementary">サイドバー</aside>
<footer role="contentinfo">フッター</footer>
</body>
緑字はHTML5で新たに定義された要素。
なお role 属性の属性値は勝手に付けていいものではなく、WAI-ARIAによって定められている通りに使用する。
フォーム部品の使い方を示す
フォーム部品の現在の状態を示して、使いやすくすることができる。
<input type="text" aria-required="true" /><!-- 入力必須(プロパティ) -->
<input type="text" aria-readonly="true" /><!-- 編集不可(プロパティ) -->
<input type="text" aria-disabled="true" /><!-- 無効化(ステート) -->
<textarea aria-invalid="true"></textarea><!-- 不正な入力値(ステート) -->
スクリーンリーダーへの配慮
スクリーンリーダーの利用者がWebページをより利用しやすくするためには、HTMLやWAI-ARIAなどのWeb標準だけでなく、様々な配慮が求められるだろう。
HTMLを解釈して読み上げるというスクリーンリーダーの特性を利用したその他の配慮を少し紹介する。
文章は順番に
スクリーンリーダーは、HTMLで記述された順に文章を読み上げる。
いくら見た目が順番通りになっていても、スクリーンリーダーは読み上げる順番までは理解できない。
マシン・リーダブルのためにも、文章は構造的に、順序よく記述すべきだ。
スクリーンリーダーだけに読ませたい文章
目で見なければ使い方がわからない部分を説明するために、スクリーンリーダー向けの説明文を挿入するのは良い方法だ。
しかし、通常の利用者からは隠したい場合、例えば display: none;
とすると、上述の通りスクリーンリーダーも読み上げなくなる。
この場合、以下のようなCSSにより単に要素を不可視とする方法で問題を解決できる。(一例)
.screen-reader-only {
display: block;
position: absolute;
top: 0px;
left: 0px;
width: 1px;
height: 1px;
opacity: 0;
overflow: hidden;
}
このCSSの記述を使えば、 <span class="screen-reader-only">隠したい文章</span>
とすることで、通常の利用者からは視覚的に隠し、スクリーンリーダーには読み上げさせることができる。
width
と height
はゼロにすれば……と思うかもしれないが、大きさがゼロの要素をスクリーンリーダーは読み飛ばすことがあるらしい。
text-indent: -9999px;
で画面外に飛ばす方法もあるが、昔のiOS Safariでパフォーマンスの問題があるらしいので推奨しない。
スクリーンリーダーだけから隠したい文章
HTML上で aria-hidden="true"
とするとスクリーンリーダーは読み飛ばすようになるが、これは本来の使い方ではない。
しかしWAI-ARIAの仕様書によると、「冗長な要素などを支援技術から隠すことがアクセシビリティの向上に繋がる場合に限り、注意深く」この方法を用いることを認めている。
この場合、支援技術に対して代替となる要素を利用可能としなければならない、とされている。
また、この方法を用いる場合、「目は見えるが肢体が不自由なためにマウス操作のかわりにスクリーンリーダーを使用している人」など、あらゆる状況を想定すること、とされている。
したがって、この方法で隠すのは、リンクやフォームなどを含まず、隠しても全く問題にならないような要素に限るのが無難だろう。
音声ブラウザって
視覚障害者がWebブラウジングに使うのは「音声ブラウザ」というイメージが根強く存在する。
俺も最近までそう思っていたのだが、実は音声ブラウザなるソフトは現在ではほとんど存在しない。
メーラーやオフィスソフトを含む画面上のあらゆる文字を読み上げることができるスクリーンリーダーに対し、Webページしか読み上げることができない音声ブラウザは使いにくい、ということらしい。
また、スクリーンリーダーを使用してWebブラウジングする人は、CSSによる見た目の装飾が必要ないから、CSSを一切解釈しない「テキストブラウザ」を使用する、というのも誤解だ。
上述の通り、スクリーンリーダーの使用者は、健常者と同じ通常のブラウザを使用していて、ブラウザによるWebページの解釈を利用している。
スクリーンリーダーなどの支援技術についてより深く知るには、実際にスクリーンリーダーを使ってみるのが一番だ。
「NVDA」など、無料のスクリーンリーダーも存在する。
自分のサイトや、よく行くサイトをスクリーンリーダーに読み上げさせてみると、いろんなことに気付くだろう。
まとめ
今回は、Webアクセシビリティのための規格「WAI-ARIA」を紹介した。
アクセシビリティに配慮したサイトを作るのはとても大変だが、このような仕組みがあるということだけでも、頭の片隅に置いておくことは無駄にならないと思う。
俺は新しいもの好きなので、最近せっせとWAI-ARIAを調べつつ実装したりもしているが、奥が深すぎてどこを妥協するかに腐心している有り様だ。
しかし、凝ったことをすればするほど、アクセシビリティから遠ざかる俺のサイト……
リッチでインタラクティブなサイトを追求した結果、こうなったのか。
いや、WAI-ARIAのような配慮を重ねれば、どんなWebサイトもアクセシブルにできるはず。
ARIAの名の通り、CSSもJavaScriptも駆使した、リッチなWebアプリケーションをアクセシブルにすることが、WAI-ARIAの究極の目標なのだと思う。
今日も俺は わぁい アリア への道を突き進む。
あかりのために!
こめんと