WCAG 2.0 達成方法集

Skip to Content (Press Enter)

HTML と XHTML の達成方法

このウェブページは、「WCAG 2.0 達成方法集 : WCAG 2.0 の達成方法と失敗例」におけるHTML と XHTML の達成方法を掲載している。ウェブコンテンツ技術特有の達成方法は、「一般 (General)」の達成方法に取って代わるものではない。コンテンツ制作者は適合に向けて作業する際には、「一般 (General)」の達成方法とウェブコンテンツ技術特有の達成方法の双方を考慮に入れる必要がある。

ウェブコンテンツ技術特有の達成方法は、あらゆる状況で WCAG 2.0 の達成基準と適合要件を満たすコンテンツを作るために使うことができる技術を指しているわけではない。 コンテンツ制作者はその技術の限界に注意を払い、障害のある人にアクセシブルな方法でコンテンツを提供す必要がある。

達成方法についての情報は、WCAG 2.0 達成方法集のイントロダクションを参照のこと。他のウェブコンテンツ技術の達成方法一覧については、目次を参照のこと。




H2: 同じリソースに対して隣接する画像とテキストリンクを結合する

適用 (対象)

リンク機能を提供する HTML4、HTML5 及び XTHML ドキュメント

これは、次の達成基準に関連する達成方法である:

解説

訳注: WAIC では H2 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H2 も参照されたい。

この達成方法の目的は、テキストとアイコンの両方でリンクを提供する際、キーボード利用者や支援技術の利用者にとって混乱や困難を招くような ウェブページを作らないようにすることである。様々な利用者がテキストとアイコンを使いやすいと見出していることから、両方を提供することでリンクのアクセシビリティを向上させることができる。

よくあるリンクとして、テキストとアイコンの両方が互いに隣接しながらも、別々の要素としてレンダリングされているものがある。視覚的にはそれらは単一のリンクのように見えるが、それらを同様のリンクが隣接しているものとして受け取る利用者も多い。キーボード利用者の場合、冗長なリンクを通過していくのは面倒である。支援技術の利用者にとって、連続する同様のリンクに遭遇すると混乱する可能性がある。アイコンのテキストによる代替がリンクテキストの複製である場合、スクリーンリーダーは読み上げを 2 度繰り返すことになる。

制作者がリンク画像の代替テキストを省略した場合、テキストによる代替が視覚的なリンクと同じ目的を果たさないため、達成基準 1.1.1 を満たせなくなる。

この達成方法は、テキストと画像を一つの a 要素にまとめ、画像に空の代替テキストを指定してテキストの重複を排除することによって、混乱や困難がないリンクを提供するものである。このようにすることで、リンクにおける両方の表現が提供されつつも、キーボード利用者にとってリンクは一つだけとなり、ウェブページのリンク先リストを利用者に提供する補助技術も重複リンクを含まなくなる。

ページをレイアウトしやすくするために、テキストとアイコンのリンクを隣接したテーブルセルに分けることがある。WCAG 2.0 ではレイアウトテーブルの使用を禁止していないが、HTML の table 要素に定義されたセマンティックな意味を保持させ、コンテンツから提示を分離するコーティング手法に準拠するためにも、CSS ベースのレイアウトが推奨されている。CSS が使用されている場合には、この達成方法を適用して、テキストとアイコンのリンクを一つにまとめることができる。

事例

事例 1

アイコンとテキストが同じ a 要素の中にある。(HTML4 又は HTML5)

コード例:

 <a href="products.html">
   <img src="icon.gif" alt="">
   Products page
 </a>      

事例 2

リンクにアイコンとテキストがあり、サイトのヘルプでそのアイコンの説明をしている。img には、サイトのヘルプで使われている名前であるテキストによる代替があり、ホームページのアイコンをクリックすることが説明されている。(HTML4 又は HTML5)

コード例:

<a href="home.html">
  <img src="house.gif" alt="home page icon">
  Go to the home page
</a>     

訳注: WAIC では H2-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H2-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。HTML 5.1§4.7.5.1. Requirements for providing text to act as an alternative for images を代わりに参照できる。

検証

手順

この達成方法を適用しているすべての a 要素に対して:

  1. a 要素に含まれるすべての img 要素の alt 属性値が空に設定されていることを確認する。

  2. a 要素に空の alt 属性値又はリンクテキストを補足し画像を説明する値のいずれかを持つ img 要素が含まれていることを確認する

期待される結果

  • 上記の全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H4: リンク、フォームコントロール、及びオブジェクトを通して、論理的なタブ順序を作成する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、初期設定のタブ順番が十分でない時に、論理的なタブ順番を提供することである。 多くの場合、「G59: コンテンツ内の順番及び関係に従った順序で、インタラクティブな要素を配置する」を用いることで十分であり、この達成方法は必要ではない。表示とは異なるタブ順番を設定すると、ユーザビリティ上の不具合を生じさせる可能性が高くなる。

場合によって、コンテンツ制作者はコード内のインタラクティブな要素の順番に従うことなく、コンテンツの関係をたどるタブ順番を指定しようとするかもしれない。この場合、インタラクティブな要素の tabindex 属性を使用することで選択肢の順番を指定できる。tabindex 属性には、0 から 32767 の間の値を付与する。

インタラクティブな要素が Tab キーを使ってナビゲートされる時、要素は tabindex 属性の値の増える順にフォーカスが与えられる。0 よりも大きな tabindex 値を持つ要素は、tabindex がない又は 0 の tabindex の要素の前にフォーカスを受けることになる。0 よりも大きな tabindex を持つ全ての要素がフォーカスを受け取った後、残りのインタラクティブな要素はウェブページに現れる順番でフォーカスが与えられる。

訳注: WAIC では H4 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H4 も参照されたい。

事例

事例 1

系図の検索フォームで結婚記録を検索する。検索フォームには花嫁及び花婿用のいくつかの入力フィールドがある。フォームは、データテーブルを用いてマークアップされ、1 列目に花婿、2 列目に花嫁のフィールドがある。コンテンツの順番は行ごとであるが、コンテンツ制作者はフォームを列ごとにナビゲートする方がより論理的であると感じている。この方法では、全ての花婿の条件は花嫁の条件へ移る前に記入できる。入力フィールドの tabindex 属性は、列ごとにナビゲートするタブ順番を指定するのに使用される。

コード例:

<form action="#" method="post">
 <table summary="the first column contains the search criteria 
  of the groom, the second column the search criteria of 
  of the bride">
 <caption>Search for marriage records</caption>
 <tr>
   <th>Search criteria</th>
   <th>Groom</th>
   <th>Bride</th>
 </tr>
 <tr>
  <th>First name</th>
  <td><input type="text" size="30" value="" name="groomfirst" 
      title="First name of the groom" tabindex="1"></td>
  <td><input type="text" size="30" value="" name="bridefirst" 
       title="First name of the bride" tabindex="4"></td>
 </tr>
 <tr>
  <th>Last name</th>
  <td><input type="text" size="30" value="" name="groomlast" 
      title="Last name of the groom" tabindex="2"></td>
  <td><input type="text" size="30" value="" name="bridelast" 
      title="Last name of the bride" tabindex="5"></td>
 </tr>
 <tr>
  <th>Place of birth</th>
  <td><input type="text" size="30" value="" name="groombirth" 
      title="Place of birth of the groom" tabindex="3"></td>
  <td><input type="text" size="30" value="" name="bridebirth" 
      title="Place of birth of the bride" tabindex="6"></td>
 </tr>
</table>
</form>      

訳注: WAIC では H4-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H4-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2

ウェブページは上部の右端に検索フィールドを提供している。コンテンツの順番が最初ではないが、タブ順番が最初になるようにフィールドには tabindex="1" が与えられている。

訳注: WAIC では H4-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H4-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3

tabindex 値は、連続した番号である必要はなく、特定の値で始まる必要もない。値は一意的である必要もない。同じ tabindex 値を持つ要素は、その文字の出現順にナビゲートされる。

タブ順番がコンテンツ順番に従っているコンテンツのセクションにおいて、個々の要素に異なる tabindex 値を指定するよりも、全ての要素に同じ値を与えることでエラーを起こりにくくすることが可能である。それらの要素を再配列する、又は新しい要素を加える、及び論理的なタブ順番を設定することは容易である。

コード例:

 <a href="xxx" tabindex = "1">First link in list</a>
<a href="xxx" tabindex = "1">Second link in list</a>
<a href="xxx" tabindex = "1">Link that was added long 
  after the original list was created</a>
<a href="xxx" tabindex = "1">Third link in list</a>
  ...
<a href="xxx" tabindex = "1">Twentieth link in list</a>      

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. tabindex が使われているかどうかを確認する。

  2. tabindex が使われている場合、tabindex 属性により指定されたタブ順番がコンテンツの関係に従っていることを確認する。

期待される結果

  • 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H24: イメージマップの area 要素にテキストによる代替を提供する

適用 (対象)

area 要素を含む HTML 及び XHTML ドキュメント

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H24 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、イメージマップ上の選択可能領域と同じ役割を果たすテキストによる代替を提供することである。イメージマップは、area 要素によって定義された選択可能領域によって分割されている 1 枚の画像である。各領域は、他のウェブページや、現在のウェブページ内の他の場所へのリンクである。各 area 要素の alt 属性は、その画像の選択可能領域と同じ目的を果たすものである。

訳注: WAIC では H24 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H24 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

訳注: WAIC では H24 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H24 も参照されたい。

事例

事例 1

この事例では、イメージマップ上の各領域の目的を示したテキストを提供するのに、area 要素の alt 属性を利用している。

コード例:

<img src="welcome.gif" usemap="#map1" 
    alt="Areas in the library. Select an area for
more information on that area." /> 
<map id="map1" name="map1">
  <area shape="rect" coords="0,0,30,30"
    href="reference.html" alt="Reference" />
  <area shape="rect" coords="34,34,100,100"
    href="media.html" alt="Audio visual lab" />
</map>   

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.1§4.7.17. Image maps 及び HTML 5.1§4.7.5.1. Requirements for providing text to act as an alternative for images を代わりに参照できる。

検証

手順

イメージマップ上の各 area 要素について:

  1. その area 要素に alt 属性があることを確認する。

  2. alt 属性で指定したテキストによる代替が、イメージマップの area 要素で参照されるイメージマップ画像の一部と同じ目的を果たしていることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H25: title 要素を用いて、ページタイトルを提供する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、フレームセットの個々のフレームに含まれるものを含む全ての HTML 及び XHTML ドキュメントにおいて、head 要素のセクション内で title 要素を用いてドキュメントの目的を簡単な文言で定義することである。これにより、ページの本文でオリエンテーション情報を探すことなく、利用者はサイト内の自分のいる場所を素早く見つけることができる。

ドキュメント内で一度しか現れない (必須の) title 要素は、ほとんど全ての HTML 及び XHTML の要素で利用されるかもしれない title 属性と異なることに注意する。

訳注: WAIC では H25 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H25 も参照されたい。

事例

事例 1

この事例はドキュメントのタイトルを定義している。

コード例:

<html xmlns="http://www.w3.org/1999/xhtml">   
   <head>     
      <title>The World Wide Web Consortium</title>     
   </head>   
   <body>     
      ...   
   </body> 
</html>  

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.2.2. The title element を代わりに参照できる。

検証

手順

  1. HTML 又は XHTML ドキュメントのソースコードを調べ、head 要素内に空でない title 要素があることを確認する。

  2. title 要素がドキュメントを説明していることを確認する。

期待される結果

  • 1. 及び 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H28: abbr 要素を用いて、略語の定義を提供する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H28 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、abbr 要素を用いることで、略語に対して元の語又は定義を提供することである

abbr 要素は、頭字語や頭文字語を含むあらゆる略語に用いてよい。HTML4 及び XHTML では、頭文字語や頭字語は acronym 要素を用いてマークアップすることもできる。abbr 要素は、頭字語や頭文字語を含むあらゆる略語に用いてよい。HTML5 以降では、より一般的な abbr 要素の利用が提案され、acronym 要素は廃止されている。

訳注: HTML 4、XHTML (XHTML 1.0 及び XHTML 1.1) は Superseded Recommendation としてマークされ、廃止された仕様である。

事例

事例 1: abbr 要素を用いて略語の元の語を示す

コード例:

<p>Sugar is commonly sold in 5 <abbr title="pound">lb.</abbr> bags.</p>
<p>Welcome to the <abbr title="World Wide Web">WWW</abbr>!</p>              

事例 2: abbr 要素を用いて略語の定義を示す

コード例:

<p>Tasini <abbr title="and others">et al.</abbr> <abbr title="versus">v.</abbr>
The New York Times <abbr title="and others">et al.</abbr> is the landmark lawsuit 
brought by members of the National Writers Union against ......</p>  

事例 3: abbr 要素を用いて頭字語の元の語を示す

コード例:

 <p>The use of <abbr title="Keep It Simple Stupid">KISS</abbr> became popular in ...</p>        
            

事例 4: abbr 要素を用いて頭文字語の元の語を示す

コード例:

 <p><abbr title="World Wide Web">WWW</abbr></p>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. 略語それぞれに、abbr 要素で元の語や定義を指定していることを確認する。

期待される結果

  • 1.の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H30: a 要素のリンクの目的を説明するリンクテキストを提供する

適用 (対象)

リンク (<a href> 要素) を含む HTML 及び XHTML ドキュメント

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、リンク先を説明するテキストを a 要素のコンテンツとして提供することにより、リンクの目的を説明することである。その説明により、利用者はこのリンクとウェブページ内にある他のリンクとの違いが区別でき、利用者がリンクをたどるかどうかを決定するのを助ける。一般的に、遷移先の URI では、そのリンクの目的を説明したことにはならない。

画像がリンクの唯一のコンテンツであるとき、画像のテキストによる代替がそのリンクに固有の機能を説明している。

リンクのコンテンツがテキスト及び一つ以上の画像を含むとき、テキストがリンクの目的を十分に説明している場合、画像は空のテキストによる代替であってもよい。(H67: 支援技術が無視すべき画像に対して、img 要素の alt テキストを空にして、title 属性を付与しない (HTML) を参照。) 画像がリンクの目的以外にも情報を伝えるときには、画像に適切な代替テキストも付与しなければならない。

訳注: WAIC では H30 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H30 も参照されたい。

事例

事例 1

HTML において、a 要素のテキストコンテンツを用いてリンクの目的を説明する。

コード例:

<a href="routes.html">
  Current routes at Boulders Climbing Gym
</a>

事例 2

画像のリンクの目的を説明するために、img 要素に alt 属性を使用する。

コード例:

<a href="routes.html">
   <img src="topo.gif" alt="Current routes at Boulders Climbing Gym" /> 
</a> 

訳注: WAIC では H30-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H30-2 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 3

アンカー (a) 要素が img 要素に加えてリンクの目的を説明するテキストを含むときは、空の alt 属性を使用する。リンクテキストはページ上で画像の隣りに表示されることに注意する。

コード例:

<a href="routes.html">
  <img src="topo.gif" alt="" />
  Current routes at Boulders Climbing Gym
</a>

事例 4

サイトでは、製品の詳細ページの「Feedback」リンクをクリックすることで、利用者がログインしたときに製品に関するフィードバックを提供することができる。他の利用者又は製品メーカーは、フィードバックに応答することができる。フィードバックのリンクは、利用者のフィードバックへの応答が利用可能な場合に、「Feedback」テキストの前にアイコンを表示する。ヘルプ情報は、このアイコンを二重引用符を含む吹き出しとして説明し、アイコン自体を例として示している。 ヘルプテキストにおけるアイコンのテキストによる代替は、「応答受信アイコン」である。複数のモダリティを使用してこのアイコンを識別できるように、製品の詳細ページ (応答が利用可能な場合) で同じテキストによる代替が使用される。

コード例:

<a href="prod_123_feedback.htm">Feedback 
         <img src="response.gif" width="15" height="15" alt="Response received icon" /></a>

事例 5

リンクはテキスト及びアイコンを含み、アイコンはリンク先についての追加情報を提供している。

コード例:

<a href="WMFP.pdf">
Woodend Music Festival Program
<img src="pdficon.gif" alt="PDF format"/>
</a>

訳注: WAIC では H30-5 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H30-5 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 6

MyCorp 社の年次レポートは企業のウェブサイト上から PDF ファイルとして入手でき、年次企業予算は Excel ファイルとして入手できる。

注記: 多くの利用者は、ファイルを開く際に新しいアプリケーションが開く場合は、あらかじめファイルの種類を知りたいので、このような追加情報を含めるのはしばしば便利であると考えられる。 ただし、この達成基準を満たすには必須ではない。

コード例:

<p>
<a href=”2009mycorp_report.pdf”>MyCorp 2009 Annual Report (pdf)</a><br />
<a href=”2009mycorp_budget.xls”>MyCorp 2009 Annual Budget (Excel)</a>
</p>

事例 7

HTML5 においてブロックレベル要素をリンクで囲む。

コード例:

<article>
<a href="news.html">
<h3>Budget Debate Continues in Parliament</h3>
<p class="subhead"><img class="alertimg" src="alerticon.png" alt="Breaking News" height="30" width="30">Members of Parliament continued vigorous debate on three challenging issues surrounding the upcoming year's budget.</p>
<p>Read more</p>
</a>
</article>

ブロックレベル要素をリンクで囲む実例を示す。

訳注: HTML5 ではブロックレベル要素は定義されていない。ブロックレベル要素 - HTML: HyperText Markup Language | MDN も参照のこと。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。HTML 5.1§4.7.5.1. Requirements for providing text to act as an alternative for images を代わりに参照できる。

検証

手順

この達成方法を使用したコンテンツのそれぞれのリンクに対して:

  1. テキスト又は非テキストコンテンツのテキストによる代替が a 要素に含まれている。

  2. img 要素だけが a 要素のコンテンツである場合、img 要素のテキストによる代替がリンクの目的を説明している。

  3. a 要素が一つ以上の img 要素を含み、かつ img 要素のテキストによる代替が空の場合、リンクのテキストがリンクの目的を説明していることを確認する。

  4. a 要素がテキストのみを含んでいる場合、そのテキストがリンクの目的を説明していることを確認する。

期待される結果

  • 上記の全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H32: 送信ボタンを提供する

適用 (対象)

フォームのコントロールを含むコンテンツ

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、利用者がコンテキストの変化を明示的に要求できるメカニズムを提供することである。送信ボタンの使用目的は、フォームに入力されたデータを送信する HTTP リクエストを生成することであるため、コンテキストの変化を起こすために使うものとして適切なコントロールである。

訳注: WAIC では H32 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H32 も参照されたい。

事例

事例 1

これは送信ボタンを持つフォームの基本的な事例である。

コード例:


<form action="http://www.example.com/cgi/subscribe/" method="post"><br /> 
 <p>Enter your e-mail address to subscribe to our mailing list.</p><br /> 
 <label for="address">Enter email address:</label><input type="text" 
 id="address" name="address" /> 
 <input type="submit" value="Subscribe" /><br /> 
</form>

事例 2

次の事例では、利用者が要求したページを転送する (action 属性により指定された) サーバーサイドスクリプトを使用している。

コード例:

 <form action="http://www.example.com/cgi/redirect/" method="get"><br /> 
    <p>Navigate the site.</p><br /> 
    <select name="dest"><br /> 
      <option value="/index.html">Home</option/><br /> 
      <option value="/blog/index.html">My blog</option/><br /> 
      <option value="/tutorials/index.html">Tutorials</option/><br /> 
      <option value="/search.html">Search</option/><br /> 
    </select><br /> 
  <input type="submit" value="Go to Page" /><br /> 
  </form> 

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. コンテンツ内の全てのフォームを見つける。

  2. それぞれのフォームに、送信ボタン (input type="submit"、input type="image" 又は button type="submit") があることを確認する。

期待される結果

  • 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H33: title 属性を用いて、リンクテキストを補足する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H33 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、リンクを説明する追加情報を提供するための、a 要素の title 属性の利用方法を示すことである。title 属性は、リンクの目的を明らかにしたり、詳しく説明したりするのに役立つ追加情報の指定に用いる。もし title 属性を通して提供する補足情報が、警告文のように利用者がリンクをたどる前に知っておくべき内容であれば、title 属性ではなくリンクテキストとして提供すべきである。

title 属性へのアクセス方法について、ユーザエージェントごとにサポートが大きく異なるため、コンテンツ制作者はこの達成方法を用いるときは注意を払うべきである。この理由から、コンテンツ制作者は達成方法 C7: リンクテキストの一部を非表示にするために、CSS を使用する (CSS) 又は H30: a 要素のリンクの目的を説明するリンクテキストを提供する (HTML) を利用することが望ましい。

訳注: HTML 5.2§3.2.5.1. The title attribute の Warning で述べられているように、多くのユーザエージェントではアクセシブルな形でこの属性を公開しないので、title 属性に依存することを勧めていない。

訳注: WAIC では H33 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H33 も参照されたい。

事例

事例 1: リンクの目的を明らかにする

コード例:

<a href="http://example.com/WORLD/africa/kenya.elephants.ap/index.html" 
   title="Read more about failed elephant evacuation">
   Evacuation Crumbles Under Jumbo load
</a>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

a 要素のソースコードについて、次のことを調べる。

  1. title 属性のある a 要素では、リンクテキストの文言とともに title 属性がそのリンクの目的を示していることを確認する。

期待される結果

  • 1.の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H34: インラインでテキストの方向を混在させるために、Unicode の right-to-left mark (RLM) 又は left-to-right mark (LRM) を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、HTML の双方向性アルゴリズムが望ましくない結果を生じるとき時に、それを無効にするために Unicode 制御文字の right-to-left mark と left-to-right mark を用いることである。たとえば、スペース又は句読点のようなニュートラルな文字が異なる方向性のテキストの間に置かれている時に必要となることがある。この達成方法で用いられているコンセプトは、W3C 文書の「What you need to know about the bidi algorithm and inline markup」に書かれている。

訳注: 上記の「What you need to know about the bidi algorithm and inline markup」は、「Inline markup and bidirectional text in HTML」とタイトルが変更されている。また、Unicode controls vs. markup for bidi support によれば、Unicode の right-to-left mark (RLM) 又は left-to-right mark (LRM) よりも、dir 属性による書字方向の制御が勧められている。H56: 入れ子になったテキストの表記方向に伴う問題を解決するために、インライン要素の dir 属性を使用する (HTML) も参照のこと。

