アクセス可能な Web アプリケーションの開発とテスト_html/css_WEB-ITnose

公開日 2013-03-20 15:24:00 読書 (3351)

A11Y と呼ばれるアクセシビリティは、ソフトウェア製品のアクセシビリティと使いやすさを指します。 A11Y の出発点は、すべてのグループと人々が Web またはソフトウェア アプリケーションにアクセスできるようにすることです。この記事では、主に Web アプリケーションにアクセスするのが難しい人々を対象として、Web アプリケーションのアクセシビリティに焦点を当てています。いくつかの主要なグループ向けに、開発中に解決すべき課題と問題が紹介されています。

視覚障害のある人は、普通の人のように目で Web を閲覧することができません。現時点での解決策は、画面読み上げソフトウェアを使用して Web ページ上のコンテンツを音声に変換し、ユーザーが画面上のコンテンツを理解しやすくすることです。聴覚や視覚に障害のある人も、Web コンテンツを点字に変換して読み取れるようにすることができます。その結果、開発者にとっての要件は次のとおりです。マウスが使用できなくなるため、キーボードのサポートを提供する必要がある。ユーザーが知っておくべき情報を示す便利なリンクを提供する必要がある。色が認識できなくなります。今日の Web サイト上で増え続けるオーディオおよびビデオ コンテンツを聴覚障害のある人が理解できるようにするには、字幕が必要です。

Web アプリケーションを使いやすく、障害のある人がアクセスできるようにするにはどうすればよいでしょうか?まず、Web 開発者は、この標準に従って、アクセシビリティに使用される要素を識別できるようにする必要があります。WAI (Assistive Accessibility Initiative) は、主に Access 標準を担当します。 Web コンテンツ アクセシビリティ ガイドライン (WCAG) は WAI によって開発された一連の文書です。現在のバージョンは 2.0 です。 WAI-ARIA (WAI-Accessible Rich Client Application) は、Web2.0 リッチ クライアント アプリケーションのために WAI によって提案された新しいガイドラインであり、動的な Web アプリケーションと Ajax アプリケーションをユーザーがより簡単にアクセスできるようにするための一連の役割とプロパティを定義します。障害。

一般的に使用されるツールの紹介

Webking は、Parasoft によって開発された自動テスト ツールで、ホワイト ボックス、ブラック ボックス、回帰テストに使用できます。この記事では、A11y でのツールの検査とテストに焦点を当てます。 Webking は、CI162 で指定されたチェックリストに従います。 Webking が解決する問題は、CI162 標準を満たさない要素を見つけることです。V: 違反、SV: 重大な違反、PSV: 重大な違反の可能性があります。 WebKing は、ローカル ファイルのチェックとテスト、および静的テスト、動的テスト、Ajax テストなどの Web サイト コンテンツのチェックとテストのためのプロジェクトの作成をサポートします。まず、図 1 に示すように、Webking のテスト標準を WCAG2.0 に設定する必要があります。

図 1. Webking の設定

静的ページの場合は、静的検査のためにページのソース コードを直接コピーできます。図 2 に示すように、静的 Web サイトのプロジェクトを作成することもできます。 図 2. 静的プロジェクトの作成

startURL に URL アドレスを入力するか、テスト用のローカル ファイルのローカル パスを指定します。動的な Web サイトの場合、Webking は、ユーザーが Web サイトを操作したときにテストを記録して再生する記録機能を提供します。

図 3. 動的プロジェクトの作成

ますます普及する Ajax アプリケーションのために、Webking は Ajax 機能テストも提供します。 WebKing は、仕様に準拠していない HTML をチェックアウトし、詳細な変更リファレンスを提供するため、開発者が問題を迅速に特定して解決するのに役立ちます。

