アクセシビリティBlog
Webサイトのアクセシビリティを高めるための方法や国内外の関連情報など、さまざまな角度からWebアクセシビリティに関する話題をご提供していきたいと思います。
当Blogの更新情報は、Twitter経由でも配信しています。興味のある方はぜひ、@mlca11yをフォローしてください。当Blogへのご意見・ご質問は、Twitter経由でも受け付けております。
2013年6月19日
HTML5 videoとブラウザーのアクセシビリティ対応状況比較
ワシントン大学のアクセシビリティスペシャリストであるTerrill Thompson氏が自身のBlogの中でブラウザー別のHTML5 Videoへのアクセシビリティ対応状況について紹介されています。
記事の中では、対応状況は日々進化しているとしたうえで、現在の各ブラウザーの状況をアクセシビリティの視点から紹介しています。
スクリーン・リーダー利用者が使用できるようなプレーヤーを提供しているブラウザーがある一方、キーボードからはプレーヤーを操作できないブラウザーもあり、今のところその対応状況は様々であるとのことです。
2013年6月18日
スキップリンクの新たな形「SkipTo」
スキップリンクと言えば、ページ内の見出し要素などに移動する手段を持たなかったスクリーン・リーダーや音声ブラウザー向けに、ページ内の本文などの開始位置に簡単に移動できるようにとの目的で実装される機能です。
Paypal Accessibility Teamでは、そんなスキップリンクの代替となる可能性のあるSkipToを公開し、利用者からのフィードバックを求めています。
SkipToは古いスキップリンクを置き換える目的で作成されたスクリプトで、利用者が初めてそのページに最初にアクセスした時には画面にも表示されます。メニューにキーボードのフォーカスがある状態でEnterキーを押すとメニューが開き、カーソルキーで移動先を選択して再びEnterキーを押すと目的の場所に移動できます。ページ内の任意の場所から再びメニューに戻るには、設定されたアクセスキーを使用することもできます。
DrupalやWordPress向けのプラグインも提供されているとのこと、これらのCMSをご利用の方は比較的簡単にSkipToを導入できるかもしれませんね。
2013年6月17日
明朝のアクセシビリティチャットのテーマは「ARIA vs 伝統的なHTML」
毎月Deque Systems社の主催で実施されているアクセシビリティチャット、日本時間の明朝5時から開催される議論のテーマは「ARIA vs 伝統的なHTML」とのこと。今回は、参加者自身がスマックダウンのようにARIA側と伝統的なHTML側に分かれて議論を戦わせるとのことです。
なお、アクセシビリティチャットについてまだご存じない方は、事前にアクセシビリティチャットのHow toガイドをチェックしてからご参加ください。私も、少し早起きしてこの興味深い戦いに参加してみたいと思います。
2013年6月14日
導入レベルのWebアクセシビリティに関する情報を探していませんか？
来る6月26日の午前0時から、このようなタイトルのWebinarが開催されます。主催するのはアクセシビリティチェックツール（Worldspace）を開発・提供しているDeque Systems社で、Webアクセシビリティの基礎的な内容が紹介されるとのことです。
講師は同社のアクセシビリティエキスパートであるTodd Liebsch氏で、『Webアクセシビリティはどこから始めたらいいの？』、『何がWebサイトをアクセシブルにするの？』、『もしもWebサイトをアクセシブルにしなかった場合、ビジネス上どのようなインパクトがあるの？』といった、これからWebアクセシビリティに取り組もうとしている方々がお持ちの疑問に答えるようなWebinarを目指しているとのこと、参加を希望される方はIntro to Web Accessibility Webinar Registrationページからお申し込みください。
2013年6月13日
みんなが使える10のアクセシビリティTips
少し前の話になりますが、5月9日はGlobal Accessibility Awareness Day (GAAD) (世界規模のアクセシビリティ啓発デイ)でした。それに合わせてユタ州立大学のCenter for Persons with Disabilities で活動するWebAIMが10 Easy Accessibility Tips Anyone Can Useという記事を公開しました。
記事の中ではWebアクセシビリティを高めるためにコンテンツ提供者が容易に取り組める10の項目が紹介されておりました。わかりやすそうな内容でしたので、本日はその概要をお伝えします。
1. ロゴに代替テキストを設定しよう
代替テキストは、画像が表示できない環境でWebサイトにアクセスしてくる利用者に、ページ内で画像で表現されている情報を説明するために用いられます。まずは、サイトのロゴに代替テキストを付加することで、利用者がどこのWebサイトにアクセスしたのかを理解できるようにしてみましょう。
サイト内のロゴのマークアップを確認し、もしも代替テキストがなければ付加してみましょう。
2. 基本的なランドマークを追加しよう
ARIA landmarkはページ内の領域を示すために使用され、それが付加されているページは対応した環境でキーボードを使ってページ内の領域間を簡単に移動できます。まずはその中から、main、navigation及びsearchの三つを指定してみましょう。
3. フォーカスのインジケーターを拡張しよう
画面を見ることのできるキーボードの利用者は、TabキーやShift+Tabキーでページやフォームを移動します。その際、今どこにフォーカスしているかを確認しやすくするには、以下のようなCSSを追加するとよいでしょう。色はサイトの色に応じて変更しても構いませんが、区別しやすいものを選んでください。
a:focus {
outline:1px solid red;
background:yellow;
}
4. 入力フォームの必須項目を指定しよう
提供している入力フォームに、入力必須項目と入力が任意の項目が混在している場合、必須項目にaria-required="true"を指定することでどの項目への入力が必須なのかをスクリーン・リーダー利用者に知らせることができます。
5. ページタイトルは<h1>でも表現しよう
そのページの内容や機能を簡潔に表したページタイトルは一般的に、ページのメインとなる部分の先頭に大きなボールドの文字で表現されています。見出しの構造をわかりやすくするために、このページタイトルは<h1>で表現するようにしましょう。
6. テーブル見出しを指定しよう
提供しているWebサイトにデータテーブルがある場合、テーブル見出しを<th>としてマークアップし、ほかの項目と区別できるようにしましょう。
7. テーブルキャプションを指定しよう
ほとんどのテーブルは、短いテキストでそのテーブルの概要を説明できます。<caption>要素を使ってそのテーブルの概要を説明するテキストを記述しましょう。
8. 「ここをクリック」のような表現を避けよう
提供中のWebサイトで「ここをクリック」のようなリンク項目がないかを検索し、もしみつかった場合にはリンク先の内容が分かるような表現に変更しましょう。
9. tabindex属性は削除しよう
提供中のWebサイトでtabindex属性を検索し、もしその値が1かそれ以上であるにも関わらず、なぜそれが追加されているのかがわからない場合は、そのtabindex属性を削除しましょう。
tabindexではキーボードの移動順序を指定することができますが、それ以上にアクセシビリティ上の問題を引き起こす可能性があります。
10. WAVEを使ってページをチェックしてみよう
WAVE web accessibility evaluation toolは簡単に使用できるツールで、Webサイトのアクセシビリティに関するフィードバックを行うことができます。http://wave.webaim.org/にアクセスしてWebサイトのURLを入力し、Webサイトがアクセシブルかどうかをチェックしてみましょう。
2013年6月12日
1スクリーンリーダー利用者としての私のWeb閲覧環境
私は、セミナーなどでスクリーン・リーダーを使ったデモンストレーションを行う時などに、「普段はどのような環境でWebを見ているのですか？」と尋ねられることがよくあります。スクリーン・リーダーにもさまざまな種類があり、今日では使用できるWebブラウザーの種類も増えてきたことから、スクリーン・リーダー利用者がどのような環境でWebにアクセスしているのかについて気になる方もいらっしゃるかもしれません。
そこで本日は、1スクリーン・リーダー使用者として、私が普段仕事やプライベートでどのような環境からWebにアクセスしているかをご紹介したいと思います。
仕事は主にJAWSとFirefoxで
私が当社でアクセシビリティ・エンジニアとして働き始めた2006年当時、Webの閲覧にはInternet Explorerを使用していました。当時はそれ以外の選択肢はほとんどなく、英語版のJAWS 7.0がようやくFirefoxへの対応を開始したところでした。
今ではJAWSを使ってInternet ExplorerだけでなくFirefoxも利用できるようになったことから、普段私はFirefoxを使用しています。様々なアドオンを使うことで、例えばリンクを共有したりInstapaperに記事を保存したりと、ブラウザーの機能を拡張できるところが便利だと感じています。
もちろん、NVDAとFirefox、PC-TalkerとInternet Explorerといった様々な環境で検証を行うこともあります。今日では、Mac OSやiOSのVoiceOverとSafariの組み合わせでコンテンツがどのように読み上げられるかを検証することもあります。
プライベートではiPhoneを使用
仕事中には様々なブラウザーを使用しますが、プライベートでは主にiPhoneのSafariを使用しています。移動中でも自宅でも簡単にWeb上の情報にアクセスできるので、以前と比較するとパソコンを起動することが少なくなりました。情報検索やショッピング、インターネットバンキングなど、様々な作業がiPhoneだけで完結するところが便利だと感じています。
しかし、SafariとVoiceOverの組み合わせでは利用できないようなWebサイトや、VoiceOverの日本語音声では理解できないようなコンテンツは、NVDAとFirefoxを使って利用しています。
このように、今日ではスクリーン・リーダー利用者のWeb閲覧環境も多様化しています。皆様のWebサイトがより多くの環境からアクセスできるよう、閲覧環境に依存しないコンテンツを提供していただければと思います。
2013年6月11日
ChromeでAccessibility Developer Toolsを使う
前回の投稿ではFirefoxのアドオン、DOM Inspectorを紹介しました。今回はChromeの拡張機能、Accessibility Developer Toolsを紹介します。
Accessibility Developer ToolsはChromeのデベロッパーツールにアクセシビリティの調査機能を追加します。追加される機能は大きく2つあります。1つは特定の要素を調査する機能で、もう1つはページ内にあるアクセシビリティの問題を見つける機能（監査）です。今回は特定の要素を調査する機能を紹介しますが、監査の基準も公開されていますので監査機能に興味があるかたはご覧ください。
Accessibility Developer Toolsの準備
まずChromeにAccessibility Developer Toolsをインストールします。なお、ローカルファイルの調査も行う場合には、拡張機能の設定画面でAccessibility Developer Toolsの「ファイルのURLへのアクセスを許可する」にチェックを入れます。準備はこれだけで、あとはデベロッパーツールを起ち上げるだけです。
特定の要素のアクセシビリティに関する情報を調査する
Chromeのデベロッパーツールは画面が大きく左右2つに分かれています。「Elements」タブを選択した場合には、左のペインには要素のツリー、右のペインには要素の情報が表示されます。Accessibility Developer Toolsをインストールすると、右のペインにAccessibility Propertiesが追加されます。Accessibility Propertiesには選択した要素のアクセシビリティに関する情報が、必要に応じて表示されます。それでは表示される各項目を簡単に見ていきましょう。
Text
Text欄には要素のテキストが表示されます。
ブラウザや支援技術は要素の子孫にあるテキストを単にくっつけて、支援技術やユーザーに伝えているわけではありません。img要素であればalt属性が使われますし、フォームコントロールなどにはラベルを設定することができます。また、WAI-ARIAを使えば、aria-label属性などを使って要素の名前（ラベル）を上書きすることもできます。Text欄にはそれらを考慮した上でのテキストが表示されます。
例えば、ミツエーリンクスのサイトには、ページの先頭に「サイト内検索」のテキスト入力欄があります。Accessibility Developer Toolsでこのテキスト入力欄を調査すると、「Text」欄には「サイト内検索」と表示されます。そして、どの情報を使ってテキストを計算したのかが表示されます。この例ではlabel要素のfor属性でテキスト入力欄に関連付けられたテキストが使われていますので、「label-for: "サイト内検索"」と表示されます。
Color
Color欄には要素の前景色と背景色のコントラスト比が表示されます。
この機能は要素に適用されているCSSを見て、コントラスト比を計算しています。WCAG 2.0ではレベルAAで4.5:1（大きな文字では3:1）（達成基準1.4.3 最低限のコントラスト）、レベルAAAで7:1（大きな文字では4.5:1）（達成基準1.4.6 より十分なコントラスト）以上のコントラスト比が求められます。要素のコントラスト比がこれらの値に満たない場合、Accessibility Developer Toolsは達成基準を満たすように調整した色の組み合わせを提示します。提示された色の組み合わせを実際に適用して、見た目を確認することも可能です。
例えば、前景色と背景色のコントラスト比が2.77:1の要素を選択すると、Color欄には「Contrast ratio: 2.77」というテキストと、前景色・背景色のスウォッチが表示されます。2.77:1はWCAG 2.0のAAやAAAで求められるコントラスト比に達していないため、行の先頭には警告アイコンが表示されます。その下には「AA level (4.53): #ffffff/#56799f」、「AAA level (7.03): #ffffff/#405b78」のように、コントラスト比を改善した色の組み合わせが提示されます。各行のスウォッチをクリックすると、色の組み合わせを変更することができます。
この機能はとても便利ですが、いくつかの注意点があります。
- 要素のfont-sizeプロパティとfont-weightプロパティによって「大きな文字」に判定されるかどうかが決まります。
- 背景画像を指定している要素には対応しておらず、「Color」欄自体が表示されません。
- 要素自身の背景色に透明度がある場合（background-colorプロパティの初期値であるtransparentは透明度をもちます）には、先祖の要素を辿りながら背景色を計算していきます。
なお、「大きな文字の判定」では、Accessibility Developer Toolsは19.2px以上の太字か、24px以上という基準を使っているようです（ソースコード）が、この基準がチェック対象に適切かどうかは検討する必要があるでしょう。WAICが公開しているWCAG 2.0解説書 日本語訳では訳注として 日本語を含む場合、少なくとも22ポイント、又は18ポイントの太字と考えるとよい
としています。
また、「背景画像が指定された要素の調査はしない」と「背景色に透明度がある要素は先祖の要素を辿りながら背景色を計算する」ことから、背景画像を指定した要素の子孫のうち、コントラスト比が表示されるのは明示的に背景色を指定した要素のみとなります。この制約はbody要素に背景画像を指定しているページでコントラスト比をチェックする場合に大きな障害となる場合があります。
Visibility
「Visibility」欄には要素が画面上で見えるのかという情報が表示されます。
幅や高さが0の要素（空のp要素やfont-size:0が指定された要素など）、画面上では視認できません。同様にopacity:0を指定された要素や、絶対配置などによって画面外に押し出された要素なども視認することはできません。 このように、要素が画面上で見えない場合にはVisibility欄に「Has zero area」や「Transaprent」、「Not visible on screen」といった理由が表示されます。
ARIA
「ARIA」欄には要素に設定されたrole属性やaria-*属性値が表示されます。
役割（role属性値）によっては必須の属性がありますが、それが含まれていない場合には警告が表示されます。なお、ARIA欄は明示的に指定された属性値を指定しており、HTMLの各要素が暗黙的にもっている役割や状態、プロパティは表示されません。
Video
「Video」欄にはvideo要素に設定されたテキストトラックの一覧が表示されます。track要素で指定したテキストトラックが種類ごと（キャプションや音声ガイド、チャプターなど）に、一覧表示されます。
まとめ
Accessibility Developer Toolsには興味深い機能をいくつも実装されています。なかでも、コントラスト比のチェックだけではなく、改善候補を提案する機能は素晴らしいと思います。一方でチェックの難しい機能を実装していることもあり、使用できる場面が限られていたり、結果の解釈を慎重に行う必要があることも事実です。
とはいえ、Accessibility Developer ToolsはChromeのデベロッパーツールに統合されており、開発のあいだも簡単に確認することができます。Chromeを利用している方は試してみると良いでしょう。