Unicode 制御文字の right-to-left mark 及び left-to-right mark は、以下に示すように、 そのまま、又は文字符号か数字符号の参照によって挿入することが可能である。

  • left-to-right mark (LRM): &lrm; 又は &#x200e; (U+200E)

  • right-to-left mark (RLM): &rlm; 又は &#x200f; (U+200F)

双方向性のアルゴリズムが原因で、ソースコード編集者は期待通りに文字符号や数字符号の参照を表示できないことがある。

事例

事例 1

この事例では、英語の文章の間にあるアラビア語のフレーズを示している。感嘆符はアラビア語のフレーズの一部であり、その左側にあるべきである。それはアラビア文字とラテン文字の間であり、段落全体の方向が LTR (左から右) であるため、双方向性のアルゴリズムはアラビア語のフレーズの右側に感嘆符を置いている。

The title is "مفتاح معايير الويب!" in Arabic.

視覚的に並び替えられた ASCII バージョン (右から左へのテキストは大文字、左から右は小文字):

the title is "HCTIWS SDRADNATS BEW!" in arabic.

表示されたテキスト (以下を参照) を見るとき、感嘆符の直後に Unicode の right-to-left mark を 挿入することによって、感嘆符を正しい位置に置くことになる。right-to-left mark を挿入するために、エスケープ文字又は (不可視の) 制御文字を使用することができる。

The title is "مفتاح معايير الويب!‏" in Arabic.

視覚的に並び替えられた ASCII バージョン:

the title is "!HCTIWS SDRADNATS BEW" in arabic.

参考リソース

検証

手順

  1. テキストの方向が変わっている箇所のソースを調べる。

  2. テキストの方向が変わる時、スペース又は句読点のようなニュートラルな文字が初期設定ではない方向でレンダリングされたテキストに隣接しているかどうかを確認する。

  3. 上記 2. が真であり、かつ HTML の双方向性のアルゴリズムがニュートラルな文字の誤った配列を生み出している場合、ニュートラルな文字の後に Unicode の right-to-left 又は left-to-right mark があり、ニュートラルな文字を前の文字列の一部として配置させているかどうかを確認する。

期待される結果

  • 3. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H35: applet 要素にテキストによる代替を提供する

適用 (対象)

applet 要素が非推奨ではない場合に、Java アプレットを読み込んでいる HTML 及び XHTML ドキュメント

訳注: applet 要素は、仕様では廃止された要素であり、さらに多くのモダンブラウザでは廃止された機能でもある。詳細については、MDN の applet 要素を参照されたい。また、Oracle 社の Oracle Java SE サポート・ロードマップによれば、Java Plugin のサポートは 2019 年 3 月までと告知されていることに注意されたい。

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H35 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、アプレットのラベルを提供する alt 属性を用いること及び applet 要素のボディにテキストによる代替を提供することによって、アプレットに対するテキストによる代替を提供することである。この達成方法では、ユーザエージェントごとに、alt 属性及び applet 要素のボディのサポート状況が異なるため、両方のメカニズムを必要としている。

訳注: WAIC では H35 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H35 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例

事例 1: 三目並べゲームのアプレット

コード例:

<applet code="tictactoe.class" width="250" height="250" alt="tic-tac-toe game">
   tic-tac-toe game
</applet>  

検証

手順

  1. applet 要素のソースコードを見る

  2. アプレットに対するテキストによる代替が applet 要素の alt 属性にあることを確認する

  3. アプレットに対するテキストによる代替が applet 要素のボディの中にあることを確認する。

期待される結果

  • 2. 及び 3. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H36: 送信ボタンとして用いる画像の alt 属性を使用する

適用 (対象)

画像の送信/実行ボタンを使用するコンテンツに適用する。

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、type 属性が「image」である input 要素において、input 要素の alt 属性を機能的なラベルを提供するのに使用することである。このラベルは、画像の説明をするのではなく、ボタンの機能を説明する。もしそのページに、それぞれ異なる結果につながる複数の送信/実行ボタンがあるならば、ラベルは特に重要である。

input 要素は、多くの種類のフォームのコントロールを作成するのに使用される。HTML 及び XHTML の DTD では、これら全てで alt 属性を用いることができるが、本来は画像の送信/実行ボタンだけに使用すべきである。ユーザエージェントでは、他の種類のフォームのコントロールでの alt 属性の使用をサポートしていないため、これらのコントロールをラベル付けするために他のメカニズムを用いている。

訳注: WAIC では H36 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H36 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

訳注: WAIC では H36 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H36 も参照されたい。

事例

事例 1

alt 属性がある input 要素

コード例:

<form action="http://example.com/prog/text-read" method="post">
  <input type="image" name="submit" src="button.gif" alt="Submit" />
</form>    

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. type 属性の値が "image" であるすべての input 要素に、alt 属性があることを確認する。

  2. その alt 属性がボタンの機能を説明していることを確認する。

期待される結果

  • 1. 及び 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H37: img 要素の alt 属性を使用する

適用 (対象)

HTML ドキュメントで用いられている画像

これは、次の達成基準に関連する達成方法である:

解説

img 要素を使用するときは、簡潔なテキストによる代替を alt 属性に指定する。注記: この属性の値は「ALT テキスト」ともいう。

画像がコンテンツを理解するために重要な文字を含むとき、代替テキストにはそれらの文字を含めなくてはならない。これにより、代替テキストはページ上で画像と同じ役割を果たすことができる。 代替テキストは、画像自体の視覚的な特徴を説明する必要はないが、画像と同じ意味を伝えなければらないことに注意する。

訳注: WAIC では H37 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H37 も参照されたい。

事例

事例 1

ウェブサイト上にある画像は、無料のニュースレターへのリンクである。画像はテキスト「Free newsletter. Get free recipes, news, and more. Learn more.」を含んでいる。画像の代替テキストは、画像にあるテキストと一致している。

コード例:

<img src="newsletter.gif" alt="Free newsletter. 
   Get free recipes, news, and more. Learn more." />

訳注: WAIC では H37-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H37-1 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 2

ウェブサイト上にある画像は、ビルの間取り図を表現している。その画像は、各部屋の部分がインタラクティブに操作できるイメージマップである。代替テキストは「ビルの間取り図。各部屋の目的又は内容に関する詳しい情報は、部屋を選択してください」である。「部屋を選択してください」という指示により、画像がインタラクティブであることを示している。

訳注: WAIC では H37-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H37-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

HTML 4.01 IMG element

HTML 4.01 alt attribute

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.1§4.7.5. The img element 及び HTML 5.1§4.7.5.1. Requirements for providing text to act as an alternative for images を代わりに参照できる。

検証

手順

  1. コンテンツに含まれる img 要素それぞれを調べる。

  2. 意味を伝える img 要素それぞれが、alt 属性を含んでいることを確認する。

  3. 画像にコンテンツを理解するために重要な単語が含まれている場合、その単語がテキストによる代替に記述されていることを確認する。

期待される結果

2. 及び 3. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H39: データテーブルのキャプションとデータテーブルを関連付けるために、caption 要素を使用する

適用 (対象)

HTML 及び XHTML のデータテーブル

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、提示でテーブルの表題を付ける場合に、プログラムで解釈できるようにデータテーブルと表題を関連付けることである。表題はテーブルの識別子であり、タイトル又は見出しのような働きをする。

caption 要素は表題のテキストのための適切なマークアップであり、(初期状態では) 表示上も、テーブルの識別子がそのテーブルに関連付けられていることを保証するものである。さらに、caption 要素を用いることによって、音声読み上げソフトウェアがテーブルの表題に利用者を直接誘導することも可能になる。

caption 要素は、テーブルに summary 属性を指定しているかどうかに関わらず利用できる。caption 要素はテーブルを特定するもの、summary 属性はテーブルの概要を提供したり、見方を説明したりするものである。両方とも指定する場合、summary 属性に caption 要素と同じ情報を含めるべきではない。

注記: WCAG 2.0 はレイアウトテーブルの利用を禁止していないが、CSS ベースのレイアウトを推奨している。HTML 及び XHTML の table 要素に与えられたセマンティックな意義を守り、コンテンツから提示を分離するというコーディングの実践に沿うためである。テーブルをレイアウトのために利用する場合、caption 要素は使用しない。レイアウトテーブルの目的は、コンテンツの配置を制御することのみであって、テーブルそのものは利用者から見て「透明」であるべきである。caption 要素を用いることによってテーブルの存在を示してしまうと、この透明性を壊すことになる。F46: 達成基準 1.3.1 の失敗例 - レイアウトテーブルで、th 要素、caption 要素、又は空ではない summary 属性を使用しているを参照のこと。

訳注: WAIC では H39 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H39 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

訳注: WAIC では H39 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H39 も参照されたい。

事例

事例 1: スケジュールカレンダーの表題

コード例:

<table>
<caption>Schedule for the week of March 6</caption>
...</table> 

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.9.2. The caption elementを代わりに参照できる。

検証

手順

各データテーブルごとに:

  1. テーブルに caption 要素が含まれていることを確認する。

  2. caption 要素の内容がテーブルを識別していることを確認する。

期待される結果

  • 1. 及び 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H40: 記述リストを使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、名前または用語の説明を記述リストの形式で提供することである。リストは dl 要素を用いてマークアップし、その中では用語それぞれを個別の dt 要素に含め、直後の dd 要素に説明を含める。意味のある順序が確保されていれば、複数の用語を単一の説明に、単一の用語を複数の説明に関連付けることもできる。title 属性を用いて、記述リストに関する補足情報を提供することもできる。記述リストを使用することで、提示が変化しても、用語とその説明が一つの単位としてグループ化され、意味的な関連が保証される。

説明がアルファベット順に並べられている場合は、記述リストを使用するのが最も容易である。記述リストの一般的な使用法は用語集である。

注記: HTML5 では、「記述リスト」という名前が導入された。以前のバージョンでは、これらのリストは「定義リスト」と呼ばれていた。

事例

事例 1

海事用語の記述リストを、航海に関するウェブサイトで利用している。

コード例:

<dl title="Nautical terms">
  <dt>Knot</dt>
  <dd>
    <p>A <em>knot</em> is a unit of speed equaling 1 
      nautical mile per hour (1.15 miles per hour or 1.852 
      kilometers per hour).</p>
  </dd>
  <dt>Port</dt>
  <dd>
    <p><em>Port</em> is the nautical term (used on 
      boats and ships) that refers to the left side
      of a ship, as perceived by a person facing towards 
      the bow (the front of the vessel).</p>
  </dd>
  <dt>Starboard</dt>
  <dd>
    <p><em>Starboard</em> is the nautical term (used 
      on boats and ships) that refers to the right 
      side of a vessel, as perceived by a person 
      facing towards the bow (the front of the vessel).</p>
  </dd>
</dl>        

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

用語とそれに関する説明の組み合わせについて:

  1. そのリストが、dl 要素に含まれていることを確認する。

  2. リストの各用語が dt 要素内に含まれていることを確認する。

  3. 同じ説明を共有する複数の用語があるときに互いの dt 要素が連続することを確認する。

  4. 各用語に対する説明が一つ以上の dd 要素に含まれていることを確認する。

  5. 用語を含む一つ以上の dt 要素の直後に、一つ以上の dd 要素があることを確認する。

期待される結果

  • 上記の全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H42: 見出しを特定するために、h1 要素~ h6 要素を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この手法の目的は、HTML 及び XHTML の見出しマークアップを用いて、コンテンツの見出しにセマンティックなコードを提供することである。見出しマークアップは、支援技術がテキストの見出し状態を利用者に提示することを可能にする。スクリーンリーダーは、コードを認識し、そのレベル、ビープ音、又は他の聴覚インジケーターを備えた見出しとしてテキストをアナウンスすることができる。スクリーンリーダーはまた、見出しマークアップをナビゲートすることもできる。これは、スクリーンリーダー利用者が関心のあるコンテンツをより迅速に見つけるための効果的な方法である。オーサリングされた視覚表示を変更する支援技術はまた、見出しマークアップで識別できる見出しのための適切な代替視覚表示を提供することもできる。

訳注: WAIC では H42 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H42 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例

事例 1: 階層的な見出し構造

以下の事例では、h3h2 のサブセクションで、h2h1 のサブセクションとなっていて、見出しが階層的なレイアウトに用いられている。

訳注: MDN の <h1>–<h6>: HTML の見出し要素 - アクセシビリティへの配慮で言及されているように、見出しレベルを飛ばしてページを作成する (例えば、h1 要素の次に h3 要素を置く) と、スクリーンリーダーの利用者がそのページの見出しをナビゲートするときに、ページには存在しない h2 要素を誤って飛ばしてしまったのではないかと誤解する恐れがあることに注意する。

コード例:

<h1>Plant Foods that Humans Eat</h1>
<p>There are an abundant number of plants that humans eat...</p>
<h2>Fruit</h2>
<p> A fruit is a structure of a plant that contains its
  seeds...</p>
<h3>Apple</h3>
<p>The apple is the pomaceous fruit of the apple tree...</p>
<h3>Orange</h3>
<p>The orange is a hybrid of ancient cultivated origin...</p>
<h3>Banana</h3>
<p>Banana is the common name for herbaceous plants ...</p>
<h2>Vegetables</h2>
<p>A vegetable is an edible plant or part of a plant other than a
  sweet fruit ...</p>
<h3>Broccoli</h3>
<p>Broccoli is a plant of the mustard/cabbage family ... </p>
<h3>Brussels sprouts</h3>
<p>The Brussels sprout of the Brassicaceae family, is a Cultivar
  group of wild cabbage ...</p>
<h3>Green beans</h3>
<p>Green beans have been bred for the fleshiness, flavor, or
  sweetness of their pods...</p> 

事例 2: 3段組レイアウトの見出し設定

この事例では、3 段組の真ん中にページのメインコンテンツがある。メインコンテンツは、ページ内で最初のコンテンツではないが、そのタイトルはページタイトルと同じで、h1 要素でマークアップされている。1 列目と 3 列目のコンテンツはそれほど重要ではなく、h2 でマークアップされている。

注記: 以下のコード例は、ウェブページの特定のセクションに対して用いるべき見出しレベルを規定するものではないことに留意することが重要である。レイアウトする際には、各カラムの最初に見出しを同じ見出しレベル (例えば、h1) で提示したり、またはコード例にあるようにメインコンテンツに関してその重要度を反映した見出しレベルで提示したりすることが可能である。

訳注: WAIC では H42 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H42 も参照されたい。

コード例:

<head>
 <title>Stock Market Up Today</title>
 </head>
 <body>
 <!-- left nav -->
 <div class="left-nav">
 <h2>Site Navigation</h2>
 <!-- content here -->
 </div>
 <!-- main contents -->
 <div class="main">
 <h1>Stock Market up today</h1>
 <!-- article text here -->
 </div>
 <!-- right panel -->
 <div class="left-nav">
 <h2>Related links</h2>
 <!-- content here -->
 </div>
 </body>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. コンテンツが見出しであるときに、見出しマークアップを利用している。

  2. コンテンツが見出しでないときは、見出しマークアップを利用していない。

期待される結果

  • 1. 及び 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H43: データテーブルのデータセルを見出しセルと関連付けるために、id 属性及び headers 属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、(データテーブル内の) 各データセルを適切な見出しセルと関連付けることである。まず、各データセル (td 要素) に headers 属性を付加する。次に、データセルの見出しとなるセルには id 属性を指定する。データセルの headers 属性で指定するのは、関連付けられる見出しセルの id 属性値であり、二つ以上の id を含める場合はスペース区切りで列挙する。

この達成方法は、データセルを二つ以上の行見出し及び/又は列見出しに関連付ける場合に利用する。こうすることで、th 要素のみ、または th 要素に scope 属性を付けただけでは、データセルと見出しセルの関係が複雑すぎて定義できない場合でも、スクリーンリーダーは各データセルと関連付けられている見出しセルを読み上げることができる。また、提示形式が変わったとしても、これらの複雑な関係を知覚しやすくなる。

この達成方法を、レイアウトテーブルに利用することは推奨しない。なぜなら、レイアウトのためにテーブルを利用する際には、意味がないにも関らず何らかの関係性を示してしまうことになるからである。

訳注: WAIC では H43 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H43 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

訳注: WAIC では H43 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H43 も参照されたい。

事例

事例 1: 行見出しが複数あるテーブル

コード例:

<table>
   <tr>
     <th rowspan="2" id="h">Homework</th>
     <th colspan="3" id="e">Exams</th>
     <th colspan="3" id="p">Projects</th>
   </tr>
   <tr>
     <th id="e1" headers="e">1</th>
     <th id="e2" headers="e">2</th>
     <th id="ef" headers="e">Final</th>
     <th id="p1" headers="p">1</th>
     <th id="p2" headers="p">2</th>
     <th id="pf" headers="p">Final</th>
   </tr>
   <tr>
    <td headers="h">15%</td>
    <td headers="e e1">15%</td>
    <td headers="e e2">15%</td>
    <td headers="e ef">20%</td>
    <td headers="p p1">10%</td>
    <td headers="p p2">10%</td>
    <td headers="p pf">15%</td>
   </tr>
  </table>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.9.10. The th element を代わりに参照できる。

検証

手順

  1. レイアウトテーブルを確認する: 内容が同じ行と列の両方に含まれる他のセルの内容と関係があるかどうか判断する。「いいえ」の場合、そのテーブルはレイアウトテーブルである。「はい」の場合、そのテーブルはデータテーブルである。

  2. データテーブルに対しては、二つ以上の行見出し及び/又は列見出しと関連付けられているあらゆるセルが、そのセルに関連付けられている全ての見出しの id を指定している headers 属性を含むことを確認する。

  3. あらゆるセルに id 属性又は headers 属性が含まれるデータテーブルの場合:

    1. データセルの headers 属性で指定した各 id が、見出し要素の id 属性値と一致していることを確認する。

    2. データセルの headers 属性が、そのデータセルと関連付けられた全ての見出しの id 属性値を含んでいることを確認する。

    3. 全ての id が一意であることを確認する (つまり、ページの中で二つ以上の要素が同じ id を持つことはできない)。

期待される結果

  • テーブルがレイアウトテーブルの場合、どのセルにも headers 属性又は id 属性がない。

  • テーブルがデータテーブルで、かつセルが id 属性を含む場合、3.a、3.b、及び 3.c の結果が真である。

  • テーブルがデータテーブルで、かつ二つ以上の行見出し及び/又は列見出しと関連付けられた全てのセルについて、2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H44: テキストラベルとフォームコントロールを関連付けるために、label 要素を使用する

適用 (対象)

ラベルを用いている HTML 及び XHTML のフォームコントロール

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H44 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、フォームコントロールとラベルを明示的に関連付けるために、label 要素を利用することである。ラベルは、label 要素の for 属性によって特定のフォームコントロールと結びつけることができる。この場合、for 属性値はフォームコントロールの id 属性値と同じでなければならない。

id 属性が name 属性と同じ値で、両方とも指定しなければならない場合でも、その id はそのウェブページ内で一意的なものとして、重複して使用してはならない。

この達成方法は、label 要素が見えているかどうか、つまり CSS で非表示にしているかどうかに関わらず、達成基準 1.1.1、1.3.1、4.1.2 を満たすことができる。しかし、達成基準 3.3.2 の場合、label 要素は、フィールドの目的を理解するのに助けが必要であるすべての人に支援を提供するため、表示しなければならない。

ラベルまたはコントロールをクリックするとコントロールがアクティブなるため、コントロールのクリック可能な領域を大きくすることは、この達成方法の更なるメリットである。これは運動制御が不十分な利用者に役立つ。

input 要素の type="checkbox"type="radio" では、label 要素をその後に配置することに注意する。

注記 1: 明示的なラベルを利用する要素は次の通りである:

  • input type="text"

  • input type="checkbox"

  • input type="radio"

  • input type="file"

  • input type="password"

  • textarea

  • select

注記 2: 次の場合には、label 要素は利用しない。これらの要素に対するラベルは、value 属性 (送信ボタン及びリセットボタン)、alt 属性 (画像ボタン)、又は要素それ自体の内容 (汎用ボタン) を介して提供されるからである。

  • 送信及びリセットボタン (input type="submit" 又は input type="reset")

  • 画像ボタン (input type="image")

  • 隠しフィールド (input type="hidden")

  • スクリプトボタン (button 要素又は input type="button")

訳注: WAIC では H44 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H44 も参照されたい。

事例

事例 1: テキスト入力フィールド

この事例では、テキスト入力フィールドに「First name:」という明示的なラベルが付けてある。label 要素の for 属性値は、input 要素の id 属性値と一致している。

コード例:

<label for="firstname">First name:</label> 
<input type="text" name="firstname" id="firstname" />

事例 2: チェックボックス

コード例:

<input type="checkbox" id="markuplang" name="computerskills" checked="checked">
<label for="markuplang">HTML</label>

事例 3: ラジオボタンのグループ

関連するラジオボタンの小さなグループについて、簡単な説明が付けてあり、さらに個々の要素にラベルが付けてある。

ラジオボタンの数が多く、それらの関連付けや操作説明を必要とする場合は、H71: fieldset 要素及び legend 要素を使用して、フォームコントロールのグループに関する説明を提供するの方法を考慮すべきである。

コード例:

 <h1>Donut Selection</h1>
<p>Choose the type of donut(s) you would like then select 
   the "purchase donuts" button.</p>
<form action="http://example.com/donut" method="post">
<p>
  <input type="radio" name="flavor" id="choc" value="chocolate" />
    <label for="choc">Chocolate</label><br/>
  <input type="radio" name="flavor" id="cream" value="cream"/>
    <label for="cream">Cream Filled</label><br/>
  <input type="radio" name="flavor" id="honey" value="honey"/>
    <label for="honey">Honey Glazed</label><br/>
  <input type="submit" value="Purchase Donuts"/>
</p>
</form>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.10.4. The label element を代わりに参照できる。

検証

手順

