フォームとアクセシビリティ

フォームはテーブルと同様、視覚的な表現を伴わないと理解しにくいところがあります。HTML4.0では、フォームの各要素とラベル(説明的な名前)を結びつける手段や、要素をグループ化する手段が提供されました。これらを使うとフォームの内容を論理的に構造化でき、スタイルシートとの組合せで自在なデザインも可能になってきます。まだ未対応のブラウザが多い要素ですが、アクセシビリティに配慮したページづくりのためにも、このような機能があることをぜひ理解しておいてください。

目次:

取り上げる要素: label fieldset legend optgroup

コントロールにラベルを付ける

フォームの入力コントロール(テキストフィールドやメニューなど)は、name属性を持ちますが、それは送信データに名前を付けるだけで画面上には表示されません。そこで多くの場合にはコントロールの隣に説明文(ラベルといいます)を加えています。しかしこれは、コントロールの説明が画面表示の状態に依存しているわけで、ブラウザの表現方法によっては関連性が不明確になりかねません(音声ブラウザなどでは、コントロールのどちら側にある文字がその説明なのか、判別不能です)。

HTML4では、コントロールと説明情報(ラベル)を関連づけるために、新たにlabel要素が導入されました。label要素によるコントロールのラベル付けは、明示的な方法と暗黙的な方法の2つがあります。

明示的なラベル付け

ラベルを付けるコントロール要素にid属性を加え、label要素にそのidを示すfor属性を加えます。label要素の内容がコントロールの説明(ラベル)になります。

(例)

<label for="uname">氏名:</label><br />
<input type="text" name="username" id="uname" />

この方法は曖昧さがなく、また一つのコントロールに複数のラベルをつける(複数のlabel要素がfor属性で同じidを参照する)こともできます。また、label要素とコントロールの間に他の要素があっても構いません。

フォームのコントロールのname属性a要素タイプの場合と異なり、所属するフォームの中だけでの識別名で、id属性とは名前空間を共有しません(id属性は常に文書中で重複不可です)。そのため、この例ではname属性とid属性には異なる値を使っています。

暗黙的なラベル付け

コントロールをlabel要素で囲むことで、ラベルの対応関係を暗黙的に示します。

(例)<label>氏名:<input type="text" name="username" /></label>

label要素の内容には、一つのコントロールしか含めることができません。いちいちfor属性やid属性を示す必要がなく簡単ですが、フォームのコントロールをtable要素を使って整列しているような場合には用いることが来ません(label要素の内容モデルはインライン要素に限られます)。

label要素のメリット

label要素を使うと、グラフィカルブラウザでも、ラベル文字列をクリックすることでコントロールが反応する(ラジオボタンが選択されたり、テキストボックスが入力状態になる)というメリットがあります。小さなラジオボタンをクリックするのは、環境や利用者の条件によっては難しいこともあるため、クリックできる範囲が広がることで操作が容易になるわけです。

なお、IEのバージョン5/6は、明示的なlabel要素にのみ対応しているようです。お使いのブラウザで、次のラジオボタンの“ラベル部分”を選択してみてください。

(表示例)

明示的なラベル付け:

暗黙的なラベル付け:

コントロールをグループ化する

入力項目が増えると、関連するコントロールがグループ化されている方が分かりやすくなります。HTML4では、複数のコントロールおよびラベルを論理的にグループ化するfieldset要素と、そのグループにキャプションを付けるlegend要素が導入されました。

(記述例)

<fieldset>
  <legend>個人情報</legend>
  <label for="uname">氏名:</label>
    <input type="text" id="uname" name="username" />
  <label for="addr">住所:</label>
    <input type="text" id="addr" name="address" />
</fieldset>
<fieldset>
  <legend>希望内容</legend>
  <label for="dest">渡航先:</label>
    <input type="text" id="dest" name="destination" />
  <label for="date">渡航日:</label>
    <input type="text" id="date" name="date" />
</fieldset>

