アクセシビリティを備えた最新のアプリの設計と開発

Rachel Appel

Rachel Appel インターネットやアプリなどさまざまな形態のメディア技術は、利用者にとって有益だからこそ価値があります。残念なことに、世の中にはすべての人々にとって有益とはいえないソフトウェアがたくさんあります。設計者、管理者、開発者は、多くの場合、アクセシビリティよりもセキュリティやパフォーマンスに注意を払います。アクセシビリティは、ソフトウェアにおける優先事項の 1 つであったとしても、たいていは優先度が下げられてしまいます。

アクセシビリティの優先度をもっと上げるべきです。WebAIM では、Web ユーザーの 20 パーセントがアクセシビリティに関するニーズを抱え、支援技術を頼りにしていると推定しています。つまり、米国だけでも 6,000 万人を超える人々が、Web サイトやアプリを使用したり、コンテンツを利用する際に困難を感じていることになります。大半の Web サイトやアプリでは、利用者の減少がそのまま収益減につながります。PDF 資料「アクセシビリティを備えた Web ページの重要性」(英語) に、アクセスシビリティを備えた設計が重要な理由をたくさん紹介しています (bit.ly/1CIx4k4 からダウンロードしてください)。

アクセシビリティの基礎

アクセシビリティを念頭に置いて設計や開発を行うときは、次のような幅広い分野に障碍がある方を考慮してください。

視覚: 視覚に障碍がある方は、さまざまな色を判別できない方を含め、低視力の方から目が見えない方まで広範囲に及びます。
聴覚: 聴覚に障碍がある方は、聞き取りにくいと感じる方から、まったく聞こえない方までさまざまです。
運動: 運動能力に障碍がある方も少なくありません。四肢の欠損や不自由に苦しんでいる方もいます。事故や病気で神経に障碍がある方もいます。運動能力に障碍がある方は、常に専用の入力装置が必要になることがあります。
認知: ADHD や失読症などの学習能力に障碍がある方は、表現方法によって情報が把握しづらくなることがよくあります。

なんらかの形態の支援技術を必要とする人はたくさんいます。支援技術とは、日常の活動が容易または可能になるよう支援するためのツールやテクノロジを指します。眼鏡を支援技術とは考えない人もたくさんいますが、たとえ技術水準が高くなくても、支援技術であることに違いはありません。眼鏡なしでは生活できない方もたくさんいます。一般的な支援技術には、点字読取装置、口棒、頭部装用棒、アダプティブキーボード、音声認識ソフトウェアなどがあります。

アクセシビリティを備えたコンテンツと設計

最もアクセスしやすい設計がすばらしい設計と考えられることはよくあります。広告が多すぎてコンテンツの流れが乱され、読み手の流れを著しく妨害している Web サイトはたくさんあります。メニューやナビゲーション部分が使いにくい Web サイトもあります。Web サイトやアプリのレイアウトとナビゲーションは、アクセシビリティのニーズを考慮する際の重要な検討事項です。

コンテンツを整理するときは、はっきりとした見出しを付けて個別のセクションに振り分けます。動画、音楽、アニメーションには、コンテンツの一部としてキャプションや字幕を含めるようにします。現在入手可能なほとんどの動画作成ソフトウェアは、クローズドキャプション用の字幕を入力できます。

優れた設計にするには、一貫性のあるわかりやすいナビゲーション体系も重要です。JavaScript のカスケードメニューは、健常者にとっても使いにくい場合がよくあります。運動能力に障碍がある方にとってはなおさらです。Web ページの上辺または下辺を横切るリンクが最も適切に機能します。スマートフォンのアプリの場合、利用するデバイスのナビゲーション体系に従って操作します。Windows 8.x のナビゲーションの詳細については、2013 年 8月のコラム「Windows ストアアプリでのナビゲーションの必須要素」(msdn.microsoft.com/magazine/dn342878) を参照してください。

フォントは、大きく、明瞭なものにします。手書き風のフォントは読みづらく感じます。フォントが原因で一部の文字が読みづらくなる症例はたくさんあります。1 つは、学習障碍の失読症です。この障碍がある方は似ている文字の区別ができません。推定では、人口の 5 パーセントが失読症と言われています。健常者にとってはすぐにわかる文字が、失読症の方には反転したり逆さになって見えます。