ウェブページ内の type="text"type="file"、又は type="password" を指定した input 要素、textarea 要素、及び select 要素全てについて:

  1. input 要素、textarea 要素又は select 要素の前に、そのコントロールの目的を特定できる label 要素があることを確認する。

  2. label 要素の for 属性が、input 要素、textarea 要素又は select 要素の id と一致している。

  3. label 要素のラベルが表示されていることを確認する。

ウェブページ内の type="checkbox" 及び type="radio" を指定した input 要素全てについて:

  1. input 要素の後に、そのコントロールの目的を特定する label 要素があることを確認する。

  2. label 要素の for 属性が、input 要素の id 属性と一致していることを確認する。

  3. label 要素のラベルが表示されていることを確認する。

期待される結果

  • 1. 及び 2. の結果が真である。達成基準 3.3.2 に関しては、3. の結果も真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H45: longdesc 属性を用いる

適用 (対象)

短いテキストによる代替では説明しきれない画像を含む HTML 及び XHTML 文書

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H45 に関するユーザエージェントサポートノートを参照のこと。

解説

訳注: WAIC では H45 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H45 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

訳注: WAIC では H45 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H45 も参照されたい。

この達成方法の目的は、短いテキストによる代替では画像の機能や情報が十分に伝達できない場合に、longdesc 属性でのファイル指定によって情報を提供することである。longdesc 属性には URI を指定する。これは非テキストコンテンツの詳しい説明を含む目的地を意味する。

制作者は、テキストを別のリソースまたはページ上の画像にテキストを含めることで、画像の説明を提供できる。別のリソースを用いて説明することの利点は、同じ画像を複数の箇所で簡単に再利用できることにあり、元となるドキュメントにページ上の視覚的なノイズを加えず、説明の最終点を利用者に明確にすることにある。画像と同じページに説明を提供する利点は、すべての利用者が説明にアクセスできることにある。ページ上のメソッドの制限は、複数の説明を単一の別ページに提供することと同様に、現在の longdesc 属性の実装サポートでは、長い説明文の最終点を識別できないということである。制作者はどこで説明文が終わるかを識別する定型文を提供することによって解決ができる。

事例

事例 1: longdesc 属性を用いて別のリソースに含まれた長い説明文を参照する。

コード例:

<p><img src="chart.gif" alt="a complex chart" longdesc="chartdesc.html"/></p>

事例 2: longdesc 属性を用いて同じページに含まれた長い説明文を参照する。

コード例:

<img longdesc="thispage.html#desc" alt="Line graph of the number of subscribers" src="http://www.company/images/graph.png">
<div id="desc">
<h3>Long Description: Line graph of the number of subscribers</h3>
<!-- すべてのグラフ説明文 -->
<p>Long description ends.</p>
<div>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. longdesc 属性を指定した img 要素があることを確認する。

  2. longdesc 属性の値が、存在するリソースの有効な URI であることを確認する。

  3. その URI で指定されたコンテンツには、関連付けられたオリジナルの非テキストコンテンツの詳しい説明が含まれていることを確認する。

期待される結果

  • 1. から 3. の全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H46: embed 要素と一緒に noembed 要素を用いる

適用 (対象)

embed 要素でプラグインを読み込むドキュメント

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H46 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、embed 要素の代替コンテンツとして noembed を提供することである。noembed 要素は embed 要素がサポートされていない場合のみレンダリングされる。ページのどこにでも配置できるが、embed 要素の子要素として組み込む方が良い。これによりテキストによる代替が embed 要素に関連付けられてことが支援技術にも明らかになる。

訳注: noembed 要素は、以前の HTML のバージョンで標準として定義されておらず、HTML5 で改めて廃止された要素として定義された。MDN の noembed 要素 によれば、新規のサイトではこの要素を使用せず、代わりに object 要素の内容として記述するように勧められている。H53: object 要素のボディを使用する (HTML) も参照のこと。

事例

事例 1: noembed 要素が embed 要素の内側にある

コード例:

<embed src="../movies/history_of_rome.mov"
  height="60" width="144" autostart="false">
  <noembed>
    <a href="../transcripts/transcript_history_rome.htm">Transcript of "The history of Rome"</a>
  </noembed>
</embed>

事例 2: noembed 要素が embed 要素のそばにある

コード例:

<embed src="moviename.swf" width="100" height="80"
  pluginspage="http://example.com/shockwave/download/" />
<noembed>
  <img alt="Still from Movie" src="moviename.gif" 
    width="100" height="80" />
</noembed>;

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

手順

  1. embed 要素に子 noembed 要素があるかどうかを確認する

  2. embed 要素の直下に noembed 要素があるかどうかを確認する

期待される結果

  • 1. 又は 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H48: リスト又はリンクのグループに、ol 要素、ul 要素、dl 要素を用いる

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H48 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、リスト要素を役割に合わせて適切に利用し、関連する項目のリストを生成することである。ol 要素は順序のあるリストに、ul 要素は順序のないリストに利用する。定義リスト (dl 要素) は、用語とその定義をまとめるのに利用する。このようなマークアップを用いることで、リストを読みやすくできるとはいえ、すべてのリストをリスト要素でマークアップする必要はない。たとえば、文章に含まれるカンマ区切りのリストを、リスト要素でマークアップする必要はない。

リストの関係を示すためではなく、見た目をリストのようにしたいためにマークアップを用いることで、利用者が情報を利用しにくくなる恐れがある。リストのような見た目にする例としては、リスト項目の最初にアスタリスクを付け、br 要素を用いて各リスト項目を分けるといったことが挙げられる。

支援技術の中には、利用者をリストからリストへ、またはリスト項目からリスト項目へと誘導する機能を備えているものがある。スタイルシートを利用すれば、リストという役割の整合性を保ったまま、提示を変更することができる。

リスト構造 (ul / ol) はハイパーリンクをグループ化するのにも役立つ。これが完了すると、スクリーンリーダーがリストの最初の項目からリストの最後までナビゲートする、または次のリストにジャンプするのに役立つ。 この選択により、リンクグループをバイパス化することができる。

訳注: WAIC では H48 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H48 も参照されたい。

事例

事例 1: 連続するステップを示すリスト

この事例では、プロセスの連続するステップを示すために順序リスト (ol 要素) を利用している。

コード例:

 <ol>
  <li>Mix eggs and milk in a bowl.</li>
  <li>Add salt and pepper.</li>
</ol>

訳注: WAIC では H48-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H48-1 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 2: 材料のリスト

この事例では、お店で購入する品目を順不同リスト (ul 要素) で示している。

コード例:

<ul>
  <li>Milk</li>
  <li>Eggs</li>
  <li>Butter</li>
</ul>

訳注: WAIC では H48-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H48-2 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 3: 言葉とその定義

この事例では、用語とそれを明確にする定義をまとめるのに定義リスト (dl 要素) を利用している。

コード例:

<dl>
  <dt>blink</dt>
  <dd>turn on and off between .5 and 3 times per second
  </dd>
</dl> 

訳注: WAIC では H48-3 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H48-3 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 4: 定義リストを用いた連絡先情報

この事例では、定義リストを用いて、対になる関連するアイテムをマークアップしている。対になっているアイテムは、それ自体が論理的に関連したリストである。定義リスト要素の CSS スタイルはブラウザによるサポートが十分ではないため、スタイル目的のためだけに span 要素がマークアップに含められているが、これは必須ではない。

<dl>
<dt><span>name:</span></dt><dd><span>John Doe</span></dd>
<dt><span>tel:</span></dt><dd><span>01-2345678</span></dd>
<dt><span>fax:</span></dt><dd><span>02-3456789</span></dd>
<dt><span>email:</span></dt><dd><span>johndoe@someemail.com</span></dd>
</dl>

以下の CSS スタイルは、対になっているアイテムそれぞれをテーブルのようなレイアウトにして 1 行に並べるために用いることが可能である。

dt, dd{float: left;margin: 0;padding: 0;}
dt{clear:both;font-weight: bold}
dt span{display: inline-block; width: 70px;}
dd span{display: inline-block; margin-right: 5px;} 

この事例のサンプルとして、定義リストを用いた連絡先情報のサンプルがある。

事例 5: リストを用いてリンクをグループ化する

この事例では、リンクが ul 要素と li 要素を用いてグループ化されている。

コード例:

<a name="categories" id="categories"></a><h2>Product Categories</h2>
<ul class="navigation">
    <li><a href="kitchen.html">Kitchen</a></li>
    <li><a href="bedbath.html">Bed &amp; Bath</a></li>
    <li><a href="dining.html">Fine Dining</a></li>
    <li><a href="lighting.html">Lighting</a></li>
    <li><a href="storage.html">Storage</a><li>
</ul> 

リスト要素のスタイルを指定するのに CSS を使用することが可能で、この達成方法はさまざまなビジュアルデザインで用いることができる。

この CSS では、リストのビュレットとインデントする左側の余白を削除して、各リスト要素を水平に並べている。

コード例:

ul.navigation {
  list-style: none; 
  padding: 0;
}
ul.navigation li {
  display: inline;
}

このスタイルは、リストのビュレットと左側の余白を削除し、リスト項目を横並びのブロックにして表示する。

コード例:

ul.navigation {
 list-style: none; 
 padding: 0;
}
ul.navigation li {
 display: block; 
 float: left;
} 

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2: 4.4. Grouping content を代わりに参照できる。

検証

手順

  1. リストの視覚表現 (ビュレットがあるかどうかに関わらず) を含んだコンテンツが、順序なしリストとしてマークアップされている。

  2. 番号の付いたリストの視覚表現を含んだコンテンツが、順序付きリストとしてマークアップされている。

  3. 用語及びその定義をリストという形式で表現する場合、そのコンテンツが定義リストとしてマークアップされていることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H49: 強調又は特別なテキストをマークアップするために、セマンティックなマークアップを使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H49 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、プログラムによる解釈が可能にするために、セマンティックマークアップを使用して強調又は特別なテキストをマークアップする方法を示すことである。強調又は特別なテキストをマークアップするためにセマンティックなマークアップを用いることで、その文書に構造を与えることもできる。そうすることで、例えば、ユーザエージェントは、異なるタイプの構造に対して異なる視覚的提示を用いたり、聴覚的提示で異なる声又はピッチを用いたりすることによって、構造を利用者に知覚可能にすることができる。

大部分のユーザエージェントは、セマンティックなマークアップによって特定されたテキストを、ほかとは別の見た目にする。支援技術の中には、セマンティックなマークアップを適切に用いることで、コンテンツの特性を決定するためのメカニズムを提供するものもある。

訳注: WAIC では H49 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H49 も参照されたい。

事例

セマンティックなテキストのレンダリング例を参照。

事例 1

この事例では、テキストの強調に em 要素と strong 要素を利用する方法を示している。em 要素と strong 要素は、構造的な強調を示すのに用意されているものであり、さまざまな形式で描画されうる (フォントスタイルの変更、読み上げ時の抑揚の変更など)。

訳注: MDN の strong 要素で示されているように、古い HTML では strong 要素を単により強い強調としていたが、現在の HTML では strong を重要性を表すものと定義している。

コード例:

 ...What she <em>really</em> meant to say was, &quot;This is not ok, 
 it is <strong>excellent</strong>&quot;!... 

訳注: WAIC では H49-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H49-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2

この事例では、長い引用文をマークアップするのに blockquote 要素を利用している。blockquote 要素ではパラグラフ分けが必要となる場合もある。また、参考資料を示すのに cite 要素も利用している。

コード例:

<p>The following is an excerpt from the <cite>The Story of my Life</cite> by Helen Keller</p>
 <blockquote>
   <p>Even in the days before my teacher came, I used to feel along the square stiff boxwood
   hedges, and, guided by the sense of smell, would find the first violets and lilies.  
   There, too, after a fit of temper, I went to find comfort and to hide my hot face 
   in the cool leaves and grass.</p>
 </blockquote>

訳注: WAIC では H49-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H49-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3

この事例では、短い引用文のマークアップに q 要素を利用している。q 要素を引用符で囲んであるのは、ユーザエージェントの多くがいまだにこの要素をサポートせず、適切に表示しないからである (前述「ユーザエージェント及び支援技術によるサポート」を参照)。引用符の自動生成を抑制するための CSS 規則は、コンテンツ制作者によって提供される引用符に加えて自動的に引用符を生成しないようにして、二重に引用符で囲まれた内容となるのを防ぐために、q 要素をサポートするユーザエージェントに対して提供される。将来、q 要素が広くサポートされるようになれば、引用符を付けたり、ブラウザの引用符生成を避けたりする必要はなくなるだろう。

訳注: MDN の q 要素で示されているように、今日のモダンなブラウザでは、q 要素の周りに自動的に引用符を追加する。

コード例:

q:before { content: ""; } 
q:after { content: ""; }  

コード例:

 <p>Helen Keller said, "<q>Self-pity is our worst enemy and if we yield to it, 
we can never do anything good in the world.</q>"</p>

訳注: WAIC では H49-3 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H49-3 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 4

上付き文字と下付き文字を、sup 要素と sub 要素を使って生成している。

コード例:

 <p>Beth received 1<sup>st</sup> place in the 9<sup>th</sup> grade science competition.</p>
<p>The chemical notation for water is H<sub>2</sub>O.</p>

訳注: WAIC では H49-4 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H49-4 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. テキストの提示のバリエーションを通して伝えられる情報に関するコンテンツを調べる。

  2. 適切なセマンティックマークアップ (emstrongciteblockquotequotesub など) が、テキストの変化を通じて情報を伝達するテキストをマークアップに用いられていることを確認する。

期待される結果

  • 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H51: 表形式の情報を提示するために、テーブルのマークアップを使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、利用者がテーブルを見ることができない場合、又は提示形式が変更された場合でも、含まれる情報の関係を保てる方法で、表の情報を提示することである。情報を表として提示すべきと考えられるのは、テキスト、数値、画像、あるいは他のデータの論理関係が (垂直及び水平に) 2 次元で存在するときである。論理関係は列と行で示され、列と行は論理関係が認識できる状態でなければならない。

table 要素は、子要素 trthtd といっしょに用いることで、論理関係を認識可能にする。一方、列を整形するのにタブを入れたり、pre 要素を利用するのは、純粋に見た目だけを考えた方法である。利用者がテーブルを見ることができない場合、又は提示形式が変更された場合は、視覚的に暗に示された論理関係は失われてしまう。

単純な表は一般的に列に対して一つのレベルの見出し、及び/又は行に対して一つのレベルの見出しがある。

通常、単純な表では、1 行目の 1 列目は空白または列全体の内容を 1 列目に記述する。1 行目の 1 列目は空白がなく (つまり、"列見出し"を含む)、列全体の内容を記述しており、読者は列と列の間の異なる意味を区別できる。

1 列目の行は、通常では空白ではなく、行全体の内容を記述した"行見出し"を含んでることが多い。読者は行と行の間の異なる意味を区別できる。その他に、1 列目は単純なデータが含まれる。

訳注: WAIC では H51 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H51 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

訳注: WAIC では H51 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H51 も参照されたい。

事例

事例 1: 列見出しと行見出しが付いた簡単なデータテーブルとしてマークアップしたスケジュール表

この事例では、簡単なデータテーブルに table 要素を利用している。1 行目は曜日、1 列目は時間である。これらのセルは th 要素でマークアップしてあり、列見出しが曜日、行見出しが時間という役割になっている。

スクリーンリーダーは、利用者がテーブルを読み進めるとき、対応する見出し情報の変化を読み上げる。それゆえ、スクリーンリーダーの利用者が同じ行を左右に動くときは、(もしあれば) 予定に対応する曜日 (列見出し) の読み上げを、同じ列を上下に移動するときは、対応する時間の読み上げを聞くであろう。

コード例:

 <table>
  <tr>
    <td> </td>
    <th>Monday</th>
    <th>Tuesday</th>
    <th>Wednesday</th>
    <th>Thursday</th>
    <th>Friday</th>
  </tr>
  <tr>
    <th>8:00-9:00</th>
    <td>Meet with Sam</td>
    <td> </td>
    <td> </td>
    <td> </td>
    <td> </td>
  </tr>
  <tr>
    <th>9:00-10:00</th>
    <td> </td>
    <td> </td>
    <td>Doctor Williams</td>
    <td>Sam again</td>
    <td>Leave for San Antonio</td>
  </tr>
</table> 

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2: 4.9. Tabular dataを代わりに参照できる。

検証

手順

  1. 表形式の情報があることを確認する。

  2. 表形式の情報それぞれについて:

    1. 少なくとも tabletrth、及び td 要素をもつテーブルマークアップが使用されていることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H53: object 要素のボディを使用する

適用 (対象)

メディアを読み込む object 要素 (HTML 及び XHTML)

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H53 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、object 要素によってレンダリングされるコンテンツに対して、テキストによる代替を提供することである。object 要素のボディは、そのオブジェクトに関する完全なテキストによる代替を提供するのに用いられるか、または追加的な非テキストコンテンツをテキストによる代替とともに含むことがある。

object 要素のフォールバックコンテンツは、ユーザエージェントによってメディアに要素が読み込まれなかった場合、つまり、ユーザエージェントがメディアテクノロジーまたは利用者の指定によるレンダリングできない場合のみ使用可能である。その状況ではフォールバックコンテンツが利用者に提示される。もしメディアがフォールバックコンテンツなしにレンダリングされた場合、メディアは直接アクセスできることが不可欠である。制作者は、適合基準にメディア技術の直接アクセス可能性に頼っておらず、利用者がフォールバックにアクセスできることを予期できるのであれば、達成基準を満たすためにのみこの達成方法に頼ることができる。

事例

事例 1: 長めの説明を含んだオブジェクト

コード例:

 <object classid="http://www.example.com/analogclock.py">
  <p>Here is some text that describes the object and its operation.</p>
</object>

訳注: WAIC では H53-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H53-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: テキストによる代替のある非テキストコンテンツを含んだオブジェクト

コード例:

<object classid="http://www.example.com/animatedlogo.py">
  <img src="staticlogo.gif" alt="Company Name" />
</object>   
            

訳注: WAIC では H53-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H53-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3: 機能の簡単な説明を含んだ画像オブジェクト

コード例:

<object data="companylogo.gif" type="image/gif">
  <p>Company Name</p>
</object>

訳注: WAIC では H53-3 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H53-3 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

事例 4

この例は、情報の代替表現が提供するために object 要素がネストされている事実を利用している。

コード例:

<object classid="java:Press.class" width="500" height="500">
  <object data="Pressure.mpeg" type="video/mpeg">
    <object data="Pressure.gif" type="image/gif">
      As temperature increases, the molecules in the balloon...
    </object>
  </object>
</object>  

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. object 要素のボディに、そのオブジェクトのテキストによる代替があることを確認する。

期待される結果

  • 1. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H54: 単語の定義箇所を特定するために、dfn 要素を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、その語句の定義を伴って語句が用いられている箇所のマーク付けに dfn 要素を用いることである。dfn 要素は、囲んだ用語の定義対象であることを示すのに用いる。言い換えれば、その語句がその場所で定義されている場合に、その用語の存在をマーク付けするのである。ただし、用語を囲むのであって、定義を囲むわけではないことに注意すること。この達成方法は、定義方法に関する G112: インラインの定義を使用するとともに用いられる。

事例

事例 1

次のコードは、dfn 要素の使用例である。

コード例:

<p>The Web Content Accessibility Guidelines require that non-text content
has a text alternative. <dfn>Non-text content</dfn> is content that is not a sequence
of characters that can be programmatically determined or where the sequence is
not expressing something in human language; this includes ASCII Art (which is a
pattern of characters), emoticons, leetspeak (which is character substitution), and
images representing text .</p>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.5.8. The dfn element を代わりに参照できる。

検証

手順

  1. テキストの中で、インラインで定義されている単語、つまり単語の近くの文章に定義が出現するものを全て特定する。

  2. インラインで定義されているそれぞれの単語が、dfn 要素に含まれていることを確認する。

期待される結果

  • 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H56: 入れ子になったテキストの表記方向に伴う問題を解決するために、インライン要素の dir 属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、入れ子になった表記方向が含まれるテキストについて、インライン要素の dir 属性で方向の変化を指定することである。入れ子になったテキストの表記方向とは、たとえば英語のパラグラフで、文章が次々と続いている中にヘブライ語の引用文が含まれるといった、表記方向の異なるテキストが混在したテキストの表記方向のことである。表記方向の異なるテキストが混在し、スペースや句読点が含まれていると、Unicode の双方向アルゴリズムだけでは望ましくない結果になってしまうので、テキストを span 要素や他のインライン要素で囲み、dir 属性を指定する必要がある。この達成方法の考え方は、What you need to know about the bidi algorithm and inline markup で説明されている。

訳注: 上記の「What you need to know about the bidi algorithm and inline markup」は、「Inline markup and bidirectional text in HTML」とタイトルが変更されている。

事例

事例 1

この事例では、ヘブライ語と英語のように、混在したテキストの表記方向を持つ文章で、右から左へと表記すべき入れ子になったテキストの表記方向を明らかにする。引用全体はヘブライ語であり、右から左に表記されるが、「W3C」というテキストとカンマは、次のようにヘブライ語のテキストの左側に (すなわち、後ろに) 現れるべきである:

The title is "פעילות הבינאום, W3C" in Hebrew.

視覚的な順序に基づく ASCII (右から左へ表記するテキストは大文字で、左から右へ表記するテキストは小文字で書く) では、次の通りである:

the title is "w3c ,YTIVITCA NOITAZILANOITANRETNI" in hebrew.

正しく表示するためには、Unicode の双方向アルゴリズムだけでは不十分なため、次に示すように「W3C」というテキストが引用の中で右側に置かれたままである:

The title is "פעילות הבינאום, W3C" in Hebrew.

視覚的な順序に基づく ASCII では、次の通りである:

the title is "YTIVITCA NOITAZILANOITANRETNI, w3c" in hebrew.

次のようにマークアップすることによって、期待する結果が得られる。

コード例:

<p>The title says "<span lang="he" 
dir="rtl"><span dir="rtl">פעילות הבינאום, W3C</span></span>" in Hebrew.</p>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. 文書内のテキストの表記方向を調べる。

  2. テキストの表記方向が右から左である場合、属性の値が "rtl" である、dir 属性を持つ先祖要素を確認する。

  3. テキストの表記方向が左から右である場合、dir 属性を持つ先祖要素がない、又は属性の値が "ltr" である、dir 属性を持つ先祖要素がないことを確認する。