コントロールをグループ化し、スタイルシートでfieldset要素の表現を工夫すれば、さらに使いやすいフォームになります。ただし、これらの要素に対応しないブラウザでは、legend要素とlabel要素が連続してしまってかえって区別しにくくなる場合もあるので、互換性を考えた使い方をしなければなりません。

(表示例)

個人情報
希望内容

なお、fieldset要素内のlegend要素は、XHTMLではオプション扱いとなっていますが、HTML4の場合は必須です。次の2つを比べてください。前者がXHTML1.0でのfieldset要素タイプの内容モデル、後者がHTML4.01での内容モデルです。

(#PCDATA | legend | %block; | form | %inline; | %misc;)*

(#PCDATA, LEGEND, (%flow;)*)

これらの内容モデルでは、legend要素の前に文字(#PCDATA)が記述できるように読めますが、DTDのコメントで、ここで許されるのは空白文字に限ると制限が課されています。また、XHTMLの場合は他の要素タイプと順不同になっていますが、legend要素を記述する場合はfieldset開始タグの直後でなければならないとコメントがあります。

メニュー項目のグループ化

select要素によるメニューは、選択肢が多くなると使いにくくなります。そこで、選択肢のoption要素をグループ化するために、optgroup要素が用意されました。グループにはlabel属性で名前を付けることができます。

(記述例)

<select name="area">
  <optgroup label="首都圏">
    <option>東京都</option>
    <option>千葉県</option>
    <option>神奈川県</option>
    <option>埼玉県</option>
  </optgroup>
  <optgroup label="京阪神">
    <option>大阪府</option>
    <option>京都府</option>
    <option>奈良県</option>
    <option>兵庫県</option>
  </optgroup>
</select>

上の例のような都道府県を選択するメニューの場合、地域ごとにoption要素をoptgroup要素でくくると、メニューの表示はたとえばoptgroup要素のlabel属性が列挙され、サブメニューの形でそのグループに属するoption要素が選択できるといった形になります。Mac版IE5が階層化メニューとして実装しているほか、IE6、Mozilla/Netscape6、iCabも対応しており、これをうまく適用するとアンケートフォームがかなり使いやすくなるでしょう。

(表示例)

上記例のメニューをMacIE5で表示した場合→

optgroupが階層メニューになっている

このブラウザでは↓

キーボードによる項目移動

フォームで値を入力するためには、コントロールを“選択”しなければなりません。たとえばマウスでコントロールをクリックするというのも一つの方法ですが、環境によってはキーボードで対象を選択することもあります。一般にキーボードである項目を選択するためには、TABキーなどで順番に項目を移動していくか、何らかのショートカットキーと組み合わせて直接項目を指定するという方法が採られます。

TAB選択の順序

TABキーなどによる選択は、通常、選択可能項目を文書の先頭から順番に移動していくことになります。必要に応じて、この選択順序を変更できると都合がよいことがあります。このためにHTML4で用意されているのがtabindex属性です。

tabindexはひとつの文書全体での選択順序を指定するもので、0〜32767の範囲の任意の数字を割り当てます。番号が小さいものから順番に選択されます。番号が0もしくはtabindexを割り当てていない要素は、そのあとで順次選択対象になります。

tabindexはinput, select, textareaといったフォームコントロールの他に、a要素やobject, button, area要素にも割り当てることができます。

(記述例)

<form action="...">
 <table>
  <tr>
   <td>住所:<input type="text" name="addr" tabindex="1" /></td>
   <td><a href="dummy.html" tabindex="6">住所記入の注意</a>
  </tr>
  <tr>
   <td>氏名:<input type="text" name="name" tabindex="2" /></td>
   <td><a href="dummy.html" tabindex="7">氏名記入の注意</a>
  </tr>
  <tr>
   <td>年齢:<input type="text" name="age" tabindex="3" /></td>
   <td><a href="dummy.html" tabindex="8">年齢記入の注意</a>
  </tr>
 </table>
</form>

上記のようなテーブルを使っている場合、TABキーを押していくと、入力コントロールと注意書きのアンカーが交互に選択されますが、tabindexを指定することで、入力コントロールを先に順番に選択させることができます。ここでは住所入力欄のtabindexが1になっているので、ほかに同じtabindexを持つ要素がなければ、フォームが文書の最後にあっても、文書を開いてTABキーを1回押すだけでこの項目にジャンプします。

(表示例)

住所記入の注意
氏名記入の注意
年齢記入の注意

ただし、tabindexをサポートしないブラウザではこの指定は意味を持ちませんし、そもそもTABキーではアンカー要素が選択されないブラウザもあります。

キーボードショートカット

TABキーで順番に選択する代わりに、特定の文字キーとショートカットキーの組合せで直接その要素を選択(あるいは実行)させる方法がHTML 4のaccesskey属性です。この属性が使えるのは、a, area, button, input, label, legend, textareaの各要素です。

(記述例)

<input type="radio" name="area" value="tokyo" accesskey="t" /> 東京地区[T]
<input type="radio" name="area" value="osaka" accesskey="k" /> 京阪神地区[K]
<input type="radio" name="area" value="nagoya" accesskey="c" /> 中京地区[C]
<input type="radio" name="area" value="other" accesskey="o" /> その他[O]

たとえばラジオボタン型inputaccesskeyを割り当てると、ショートカットキーでボタンを選択することができます。フォームのコントロールなら「選択」が一般的な動作ですが、a要素の場合は要素を選択するだけではなく、そのリンク先までジャンプするブラウザもあります*

(表示例)

エリア: 東京地区[T] 京阪神地区[K] 中京地区[C] その他[O]

accesskeyを働かせる「ショートカットキー」は、機種やブラウザによって異なります。たとえばWindows用のIEならAltキーと、Macintosh用のIEならControlキーとの組合せでショートカットが働きますが、同じMacintosh用ブラウザでもiCabなら単に割り当てられた文字キーのみでaccesskeyが働きます。

iCabではボタンの横に小さく文字が表示されてアクセスキーが分かる

上はiCabで表示したラジオボタンの一部分です。このように、accesskeyを割り当てた要素の隣に小さくその文字を表示してくれるブラウザもありますが、そこまで親切ではないブラウザの場合は、上記の例のようにラベルにアクセスキーを記述しておかないと分からないでしょう。このあたりはまだ実装が未熟な部分で、今後スタイルシートとの組合せなどで使いやすくなっていくことが期待されます。

選択か実行か

accesskeyに対応するキーを押したときに、その要素が選択(focus)されるのか実行(activate)されるのかは、解釈が曖昧で、ブラウザによって実装が異なります。特に、リンク(a要素)にaccesskey属性を割り当てたときに、アンカーを選択するだけなのか直接リンク先のページに移動するべきなのかは、WAIのメーリングリストでも意見が分かれているという状況です。HTML4の仕様書は

Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the A element, the user agent generally follows the link. (17.11.2)

としているのですが、これは「a要素がフォーカスを受けた場合、(=利用者によるアクティベートであるという飛躍があって)UAは一般的にリンクをたどる」と読めてしまいます。a要素のaccesskeyをリンクをたどるとしているブラウザ(iCab, Mozilla, MacIE, Amayaなど)は、たぶんこれをストレートに解釈しているのでしょう。 しかしフォーカスとは、例えばUAAG

The user may "set" content focus (programmatically or through the user interface) on an enabled element without triggering the associated behaviors.

と定義するように、基本的には機能を働かせることとは別のものです。こうした考えに従い、accesskeyを押すとアンカーを選択するだけのブラウザ(Win IEなど)もあり、混乱します。UAAGのチェックポイントが

Allow configuration so that moving the content focus to or from an enabled element does not automatically activate any explicitly associated event handlers.(9.5 No events on focus change)

と示すように、accesskeyについても、どんな動作をするのかユーザーが設定できるようになるのが一番望ましいのだと思いますが、なかなかそんな環境は実現しそうにありません。