失読症に関するこのような知識を活かして、dyslexiefont.com のサイト運用者は、少し文字を変えて失読症の方が読みやすいフォントを作成しています。これまでのところ、フォントを試した人たちには好評です。dyslexiefont を使用しないことにしても問題はありません。失読症の方を冷遇していることにはなりません。ただし、できるだけ読みやすいフォントを選択するようにします。

アプリのターゲットが企業家の場合、必要に応じて、フォントの変更を見直します。フォントの色は、ハイコントラストになるようにします。白などの明るい背景に黒などの暗いテキストを合わせるのが、ハイコントラストのよくある例です。もちろん、色合わせを反対にしてもかまいません。暗い背景に明るいテキストを使用してもうまくいきます。通常、十分なコントラストがあれば、どちらを採用するかは好みとスタイルの問題です。

モバイル優先の設計戦略にすれば、間違いありません。通常、モバイル優先の設計では、有用なスペースを効率よく使うことが求められます。ほとんどのスマートフォンや小型タブレットでは、コンテンツのスペースが数インチしかありません。そのため、通常、アプリは最も重要な情報しか表示しません。このシナリオでは、縦に広告を入れるスペースはまったくありません。

アクセシビリティを確保するうえで参考になる設計方法は他にもたくさんあります。Web 上で最も人気のあるニュースサイトやソーシャルサイトについて考えてみます。このようなサイトでは、アクセシビリティが備わっていないことや、アクセシビリティの水準が低いことがよくあります。また、邪魔なポップアップがあり、スクリーンリーダーもユーザーもポップアップで完全に停止します。変わり映えのしないこれらのポップアップの [閉じる] ボタンは、たいてい、一般的なデバイスでもクリックやタップができないように小さくて見つけにくくなっています。

連続ポップアップを採用しているサイトもあります。1 つのポップアップからやっと解放されても、次のポップアップが出現します。これでは欲求不満になります。アクセシビリティのニーズを抱える多くのユーザーは、このようなサイトを利用しなくなります。煩わされるほどの価値はないと考えます。

ストローブ効果やフラッシング効果、警告なしの画像の点滅は避けるようにします。発作が起きる危険性が高まります。目の錯覚を利用したトリックは、特別に意図している場合は別ですが、通常は煩わしく感じます。

ユーザーに通知を表示する場合は、色だけに頼らないようにします。たとえば、多くのフォームでは必須フィールドを示すために赤いフォントが使用されます。色覚に障碍のある方にはその違いがわからないことがあります。また、「こちらをクリック」という表現をリンクテキストに使用しないようにします。スクリーンリーダーにとってはまったく役に立ちません。別の説明的な表現を使用します。

アクセシビリティを備えたコードのプログラミング

アクセシビリティを備えた Web サイトやアプリを開発するために使用できるプログラミング技法があります。開発者としては、入力と出力をどちらも操作する必要があります。ソフトウェアと対話する方法はマウスとキーボードだけでなく、人によってさまざまな方法が使われることに留意します。

キーボードを主に使用するユーザーのために、フィールドのタブオーダーはわかりやすい順番に設定します。また、HTML の <label> 要素を使って、ボタンなどのフィールドや要素にラベルを付けます。これで、かなり明確になります。画像の alt 属性には、簡潔な説明を設定します。スクリーンリーダーは魔法のように画像を読むことはできません。alt タグを使って聞き手に画像を説明します。

HTML5 には、セマンティック要素と呼ばれる一連の要素があります。これらの要素のポイントは、コンピューターも人間も簡単に HTML 要素を読んで理解できるようにすることです。セマンティック要素は XML のようにコンテンツを説明します。たとえば、caption、figure、article、footer、header、summary、time、nav、mark、main などのセマンティック要素は読むだけで、その意味をを理解できます。

スクリーンリーダーの利用者には、スキップリンクが非常に役立ちます。スキップリンクによって、スクリーンリーダーは Web サイト上のナビゲーション要素や広告を避けて、目的のコンテンツまで直接移動できます。オプションや広告が不要にしつこく繰り返されるのをじっと座って待たなければならないのは苦痛です。このような苦痛をユーザーに強要しないでください。以下のコードに示すように、スキップナビゲーションリンクの移動先は <body> 要素の直後に記述します。

<body>
<a href="#maincontent">Skip to main content</a>
<nav><!-- navigation here --></nav>
<main id="maincontent">
<p>The quick brown fox jumps over the lazy dog.</p>