期待される結果

  • 全てのテキストに対して 2. 及び 3. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H57: html 要素の言語属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H57 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、html 要素に lang 属性及び (又は) xml:lang 属性を指定することで、文書の初期設定言語を特定することである。

次のようなさまざまな理由から、文書の言語を特定することが重要である:

  • 点字翻訳ソフトウェアでは、制御符号をアクセント付き文字の代わりにすることや、2 級点字の縮約形を誤って生成するのを避けるために制御符号を挿入することができる。

  • 複数の言語をサポートする音声合成装置は、ページの言語に固有な発音及び構文に適応でき、適切な発音とともに適切なアクセントでテキストを話す。

  • 言語をマークアップしておくことは、将来の技術発展に寄与する。たとえば、言語を自分で翻訳できない利用者でも、なじみのない言語を翻訳するマシンを利用できるようになるだろう。

  • 言語をマークアップしておくことは、ユーザエージェントが辞書で定義を提供するのにも役立つ。

HTML 4.01 では、html 要素に lang 属性を指定する。一方、XHTML を text/html として配信する場合には、XHTML 仕様の要求に合致しつつ、HTML との後方互換性を確保するために、html 要素に lang 属性と xml:lang 属性を指定する。XHTML を application/xhtml+xml として配信する場合には、html 要素の xml:lang 属性のみを指定する。lang 属性と xml:lang 属性の双方には、同じ値のみが指定できる。

注記 1: HTML は lang 属性の利用のみを指示しているが、XHTML 1.0 は (経過措置として) 両方の属性を認めており、XHTML 1.1 は xml:lang 属性のみを認めている。

注記 2: lang 属性と xml:lang 属性で指定できる値については、下記の参考リソースで示されている。言語タグでは、その言語を示すために主言語コードを用い、(ハイフン区切りで示す) 任意の副言語コードは言語の異体を示すのに用いる。たとえば、英語は主言語コードでは「en」で示すが、イギリス英語とアメリカ英語は「en-GB」と「en-US」という形で区別できる。この達成方法では、主言語コードの利用が重要である。副言語コードの利用は任意であるが、ある状況では役に立つかもしれない。

訳注 1: HTML 4.01、XHTML 1.0 及び XHTML 1.1 は Superseded Recommendation としてマークされ、廃止された仕様である。

訳注 2: 上記の「主言語コード」及び「副言語コード」は古い HTML に基づいた説明である。現在の HTML に基づいた言語タグの組み立て方については、参考リソースにある「Language tags in HTML and XML」を参照のこと。

訳注 3: 現在の HTML においては、text/html として提供される場合は lang 属性を、application/xhtml+xml として提供される場合は xml:lang 属性をそれぞれ用いればよい。両方の属性を同時に用いてもよいが、その場合は属性値を同じ値にする必要がある。HTML 5.2§3.2.5.2. The lang and xml:lang attributes も参考のこと。

訳注: WAIC では H57 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H57 も参照されたい。

事例

事例 1

この事例では、HTML 文書の内容がフランス語であることを明確にしている。

コード例:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="fr"> 
<head>
  <title>document écrit en français</title>
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />
</head>  
<body>     
	...document écrit en français...   
</body>
</html>

訳注: WAIC では H57-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H57-1 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 2

この事例では、text/html というコンテンツタイプの XHTML 1.0 文書の内容がフランス語であることを明確にしている。XHTML 仕様の要求に合致しつつ、HTML との後方互換性を確保するために、lang 属性と xml:lang 属性の両方を指定している。

コード例:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr">
<head>
  <title>document écrit en français</title>
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />
</head>
<body> 
...document écrit en français...      
</body>
</html>

訳注: WAIC では H57-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H57-2 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 3

この事例では、application/xhtml+xml というコンテンツタイプの XHTML 1.1 文書の内容がフランス語であることを明確にしている。xml:lang 属性のみを指定している。

コード例:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
<head>
  <title>document écrit en français</title>
	<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
</head>
<body> 
	...document écrit en français... 
</body>
</html>

訳注: WAIC では H57-3 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H57-3 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

参考リソース

検証

手順

  1. 文書の html 要素を調べる。

  2. html 要素に lang 属性及び/又は xml:lang 属性があることを確認する。

  3. lang 属性及び/又は xml:lang 属性の値が BCP 47: Tags for the Identification of Languages 又はその後継仕様に準拠しており、そのウェブページの主言語を反映していることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H58: 自然言語の変更を指定するために、言語属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H58 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、使用している HTML または XHTML のバージョンに応じて、lang または xml:lang 属性を用いることで、ページ上で用いられている自然言語の変化を明示することである。

HTML 4.01 では、各要素の lang 属性を用いる。text/html として提供される XHTML では、各要素の lang 属性と xml:lang 属性を用いることで XHTML の仕様を満たし、また HTML に対する後方互換性を保持する。application/xhtml+xml として提供される XHTML の場合は、各要素の xml:lang 属性を用いる。

注記: HTML では lang 属性のみを使用できる。XHTML 1.0 では移行措置として両方の属性を使用できる。XHTML 1.1 では xml:lang 属性のみを使用できる。

訳注 1: HTML 4.01、XHTML 1.0 及び XHTML 1.1 は Superseded Recommendation としてマークされ、廃止された仕様である。

訳注 2: 現在の HTML においては、text/html として提供される場合は lang 属性を、application/xhtml+xml として提供される場合は xml:lang 属性をそれぞれ用いればよい。両方の属性を同時に用いてもよいが、その場合は属性値を同じ値にする必要がある。HTML 5.2§3.2.5.2. The lang and xml:lang attributes も参考のこと。

lang 及び xml:lang 属性に指定できる値については、以下に示す参考リソースに示されている。言語タグは、言語を表すプライマリーコードと、その言語が使用される地域や記述に用いる文字コードなどを表すサブコードから成っている。サブコードの指定は任意で、指定する場合にはプライマリーコードに続けてハイフンを記述し、その後に記述する。たとえば、プライマリーコード「en」は英語を示し、「en-gb」と「en-us」はそれぞれイギリス英語とアメリカ英語を示す。この達成方法において、プライマリーコードの使用は重要である。サブコードの使用は任意だが、状況によっては有用なものになり得る。

訳注: 上記の「プライマリーコード」及び「サブコード」は古い HTML に基づいた説明である。現在の HTML に基づいた言語タグの組み立て方については、参考リソースにある「Language tags in HTML and XML」を参照のこと。

訳注: WAIC では H58 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H58 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例

事例 1

この例では、xml:lang 属性を用いてドイツ語の引用部分を示している。このコードは、lang 属性の使用が許されていない XHTML 1.1 に含むことができるように書かれている。

コード例:

<blockquote xml:lang="de">
  <p>
    Da dachte der Herr daran, ihn aus dem Futter zu schaffen,
    aber der Esel merkte, daß kein guter Wind wehte, lief fort
    und machte sich auf den Weg nach Bremen: dort, meinte er,
    könnte er ja Stadtmusikant werden.
  </p>
</blockquote> 

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

ドキュメントにおける各要素について:

  1. 要素のコンテンツの自然言語が、HTML 4.01, Inheritance of language codes で指定されているように、要素に継承されている言語と同一であることを確認する

ドキュメントにおける各 lang 属性について:

  1. lang 属性の値が BCP 47: Tags for the Identification of Languages 又はその後継に適合していることを確認する

ドキュメントにおける各 xml:lang 属性について:

  1. xml:lang 属性の値が BCP 47: Tags for the Identification of Languages 又はその後継に適合していることを確認する

期待される結果

  • 上記の全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H59: link 要素及びナビゲーションツールを使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H59 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、link 要素を用いて、ある HTML ページがウェブページ一式の中でどのような位置にあるのかを示すメタデータを提供する方法、及び利用者がウェブページ一式の中で特定のコンテンツを発見することを支援する方法について解説することである。rel 属性の値が、どのような関係性が定義されているのかを示し、href 属性がその関係を持つドキュメントへのリンクを提供する。複数の link 要素を用いることで、複数の関係を示すこともできる。rel 属性の値としては、以下のようなものが有用である:

  • Start: 複数のドキュメントの中の最初のドキュメントへのリンク

  • Next: 一連のドキュメントにおける次のドキュメントへのリンク

  • Prev: 一連のドキュメントにおける前のドキュメントへのリンク

  • Contents: 目次の役割を果たすドキュメントへのリンク

  • Index: 現在のドキュメントに対して索引を提供するドキュメントへのリンク

事例

事例 1

オンライン書籍の第 2 章のウェブページがあり、head 要素セクションに次のリンクが含まれている。

コード例:

<link rel="Contents" href="Contents.html" title="目次"  />
<link rel="Index" href="Index.html" title="索引" />
<link rel="Prev" href="Chapter01.html" title="01. なぜ進んでやるのか?" />
<link rel="Next" href="Chapter03.html" title="03. 誰が進んでやるのか?" /> 

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注 1: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2§4.2.4. The link elementHTML 5.2§4.8.6. Link types を代わりに参照できる。

訳注 2: 「Link Toolbar extension」は 2018 年現在、最新の Firefox と互換性がないためにインストールできない。

検証

手順

一連のまたは集合的なウェブページにおける、あるウェブページについて:

  1. ナビゲーションに関する全ての link 要素が、その文書の head 要素セクションに含まれている。

  2. その文書の head 要素セクション内のナビゲーションに関する各 link 要素に、少なくとも以下が指定されていることを確認する:

    1. リンクタイプを特定するための rel 属性

    2. 適切なリソースを見つけるための妥当な href 属性

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H60: 用語集にリンクするために、link 要素を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H60 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、用語集の場所を示すメカニズムを提供することである。コンテンツの中にある用語が、別の用語集ページで定義されている場合、用語集を用いるドキュメントの head 要素の範囲内に link 要素を指定することで、その用語集が参照できる。link 要素の rel 属性に「glossary」という値を指定し、href 属性には用語集ページの URI を指定する。これで、利用者が素早く簡単に用語集にアクセスするのをユーザエージェントが支援できるようになる。

事例

事例 1: WCAG 2.0 の用語集

コード例:

<link rel="glossary" href="http://www.w3.org/TR/WCAG20/#glossary">

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2§4.2.4. The link elementHTML 5.2§4.8.6. Link types を代わりに参照できる。

(今のところ、なし。)

検証

手順

用語集の役割を果たしている、単語と定義のあらゆる組み合わせについて:

  1. 用語集で定義した単語、語句又は略語を含むウェブページの head 要素セクションに、link 要素が含まれていることを確認する。

  2. link 要素が rel="glossary" 属性であることを確認する。

  3. link 要素の href 属性が、用語集ページを参照していることを確認する。

期待される結果

  • 上記全ての結果が真である。

注記: WCAG で用いている略語の定義は、「単語、語句、又は名称の短縮形で、その略語が言語の一部になっていないもの。」である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H62: ruby 要素を使用する

適用 (対象)

XHTML 1.1 及び HTML5

訳注: XHTML 1.1 は Superseded Recommendation としてマークされ、廃止された仕様である。

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H62 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、読み方の情報、及び意味が読み方によって決まる場合の連続するテキストの意味に関する情報を提供するために、ルビを振ることである。

多くの言語では、連続するテキストが読み方によって意味が異なる場合がある。これは、ヘブライ語、アラビア語、ほかの諸言語と同様に東アジア言語によくある。また、英語など西ヨーロッパ言語でも起こる。

「Ruby Annotation」は XHTML 1.1 のモジュールのひとつとして定義されている。コンテンツ制作者は「Ruby Annotation」によって、読み方や、場合によっては定義を提供すべく、「ベーステキスト」に注釈を加えることができる。日本語など東アジア言語のテキストでは、ルビが当たり前に利用される。

ルビのマークアップには単純と複雑の 2 種類がある。単純なルビのマークアップは完全な言葉やフレーズのようなテキストの実行が適用される。これは"ベース"テキスト (rb 要素) として知られている。ルビの注釈はどのように読むか示す用語 (rt 要素、または Ruby テキスト) を小さなフォントで表示している。("ルビ"という用語は、印刷でこの目的のために使用される小さい活字が由来)。ルビのテキストは通常、ベーステキストの上または直前に、つまり、横書きのテキストでは直上、縦書きのテキストでは右にレンダリングされる。日本語では、テキストの意味を提供するために、読み方のルビに対して (視覚的に) ベーステキストの反対側に、ルビを用いることもある。また、単純なルビのマークアップでは、ルビのマークアップをサポートしていないユーザエージェント (つまり、XHTML 1.1 又は HTML5 をサポートしていないユーザエージェント) のために、"フォールバック"オプションを提供している。

複合ルビマークアップでは、ベーステキストを小さな単位に分け、ルビ注釈を別々に関連づけることができる。複合ルビマークアップではフォールバックオプションはサポートされない。

読み方を伝える発音区別符号が Unicode フォントに含まれているヘブライ語などの言語では、ルビが用いられるのは稀である。また、英語やヨーロッパ言語でも珍しい。

注記: ルビ又は他の方法によって読み方を示す主な理由は、読み方さえ提供されていれば、コンテンツの書かれた言語を読み、理解することが可能な、障害のある利用者がコンテンツにアクセスできるようにするためである。ただし、そのコンテンツが書かれている言語に馴染みがない利用者のために、読み方を提供する必要はない。

事例

事例 1: 頭文字語の読み方を提供するルビのマークアップ

この事例では、Web Content Accessibility Guidelines という複数の単語の 1 文字目をとって作った頭文字語 (頭字語) の読み方を提供するために、ルビを用いている。WCAG という文字がルビベース (rb 要素) であり、読み方をルビテキスト (rt 要素) として示す。ルビのカッコを指定する rp 要素は、ルビをサポートしていないユーザエージェントに対して、rt 要素で囲まれたテキストが読み方を提供していることを示すために用いられる。ベーステキストの直後にカッコ付きで読み方を描画する (ルビをサポートしているユーザエージェントでは、カッコは表示されない)。

コード例:

<p>When we talk about these guidelines, we often just call them
  <ruby>
    <rb>WCAG</rb>
    <rp>(</rp>
      <rt>Wuh-KAG</rt>
    <rp>)</rp>
  </ruby>.
</p>

事例 2: 日本語のルビ注釈

次は、日本語の事例である。日本語では漢字の読み (ふりがな) を提供するのにルビが用いられる。ルビのカッコを指定する rp 要素は、読み方を提供する rt 要素のテキスト、つまりルビをサポートしていないユーザエージェントが利用し、ベーステキストの直後にカッコ付きで読み方を描画する (ルビをサポートしているユーザエージェントでは、カッコは表示されない)

コード例:

<p>
  <ruby>
    <rb>慶應大学</rb>
    <rp>(</rp>
    <rt>けいおうだいがく</rt>
    <rp>)</rp>
  </ruby>
</p> 

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

読み方を提供するためにルビ注釈が使用されている、連続するテキストについて:

  1. rb 要素で定義した連続するテキストに、rt 要素で読み方が指定してあることを確認する。

  2. 単純ルビマークアップを用いている場合、rp 要素があることを確認し、ルビ注釈をサポートしていないユーザエージェントに対して、rt 要素に囲まれたテキストが読み方を提供している。

期待される結果

  • 1. 及び 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H63: データテーブルで見出しセルとデータセルを関連付けるために、scope 属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H63 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、scope 属性を利用して見出しセルとデータセルを関連付けることである。 scope 属性を利用するのは、見出しとして利用するあらゆるセルが及ぶ範囲を明確にするためである。範囲とは、そのセルが行、列、行グループ、列グループのどの見出しであるかを特定するものである。rowcolrowgroupcolgroup という値によって範囲を特定することになる。

事例 1 のように、見出しが 1 行目や 1 列目にない単純なテーブルに対してこの達成方法が利用できる。今日のスクリーンリーダーのサポートを考えると、単純なテーブルについて次の二つの状況が当てはまる場合に、この達成方法の利用が示唆される:

  • td 要素でマークアップしてあるデータセルが、行見出し又は列見出しとしても機能する場合

  • th 要素ではなく td 要素でマークアップしてある見出しセルがある場合、コンテンツ制作者は、CSS でコントロールする方法があるがそれを採用せず、th 要素の表示特性を避けるために td 要素でマークアップすることがある。

注記 1: 1 行目や 1 列目に見出しがある単純なテーブルについては、scope 属性を指定せずに th 要素を利用するだけで十分である。

注記 2: 複雑なテーブルについては、H43: データテーブルのデータセルを見出しセルと関連付けるために、id 属性及び headers 属性を使用するの通り、id 属性と headers 属性を利用する。

注記 3: 一つの複雑な表よりも、単純な複数の表を用いて作業するほうが簡単だと思う利用者もいるだろう。制作者は、複雑な表を一つ以上の単純な表に変換できるかどうかを検討したい場合がある。

訳注: WAIC では H63 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H63 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

訳注: WAIC では H63 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H63 も参照されたい。

事例

事例 1: 単純なスケジュール表

次のコード例では、1 列目にテーブルの行番号を示す連番が含まれている。行の中でも重要な値は 2 列目に含まれるため、各セルに scope="row" と指定してある。1 行目のセルは td 要素でマークアップし、これらにも scope="col" と指定してある。

コード例:

 <table border="1">
  <caption>Contact Information</caption>
  <tr>
    <td></td>
    <th scope="col">Name</th>
    <th scope="col">Phone#</th>
    <th scope="col">Fax#</th>
    <th scope="col">City</th>
  </tr><tr>
    <td>1.</td>
    <th scope="row">Joel Garner</th>
    <td>412-212-5421</td>
    <td>412-212-5400</td>
    <td>Pittsburgh</td>
  </tr><tr>
    <td>2.</td>
    <th scope="row">Clive Lloyd</th>
    <td>410-306-1420</td>
    <td>410-306-5400</td>
    <td>Baltimore</td>
  </tr><tr>
    <td>3.</td>
    <th scope="row">Gordon Greenidge</th>
    <td>281-564-6720</td>
    <td>281-511-6600</td>
    <td>Houston</td>
  </tr>
</table> 

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2§4.9.10. The th element を代わりに参照できる。

検証

手順

各データテーブルについて:

  1. th 要素全てに、scope 属性があることを確認する。

  2. 他の要素の見出しとしての役割を果たす全ての td 要素に、scope 属性があることを確認する。

  3. 全ての scope 属性に、値として rowcolrowgroup、又は colgroup があることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H64: frame 要素及び iframe 要素の title 属性を使用する

適用 (対象)

frame 要素又は iframe 要素を用いている HTML 及び XHTML ドキュメント

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H64 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、フレームの内容を説明するための、frame 要素又は iframe 要素での title 属性の使用方法を示すことである。title 属性はフレームのラベルを提供するものなので、利用者はどのフレームの中に入ってその詳細を見て回るかどうかを判断できる。title 属性は、フレームセットの中の個々のページ (frame 要素) やインラインフレーム (iframe 要素) のラベルを付けるものではない。

title 属性はフレームにラベルを付けるものであって、文書にラベルを付ける title 要素とは異なることに注意しよう。title 属性は利用者が複数のフレームの間を移動しやすくし、また title 要素は利用者の現在位置を明確にするものであり、双方を提供すべきである。

title 属性を name 属性に置き換えることはできない。title 属性は利用者のためにフレームにラベルを付けるものであるのに対して、name 属性はスクリプトによる操作やウィンドウのターゲットを決めるためにフレームにラベルを付けるものだからである。つまり、name 属性は利用者に提供されるものではなく、title 属性だけがその役割を果たしている。

HTML5 では、frame 要素が廃止されている。iframe 要素は未だに HTML5 仕様の一部である。

事例

事例 1

この事例は、ナビゲーションバーと主要コンテンツを別の文書として読み込んでいるフレームそれぞれを説明するために、frame 要素に title 属性を指定する方法を示している。

コード例:

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>A simple frameset document</title>
  </head>
  <frameset cols="10%, 90%">
    <frame src="nav.html" title="Main menu" />
    <frame src="doc.html" title="Documents" />
    <noframes>
      <body>
        <a href="lib.html" title="Library link">Select to
        go to the electronic library</a>
      </body>
    </noframes>
  </frameset>
</html> 

訳注: WAIC では H64-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H64-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2

この事例は、インラインフレームの内容を説明するために、iframe 要素に title 属性を指定する方法を示している。さらに、iframe 要素を解釈できない古いブラウザのために、読み込むページへの代替リンクを iframe 要素の内容に含めてある。

コード例:

 <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>A document using iframe</title>
  </head>
...
<iframe src="banner-ad.html" id="testiframe" 
  name="testiframe" title="Advertisement">
    <a href="banner-ad.html">Advertisement</a>
</iframe>
...
</html>  

訳注: WAIC では H64-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H64-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記に関して、frame 要素は HTML 5.2§11.3.3. Frames で廃止された機能として定義されており、iframe 要素は HTML 5.2§4.7.6. The iframe element を代わりに参照できる。

検証

手順

  1. HTML 又は XHTML のソースコードにある frame 要素及び iframe 要素のそれぞれに、title 属性が存在するかどうかを確認する。

  2. title 属性の値として、そのフレームを特定できるテキストがあることを確認する。

期待される結果

  • 1. 及び 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H65: label 要素を使用できない場合に、フォームコントロールを特定するために、title 属性を使用する

適用 (対象)

value 属性、alt 属性、または要素内容で特定できない HTML 及び XHTML のフォームコントロール

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H65 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、ラベルを付けるのが視覚デザイン上そぐわない場合 (たとえば、ラベルとなりうるテキストが画面上にない場合) や、ラベルを表示することで混乱を引き起こしてしまう場合に、title 属性を利用してフォームコントロールにラベルを付けることである。それによって、ユーザエージェントや支援技術が、title 属性を読み上げることができる。

訳注: HTML 5.2§3.2.5.1. The title attribute の Warning で述べられているように、多くのユーザエージェントではアクセシブルな形でこの属性を公開しないので、title 属性に依存することを勧めていない。

訳注: WAIC では H65 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H65 も参照されたい。

事例

事例 1: 検索対象を絞り込むプルダウンメニュー