JAWS は、Freedom Scientific の画面読み上げソフトウェアです。現在のバージョンは 11.0.734 です。画面読み上げソフトウェアの動作原理は、ページ全体のコンテンツを仮想バッファーに保存することです。キーボードを使用してコンテンツを閲覧したり聞いたりできます。ブラウズは、文字ごとまたは行ごとに行うことができます。 ユーザーがアプリケーションと対話する必要がある場合、この仮想バッファに依存できなくなり、別のモードに切り替える必要があるため、アプリケーションと対話するためにこのバッファから飛び出す必要があります。 JAWS は、バージョン 9 以降、通常の Form 要素の対話モードへの自動切り替えをサポートしています。 JAWS を使用する場合はマウスを使用しないでください。マウスを使用すると、仮想バッファーでエラーが発生し、読み取り内容が乱雑になります。もう 1 つの正しいテスト方法は、最初に JAWS を起動し、次にブラウザを開いて対応する URL を入力し、ページ全体の読み込みが完了したときに操作を開始することです。読み込みプロセス中に、JAWS は読み込まれたページの割合を示すプロンプトを表示します。この方法でのみ、この仮想バッファに格納されている内容の正確性を保証できます。

アクセシブルな Web アプリケーションを開発およびテストする手順

アクセシブルな Web アプリケーションの開発およびテストには、主に次の手順が含まれます:

• Webking は、CI162 に対応するリストを満たさない HTML ページ内の項目をチェックするために、通常は単体テスト中に開発者によって実行される静的チェックを実行します。現在、WebKing は ARIA をサポートしていないため、多くの ARIA タグを正しく認識できません。そのため、WebKing によって検出されたエラーを 1 つずつチェックして、実際にチェックリストに違反しているのか、WebKing が ARIA タグを認識できないことが原因であるのかを判断する必要があります。
• キーボードのサポートでは、マウスを介して完了できるすべての操作がキーボードでも同じ効果を達成できる必要があります。
• ハイ コントラスト サポート: ハイ コントラスト モードでは、画面は白黒のみになります。このモードでは Web アプリケーションが情報を失わないようにする必要があります。
• 画面読み取りソフトウェアのサポートは通常、テスターに​​よって行われます。テスターは、画面読み取りソフトウェアを使用して視覚障害者をシミュレートし、ページ上のコンテンツが基本的に画面読み取りソフトウェアによって認識され、さまざまな操作を完了できることを確認しました。

開発のベスト プラクティス

アクセシブルな Web アプリケーションを開発するには、ツールやブラウザーのサポートが必要なだけでなく、開発者は特定の仕様に従い、最終的な目標を達成するために対応する要素情報を提供する必要があります。以下では、開発におけるいくつかのベスト プラクティスを取り上げます。

画像について

1. 画面読み上げソフトウェアが画像アニメーションの内容を明確に読み取ることができるように、画像またはアニメーションには代替情報を提供する必要があります。図 4 に示すように:

図 4. 猫の画像

に対応する HTML は次のとおりです。

リスト 1. 画像の HTML

<img src="cat.gif" alt="Image about cat" />

2 が必要です。 alt を空に設定して、画面読み上げソフトウェアがこの要素を無視できるようにします。図 5 など、ページ ヘッダーの装飾に使用される画像は、実際には貴重な情報を伝えません。 gigure 5.装飾的な画像の対応するhtmlは次のとおりです。 Web 王のチェックに合格し、画面読み取りソフトウェアがこの要素を無視できるようにします。

3. チャート ファイルの場合、alt 属性の設定は、内部の詳細をすべて記述することなく、チャート情報を簡潔に表現する必要があります。たとえば、以下の図 6: 代替情報は、1996 年から 2004 年にかけて 400 万から 1,600 万まで着実に成長し続けた売上に設定されています。毎年の成長を詳しく説明する必要はありません。

図 6. 画像チャート

4. リンクに配置された画像について、すでにテキスト説明がある場合、画面読み上げソフトウェアが説明を繰り返すのを防ぐために、alt も空に設定されます。同じ内容。たとえば、次の HTML:

リスト 3. 画像の alt 属性を繰り返し設定する必要はありません

<img src="ring.gif" alt="" />

A のコンテンツは、これが Apple 電話であることをすでに示しているため、 IMG の alt 属性を再度設定する必要はありません。そうしないと、画面読み上げソフトウェアが繰り返しのコンテンツを 2 回続けて読み上げることになり、混乱が生じます。