スクリーンリーダーはスキップリンクを見つけると、スキップリンクの ID で指示される要素にフォーカスを移動します。上記の例では、スキップリンクは "maincontent" ID を使って <main> 要素への移動を指示しています。スキップリンクは先頭の要素を指すようにする必要がありますが、多くの設計者はスキップリンクをそれ以外の場所を指すようにすることを好むため、以下のコードに示すように、CSS を使ってスキップリンクを非表示にしたうえで、支援技術に対してはこのリンクが提示されるようにします。

.skiplink-offscreen {
  position:absolute;
  left:-10000px;
  top:auto;
  width:1px;
  height:1px;
  overflow:hidden;
}

ご覧のように、位置を決めるクラスセレクターを absolute に、その値属性を -10000px に設定して、overflow を hidden にしています。このコードは、このセレクターを使用してユーザーには要素が見えないようにし、スクリーンリーダーにはこの要素があることがわかるように要素の位置を決めています。スクリーンリーダーは、hidden 属性を hidden に設定した要素、または display 属性を none に設定した要素をスキップします。この短いコードを使用するのはそのためです。

ARIA による開発

Accessible Rich Internet Applications (ARIA) とは、支援技術が効率よく機能するように、HTML などのマークアップに適用できる標準属性のセットです。ARIA を使えば、状態、プロパティ、役割に応じて要素を定義できます。スクリーンリーダーは、定義された情報を基にソフトウェアの動作を判断できます。

たとえば、チェックボックスは ARIA のチェック済み (checked) 状態を保持することができます。また、要素がメニューの役割を想定させることもできます。このように状態や役割に関する情報を少し補足することで、スクリーンリーダーは Web ページコンテンツのより適切な表現を組み立てることができるようになります。これらの属性は要素を変更することはありませんが、要素の動作の意味合い (セマンティック) がわかるようにします。セマンティックマークアップは、人間にとってもコンピューターにとっても理解しやすいものです。たとえば、次のコードは、意味合いを示すセマンティックセクションを備えた記事 (article) を示しています。これにより、スクリーンリーダーは関連するコンテンツをより正確に識別し、ユーザーに伝えることができます。

<article>
<section aria-labelledby="ProgrammingBestPractices">
  <h2 id="ProgrammingBestPractices">Best Practices for Programmers</h2>
  <ol>
  <li>Take a few minutes a day to refactor small portions of code.</li>
  <li>Learn a new programming language every year.</li>
  </ol>
</section>
</article>

アクセシビリティを高めるこのセマンティックマークアップは、HTML フォームに展開することができます。スクリーンリーダーは、フォームのフィールドにラベルや説明を付けている要素や、同じグループに属するフィールドを把握する必要があります。また、ボタンやチェックボックスの状態も把握しなければなりません。優れたフォームを設計するということは、スクリプトが支援技術にどのように影響するかを理解することです。フォーカスをコントロールに自動設定するコードや、フォームコントロールの状態を動的に変更するコードは見直すようにします。

HTML の <label> 要素を使って、フォームの個々の要素にラベルを 1 つ付けます。ただし、表などの場合は、1 つの要素に複数のラベルが必要になることもあります。それも可能です。そのような場合は、aria-labelledby 属性が有効です。グループ内の各要素の arial-labelledby に、ラベルを付ける要素の ID を設定します。<label> 要素と aria-labelledby 属性の両方を同じフォーム内で使用できます。画像ボタンでないかぎり、[送信] ボタンや [リセット] ボタンにラベルを付ける必要はありません。画像ボタンの場合は、alt 属性を設定するようにします。

どのフォームにも必須要素や、許可されるデータ型の制約がある要素が含まれています。ほとんどのフォームでは、JavaScript を実行して必須フィールドや制約のあるフィールドの検証を行います。エラーはなるべく早くユーザーに通知するほうがよいため、すべてのデータをサーバーに送り返して処理する前に、このような検証を行います。スクリーンリーダーにとっては、スクリプトの実行中にページで何が行われているかを判断するのは困難です。この問題に対処するには、図 1 に示すように、aria-required 属性と aria-invalid 属性を使用します。

図 1 ARIA 属性を備えたアクセシビリティの高い HTML フォーム