検索フォームで検索対象を絞り込むプルダウンメニューを用いている。そのプルダウンメニューは、検索語を入力するテキストフィールドのすぐそばにある。テキストフィールドとプルダウンメニューの関係は、見た目のデザインを目で見ることができる利用者には明白であり、ラベルを置くスペースはない。そこで、select 要素を特定するのに title 属性を利用している。title 属性はスクリーンリーダーによって読み上げられたり、画面拡大ソフトを使っている利用者にはツールチップとして表示されたりする。

コード例:

<label for="searchTerm">Search for:</label>
<input id="searchTerm" type="text" size="30" value="" name="searchTerm">
<select title="Search in" id="scope">
…
</select> 

訳注: WAIC では H65-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H65-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: 電話番号の入力フィールド

ウェブページの中に、アメリカでの電話番号を入力するコントロールがあり、市外局番、市内局番、下 4 桁の三つのフィールドで構成されている。

コード例:

<fieldset><legend>Phone number</legend>
<input id="areaCode" name="areaCode" title="Area Code" 
type="text" size="3" value="" >
<input id="exchange" name="exchange" title="First three digits of phone number" 
type="text" size="3" value="" >
<input id="lastDigits" name="lastDigits" title="Last four digits of phone number" 
type="text" size="4" value="" >
</fieldset> 

訳注: WAIC では H65-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H65-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3: 検索機能

ウェブページに、利用者が検索語を入力できるテキストフィールドと、検索を実行するための「検索」というラベルが付いたボタンがある。フォームコントロールを特定するの title 属性を利用し、ボタンはテキストフィールドの直後に置いてあるので、テキストフィールドに検索語を入力すべきことは利用者にとって明白である。

コード例:


<input type="text" title="Type search term here"/> <input type="submit" value="Search"/>

訳注: WAIC では H65-3 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H65-3 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 4: フォームコントロールのデータテーブル

フォームコントロールのデータテーブルは、各コントロールをそのセルの列ヘッダーと行ヘッダーに関連付ける必要がある。 タイトル (またはオフスクリーン LABEL) がないと、フォームをタブで移動しながら補助技術を使用して対応する行/列ヘッダー値を一時停止して調べることは視覚的でない利用者には困難である。

例えば、調査のフォームには 質問、同意、未決定、同意しないの四つの列見出しが最初の行にある。これらの行は質問と、三つの列の回答選択に対応する各セルのラジオボタンが含まれている。すべてのラジオボタンの title 属性は、回答選択 (列見出し) と質問のテキスト (行見出し) をハイフンまたはコロンをセパレータとして連結したものである。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§3.2.5.1. The title attribute を代わりに参照できる。

検証

手順

  1. label 要素に関連付けられていない各フォームコントロールを特定する。

  2. そのコントロールに title 属性が指定されていることを確認する。

  3. title 属性がそのコントロールの目的を特定していることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H67: 支援技術が無視すべき画像に対して、img 要素の alt テキストを空にして、title 属性を付与しない

適用 (対象)

画像を読み込む HTML 及び XHTML ドキュメント

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、支援技術が無視できるように画像をマークアップする方法を示すことである。

title 属性が使用されておらず、代替テキストが空に指定されているなら (例 alt="")、それは画像を無視して差し支えないことを支援技術に示している。

注記: alt 属性を 「空」にするのと、alt 属性が指定されていないことは同義ではない。

訳注: WAIC では H67 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H67 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

訳注: WAIC では H67 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H67 も参照されたい。

事例

事例 1

次の画像は、ウェブページに装飾のための画像を挿入するのに使用される。

コード例:

<img src="squiggle.gif" width="20" height="20" alt="" />

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

手順

無視すべき各画像に対して、

  1. title 属性がない又は空のいずれかであることを確認する。

  2. alt 属性が存在し、空であることを確認する。

期待される結果

  • 1. 及び 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H69: コンテンツの各セクションの開始位置に見出し要素を提供する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H69 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、コンテンツの構造を伝達するために、セクションごとに見出しを指定することである。見出しのマークアップは、次のように利用されることがある。

  • メインコンテンツの開始位置を示す

  • メインコンテンツ領域にあるセクションの見出しをマークアップする

  • 上部又はメインのナビゲーション、左側又はサブのナビゲーション、そしてフッターのナビゲーションなど、さまざまなナビゲーションを含んだセクションを区別する

  • 見出しとして用いられる文字画像をマークアップする

  • セクションによって利用者がページをナビゲートできるように、または、繰り返される情報のブロックをスキップできるようにする

見出しは論理的な階層を伝えるためにデザインされている。見出しの階層の中のレベルを飛ばすと、文書構造がきちんと検討されなかったのではないか、又は一部の見出しが意味ではなく視覚的な表現を得るために選択されたのではないか、といった印象を与えてしまうかもしれない。著者には見出しを階層的に入れ子にすることが推奨される。見出しが階層的である場合、もっとも重要な情報には最も高い論理レベルが与えられ、下位のセクションにはその後の論理レベルが与えられる (すなわち、h2 は h1 の下位セクションである)。このような種類の見出しを与えることは、コンテンツの全体的な構成を、利用者がより簡単に理解することに役立つ。

見出しは、コンテンツの中の重要なセクションの開始位置を示すものであるため、支援技術のユーザーが適切な見出しまで直接ジャンプしてから、コンテンツを読み始めることができる。これにより、他の方法でそのコンテンツに到達するのに時間を要していた利用者のインタラクションが大幅に速くなる。見出しによって、スクリーンリーダ―を利用する全盲の人や、情報のグループを作る支援技術を利用する認知的な障害のある人、あるいは、コミュニケーション障害や読書のときにスクリーンリーダ―に支援される文盲の人のような、障害者がより簡単に見つけられる情報の塊を作ることができる。

注記: 全ての達成方法は、特別なユーザエージェント (支援技術や特別なプラグインを含む) を必要とする人たちが入手でき、そうした種類のユーザエージェント (例えば、スクリーンリーダ―、あるいは適切にマークアップされたコンテンツのナビゲーションにキーボードが使えるようにするプラグインなど) を利用できることを仮定している。

訳注: WAIC では H69 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H69 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

訳注: WAIC では H69 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H69 も参照されたい。

事例

事例 1

この事例では、各セクションの見出しを h2 要素でマークアップすることによって、検索ページ内の複数のセクションを構成している。

コード例:

<h1>Search Technical Periodicals</h1>
 <h2>Search</h2>
 <form action="search.php">
  <p><label for="searchInput">Enter search topic: </label>
  <input type="text" size="30" id="searchInput">
  <input type="submit" value="Go"></p>
 </form>
 <h2>Available Periodicals</h2>
 <div class="jlinks">
  <a href="pcoder.com">Professional Coder</a> |
  <a href="algo.com">Algorithms</a> |
  <a href="jse.com">Journal of Software Engineering</a>
 </div>
 <h2>Search Results</h2>
 ... search results are returned in this section ...   

事例 2: コンテンツ全体の構成を示している見出し

この事例では、ナビゲーションとメインコンテンツを知覚できるように、見出しマークアップを利用している。

コード例:

<!-- ロゴ、バナー画像、検索フォームなど  -->
  <h2>Navigation</h2>
    <ul>
      <li><a href="about.htm">About us</a></li>
      <li><a href="contact.htm">Contact us</a></li>
       ...
    </ul>
  <h2>All about headings</h2>
   <!-- メインコンテンツを構成するテキスト、画像、その他のもの…… -->

事例 3: メインコンテンツ部分にあるコンテンツの構成を示している見出し

HTML 4.01 及び XHTML 1.x において、見出し要素はセクションの先頭をマークするだけであることに注意すること。見出し要素をセクションコンテンツに明示的に関連付けるためのマークアップが存在しないため、次の見出し要素が出現するまで、見出しは後に続くすべてのコンテンツに適用されると見なされる。

コード例:

 <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Cooking techniques</title>  
  </head>   
  <body>     
    <h1>Cooking techniques</h1>     
    <p>       
      ... some text here ...     
    </p>           
    <h2>Cooking with oil</h2> 
    <p> 
        ... text of the section ...     
    </p>           
    <h2>Cooking with butter</h2>       
    <p>
        ... text of the section ...     
    </p>   
  </body> 
</html>    

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: 「Accessibility Evaluation Toolbar」は 2018 年現在、最新の Firefox と互換性がないためにインストールできない。

検証

手順

  1. コンテンツが別々のセクションに分けられていることを確認する

  2. そのページの各セクションが見出しで始まることを確認する

期待される結果

  • 達成基準 2.4.1 の場合、2 の結果が真であることをを確認する。

  • 達成基準 2.4.10 の場合、1 及び 2 の結果が真であることを確認する。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H70: 繰り返されているコンテンツのブロックをグループ化するために、frame 要素を使用する

適用 (対象)

フレームを用いている HTML 及び XHTML ドキュメント

これは、次の達成基準に関連する達成方法である:

解説

訳注: WAIC では H70 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H70 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

訳注: WAIC では H70 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H70 も参照されたい。

この達成方法の目的は、繰り返しているブロックをグループ化するために、どのようにフレームセットを用いることができるかを示すことである。ユーザエージェント及び支援技術のほとんどが、フレームからフレームへとナビゲートする手段を提供しているため、要素をまとめるのにフレームを使うことによって、繰り返されているコンテンツのブロックを簡単に通過できるメカニズムを提供することができる。ウェブサイトでフレームセットを用いている場合、コンテンツのブロックそれぞれを別々のフレームにまとめられる。そして、繰り返しているコンテンツのブロックを、各ウェブページのフレームセットの中で、同一のフレームに表示させる。さらに、各 flame 要素には、そのフレームの内容を説明する title 属性を指定しなければならない。フレームに適切なタイトルが付いていれば、利用者はフレームのナビゲーション機能を使用してコンテンツのブロック間を簡単に移動することができるようになる。

この達成方法は、ページ内のコンテンツを構成するのに既にフレームセットを用いている場合に適している。フレームセットを用いていないウェブページには、他の達成方法を用いることが望ましい。多くの支援技術利用者は、フレームの扱いに手間がかかるからである。さらに対応が望まれる達成方法 (参考) として、ノーフレーム (noframes 要素) を用いる達成方法が、達成基準 1.1.1 にある。

HTML5 では、frame 要素は廃止されている。

事例

事例 1

次のコード例では、コンテンツを構成するのに二つのフレームを用いている。一つ目のフレームのソースは navigation.html というウェブページであり、ナビゲーションのための HTML が含まれている。このフレームには、ナビゲーションバーであることを特定する title 属性が指定してある。二つ目のフレームはサイトの主要コンテンツであり、main.html がソースである。title 属性に「主要ニュースコンテンツ」とありその機能を特定している。

コード例:

<frameset cols="20%, *">
  <frame src="navigation.html" name="navbar" title="Navigation Bar" />
  <frame src="main.html" name="maincontent" title="Main News Content" />
  <noframes>
    <p>View <a href="noframe.html">no frame version</a>.</p>
  </noframes>
</frameset>   

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記に関して、frame 要素及び frameset 要素は HTML 5.2§11.3.3. Frames で廃止された機能として定義されている。

検証

手順

ウェブページが、フレームを用いてコンテンツを構成している場合:

  1. 繰り返されているコンテンツのブロックそれぞれを、別々のフレームにまとめているかどうかを確認する。

  2. 繰り返されているコンテンツのフレームそれぞれが、各ページのフレームセット内で同じ場所に出現することを確認する。

期待される結果

  • 1. 及び 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H71: fieldset 要素及び legend 要素を使用して、フォームコントロールのグループに関する説明を提供する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、関連するフォームコントロールをセマンティックにグループ化する方法を提供することである。これによって、利用者はフォームコントロールの関係が理解でき、より早く効率的にフォームを利用できるようになる。

フォームコントロールは、fieldset 要素で囲むことによってグループ化できる。つまり、fieldset 要素内にある全てのフォームコントロールが関連付けられることになる。fieldset 要素内での最初の要素は legend 要素でなければならず、legend 要素はそのグループのラベルや説明を提供するものである。なお、利用者を混乱させてしまう恐れがあるため、コンテンツ制作者は必要以上に fieldsets 要素を入れ子にすることを避けるべきである。

フォームコントロールのグループ化が最も重要なのは、関連するラジオボタンやチェックボックスをまとめるときである。ラジオボタンやチェックボックスは、name 属性で同じ値が指定されている場合に、一組のコントロールとして関連付けられる。これらは、選択肢の中から自由に選択できるセレクトメニューと同じように動作することになるが、セレクトメニューは単一のコントロールであるのに対し、ラジオボタンとチェックボックスは複数のコントロールである点が異なる。それぞれのラジオボタンやチェックボックスの個々のラベルは、そのグループの説明となる文脈を十分に伝えられないことがある。この場合、セマンティックにグループ化しておくことが特に重要であり、それによって単一のコントロールのように簡単に操作できるようになり、またグループの説明を補足することができる。ユーザエージェントは、その説明を提供し、複数のコントロールが同じグループの一部であることを利用者に伝えるために、各コントロールのラベルよりも先に legend 要素の内容を提示することが多い。

ラジオボタンやチェックボックスほどには明確に関連していないコントロールをグループ化することが有用になることがある。たとえば、利用者の住所を入力するフィールドがいくつかに分かれている場合、「住所」という legend 要素を付けてグループ化しておくとよい。

ただし、(単一の名前付きフィールドの値を持つ場合でも) 関連するラジオボタン又はチェックボックスのグループに明らかな指示及び明確な選択肢が含まれている (すなわち、特定の各コントロールに関連付けられた個々のラベルが十分な記述を提供する) 場合、fieldset 及び legend 要素は必須ではない。この場合は、H44: テキストラベルとフォームコントロールを関連付けるために、label 要素を使用するで十分である。

ブラウザの初期状態では、fieldset 要素によってグループ化したコントロール全体を枠で囲むという表示であるため、コンテンツ制作者は fieldset 要素の利用を避けたい場合がある。しかし、このような視覚的なグループ化も有益であり、その状態のままにしておくこと (あるいは、何らかの形で視覚的にグループ化すること) をしっかり検討すべきである。見た目のスタイルについては、CSS で fieldset 要素に対する「border」プロパティを上書きしたり、fieldset 要素に対する「position」プロパティを上書きしたりすることによって変更できる。

訳注: WAIC では H71 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H71 も参照されたい。

事例

事例 1: 選択式のテスト

この事例では、一つの質問に対して五つの解答の中からどれかを選べるテスト項目を示している。解答はそれぞれラジオボタン (input type="radio") で提示されており、fieldset 要素に含めてある。テストの質問内容は legend 要素でタグ付けしてある。

コード例:

<fieldset>
  <legend>The play <cite>Hamlet</cite> was written by:</legend>
  <input type="radio" id="shakesp" name="hamlet" checked="checked" value="a">
  <label for="shakesp">William Shakespeare</label><br />
  <input type="radio" id="kipling" name="hamlet" value="b">
  <label for="kipling">Rudyard Kipling</label><br />
  <input type="radio" id="gbshaw" name="hamlet" value="c">
  <label for="gbshaw">George Bernard Shaw</label><br />
  <input type="radio" id="hem" name="hamlet" value="d">
  <label for="hem">Ernest Hemingway</label><br />
  <input type="radio" id="dickens" name="hamlet" value="e">
  <label for="dickens">Charles Dickens</label>
</fieldset>   

訳注: WAIC では H71-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H71-1 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 2: チェックボックスのグループ

あるウェブサイトでの利用者プロフィールのページで、利用者が複数のチェックボックスを選んで自分の興味を示せるようになっている。各チェックボックス (input type="checkbox") には、label がある。すべてのチェックボックスは、fieldset 要素に含められており、legend 要素にはチェックボックスのグループ全体の説明がある。

コード例:

<fieldset>
  <legend>I am interested in the following (check all that apply):</legend>
  <input type="checkbox" id="photo" name="interests" value="ph">
  <label for="photo">Photography</label><br />
  <input type="checkbox" id="watercol" name="interests" checked="checked" value="wa">
  <label for="watercol">Watercolor</label><br />
  <input type="checkbox" id="acrylic" name="interests" checked="checked" value="ac">
  <label for="acrylic">Acrylic</label>
  …
</fieldset>    

訳注: WAIC では H71-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H71-2 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 3: 同じ名前を付けたフィールドとして送信されるラジオボタン

この事例では、1 人の哲学者を選ぶように利用者に求めている。各ラジオボタンが関連している (同じフィールドとして送信される) ことを示すために「name」属性で同じ値を指定し、見た目としてもグループ化すべき点に注意しよう。また、「name」属性は同じ値であっても、「id」属性はそれぞれ一意的な値でなければならない点にも注意しよう。

コード例:

<form action="http://example.com/vote" method="post">
  <fieldset>
    <legend>Your preferred philosopher</legend>
    <input type="radio" name="philosopher" id="philosopher_socrates" value="socrates"/>
    <label for="philosopher_socrates">Socrates</label>
    <input type="radio" name="philosopher" id="philosopher_plato" value="plato"/>
    <label for="philosopher_plato">Plato</label>
    <input type="radio" name="philosopher" id="philosopher_aristotle" value="aristotle"/>
    <label for="philosopher_aristotle">Aristotle</label>
  </fieldset>
  </form> 

注記: 関連するチェックボックスのグループも同じように動作するが、利用者が一つ以上のフィールドを選べる点がラジオボタンとは異なる。

訳注: WAIC では H71-3 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H71-3 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 4: 論理的に関連付けたコントロール

この事例では、居住地と郵送先のフィールドを別々に fieldset 要素でグループ化し、legend 要素で異なる内容を指定している。

コード例:

<form action="http://example.com/adduser" method="post">
   <fieldset>
     <legend>Residential Address</legend>
     <label for="raddress">Address: </label>
     <input type="text" id="raddress" name="raddress" />
     <label for="rzip">Postal/Zip Code: </label>
     <input type="text" id="rzip" name="rzip" />
     ...more residential address information...
   </fieldset>
   <fieldset>
     <legend>Postal Address</legend>
     <label for="paddress">Address: </label>
     <input type="text" id="paddress" name="paddress" />
     <label for="pzip">Postal/Zip Code: </label>
     <input type="text" id="pzip" name="pzip" />
     ...more postal address information...
   </fieldset>
</form>

訳注: WAIC では H71-4 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H71-4 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

関連するコントロールのグループにおいて、各コントロールの個々のラベルが十分な記述を提供しておらず、追加でグループレベルの記述が必要な場合

  1. 論理的に関連している input 要素又は select 要素のグループが、fieldset 要素内に含まれていることを確認する。

  2. fieldset 要素には、そのグループの説明を含む legend 要素が指定されていることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H73: データテーブルの概要を提供するために、table 要素の summary 属性を使用する

適用 (対象)

HTML 4.01 及び XHTML 1.x

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、テーブルにどのようにデータがまとめられているかという短い概略や、テーブルをどのように読み進めるかという短い説明を提供することである。table 要素に summary 属性を指定しておくことで、スクリーンリーダーの利用者がこのような情報を入手できるが、視覚的には表示されない。

summary 属性は、テーブルの構造が複雑な場合 (たとえば、行ヘッダーや列ヘッダーが複数組み合わせてある場合や、行グループや列グループが複数ある場合) に有用である。また、summary 属性は、構造は単純でもたくさんの行や列を含んでいるデータテーブルでも役に立つ。

summary 属性は、そのテーブルに caption 要素があるかどうかに関わらず指定できる。両方を用いる場合には、summary 属性の内容が単に caption 要素の繰り返しであってはならない。

注記: HTML5 では、summary 属性は廃止された。支援技術はこの属性を引き続きサポートしているかもしれないし、していないかもしれない。コンテンツ制作者は代替手段を検討し、慎重に使うべきである。

注記: WCAG 2.0 はレイアウトレテーブルの使用を禁止していないが、CSS ベースのレイアウトを推奨している。HTML の table 要素に与えられたセマンティックな意義を守り、コンテンツから提示を分離するというコーディング実務に従うためである。レイアウトテーブルを用いる場合には、summary 属性は使用しないか、値を空にする。レイアウトテーブルの目的は、コンテンツの配置を制御することのみであって、テーブルそのものは利用者から見て「透明 (不可視)」であるべきである。summary 属性がテーブルの存在を示してしまうと、この透明性を「壊して」しまう。なお、レイアウトテーブルに空の summary 属性 (summary="") を指定することは許容範囲である。F46: 達成基準 1.3.1 の失敗例 - レイアウトテーブルで、th 要素、caption 要素、又は空ではない summary 属性を使用しているを参照のこと。

事例

事例 1: summary 属性はあるが、caption 要素はないデータテーブル

この事例は、バスの時刻表を表している。summary 属性には、運行系統と目的地、時刻表の利用方法が記述されている。

コード例:

<table summary="Schedule for Route 7 going downtown. Service begins 
at 4:00 AM and ends at midnight. Intersections are listed in the top row. 
Find the intersection closest to your starting point or destination, then read 
down that column to find out what time the bus leaves that intersection.">
  <tr>
    <th scope="col">State & First</th>
    <th scope="col">State & Sixth</th>
    <th scope="col">State & Fifteenth</th>
    <th scope="col">Fifteenth & Morrison</th>
  </tr>
  <tr>
    <td>4:00</td>
    <td>4:05</td>
    <td>4:11</td>
    <td>4:19</td>
  </tr>
  …
</table>  

訳注: WAIC では H73-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H73-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: summary 属性と caption 要素の両方があるデータテーブル

この事例では、summary 属性と caption 要素の両方を用いている。caption 要素ではバスの運行系統を特定している。summary 属性には、全盲の利用者が時刻表の利用方法を理解するのに役立つ内容を記述している。スクリーンリーダーは、まず caption 要素を、続いて summary 属性を読み上げる。

コード例:

<table summary="Intersections are listed in row 1. 
Find the intersection closest to your starting point 
or destination, then read down that column to find 
out what time the bus leaves that intersection.  
Service begins at 4:00 AM and ends at midnight.">
  <caption>Route 7 Downtown (Weekdays)</caption>
…
</table>

訳注: WAIC では H73-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H73-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§11.2. Non-conforming features で不適合な機能として定義されている。

検証

手順