5.CSS はスタイルと構造を分離し、HTML コードの構造を明確にします。多くの装飾画像も CSS で読み込まれます。これによって生じる問題の 1 つは、CSS の画像をハイコントラスト モードで表示できないことです。画像が単なる装飾的なものではなく、機能をトリガーすることもできる場合は、その画像を CSS から取り出して、独立した IMG または INPUT 要素として使用する必要があります。たとえば、次のプロンプトは画像を保存します

図 7. CSS で記述された画像

を保存する方法は次のとおりです:

リスト 4. CSS で記述された画像

れーれー

このように、ユーザーがハイ コントラスト モードに切り替えると、画像は空白になり、ユーザーはクリックして保存できなくなります。次のように変更します。

List 5. CSS で画像を取り出します

6. 画像リスト内の画像を選択し、それが選択されているかどうかを区別します。枠線のロゴの色。以下に示すように、選択された画像の境界線は青色です

図 8. 選択されている画像の通常の効果

リスト 6. 画像が選択されている場合の対応する CSS

<a href=”http://apple.com/iphone/”> 	 <img src=”iphone.jpg” alt=””>Apple iPhone  </a>

しかしこのように、ある実装は実際にアクセシビリティ チェック リストの項目の 1 つに違反しています。つまり、黒か白しかない場合、そのような区別は高コントラストでは効果がないため、色だけで異なる要素を区別することはできません。簡単に考えられる方法としては、選択されている場合のみ枠線を追加し、選択されていない場合は枠線を表示しないことで区別することが考えられます。次のように変更します。

リスト 7. 画像が選択されたときに変更された CSS

<div class=” save_button” />  .save_button{ 	 background: url("images/save_button.png"); 	 width: 33px; 	 height: 33px; 	 vertical-align:middle; 	 }

これによって生じる問題は、画像が選択されるとレイアウトがフローティングになり、5 ピクセルの境界線が追加されることです。効果があるように見えますが、悪いです。では、レイアウトがアクセシビリティ要件を満たしていることを確認するにはどうすればよいでしょうか? 上記の CSS に基づいてパディング属性を使用して、レイアウトを正しくすることができます:

清单 8. 图片被选中时正确的 CSS