<form>     
  <div>
    <label for="name">* Name:</label>
    <input type="text" id="name" aria-required="true" />
  </div>
  <div>
    <label for="checkboxGroupLabel">* Language</span>
    <ul role="radiogroup" aria-labelledby="checkboxGLabel">
      <li role="checkbox"><input type="checkbox" value="C#"
        name="language" aria-checked="false" />C#</li>
      <li role="checkbox"><input type="checkbox" value="JavaScript"
        name="language" aria-checked="false" />JavaScript</li>
      <li role="checkbox"><input type="checkbox" value="Python"
        name="language" aria-checked="false" />Python</li>
    </ul>
  </div>
  <div>
    <span id="yearsLabel">* Years Experience</span>
    <select name="YearsExperience" aria-labelledby="yearsLabel" >
      <option value="1">1-5 Years</option>
      <option value="6">6-10 Years</option>
      <option value="10">10-20 Years</option>
      <option value="20">20+ Years</option>
    </select>
  </div>
  <div>
    <input type="submit" alt="Submit" />
  </div>
</form>

図 1 は、aria-required と aria-labelledby、および役割の使用例を示しています。情報を添えてはいますが、あまり目立たない HTML を追加しているだけです。あまり労力をかけずに、大きなメリットが得られます。

支援技術では、静的要素よりもこれらの属性を重視して処理する必要があります。JavaScript、AJAX 呼び出し、SPA 形式のアプリでは、Web サイトやアプリのコンテンツが頻繁に変更されます。このような動的スクリプトが、スクリーンリーダーの妨げになる場合もあります。JavaScript 検証が実行された後は、aria-invalid など、一部の ARIA 属性の状態はリセットする必要があります。

アクセシビリティを備えたコードのテスト

スクリーンリーダーソフトウェアをダウンロードして支援技術を自分自身で試すことによって、作成した HTML をテストします。目を閉じて、目が見えないという想定でスクリーンリーダーを使用します。支援技術を使用するユーザーからのフィードバックを得ることも、開発したソフトウェアのアクセシビリティを確認する有効な方法です。ダウンロードして使用できるスクリーンリーダーを以下にいくつか紹介します。

NVDA: nvaccess.org
JAWS for Windows: bit.ly/1yJkxuV
Window-eyes: gwmicro.com
VoiceOver for OS X: bit.ly/1JuA1q9

スクリーンリーダーのテストを終えたら、WebAIM には、Web Accessibility Evaluation Tool (WAVE) という包括的なチェックリストとページスキャナーがあります。このツールは、ページのアクセシビリティの状態に関するエラーや警告などの情報を報告します。使い方は簡単です。wave.webaim.org へ移動し、スキャンする URL を入力します。WAVE は、対象ページをインラインで表示し、問題の箇所や、変更してアクセシビリティを改善できる要素に注釈を付けます。図 2 は、MSDN マガジンの 2015 年 1 月号のページにスキャナーを実行した結果を示しています。いくつかの項目にフラグが設定されています。

図 2WAVE スキャナー実行後の MSDN マガジン

注釈が付いたいずれかの要素をクリックすると、WAVE によってその要素に関するエラー情報とメタデータが表示されます。スキャナーは、ラベルや alt 属性の設定漏れからコントラストの問題まで、あらゆる観点で検査を行います。問題の箇所にはエラーや警告のフラグが設定されるので、より重大な問題を優先して変更できます。WAVE はスタンドアロン版を実行することも、自動 QA プロセスに API を追加することもできます。

まとめ

アクセシビリティを備えた設計は、通常、すべてのユーザーに適切な設計方法です。設計の際にアクセシビリティを考慮しないと、かなりの割合の利用者が離れてしまうため、ソフトウェアのアクセシビリティを高めることに労力をかけるのはビジネス上賢明な判断です。UI は、はっきりとラベルを付け、見つけやすいようにオプションを提示します。また、タスクが円滑に終わるように工夫します。アクセシビリティの高い設計を目指せば、必然的に誰が使ってもうまく機能するわかりやすいシステムになります。

Rachel Appel は 20 年を超える IT 業界での経験を持つマイクロソフトの元社員で、コンサルティング、執筆活動、および指導を行っています。彼女は Visual Studio Live!、DevConnections、MIX など、業界トップクラスのカンファレンスで講演しています。専門分野は、マイクロソフトの各種開発ツールやオープン Web を重視したテクノロジとビジネスを連携させるソリューションの開発です。彼女のことをもっと知りたい方は、彼女の Web サイト rachelappel.com (英語) をご覧ください。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Frank La Vigne に心より感謝いたします。

最新のアプリ