各データテーブルにおいて:

  1. summary 属性がある場合、その summary 属性がテーブルの構造を記述しているか、又は、テーブルの使い方を説明していることを確認する。

  2. データテーブルに summary 属性と caption 要素の両方が存在している場合、summary 属性の内容が単に caption 要素の繰り返しになっていないことを確認する。

期待される結果

  • 1 及び 2 の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H74: 開始タグ及び終了タグを仕様に準じて使用していることを確認する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、支援技術がコンテンツを解析するときに生じる (ことで知られている) キーエラーを回避することである。このエラーは、コンテンツが、仕様に準じて用いられていない開始タグや終了タグを含むときに起こる。HTML あるいは XHTML のメカニズムをウェブコンテンツ技術やウェブコンテンツ技術のバージョンを特定するために用いたり、このようなタイプのエラーがないようにウェブページを制作したりすることで回避できる。バリデーターにはコンテンツ開発者が利用可能なものがいくつかあり、バリデーターのレポートではこのようなタイプのエラーが指摘される。この達成方法は、間違って形成された開始タグと終了タグに関連するエラーのみを対象としている。文書型宣言は、この検証では必ずしも必要ではないが、文書型宣言をしておくことでバリデーターを活用しやすくなる。

事例

事例 1: HTML

HTML ページが文書型宣言を含んでいる (!DOCTYPE として示されることが多い)。コンテンツ開発者はオフラインあるいはオンラインでバリデーターを利用できる (下記の参考リソース参照)。バリデーターでは、すべての id 属性の値が一意的で、かつ開始タグと終了タグが仕様に準じて用いられていることをチェックできる。

注記: どの要素が終了タグを必要とするかの仕様が、HTML5 の導入とともに変更された。

事例 2: XHTML

XHTML その他の XML ベースの文書同様に、XHTML 文書は、文書型定義 (DTD) や他のタイプの XML スキーマを参照する。コンテンツ開発者はオンラインあるいはオフラインでバリデーターを利用でき (エディターに組み込まれているバリデーションツールを含む)、開始タグや終了タグが仕様に準じて用いられていることをチェックする。

事例 3: 検証のフレームワークを用いる

ウェブサイトが静的なページではなく、HTML あるいは XHTML のページが動的に生成されるときは、コンテンツ開発者は XHTMLUnitXML Test Suite あるいは類似のフレームワークを用いて生成される XHTML コードのチェックを行うことができる。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

G134: ウェブページをバリデートするの参考リソースを参照のこと。

(今のところ、なし。)

検証

手順

  1. 終了タグが必要なすべての要素に対して、終了タグがあることを確認する。

  2. 終了タグが禁止されているすべての要素に対して、終了タグがないことを確認する。

  3. 入れ子になっているすべての要素の開始タグと終了タグが正しく入れ子になっていることを確認する。

期待される結果

1. 2. 及び 3. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H75: ウェブページが well-formed であることを確認する

適用 (対象)

すべての XML ベースのマークアップ言語

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、支援技術がコンテンツを解析するときに生じるエラーを避けることである。well-formed については、文書を XML パーサーを用いてチェックし、バリデーションレポートが well-formed に関するエラーを含んでいるかどうかで確認できる。すべての XML パーサーには、well-formed をチェックし、well-formed に関するエラーが見つかったときは、通常の処理を停止することが要求される (XML パーサーは、バリデーションをサポートしていなくてもよい)。

事例

事例 1

XML ファイルは、文書タイプ宣言、xsi:schemaLocation 属性あるいは他のタイプのスキーマへのリファレンスを含む。コンテンツ開発者は、オンラインあるいはオフラインのバリデーター、XML エディタもしくは XML サポートのある IDE (下記参考リソースを参照) を用いて、well-formed であることをチェックできる。

事例 2

XML ファイルが文書タイプ宣言、xsi:schemaLocation 属性又はスキーマがあるのにスキーマ参照のインストラクションのない処理を含まないとき、関連するスキーマがコマンドラインの指示、ユーザダイアログあるいは (構成) コンフィグレーションファイルで指定されている。そして、XML ファイルがスキーマに対してチェックされている。

事例 3

XML ファイルが文書タイプ宣言、xsi:schemaLocation 属性あるいはスキーマがあるのにスキーマ参照のインストラクションのない処理を 含まないとき、名前空間がスキーマ文書又は RDDL (Resource Directory Description Language) を読み出すのに参照されておらず、そして XML ファイルがスキーマに対してチェックされている。

事例 4

ウェブサイトが静的な文書ではなく、XML を動的に生成するとき、コンテンツ開発者は XMLUnitXML Test Suite あるいは類似のフレームワークを用いて、生成される XML コードをチェックできる。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

G134: ウェブページをバリデートするの参考リソースを参照のこと。

(今のところ、なし。)

検証

手順

  1. 各ファイルを XML パーサーにロードする。

  2. well-formedness エラーがないことを確認する。

期待される結果

2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H76: クライアントサイドで瞬間的にリダイレクトするために、meta 要素の refresh を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、クライアントサイドで利用可能なリダイレクトを、利用者を混乱させることなく用いることである。リダイレクトはサーバーサイドで実装するほうが望ましいが (SVR1: クライアントサイドではなく、サーバーサイドで自動リダイレクトを実装する (SERVER) を参照)、コンテンツ制作者がサーバーサイド技術を管理しているとは限らない。

HTML 及び XHTML では、meta 要素に http-equiv 属性には「Refresh」という値、content 属性の値には「0」(ゼロ秒を意味する) を、ブラウザが要求すべき URI を後に伴って指定することができる。重要なのは、新たなページを読み込む前にコンテンツが表示されるのを避けるために、タイムアウトをゼロに設定することである。リダイレクトのコードを指定したページには、リダイレクトに関する情報のみを含めるべきである。

事例

事例 1

コード例:

 <html xmlns="http://www.w3.org/1999/xhtml">    
  <head>      
    <title>The Tudors</title>      
    <meta http-equiv="refresh" content="0;URL='http://thetudors.example.com/'" />    
  </head>    
  <body> 
    <p>This page has moved to a <a href="http://thetudors.example.com/">
      theTudors.example.com</a>.</p> 
  </body>  
</html>     

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. ドキュメント内の meta 要素を全て見つける。

  2. meta 要素について、値が "refresh" (大文字と小文字の区別なし) の http-equiv 属性、及び content 属性で 0 より大きい数字、その後に続いて ;'URL=anyURL' (anyURL は、現在のページから置き換えるべき URI を表す) という値が含まれていることを確認する。

期待される結果

2. の結果が偽である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H77: リンクテキストとそれが含まれているリスト項目とを組み合わせて、リンクの目的を特定する

適用 (対象)

リンクが含まれる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、リンクとそれを含んでいるリスト項目の文脈から、リンクの目的を特定することである。リンクを含んでいるリスト項目が、先祖要素であるブロックレベル要素の中で最もそのリンクに近い場合、リンクテキストだけでは不明瞭なリンクに文脈を与えることになる。その説明によって、利用者がそのリンクと、そのウェブページ内にある他のリンクとを区別できるようになり、そのリンク先へ移動するかどうかを判断しやすくなる。一般的に、リンクテキストとして単に目的地の URI を示すだけでは、リンク先の説明として不十分であることに注意すべきである。

注記: このような説明が利用者にとって最も役立つのは、リンクを理解するのに必要な追加情報が、そのリンクよりも前に書かれている場合である。追加情報がリンクの後に書かれていると、ページを (先頭から最後へと) 順番に読むスクリーンリーダーの利用者には混乱や支障が生じることがある。

訳注: WAIC では H77 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H77 も参照されたい。

事例

事例 1

コード例:

<ul>
  <li>
    Check out the video report for last year's 
    <a href="festival.htm">National Folk Festival</a>.
  </li>
  <li>
    <a href="listen.htm">Listen to the instruments</a>
  </li>
  <li>
    Guitar Man: George Golden talks about 
    <a href="mkguitars.htm">making guitars</a>.
  </li>
</ul>

訳注: WAIC では H77-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H77-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: ビデオゲームのダウンロードリスト

コード例:

<ul>
  <li>
    <a href="tomb_raider.htm">Tomb Raider: Legend</a>
    <a href="tomb_raider_images.htm">See Images</a>
    <a href="tomb_raider.mpeg">(Download Demo)</a>
  </li>
  <li>
    <a href="fear_extraction.htm">F.E.A.R. Extraction Point</a>
    <a href="fear_extraction_images.htm">See Images</a>
    <a href="fear_extraction.mpeg">(Download Demo)</a>
  </li>
  <li>
    <a href="call_of_duty.htm">Call of Duty 2</a>
    <a href="call_of_duty_images.htm">See Images</a>
    <a href="call_of_duty.mpeg">(Download Demo)</a>
  </li>
  <li>
    <a href="Warhammer 40K.htm">Warhammer 40K</a>
    <a href="warhammer_40k_images.htm">See Images</a>
    <a href="Warhammer_40k.mpeg">(Download Demo)</a>
  </li>
</ul>   

訳注: WAIC では H77-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H77-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

この達成方法に関する参考リソースはない。

検証

手順

コンテンツの中で、この達成方法を利用するリンクそれぞれに対して:

  1. そのリンクがリスト項目の一部であることを確認する。

  2. そのリンクテキストとリスト項目を組み合わせると、リンクの目的が説明されていることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H78: リンクテキストとそれが含まれている段落とを組み合わせて、リンクの目的を特定する

適用 (対象)

リンクが含まれる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H78 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、リンクとそれを含んでいるパラグラフの文脈から、リンクの目的を特定することである。リンクを含んでいるパラグラフが、先祖要素であるブロックレベル要素の中で最もそのリンクに近い場合、リンクテキストだけでは不明瞭なリンクに文脈を与えることになる。その説明によって、利用者がそのリンクと、そのウェブページ内にある他のリンクとを区別できるようになり、そのリンク先へ移動するかどうかを判断しやすくなる。一般的に、リンクテキストとして単に目的地の URI を示すだけでは、リンク先の説明として不十分であることに注意すべきである。

注記: このような説明が利用者にとって最も役立つのは、リンクを理解するのに必要な追加情報が、そのリンクよりも前に書かれている場合である。追加情報がリンクの後に書かれていると、ページを (先頭から最後へと) 順番に読むスクリーンリーダーの利用者には混乱や支障が生じることがある。

訳注: WAIC では H78 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H78 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

訳注: WAIC では H78 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H78 も参照されたい。

事例

事例 1

民族音楽祭のウェブページの告知文。

コード例:

<h3>The final 15</h3>
<p>Coming soon to a town near you...the final 15 in the 
National Folk Festival lineup.
<a href="final15.html">[Read more...]</a>
</p>
<h3>Folk artists get awards</h3>
<p>Performers from the upcoming National Folk Festival receive 
 National Heritage Fellowships. 
 <a href="nheritage.html">[Read more...]</a>
</p>
…   

参考リソース

この達成方法に関する参考リソースはない。

検証

手順

コンテンツの中で、この達成方法を用いているリンクそれぞれに対して:

  1. そのリンクが段落の一部であることを確認する。

  2. そのリンクテキストと段落を組み合わせると、リンクの目的が説明されていることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H79: リンクテキストとそれが含まれているデータセル及び関連づけられた見出しセルとを組み合わせて、リンクの目的を特定する

適用 (対象)

リンクが含まれる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、リンクとそれを含んでいるデータテーブルの文脈から、リンクの目的を特定することである。文脈とは、そのリンクを含んでいるテーブルセルと、そのセルに関連付けられたテーブルの見出しセルとの関係を指している。データテーブルの文脈によって、リンクを含んでいるセルが、先祖要素であるブロックレベル要素の中で最もそのリンクに近い場合、リンクテキストだけでは不明瞭なリンクに目的が与えられる。それによって、利用者がそのリンクと、そのウェブページ内にある他のリンクとを区別できるようになり、そのリンク先へ移動するかどうかを判断しやすくなる。リンクテキストとして単に目的地の URI を示すだけでは、障害のある利用者、特に認知障害のある利用者にとってはリンク先の説明として不十分であることに注意すべきである。

訳注: WAIC では H79 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H79 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

訳注: WAIC では H79 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H79 も参照されたい。

事例

事例 1: レンタカー会社の料金比較表

コード例:

 <table>
<tr>
  <th></th>
  <th scope="col">Alamo</th>
  <th scope="col">Budget</th>
  <th scope="col">National</th>
  <th scope="col">Avis</th>
  <th scope="col">Hertz</th>
</tr>
<tr>
  <th scope="row">Economy cars</th>
  <td><a href="econ_ala.htm">$67/day</a></td>
  <td><a href="econ_bud.htm">$68/day</a></td>
  <td><a href="econ_nat.htm">$72/day</a></td>
  <td><a href="econ_av.htm">$74/day</a></td>
  <td><a href="econ_hz.htm">$74/day</a></td>
</tr>
<tr>
  <th scope="row">Compact cars</th>
  <td><a href="comp_ala.htm">$68/day</a></td>
  <td><a href="comp_bud.htm">$69/day</a></td>
  <td><a href="comp_nat.htm">$74/day</a></td>
  <td><a href="comp_av.htm">$76/day</a></td>
  <td><a href="comp_hz.htm">$76/day</a></td>
</tr>
<tr>
  <th scope="row">Mid-sized cars</th>
  <td><a href="mid_ala.htm">$79/day</a></td>
  <td><a href="mid_bud.htm">$80/day</a></td>
  <td><a href="mid_nat.htm">$83/day</a></td>
  <td><a href="mid_av.htm">$85/day</a></td>
  <td><a href="mid_hz.htm">$85/day</a></td>
</tr>
<tr>
  <th scope="row">Full-sized cars</th>
  <td><a href="full_ala.htm">$82/day</a></td>
  <td><a href="full_bud.htm">$83/day</a></td>
  <td><a href="full_nat.htm">$89/day</a></td>
  <td><a href="full_av.htm">$91/day</a></td>
  <td><a href="full_hz.htm">$91/day</a></td>
</tr>
</table>  

参考リソース

この達成方法に関する参考リソースはない。

検証

手順

コンテンツの中で、この達成方法を用いているリンクそれぞれに対して:

  1. そのリンクがテーブルセルの中にあることを確認する。

  2. そのリンクテキストと関連付けられたテーブル見出しセルを組み合わせると、リンクの目的が説明されていることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H80: リンクテキストと先行する見出し要素とを組み合わせて、リンクの目的を特定する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H80 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、リンクとその直前にある見出しの文脈から、リンクの目的を特定することである。直前にある見出しは、リンクテキストだけでは不明瞭なリンクに文脈を提供する。それによって、利用者がそのリンクと、そのウェブページ内にある他のリンクとを区別できるようになり、そのリンク先へ移動するかどうかを判断しやすくなる。

注記: 可能なかぎり、文脈による補足を必要とせずにリンクの目的が特定できるリンクテキストを提供すべきである。

訳注: WAIC では H80 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H80 も参照されたい。

事例

事例 1: 複数のホテルに関する情報のブロック

各ホテルの情報は、ホテル名、概要、地図、写真、案内、お客様レビュー、そして予約フォームへのリンクで構成されている。

コード例:

<h2><a href="royal_palm_hotel.html">Royal Palm Hotel</a></h2>
  <ul class="horizontal">
    <li><a href="royal_palm_hotel_map.html">Map</a></li>
    <li><a href="royal_palm_hotel_photos.html">Photos</a></li>
    <li><a href="hroyal_palm_hotel_directions.html">Directions</a></li>
    <li><a href="royal_palm_hotel_reviews.html">Guest reviews</a></li>
    <li><a href="royal_palm_hotel_book.html">Book now</a></li>
  </ul>
<h2><a href="hotel_three_rivers.html">Hotel Three Rivers</a></h2>
  <ul class="horizontal">
    <li><a href="hotel_three_rivers_map.html">Map</a></li>
    <li><a href="hotel_three_rivers_photos.html">Photos</a></li>
    <li><a href="hotel_three_rivers_directions.html">Directions</a></li>
    <li><a href="hotel_three_rivers_reviews.html">Guest reviews</a></li>
    <li><a href="hotel_three_rivers_book.html">Book now</a></li>
  </ul>     

訳注: WAIC では H80-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H80-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: ある文書を 三つのファイル形式で提供する場合

コード例:

<h2>Annual Report 2006-2007</h2>
<p> 
  <a href="annrep0607.html">(HTML)</a>&nbsp;
  <a href="annrep0607.pdf">(PDF)</a>&nbsp;
  <a href="annrep0607.rtf">(RTF)</a>
</p>       

訳注: WAIC では H80-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H80-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3: 新聞社のウェブサイト

コード例:

<h2><a href="Stockmarket_05052007.htm>Stock market soars as bullishness prevails</a></h2>
<p>this week was a stellar week for the stock market as investing in gold rose 2%. 
<a href="Stockmarket_05052007.htm>More here</a></p>     

訳注: WAIC では H80-3 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H80-3 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

この達成方法に関する参考リソースはない。

検証

手順

コンテンツの中で、この達成方法を用いているリンクそれぞれに対して:

  1. そのリンクに先行する見出し要素を見つける。

  2. そのリンクテキストと見出しを組み合わせると、リンクの目的が説明されていることを確認する。

期待される結果

  • 2.の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H81: リストが入れ子になっている状況で、親のリスト項目と結合したリンクテキストを用いて、入れ子になったリストの中でリンクの目的を特定する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H81 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、入れ子になったリストに含まれるリスト項目によって与えられる文脈から、リストの中のリンクの目的を特定することである。このリスト項目によって、リンクテキストだけでは不明瞭なリンクに文脈が与えられることになる。その説明によって、利用者がそのリンクと、そのウェブページ内にある他のリンクとを区別できるようになり、そのリンク先へ移動するかどうかを判断しやすくなる。

現在の支援技術には、親のリスト項目によって与えられる文脈的な情報を照会するコマンドがないため、この達成方法を用いても、利用者はリスト項目ひとつひとつに移動する必要がある。そのため、この達成方法は、非常に長く又は深く入れ子になったリストには適していないことがある。

注記: 可能なかぎり、文脈による補足を必要とせずにリンクの目的が特定できるリンクテキストを提供すべきである。

訳注: WAIC では H81 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H81 も参照されたい。

事例

事例 1: ある文書を三つのファイル形式で提供する場合

コード例:

<ul>
<li>Annual Report 2005-2006
  <ul> 
  <li><a href="annrep0506.html">(HTML)</a></li>
  <li><a href="annrep0506.pdf">(PDF)</a></li>
  <li><a href="annrep0506.rtf">(RTF)</a></li>
  </ul>
</li>
<li>Annual Report 2006-2007
  <ul> 
  <li><a href="annrep0607.html">(HTML)</a></li>
  <li><a href="annrep0607.pdf">(PDF)</a></li>
  <li><a href="annrep0607.rtf">(RTF)</a></li>
  </ul>
</li>
</ul> 

訳注: WAIC では H81-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H81-1 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

事例 2: 複数のホテルに関する情報のブロック

各ホテルの情報は、ホテル名、概要、地図、写真、案内、お客様レビュー、そして予約フォームへのリンクで構成されている。

コード例:

<ul>
<li><a href="royal_palm_hotel.html">Royal Palm Hotel</a>
  <ul class="horizontal">
    <li><a href="royal_palm_hotel_map.html">Map</a></li>
    <li><a href="royal_palm_hotel_photos.html">Photos</a></li>
    <li><a href="hroyal_palm_hotel_directions.html">Directions</a></li>
    <li><a href="royal_palm_hotel_reviews.html">Guest reviews</a></li>
    <li><a href="royal_palm_hotel_book.html">Book now</a></li>
  </ul>
</li>
<li><a href="hotel_three_rivers.html">Hotel Three Rivers</a>
  <ul class="horizontal">
    <li><a href="hotel_three_rivers_map.html">Map</a></li>
    <li><a href="hotel_three_rivers_photos.html">Photos</a></li>
    <li><a href="hotel_three_rivers_directions.html">Directions</a></li>
    <li><a href="hotel_three_rivers_reviews.html">Guest reviews</a></li>
    <li><a href="hotel_three_rivers_book.html">Book now</a></li>
  </ul>
</li>
</ul> 

訳注: WAIC では H81-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H81-2 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

参考リソース

この達成方法に関する参考リソースはない。

検証

手順

コンテンツの中で、この達成方法を用いているリンクそれぞれに対して:

  1. そのリンクが含まれる ul 要素又は ol 要素を見つける。

  2. そのリスト要素 (ulol) が、li 要素の子孫要素であることを確認する。

  3. その li 要素のテキストとリンクテキストを組み合わせると、リンクの目的が説明されていることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H83: 利用者の要求に応じて新しいウィンドウを開くために target 属性を使用して、そのことをリンクテキストで明示する

適用 (対象)

HTML5、HTML 4.01 Transitional 及び XHTML 1.0 Transitional

訳注: HTML4 及び XHTML 1.0 は Superseded Recommendation としてマークされ、廃止された仕様である。

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、利用者が要求していない新しいウィンドウの出現によって、利用者が混乱するのを避けることである。利用者によっては、突然開いた新しいウィンドウによって混乱してしまったり、新しいウィンドウを完全に見逃がしてしまう場合がある。HTML5、HTML 4.01 Transitional 及び XHTML 1.0 Transitional では、新しいウィンドウを開くのに、自動ポップアップの代わりに target 属性を用いることができる (target 属性は、HTML 4.01 Strict と XHTML 1.0 Strict では廃止されている)。注意すべきは、target 属性を用いなければ、利用者が新しいウィンドウを開くべきかどうかを自分で決定できることである。target 属性の利用によって、新しいウィンドウを開くというマシンリーダブルな指示が明確に提供される。ユーザエージェントは、あらかじめ利用者に知らせることができ、新しいウィンドウを開かない設定にすることもできる。支援技術を利用していない利用者のために、リンクテキストからも新しいウィンドウを開くことがわかるようにしておく。

事例

事例 1

次の事例では、新しいウィンドウが開くことが示されたリンクで、target 属性が用いられている。

コード例:

<a href="help.html" target="_blank">Show Help (opens new window)</a>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. 新しいウィンドウが開くかどうか確認するために、ドキュメント内の各リンクを起動させる。

  2. 新しいウィンドウを開くリンクに target 属性が指定されていることを確認する。

  3. リンクテキストには、新しいウィンドウが開くことを示す情報が含まれていることを確認する。