.selectedIcon {border:1px solid #ACC6F3; 	 padding:4px;}  .unSelectedIcon {border:0 none; 	 padding:5px;}

这样保证整体的边界都是 5px，在高对比度下的效果如图 9 所示：

图 9. 图片被选中时的高对比度效果图

关于 Table

Table 分为两类：一类是做布局的 table，一类是数据 table。对于布局用的 table，读屏软件没必要知道这是一个表，可以通过设置 role=presentation 使 JAWS 忽略这个表，只关注里面的内容。对于数据表格，则需要设置 caption 属性，说明整个表是用来做什么的，使得 JAWS 可以告诉用户这个表的作用。对于每一个单元内的数据，还应该通过 th 属性使得 JAWS 能识别这个数据的表头是什么。对于复杂表，可以通过 id 和 header 属性来标识。如图 10 所示 :

图 10. 数据图表

以第一行的数字 5 为例，正常人可以很容易得看出 5 指的是一年级 Mr.Henry 老师这个班的男生有 5 个，但当 JAWS 面对这个数字 5 的时候，怎么能识别出来呢？通过 header 来标识表头，header 的值就指向对应表头的 id。对应的 HTML 如下：

清单 9. 数据图表

<tr> 	 <th id="class"> Class </th> 	 <th id="teacher"> Teacher </th> 	 <th id="boys"> #of Boys </th> 	 <th id="girls"> #of Girls </th>  </tr>  <tr> 	 <th id="1stgrade" rowspan="2"> 1st Grade </th> 	 <th id="MrHenry" headers="1stgrade teacher"> Mr . Henry </th> 	 <td headers="1stgrade MrHenry boys"> 5 </td> 	 <td headers="1stgrade MrHenry girls"> 4 </td>  </tr>  <tr> 	 <th id="MrsSmith" headers="1stgrade teacher"> Mrs . Smith </th> 	 <td headers="1stgrade MrsSmith boys"> 7 </td> 	 <td headers="1stgrade MrsSmith girls"> 9 </td>  </tr>  <tr> 	 <th id="2ndgrade" rowspan="3"> 2nd Grade </th> 	 <th id="MrJones" headers="2ndgrade teacher"> Mr . Jones </th> 	 <td headers="2ndgrade MrJones boys"> 3 </td> 	 <td headers="2ndgrade MrJones girls"> 9 </td>  </tr>  <tr> 	 <th id="MrsSmith" headers="2ndgrade teacher"> Mrs . Smith </th> 	 <td headers="2ndgrade MrsSmith boys"> 4 </td> 	 <td headers="2ndgrade MrsSmith girls"> 3 </td>  </tr>  <tr> 	 <th id="MrsKelly" headers="2ndgrade teacher"> Mrs . Kelly </th> 	 <td headers="2ndgrade MrsKelly boys"> 6 </td> 	 <td headers="2ndgrade MrsKelly girls"> 9 </td>  </tr>

关于 Form

Form 元素需要关联一个 label 元素，所有的 button 都已经有了一个隐含的 label，所以不再需要显示关联。对于 Input，Select， Checkbox， Radio button 则都需要显示一个 label 元素。这样 JAWS 在面对这个表单元素的时候才能告诉用户这个表单的作用。例如下面清单 10 中的 input， JAWS 会告诉用户这个是需要输入名字的一个输入框。当 label 属性不方便使用的时候，还可以通过 title 属性达到相同的效果，也可以满足 Webking 检查的需要。清单 10 中的两种写法都可以。但前提是 Name 不需要被显示出来。当 title 和 label 都设置的时候 title 会被 JAWS 忽略。

清单 10. Form 元素示例

<label for="name1">Name:</label>  <input name="name" id="name1" size="30" /> 或  <input name=”name” id=”name1” size=”30” title=”name”>

当一个表单元素如果前后都需要描述的时候， label 就显得力不从心了。ARIA 规范的出现解决了这一问题。aria-labelledby 属性可以设置多个值，说明这个表单元素是被那些值所描述的, aria-describedby 属性则更详细的扩展了这个描述。如图 11 所示：

图 11. 需要多个 Label 描述的输入框

当 JAWS 把焦点放在 10 上的时候，会告诉用户 10 表示的是 10 分钟刷新一次。对应的 HTML 代码如清单 11 所示。aria-required 的属性标识这个元素是必须的，JAWS 识别此元素并告知用户必须输入此元素。我们可以看到中间的 input 元素被多个元素来描述（aria-labelledby 中的几个 id 值），这样 JAWS 就能够识别这个标签，并且按照这个标签的顺序读出前后的 label， 并且提示用户如果还有更详细的描述以及如何获取这个更详细的描述。当用户需要时，aria-describedby 所对应的元素信息就会被读出来。增强了视力有障碍人士与普通人了解内容的一致性。

清单 11. 需要多个 Label 描述的输入框

<div> 	 <span id="labelRefresh"> 		  <label for=“refreshTime">Refresh after</label> 	 </span> 	 <input id=“refreshTime" type="text" aria-describedby=“refreshDescriptor" 	 aria-labelledby=" labelRefresh refreshTime refreshUnit" value="10"/> 	 <span id=“refreshUnit"> minutes</span>  </div>  <div id=“refreshDescriptor">Allows you to specify the number of minutes of  refresh time.</div>

关于 Tabindex 与获取焦点的顺序

Tabindex 属性的使用可以使得原本无法取得焦点的元素获取焦点。目的是为了使用户可以用键盘访问任何可以用鼠标访问的元素。我们知道，使用 Tab 键可以按文档顺序 tab 到所有可以获取焦点的元素。Tabindex 可以设置为 -1， 0 或者是任何自然数。

• Tabindex = 0 就使原本无法获取焦点的元素可以在用户 tab 的时候获取焦点，并且按照文档顺序排列。
• Tabindex = -1 使得元素可以获取焦点，但当用户用 tab 键访问的时候并不出现在 tab 的列表里面。可以方便的通过 Javascript 设置上下左右键的响应事件。非常有利于应用小部件（widget）内部的键盘访问。
• Tabindex 设置为大于 0 的数字则可以控制用户 Tab 时候的顺序，一般很少用。

当用户使用 Tab 键浏览页面时，元素获取焦点的顺序是按照 HTML 代码里面元素出现的顺序排列的，有时跟实际看到的页面顺序并不一致。例如图 12 所示的页面：

图 12. 图片被选中时的高对比度效果图

按照页面顺序，tab 的顺序为自左向右，可实际上操作的时候却发现“search all”出现在了“go to edit”的前面。对应的 HTML 代码如清单 12 所示：

清单 12. 页面获取 focus 的顺序

<div>    <span style=”float:left;”> 			 welcome page    </span>    <span style=”float:right;margin-left:6em;”> 			 search all    </span>    <span style=”float:right;”> 		   go to edit    </span>  </div>

原来是通过 float:right 达到了布局上的效果，实际文档顺序确实是 search all 在前面的。所以为了不引起混淆，最后能保持代码的顺序与实际呈现出来的页面上的顺序一致。可以修改上面的代码为清单 13 所示：

清单 13. 页面获取 focus 的顺序 — 调整后

<div>    <span style=”float:left;”> 			 welcome page 	 </span> 	 <span style=”float:right;width:15em;”> 		<span style=”float:left;”> 				   go to edit 	    </span> 		<span style=”float:right;”> 				  search all 	    </span> 	 </span>  </div>

关于隐藏的内容

隐藏的内容分为两种，一种是为了布局的需要，在条件满足的情况下才会显示出来；另一种是只给读屏软件读的内容：有时候我们为了使读屏软件更准确的读取信息，会提供一些额外的描述来达到此效果，但为了不给正常用户带来困扰，这些内容对正常用户来说是隐藏起来的。隐藏内容我们通常用 display：none 或者 visibility:hidden 来表示，但读屏软件同样也会忽略这类内容。那如何隐藏内容又能使读屏软件读出来呢？另外一种隐藏内容的方式是使用绝对定位使得内容不出现在当前屏幕上，如：{position:absolute;top:-30000px;} 所以在选择使用哪种方式隐藏内容时就需要慎重考虑，display:none visibility:hidden 对任何人都是隐藏的，如果想只给读屏软件读到就需要使用上面的绝对定位方式。例如在图 13 所示的菜单的选中项上加上如下的 css：

清单 14. 只给读屏软件读的内容

<span>  is selected</span>  .access{ position:absolute; top:-30000px; }

图 13. 菜单

这样当用户使用 JAWS 浏览每一个菜单项时，在选中项上就能听到哪一项是当前的所选中。

高对比度模式的小技巧

系统切换到高对比度模式，只有黑白两色，很多在正常模式下依靠颜色来区分的（如界面边界）都无法辨识了，写在 CSS 里面的很多图片也都无法显示出来。此时就需要在高对比度下增加边界或者另外 DOM 节点来显示同样的内容。Dojo 的 WAIState Api 提供了一种方式来判断系统是否处于高对比模式，如果是则在 body 上增加 dijit_a11y 的一个 CSS。这样可以在正常模式下显示一个 DOM 节点在高对比度下显示另外一个 DOM 节点，从而方便的区分。如图 14 所展示的正常模式与高对比模式下的对比：

图 14. 高对比模式与正常模式的对比

正常模式下如左图所示，子菜单通过一个图片标识，但这个图片是在 CSS 里面设置的，切换到高对比度模式即无法显示出来。此时，我们增加一个在高对比度模式下才显示出来的节点，达到如图右所示的效果，在高对比度下显示一个 + 号。代码清单如清单 15 所示，在高对比模式下，dijit_a11y 加在 body 上，dijitMenuExpandA11y 所对应的 DOM 即应用右面的 CSS 得以显示出来。

清单 15. 正常模式与高对比模式显示不同的 Dom 节点

<td waiRole="presentation"><div dojoAttachPoint="arrowWrapper" style="visibility: hidden"><img src="${_blankGif}" alt=""><span>+</span></div> </td>  tundra .dijitMenuExpand { width: 7px; height: 7px; background-image: url('images/spriteArrows.png'); background-position: -14px 0px; } .dijitMenuExpandA11y {display: none; } .dijit_a11y .dijitMenuExpandA11y {display: inline; }

总结

本文介绍了开发测试可访问无障碍的 Web 应用的工具，步骤以及开发中的最佳实践。应用这些最佳实践与小技巧能帮助您在开发中迅速的为您的 Web 应用提供 A11Y 的支持。