期待される結果

  • 2. 及び 3. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H84: アクションを実行するために、select 要素とともにボタンを使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、select 要素の値を選択することで意図せずアクションが実行されるのではなく、アクションの実行を利用者が制御できるようにすることである。利用者は、アクションが実行されるとは思わずに、select 要素にどんな値があるのかを調べたり、間違って意図しない値を選んだりするかもしれない。利用者が自分の選択に納得したとき、アクションを実行するボタンを選択できるようにする。

select 要素の選択肢の操作によって (フォームの) コントロールの値が変化する場合、キーボードで select 要素の値を選んでいる利用者に対して特に重要である。

事例

事例 1: カレンダー

あるウェブページでは、利用者が任意の年の任意の月を選ぶと、その月のカレンダーが表示される。利用者が月と年を指定した後に「表示」ボタンを押すことでカレンダーが表示される。この例では、クライアントサイドスクリプティングでアクションを実装している。

コード例:


<label for="month">Month:</label>
<select name="month" id="month">
  <option value="1">January</option>
  <option value="2"> February</option>
  ...
  <option value="12">December</option>
</select> 
<label for="year">Year:</label>
<input type="text" name="year" id="year">
<input type="button" value="Show" onclick = "...">

事例 2: アクションを選ぶ

select 要素は実行可能なアクションのリストを含んでいる。利用者が「実行」というボタンを押すまで、アクションは実行されない。

コード例:


<form action="http://somesite.com/action" method="post">
  <label for="action">Options:</label>
  <select name="action" id="action">
    <option value="help">Help</option>
    <option value="reset">Reset</option>
    <option value="submit">Submit</option>
  </select> 
  <button type="submit" name="submit" value="submit">Do It </button>
</form>              

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

それぞれの select 要素/ボタンの要素の組み合わせに対して:

  1. select 要素の選択肢にフォーカスがあたったとき (キーボードフォーカスを含む)、どのアクションも実行されないことを確認する。

  2. ボタンを選択すると、現在の select 要素の値に関連付けられたアクションが実行されることを確認する。

期待される結果

  • 上記全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H85: select 要素内の option 要素をグループ化するために、optgroup 要素を使用する

適用 (対象)

利用者の入力項目をまとめている HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H85 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、セレクトメニューの中の選択肢をグループ化することである。セレクトメニューは、複数選択式リストやコンボボックスといった、フォームコントロールの許容値の一組である。セレクトメニューには、関連する選択肢のグループが含まれることがある。単に「ダミー」の選択肢を使ってこれらのグループを区切るのではなく、セマンティンクに特定すべきである。これによって、ユーザエージェントは、グループごとに選択肢を閉じておき、利用者が選択肢を素早く拾い読みできるようにしたり、利用者にとって興味のある選択肢がどのグループに属しているのかを示すことができる。また、長い項目を視覚的に分割して、利用者が簡単に自分が選びたい選択肢を発見することにも役立つ。

HTML では、select 要素は複数選択式リストとコンボボックスの両方の生成に利用される。選択肢それぞれは、option 要素で示される。選択肢をグループ化するには、optgroup 要素の子要素に、関連する option 要素を含める。グループに「label」属性でラベル付けすることで、利用者がそのグループに含まれているものは何か予想できるだろう。

optgroup 要素は select 要素の直接の子要素、option 要素は optgroup 要素の直接の子要素として含めるべきとされる。select 要素では、optgroup 要素に一つだけ option 要素を含めることもできるが、実はこのような利用法がデザインを意図したものでないか、コンテンツ制作者は検討すべきである。optgroup 要素を入れ子にはできないので、select 要素内では 1 段階のグループ化しかできない。

グループ分け情報がリストの理解に不可欠な場合でも、コンテンツ制作者は、optgroup 要素が提供するグループ分け情報をスクリーンリーダーが読み上げなくても理解可能なように option 要素のラベルを定義するとよい。

訳注: WAIC では H85 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H85 も参照されたい。

事例

事例 1

次のコンボボックスは、好きな食べ物のデータをまとめたものである。利用者が好みのものを素早く選択できるように、食べ物の種類によってグループ化してある。

コード例:


<form action="http://example.com/prog/someprog" method="post">
    <label for="food">What is your favorite food?</label>
    <select id="food" name="food">
      <optgroup label="Fruits">
        <option value="1">Apples</option>
        <option value="3">Bananas</option>
        <option value="4">Peaches</option>
        <option value="5">...</option>
      </optgroup>
      <optgroup label="Vegetables">
        <option value="2">Carrots</option>
        <option value="6">Cucumbers</option>
       <option value="7">...</option>
     </optgroup>
     <optgroup label="Baked Goods">
       <option value="8">Apple Pie</option>
       <option value="9">Chocolate Cake</option>
       <option value="10">...</option>
     </optgroup>
   </select>
</form>              

訳注: WAIC では H85-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H85-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2

次の事例は、複数選択式リストで optrgroup 要素をどのように用いるかを示している。

コード例:


<form action="http://example.com/prog/someprog" method="post">
    <label for="related_techniques"><strong>Related Techniques:</strong></label>
    <select name="related_techniques" id="related_techniques" multiple="multiple" size="10">
  <optgroup label="General Techniques">
    <option value="G1">G1: Adding a link at the top of each page ... </option>
    <option value="G4">G4: Allowing the content to be paused and restarted ... </option>
    <option value="G5">G5: Allowing users to complete an activity without any time... </option>
    <option value="G8">G8: Creating an extended audio description for the ... </option>
    <option value="G9">G9: Creating captions for live synchronized media... </option>
    <option value="G10">G10: Creating components using a technology that ... </option>
  </optgroup>
  <optgroup label="HTML Techniques">
    <option value="H2">H2: Combining adjacent image and text links for the same ... </option>
    <option value="H4">H4: Creating a logical tab order through links, form ... </option>
    <option value="H24">H24: Providing text alternatives for the area ... </option>
  </optgroup>
  <optgroup label="CSS Techniques">
    <option value="C6">C6: Positioning content based on structural markup... </option>
    <option value="C7">C7: Using CSS to hide a portion of the link text... </option>
  </optgroup>
  <optgroup label="SMIL Techniques">
    <option value="SM1">SM1: Adding extended audio description in SMIL 1.0... </option>
    <option value="SM2">SM2: Adding extended audio description in SMIL 2.0... </option>
    <option value="SM6">SM6: Providing audio description in SMIL 1.0... </option>
  </optgroup>
  <optgroup label="ARIA Techniques">
    <option value="ARIA1">ARIA1: Using WAI-ARIA describedby... </option>
    <option value="ARIA2">ARIA2: Identifying required fields with the "required"... </option>
    <option value="ARIA3">ARIA3: Identifying valid range information with "valuemin" ... </option>
  </optgroup>
  <optgroup label="Common Failures">
    <option value="F1">F1: Failure of SC 1.3.2 due to changing the meaning of content by... </option>
    <option value="F2">F2: Failure of SC 1.3.1 due to using changes in text presentation... </option>
    <option value="F3">F3: Failure of SC 1.1.1 due to using CSS to include images  ... </option>
    <option value="F4">F4: Failure of SC 2.2.2 due to using text-decoration:blink ...</option>
  </optgroup>
</select>
</form>              

訳注: WAIC では H85-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H85-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. 選択リストに含まれる選択肢について、関連する選択肢のグループがあるかどうかを確認する。

  2. 関連する選択肢のグループがある場合、optgroup 要素でグループ化すべきである。

期待される結果

  • 2.の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H86: ASCII アート、顔文字、及びリート語にテキストによる代替を提供する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H86 に関するユーザエージェントサポートノートを参照のこと。

解説

インターネットでグラフィックが広く用いられるようになる前は、ASCII 文字を並べて絵やグラフを描くことがよくあった。今では ASCII アートはウェブではあまり使われないが、もし使うのであれば、スクリーンリーダーでインターネットにアクセスする全盲の人には全く意味が分からないことを覚えておかなかればならない。ASCII アートを使う場合、その絵が何なのかというテキストによる説明も付けておくべきである。また、その ASCII アートをスキップするリンクを置いておくほうがよい。(ただし、これは必須ではない)。

顔文字は非常に広く利用されている。顔文字は、ASCII 文字を組み合わせて、顔の表情や他の方法にして感情を伝える。ただし、スクリーンリーダーの利用者は意味が分からないかもしれないので、できれば顔文字の代わりに、単純に「笑顔」といった言葉を使ったほうがよい。もし顔文字を使うのであれば、テキストによる代替を指定すべきである。場合によっては、ブログやフォーラムを構築するソフトウェアで、たとえばプラグインを利用して、顔文字に使用している ASCII 文字をテキストによる代替の付いた HTML 画像に自動変換することができる。

リート語は、数字や特殊文字を含むさまざまな文字の組み合わせで標準的な文字を置き換える表記法である。リート語はすでに、インターネット文化や俗語の一部となっており、テキストフィルターやスパムフィルターをあざむくのにしばしば利用される。リート語はスクリーンリーダーを利用する全盲の人が理解できないことがあるため、達成基準 1.1.1 に準拠するにはテキストによる代替の提供が求められる。

注記: この達成方法のサポートは限られているため、コンテンツ制作者はテキストによる代替を提供することが推奨される。

事例

事例 1

以下では、イコール記号に数字の 8、ハイフン、数字の 0 をつなげて「恐怖」を表現する顔文字に対する、3 通りの代替の指定方法を示している。

コード例:


=8-0 (fright)
<abbr title="fright">=8-0</abbr>
<img src="fright.gif" alt="fright"/>
             

訳注: WAIC では H86-1 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H86-1 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

事例 2

この事例では、ASCII アートの前にその絵の説明を付け、ASCII アートをスキップするリンクがある。ASCII アートの事例をスキップして事例 3 へ

コード例:


 Figure 1: ASCII art picture of a butterfly. 
 <a href="#skipbutterfly">Skip ASCII image</a>
                                 
                                                                LLLLLLLLLLL
                                                            __LLLLLLLLLLLLLL
                                                           LLLLLLLLLLLLLLLLL
                                                         _LLLLLLLLLLLLLLLLLL
                                                        LLLLLLLLLLLLLLLLLLLL
                                                      _LLLLLLLLLLLLLLLLLLLLL
                                                      LLLLLLLLLLLLLLLLLLLLLL
                                              L     _LLLLLLLLLLLLLLLLLLLLLLL
                                             LL     LLLLLL~~~LLLLLLLLLLLLLL
                                            _L    _LLLLL      LLLLLLLLLLLLL
                                            L~    LLL~        LLLLLLLLLLLLL
                                           LL   _LLL        _LL   LLLLLLLL
                                          LL    LL~         ~~     ~LLLLLL
                                          L   _LLL_LLLL___         _LLLLLL
                                         LL  LLLLLLLLLLLLLL      LLLLLLLL
                                         L  LLLLLLLLLLLLLLL        LLLLLL
                                        LL LLLLLLLLLLLLLLLL        LLLLL~
                  LLLLLLLL_______       L _LLLLLLLLLLLLLLLL     LLLLLLLL
                         ~~~~~~~LLLLLLLLLLLLLLLLLLLLLLLLL~       LLLLLL
                       ______________LLL  LLLLLLLLLLLLLL ______LLLLLLLLL_
                   LLLLLLLLLLLLLLLLLLLL  LLLLLLLL~~LLLLLLL~~~~~~   ~LLLLLL
             ___LLLLLLLLLL __LLLLLLLLLLLLL LLLLLLLLLLLLL____       _LLLLLL_
          LLLLLLLLLLL~~   LLLLLLLLLLLLLLL   LLLLLLLLLLLLLLLLLL     ~~~LLLLL
      __LLLLLLLLLLL     _LLLLLLLLLLLLLLLLL_  LLLLLLLLLLLLLLLLLL_       LLLLL
     LLLLLLLLLLL~       LLLLLLLLLLLLLLLLLLL   ~L ~~LLLLLLLLLLLLL      LLLLLL
   _LLLLLLLLLLLL       LLLLLLLLLLLLLLLLLLLLL_  LL      LLLLLLLLL   LLLLLLLLL
  LLLLLLLLLLLLL        LLLLLLLLLLLLL~LLLLLL~L   LL       ~~~~~       ~LLLLLL
 LLLLLLLLLLLLLLL__L    LLLLLLLLLLLL_LLLLLLL LL_  LL_            _     LLLLLL
LLLLLLLLLLLLLLLLL~     ~LLLLLLLL~~LLLLLLLL   ~L  ~LLLL          ~L   LLLLLL~
LLLLLLLLLLLLLLLL               _LLLLLLLLLL    LL  LLLLLLL___     LLLLLLLLLL
LLLLLLLLLLLLLLLL              LL~LLLLLLLL~     LL  LLLLLLLLLLLL   LLLLLLL~
LLLLLLLLLLLLLLLL_  __L       _L  LLLLLLLL      LLL_ LLLLLLLLLLLLLLLLLLLLL
 LLLLLLLLLLLLLLLLLLLL        L~  LLLLLLLL      LLLLLLL~LLLLLLLLLLLLLLLL~
  LLLLLLLLLLLLLLLLLLLL___L_ LL   LLLLLLL       LLLL     LLLLLLLLLLLLLL
   ~~LLLLLLLLLLLLLLLLLLLLLLLL     LLLLL~      LLLLL        ~~~~~~~~~
           LLLLLLLLLLLLLLLLLL_ _   LLL       _LLLLL
               ~~~~~~LLLLLLLLLL~             LLLLLL
                         LLLLL              _LLLLLL
                         LLLLL    L     L   LLLLLLL
                          LLLLL__LL    _L__LLLLLLLL
                          LLLLLLLLLL  LLLLLLLLLLLL
                           LLLLLLLLLLLLLLLLLLLLLL
                            ~LLLLLLLLLLLLLLLLL~~
                               LLLLLLLLLLLLL
                                 ~~~~~~~~~
<a name="skipbutterfly></a> 

訳注: WAIC では H86-2 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H86-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3

以下は、リート語で「Austin Rocks」と書いた例である。

コード例:

<abbr title="Austin Rocks">Au5t1N r0xx0rz</abbr> 

訳注: WAIC では H86-3 に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H86-3 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

検証

手順

  1. そのページを一般的なブラウザで開く。

  2. ASCII アート、顔文字、及び/又はリート語がコンテンツに含まれていることを確認する。

  3. 全ての ASCII アート、顔文字、及び/又はリート語の直前又は直後に、テキストによる代替があることを確認する。

期待される結果

  • 3. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H88: 仕様に準じて HTML を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、HTML 及び XHTML をそれぞれの仕様に準じて用いることである。技術仕様では、そのウェブコンテンツ技術の意味及び機能の適切な取扱方法を定めている。仕様に記述されている通りに HTML 及び XHTML の機能を用いることによって、支援技術を含むユーザエージェントが、コンテンツ制作者の意図通りで互いに相互運用性のある機能を提示することが可能となる。

この文書を記述した時点では、HTML 及び XHTML の妥当なバージョンは、HTML 4.01 及び XHTML 1.0 である。HTML 4.01 は、HTML の最も成熟したバージョンであり、特定のアクセシビリティ機能を提供し、ユーザエージェントによって広くサポートされている。XHTML 1.0 は、HTML 4.01 と同じ機能を提供しているが、XML 構造を用いており、HTML の構造よりも厳密な構文となっている。HTML 及び XHTML の最新バージョンは、まだ未成熟であり、ユーザエージェントにもまだ広くサポートされていないのが現状である。

訳注: HTML4 及び XHTML 1.0 は Superseded Recommendation としてマークされ、廃止された仕様である。2018 年 11 月現在、有効な W3C Recommendation は HTML 5.1 及び HTML 5.2 である。

HTML 及び XHTML を仕様に準じて用いるにあたり、幾つかの留意すべき点がある。

  1. 仕様で定められている機能だけを用いる: HTML では、ウェブページで用いることのできる要素、属性及び属性値の一式を定義している。それらには固有のセマンティックな意味を持ち、ユーザエージェントが特定の方法で処理するよう意図されている。しかし、時には、仕様にはない方法がコンテンツ制作の際に一般的に用いられることがある。それが一つのユーザエージェントだけによってサポートされることが、そのきっかけとなることが多い。仕様にはない方法を用いた場合、多くのユーザエージェントはそれを当分の間サポートしなかったり、いつまでもサポートしなかったりする。さらに、標準仕様にない用い方をすると、ユーザエージェントによってそのサポート方法が異なることもある。そして、主流のブラウザと比べ少ないリソースで開発されている支援技術は、有用なサポートを追加する場合でも時間を要するため、アクセシビリティに影響を及ぼすことになる。よって、予期しないアクセシビリティの問題を回避するためにも、コンテンツ制作者は HTML 及び XHTML で定義されていない用法を避けるべきである。

  2. 仕様によって規定されている方法で機能を用いる: HTML の仕様では、どのように特定の要素、属性及び属性値をセマンティックに処理し解釈すべきかについて、具体的なガイダンスを提供している。しかし、時には、コンテンツ制作者が仕様ではサポートされていない方法でそれらを用いることがある。例えば、本来のセマンティックなメッセージが伝わることを意図せずに、セマンティックな要素を用いて視覚的な効果を得ることが挙げられる。これは、正確なセマンティック情報を用いて首尾一貫したページを描画しているユーザエージェント及び支援技術に対して混乱を招くことにつながる。あくまで HTML の仕様によって規定されている機能として、HTML の各機能を用いることが重要である。

  3. コンテンツが解析可能であることを確認する: HTML 及び XHTML では、ユーザエージェントによって正しく処理されるためには、コンテンツをどのようにコーディングすべきかも定めている。開始タグ及び終了タグ、属性及び値、要素の入れ子などの構造に関するルールは、意図された文書の表現となるようにユーザエージェントがコンテンツを処理できるようにするためにある。HTML 及び XHTML の仕様における構造のルールに従うことが、仕様に準じてそれらのウェブコンテンツ技術を用いる上で重要なことの一つである。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

G134: ウェブページをバリデートするの参考リソースを参照のこと。

検証

手順

HTML 又は XHTML の各ページに対して:

  1. ページが、関連する仕様において定義されている要素、属性及び属性値のみを用いていることを確認する。

  2. 要素、属性及び値が、関連する仕様によって規定されている方法で用いられていることを確認する。

  3. ページが、関連する仕様のルールに従って、正しく解析可能であることを確認する。

注記: 上記 1. 及び 3. は、ページバリデーションツールを用いて容易に確認することができる。上記 2. は、通常は人間による判断が求められるが、ヒューリスティックな評価ツールを補助的に用いて確認することが可能である。

期待される結果

  • 上記の全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H89: コンテキストに応じたヘルプを提供するために、title 属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H89 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、title 属性にヘルプ情報を提供することで、フォームにデータを入力する利用者にコンテキストに応じたヘルプを提供することである。ヘルプは書式情報もしくは入力例を含んでもよい。

注記: 現在のユーザエージェントおよび支援技術は title 属性に含まれた情報を利用者に常には提供しない。title 属性が広範囲にサポートされるまではこの達成方法を単独で利用することは避けるべきである。

訳注: 上記の注記同様、HTML 5.2§3.2.5.1. The title attribute の Warning で述べられているように、多くのユーザエージェントではアクセシブルな形でこの属性を公開しないので、title 属性に依存することを勧めていない。

事例

事例 1

地図検索アプリケーションはラベル"住所:"で構成されるフォームと、入力ボックスと、"地図検索"という値の実行ボタンを提供する。インプットボックスは利用者が入力するアドレス書式の例を title 属性に持つ。

コード例:


<label for="searchAddress">Address: </label>
<input id="searchAddress" type="text" size="30" value="" name="searchAddress" 
 title="Address example: 101 Collins St, Melbourne, Australia" />
             

事例 2

利用者が請求書をオンラインで支払うことを可能にするフォームでは、利用者は自分の口座番号を入力する必要がある。ラベル「口座番号」がついたインプットボックスは、口座番号の特定に関する情報を提供する title 属性を持つ。

コード例:


<label for="accNum1">Account number: </label>
<input id="accNum1" type="text" size="10" value="" title="Your account number 
 can be found in the top right-hand corner of your bill." />
             

検証

手順

  1. テキスト入力を要求しているフォームコントロールを特定する。

  2. 各フォームコントロールに明示的に関連付けられたラベルがあることを確認する。

  3. 各フォームコントロールがコンテキストに応じたヘルプを title 属性で提供していることを確認する。

期待される結果

  • 上記 2. 及び 3.の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H90: label 要素又は legend 要素を使用して、必須のフォームコントロールを明示する

適用 (対象)

外部ラベルを用いている HTML 及び XHTML のコントロール

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H90 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、ウェブアプリケーションまたはフォームで特定のフォームコントロールが必須項目であることを明確に示すことである。コントロールが必須項目であることを示す記号またはテキストは、label 要素、又は fieldset 要素でグループ化されたコントロールに対する legend 要素を用いて、プログラムが解釈できるようにそのコントロールと関連付ける必要がある。記号が用いられている場合には、事前に利用者にその意味を説明する必要がある。

事例

事例 1: テキストを用いて必須項目であることを示す

以下のコード例にあるテキストフィールドには、明示的なラベル「名前 (必須)」がある。label 要素の for 属性値が、input 要素の id 属性値と合致していて、label 要素でマークアップされたテキストによってそのコントロールが必須項目であることを示している。

コード例:


<label for="firstname">First name (required):</label> 
<input type="text" name="firstname" id="firstname" />

注記: 英語では、必須項目の "required" を略して "req." とするコンテンツ制作者もいるが、この略語は分かりにくいという報告がある。

事例 2: アスタリスクを用いて必須項目であることを示す

以下のコード例にあるテキストフィールドには、必須項目であることを示すアスタリスクを含んだ明示的なラベルがある。アスタリスクの意味をフォームの先頭で定義することが重要である。このコード例では、アスタリスクは abbr 要素内にあって、アスタリスク文字にスタイルを指定できるようになっている。この CSS は、アスタリスク文字は視覚に障害のある利用者にとっては見えづらいため、デフォルトのアスタリスク文字よりもサイズを大きくしている。

コード例:


CSS:
.req {font-size: 150%} 
HTML:
<p> Required fields are marked with an asterisk (<abbr class="req" title="required">*</abbr>).</p>
<form action="http://www.test.com" method="post">
<label for="firstname">First name <abbr class="req" title="required">*</abbr>:</label> 
<input type="text" name="firstname" id="firstname" />

事例 3: 画像を用いて必須項目であることを示す

以下のコード例にあるテキストフィールドには、コントロールが必須項目であることを示す画像を含む明示的なラベルがある。画像の意味をフォームの先頭で定義することが重要である。

コード例:


<p><img src="req_img.gif" alt="Required Control" /> indicates that the form control is required</p>
<form action="http://www.test.com" method="post">
<label for="firstname">First name <img src="req_img.gif" alt="Required Control" />:</label> 
<input type="text" name="firstname" id="firstname" />
...

事例 4: ラジオボタンまたはチェックボックスのグループが必須項目であることを示す

ラジオボタン及びチェックボックスは、個々のラジオボタンやチェックボックスではなく、そのグループ全体で一つの必須項目となるため、他のインタラクティブなコントロールとは異なった扱われかたをする。事例 1〜3 で使用された方法は、ラジオボタン及びチェックボックスに適用されるが、必須状態の表示は、label 要素ではなく legend 要素に配置すべきである。

コード例:


<fieldset>
<legend>I am interested in the following (Required):</legend>
<input type="checkbox" id="photo" name="interests" value="ph">
<label for="photo">Photography</label></br>
<input type="checkbox" id="watercol" name="interests" checked="checked" value="wa">
<label for="watercol">Watercolor</label></br>
<input type="checkbox" id="acrylic" name="interests" checked="checked" value="ac">
<label for="acrylic">Acrylic</label>
…
</fieldset>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.10.4. The label element を代わりに参照できる。

検証

手順

  1. 必須項目であるフォームコントロールに対して、必須項目であることがフォームコントロールの label 要素又は legend 要素で示されている。

  2. 必須項目であることを示すテキスト以外のものに対して、それを使用しているフォームコントロールの前にその意味が説明されていることを確認する。

期待される結果

  • 上記の全ての結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H91: HTML のフォームコントロール及びリンクを使用する

適用 (対象)

HTML のフォームコントロール及びリンク

これは、次の達成基準に関連する達成方法である:

ユーザエージェント及び支援技術によるサポート

H91 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、インタラクティブなユーザインタフェースを構成する要素のキーボード操作及び支援技術との相互運用性を提供するために、標準的な HTML のフォームコントロール及びリンク要素を用いることである。

ユーザエージェントは、HTML のフォームコントロール及びリンクのキーボード操作を提供している。さらに、ユーザエージェントは、フォームコントロール及びリンクを、アクセシビリティ API に結び付けている。支援技術は、アクセシビリティ API を利用して、役割 (role)、識別名 (name)、状態 (state)、値 (value) といった適切なアクセシビリティ情報を抽出し、それらを利用者に提供している。役割は HTML の要素によって提供され、名前はその要素に関連付けられているテキストによって提供される。値及び状態が適切な要素は、複合的なメカニズムを通じて、それらの値及び状態も支援技術に提示している。

必須の属性を通じてテキストがすでにコントロールと関連付けられている場合もある。たとえば、送信ボタンは、button 要素内のテキスト又は画像の「alt」属性を識別名として用いている。フォームコントロールの場合は、label 要素又は「title」属性が用いられる。次の表は、HTML のフォームコントロール及びリンクの役割、識別名、値、状態がどのように決定されるかを示したものである。

HTML 要素役割 (role)識別名 (name)値 (value)状態 (state)
<a>リンク<a> 要素の title 属性、画像リンクの場合は alt 属性。テキストと画像の alt 属性を両方が提供されている場合は、両者を結合する。href 属性
<button>プッシュボタン<button> 要素内のテキスト又は title 属性
<fieldset>グループ化フィールドセット要素にある <legend> 要素内のテキスト
<input type = "button", "submit", or "reset">プッシュボタンvalue 属性
<input type = "image">プッシュボタンalt 属性又は title 属性
<input type = "text">編集可能なテキストそのコントロールに関連付けられた <label> 要素又は title 属性value 属性
<input type = "password">編集可能なテキストそのコントロールに関連付けられた <label> 要素又は title 属性値は意図的に隠されている
<input type="file">編集可能なテキストそのコントロールに関連付けられた <label> 要素又は 'title' 属性'value' 属性
<input type="checkbox">チェックボックスそのコントロールに関連付けられた <label> 要素又は title 属性 checked 属性
<input type="radio">ラジオボタンそのコントロールに関連付けられた <label> 要素又は title 属性 checked 属性
<select>リストそのコントロールに関連付けられた <label> 要素又は title 属性<option> 要素の selected 属性で「selected」と指定
<textarea>編集可能なテキストそのコントロールに関連付けられた <label> 要素又は title 属性<textarea> 要素内のテキスト

事例

事例 1: リンク

ユーザエージェントは、リンクをナビゲートして選択するメカニズムを提供する。次の各事例では、<a href> により、役割 (role) は "link" となる。<a name> は "link" の役割 (role) を提供しないことに注意する。値 (value) は、href 属性の URI である。

事例 1a

事例 1a では、名前 (name) はリンクの中にあるテキストである。この場合は「Example Site」が該当する。

コード例:

<a href="www.example.com">Example Site</a>
                    
事例 1b

リンクの中にある画像に関する事例 1b では、画像の alt 属性が名前 (name) を提供している。例えば、Microsoft Inspect Objects などのように API を閲覧するツールには、alt 属性を可視化できないものもあるが、支援技術では抽出できる。

コード例:

<a href="www.example.com"><img src="example_logo.gif" alt="Example"></a>
                    
事例 1c

事例 1c では、画像の代替テキストとリンクのテキストを連結するときに自動的に空白文字を挿入しない支援技術もある。テキストをスペースなしで連結すべきでない場合、画像と隣接する単語との間にスペースを挿入して、単語が混ざらないようにするのが最も安全である。

コード例:

<a href="www.example.com"><img src="example_logo.gif" alt="Example"> Text</a>

訳注: WAIC では H91-1c に関するアクセシビリティ・サポーテッド(AS)情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド(AS)情報: H91-1c では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: ボタン

HTML では、ボタンを生成するのにさまざまな方法があるが、それらは全て「プッシュボタン」という役割 (role) に位置付けられる。

事例 2a

事例 2a では、button 要素内の「save」というテキストが名前 (name) となる。値 (value) はない。

コード例:

<button>Save</button>
                    
事例 2b

事例 2b では、value 属性を用いて「Save」「Submit」「Reset」という名前 (name) を指定している。

コード例:

<input type="button" value="Save" /> 
<input type="submit" value="Submit" />  
<input type="reset" value="Reset" />   
                    
事例 2c

事例 2c では、alt 属性を用いて「save」という名前 (name) を指定している。

コード例:

<input type="image" src="save.gif" alt="save" /> 
                    
事例 2d

事例 2d では、alt 属性ではなく、title 属性を用いて「save」という名前 (name) を指定している。

コード例:

<input type="image" src="save.gif" title="save" />
                    
事例 2e

事例 2e は、コンテンツ制作者が input 要素の 'alt' 属性と 'title' 属性の両方を指定する場合、ユーザエージェントが名前 (name) をどのように決定するかを明らかにする。この場合、ユーザエージェントは、 'alt' 属性 ("save") を使用して、 'title' 属性を無視する。

コード例:

<input type="image" src="save.gif" alt="save" title="save the file" />

事例 3: 入力フィールド

事例 3a

事例 3a では、入力フィールドが「編集可能テキスト」という役割 (role) を持っている。label 要素の for 属性が、input 要素の id 属性を参照することで、label 要素を input 要素と関連付けている。input 要素の名前 (name) は、label 要素で指定した「Type of fruit」となる。値 (value) は、value 属性の「bananas」となる。

コード例:

<label for="text_1">Type of fruit</label>
<input id="text_1" type="text" value="bananas">
事例 3b

事例 3b では、入力フィールドが事例 3a と同じ役割 (role) を持つが、値 (value) がなく、名前 (name) を title 属性で指定している点が異なる。

コード例:

<input id="text_1" type="text" title="Type of fruit">

事例 4: チェックボックス

事例 4 は、input 要素の type 属性から「チェックボックス」という役割 (role) を持っている。label 要素の for 属性が input 要素の id 属性を参照することで、label 要素を input 要素と関連付けている。input 要素の名前 (name) は、label 要素で指定した「Cheese」となる。状態 (state) は checked 属性で「チェックあり」又は「チェックなし」に設定できる。そのコントロールに対する利用者のインタラクションによって、状態 (state) が変更される。

コード例:

<label for="cb_1">Cheese</label> 
<input id="cb_1" type="checkbox" checked="checked">
                    

事例 5: ラジオボタン

事例 5 は、input 要素の type 属性から「ラジオボタン」という役割 (role) を持っている。input 要素の名前 (name) は、label 要素から与えられる。状態 (state) は、checked 属性によって「チェックあり」又は「チェックなし」に設定できる。状態 (state) は、利用者が変更できる。

コード例:

<input type="radio" name="color" id="r1" checked="checked"/><label for="r1">Red</label>
<input type="radio" name="color" id="r2" /><label for="r2">Blue</label>
<input type="radio" name="color" id="r3" /><label for="r3">Green</label>
                    

事例 6: セレクトメニュー

事例 6a

事例 6a は、select 要素によって「リストボックス」という役割 (role) を持っている。名前 (name) は「Numbers」で、label 要素から与えられている。select 要素に名前 (name) を付け忘れるのは、よくあるエラーの一つである。値 (value) は、selected 属性 (XHTML では値を "selected" と指定) のある option 要素であり、初期値は「Two」ということになる。

コード例:

<label for="s1">Numbers</label>
<select id="s1" size="1">
 <option>One</option>
 <option selected="selected">Two</option>
 <option>Three</option>
</select>
                    
事例 6b

事例 6b では、事例 6a の select 要素と同じ名前 (name)、役割 (role)、値 (value) であるが、名前 (name) を title 属性で指定している点が異なる。この方法は、ラベルを視覚的に表示しないほうがよい場合に用いることができる。

コード例:

<select id="s1" title="Numbers" size="1">
 <option>One</option>
 <option selected="selected">Two</option>
 <option>Three</option>
</select>
                    

事例 7: テキストエリア

事例 7a

事例 7a は、textarea 要素の「編集可能なテキスト」という役割 (role) を持っている。名前 (name) は、label 要素で指定した「Type your speech here」である。値 (value) は、textarea 要素内にある「Four score and seven years ago」である。

コード例:

<label for="ta_1">Type your speech here</label>
<textarea id="ta_1" >Four score and seven years ago</textarea>
                    
事例 7b

事例 7b は、同じ役割 (role) を持ち、名前 (name) は title 属性を用いて指定していて、値 (value) は空である。

コード例:

<textarea id="ta_1" title="Type your speech here" >Four score and seven years ago</textarea>
                    

事例 8: フォームコントロールのグループ化

ラジオボタンのフィールドセット

事例 8 のラジオボタンのフィールドセットには「グループ化」という役割 (role) がある。名前 (name) は legend 要素によって与えられている。

コード例:

<fieldset>
  <legend>Choose a Color:</legend> 
     <input id="red" type="radio" name="color" value="red" /><label for="red">Red</label><br /> 
     <input id="blue" type="radio" name="color" value="blue" /><label for="blue">Blue</label><br /> 
     <input id="green" type="radio" name="color" value="green" /><label for="green">Green</label> 
</fieldset>
                    

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. HTML のソースコードを調べる。

  2. リンク及びフォーム要素に対して、上記の表で示されているように、名前 (name)、値 (value)、状態 (state) が指定されていることを確認する。

期待される結果

  • 上記 2. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H93: ウェブページの id 属性値が一意的 (ユニーク) であるようにする

適用 (対象)

HTML のウェブページすべて

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、異なる要素に同一の id 属性値があることによって、支援技術がコンテンツを解析しようとする際に問題が生じるエラーを回避することである。このエラーは、ウェブページに重複した id 属性値がないことを確認することによって回避できる。人的に確認することができるほか、HTML のバージョンを特定するメカニズムを用いて HTML 文書をバリデートすることによって確認することが可能である。コンテンツ制作者が利用できるバリデータがいくつかあり、この種のエラーはバリデーションの結果レポートで言及される。このようなバリデーションに文書型宣言は絶対に必要というわけではないが、文書型宣言を明記することによってバリデータをより容易に使用できるようになる。

事例

事例 1: HTML バリデータ

HTML のウェブページに文書型宣言 (!DOCTYPE 宣言ともよばれる) がある。コンテンツ制作者は、オフラインまたはオンラインのバリデータ (下記の参考リソースを参照) を用いて、あるウェブページで同一の id 属性値が一度だけしか用いられていないことを確認することができる。例えば、W3C のバリデータは、ある id 属性値が 2 回使われているのを発見すると、「ID "X" はすでに定義済みである」というふうにレポートする。

参考リソース

検証

手順

  1. そのウェブページで、すべての id 属性値が一意であることを確認する。

期待される結果

  • 1. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H94: 要素には重複した属性がないようにする

適用 (対象)

全ての HTML ページ

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、同一の要素に重複した属性があることによって、支援技術がコンテンツを解析しようとする際に問題が生じるエラーを回避することである。このエラーは、人的に確認することができるほか、HTML のバージョンを特定するメカニズムを用いて HTML 文書をバリデートすることによって確認することが可能である。コンテンツ制作者が利用できるバリデータがいくつかあり、この種のエラーはバリデーションの結果レポートで言及される。このようなバリデーションに文書型宣言は絶対に必要というわけではないが、文書型宣言を明記することによってバリデータをより容易に使用できるようになる。

事例

事例 1: HTML バリデータ

HTML のウェブページに文書型宣言 (!DOCTYPE 宣言ともよばれる) がある。コンテンツ制作者は、オフラインまたはオンラインのバリデータ (下記の参考リソースを参照) を用いて、あるウェブページで同一の id 属性値が一度だけしか用いられていないことを確認することができる。例えば、W3C のバリデータは、ある要素で同じ属性が 2 回使われているのを発見すると、「"X" 属性が重複している」というふうにレポートする。

参考リソース

検証

手順

  1. 同一の要素で 2 回以上使われている属性がないことを確認する。

期待される結果

  • 1. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H95: キャプションを提供するために、track 要素を使用する

適用 (対象)

HTML5

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、タイミングを指定したテキストのキャプショントラックを video 要素に指定するために HTML5 track 要素を用いることである。テキストのタイミングのとれたキャプショントラックは、音声が利用できない又は明確に聞こえない場合に適した、会話、効果音、関連する音楽の合図、及びその他の関連する音声情報の転写又は翻訳を含む。

track 要素の src 属性は URL であり、これはテキストトラックデータのアドレスである。

track 要素の kind 属性はタイミングを指定したテキストの情報の種類を指示している。キャプションテキストトラックはダイアログおよび他ビデオを理解するために重要な音声のテキストバージョンを提供している。字幕は発話コンテンツのみを含んでいる。もしほかの音声情報がビデオを理解するために重要なのであれば、字幕トラックは達成基準を満たすために十分ではない。

注記: 一部の領域では、オーディオトラックの表示可能なテキスト表示に「字幕」という用語が使われている。 制作者は、kind=captions ではなく、kind=subtitles として、オーディオトラックの言語でタイミングを指定したテキストのトラックをマークアップすることができ、関連するオーディオ情報を追加することある。 そのようなタイミングを指定したテキストトラックは達成基準 1.2.2 の要件を満たすつもりであったのに、キャプションを見つけようとする利用者を混乱させる可能性があるので、この状況で字幕を使用することは好事例ではない。

事例

事例 1: 一つの言語におけるキャプション

英語のキャプショントラックを持つ、英語ビデオのための video 要素。キャプションは WebVTT フォーマットで提供されている。

コード例:


			 <video poster="myvideo.png" controls>
				 <source src="myvideo.mp4" srclang="en" type="video/mp4">
				 <track src="myvideo_en.vtt" kind="captions" srclang="en" label="English">
			  </video>
            

事例 2: 複数の言語におけるキャプション

英語のキャプショントラックを持つ、英語ビデオのための video 要素。キャプションは WebVTT フォーマットで提供されている。

コード例:


			  <video poster="myvideo.png" controls>
				<source src="myvideo.mp4" srclang="en" type="video/mp4">
				<source src="myvideo.webm" srclang="fr" type="video/webm">
				<track src="myvideo_en.vtt" kind="captions" srclang="en" label="English">
				<track src="myvideo_fr.ttml" kind="captions" srclang="fr" label="French">
			  </video>            

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

動画を再生するために用いられる各 video 要素において:

  1. 動画の言語で kind キャプションの track 要素を含むことを確認する。

期待される結果

  • 上記 1. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H96: 音声解説を提供するために、track 要素を使用する

適用 (対象)

HTML5

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、タイミングを指定したテキストの音声解説トラックを video 構成要素に指定するために HTML5 track 要素を用いることである。タイミングの指定されたテキストの音声解説トラックは、視覚的な構成要素が隠れていたり、使えなかったり、使うのに不適であったりしたときの音声合成のための、メディア資源のビデオ構成要素のテキスト記述を含む。ユーザエージェントは視覚的でない方法で、例えばそれらを音声合成することによって、利用者にきっかけを使えるようにする。

track 要素の src 属性は URL であり、これはテキストトラックデータのアドレスである。

音声解説のきっかけは、メディア資源の聴覚的な構成要素で利用可能なギャップに収まる必要がある。トラックキューの時間間隔内に記述テキストを合成するのに十分な時間がない場合、ユーザエージェントはスピーチを切り捨てることがある。 これにより、追加可能な補足情報の量が制限される。

ユーザエージェントは、解説が完全に同期するまでビデオを一時停止し、そしてビデオを再開することで拡張音声解説もサポートしうる。

事例

事例 1: 複数言語における音声解説

英語ビデオのための video 要素。音声解説は WebVTT フォーマットで提供されている。

コード例:


			 <video poster="myvideo.png" controls>
				<source src="myvideo.mp4" srclang="en" type="video/mp4">
				<track src="myvideo_en.vtt" kind="descriptions" srclang="en" label="English">
			  </video>
            

事例 2: 複数言語における音声解説

ビデオに英語とフランス語両方のソース要素を含み、WevVTT (vtt) ファイルフォーマットを使った英語とフランス語の音声解説を持つ video 要素。

コード例:


			 <video poster="myvideo.png" controls>
				<source src="myvideo.mp4" srclang="en" type="video/mp4">
				<source src="myvideo.webm" srclang="fr" type="video/webm">
				<track src="myvideo_en.vtt" kind="descriptions" srclang="en" label="English">
				<track src="myvideo_fr.vtt" kind="descriptions" srclang="fr" label="French">
			  </video>            

事例 3: 一つの言語におけるキャプション

音声解説トラックを持つ「グーグル自動走行車」の video

コード例:


			<video controls tabindex="1">
				<source src="cdgQpa1pUUE.webm" type="video/webm">
				<source src="cdgQpa1pUUE.mp4" type="video/mp4">
				<track id="audesc" src="cdgQpa1pUUE.vtt" kind="descriptions" label="English descriptions" srclang="en-us"></track>
			</video>            

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

動画を再生するために用いられる各 video 要素において:

  1. 動画の言語で kind 説明の track 要素を含むことを確認する。

期待される結果

  • 上記 1. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H97: nav 要素を使用して、関連したリンクをグループ化する

適用 (対象)

関係のあるリンクを含む HTML5 文書

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、HTML5 nav 要素を使ってナビゲーションリンクをグループ化することである。nav 要素は、HTML5 のいくつかの区分される要素の一つである。このマークアップを使うと、スクリーンリーダーのような支援技術の利用者が過去に場所を確認してスキップしたリンクを分類するのが容易になる。セマンティックな構造を使うと、カスタムスタイルシートでそれらの関係性を維持しながらリンクのグループの提示を変更できる。nav 要素がページ上で複数回使用されている場合は、aria-label 又は aria-labelledby 属性を使用してナビゲーショングループを区別する。

リンクのグループ全てを nav 要素でマークアップする必要は無い。例として、リンクはリストのような他の構造にグループ化されることもあり、またはページの分離されたセクションを表現しない場合 ARIA マークアップを使うこともある。

訳注: WAIC では H97 に関するアクセシビリティ サポーテッド(AS)情報を提供している。

2020 年 3 月版の アクセシビリティ サポーテッド(AS)情報: H97 も参照されたい。

事例

事例 1: 一つの nav 要素に囲まれたナビゲーションリンク

この例は、アクセシビリティカリキュラムにおけるナビゲーションリンクを分類するために nav 要素を使う。

コード例:


				 <nav>
				    <a href="../webaccessibility.html">Web Accessibility</a>
				    <a href="../docaccessibility.html">Document Accessibility</a>
					<a href="../mobileaccessibility.html">Mobile Accessibility</a>
				 </nav>
            

事例 2: 多くの nav 要素

この例は、文書中に一つ以上の nav 要素があるときに、ナビゲーション分類を識別するために aria-label 属性と nav 要素を使う。

コード例:


			<nav aria-label="Site menu">
			  <ul>
				  <li>...a list of links site navigation link here ...</li>
			  </ul>
			</nav>
			...
			<article>
			  <nav aria-label="Related links">
				...a list of related links here ...
			  </nav>
			</article>          

事例 3: 一般的な多くの nav 要素

以下の例は、同じページに二つ以上のナビゲーションメニューが存在し、ラベルとして参照されうるページ上に既存のテキストが無いという状況での良い事例である。

コード例:


			<nav aria-label="primary">
				<a href="home.html">Home</a>
				<a href="about-us.html">About Us</a>
				<a href="products.html">Products</a>
			</nav>
			<nav aria-label="secondary">
				<a href="adverts.html">Our Advertisers</a>
				<a href="related.html">Related Links</a>
				<a href="subsidiaries.html">Subsidiaries</a>
			</nav>            

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

  1. 視覚的に寄せ集められておりページのセクションを表現するリンクが nav 要素で囲まれていることを確認する。

期待される結果

  • 上記 1. の結果が真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。