🗂️ Design Materials：アクセシビリティからデザインを学ぼう。アクセシブルなフォームを作成するためのベストプラクティス

Webアクセシビリティとは、障害者など心身の機能に制約のある人でも、さまざまな条件に関わらず、ウェブで提供されている情報にアクセスし利用できることを意味します。

しかし、現在のインターネットの多くは、まだ障害を持つユーザーに対応するようにデザインされていません。 たとえば、Deque Systemsの調査によると、視覚障害を持つ人々はWebサイトの70％にアクセスできませんでした。

Deque Systemsが委託した調査によると、特定の業界のインターネットWebサイトの70％は、視覚障害者がアクセスできず、69億ドルの市場を失っています。

Deque Systems

アクセスできないフォームは、単に思いやりがないだけでなく、ビジネスの妨げになります。逆にアクセシビリティを念頭に置いてデザインすれば、誰もがあなたのWebサイトから必要なものを取得することができて、インクルーシブなデザインであるだけではなく、ビジネスの成長にも役立つのです。

幸い、HTMLを使用してアクセシブルなフォームを作成するのは非常に簡単です。 これらのベストプラクティスを使用すると、視覚障害、認知障害のある人、およびキーボードを使用してWebをナビゲートしている人がフォームにアクセスできるようになります。

キーボードナビゲーションをサポートする

視覚障害または運動機能に障害のある人は、キーボードを使用してオンラインフォームをナビゲートします。

タブキーを使用すると、ユーザーはリンクとフォームコントロール間を移動できます。一部の人々は、能力に関係なく、マウスを使用するよりも手で簡単で高速であるため、この方法でナビゲートすることを好みます。

セマンティックHTMLフォーム要素を使用する
セマンティック要素は、<form>や<button>など、名前がその目的を明確に識別するコードです。 <div>などの非セマンティック要素は、タグ内にどのような種類のコンテンツが含まれているかを示しません。

セマンティックHTML要素を使用してWebサイトをコーディングすると、タブキーがフォームフィールド間を自動的に移動します。

フォーカススタイリングを使用する

キーボードナビゲーターがどのフィールドが選択されているかを認識できるように、フォームに強力な視覚的手がかりが必要です。タブキーでフィールドを選択するときは、対照的な色のボックスで囲む必要があります。

インターネットの「アクセシビリティバイブル」であるワールドワイドウェブコンソーシアム（W3C）によると、14ポイント未満のテキストのコントラスト比は少なくとも4.5対1である必要があります。

CSSスタイルシートに追加できるフォーカス・スタイリング・スニペットの例を次に示します。

&:focus {     
outline: 3px solid #2E1BA6;     
border-color: transparent;   
}

フォーカススタイリングは、デザインを犠牲にする必要があるという意味ではありません。 十分なコントラストがある限り、ブランドの色に合わせてボックスの色をカスタマイズできます。 キーボードとマウスのナビゲーションにさまざまな視覚的手がかりを設定することもできます。Spotifyはこのアプローチを採用しました。 ここで、カーソルでその近くにカーソルを合わせると、右上のダウンロードボタンが緑色に変わります。

Tabキーで同じボタンを選択すると、その周りにもライトボックスが表示されます。

プレースホルダーテキストではなく、明確なビジュアルラベルを使用する

プレースホルダー・テキスト（フォームフィールドの時的なコピー）は、ユーザーに多くの問題をもたらします。

ここでは、フォーム・フィールドのタイプ（電話番号）とフォーマットの手順（XXX-XXX-XXXX）の両方がプレースホルダーテキストに含まれています。これは、インターネットで見られるアクセシビリティの失敗の例です。

テキストの色とフォームフィールドの背景のコントラストが低いため、視覚障害者は読みにくいことがよくあります。さらに、スクリーンリーダーは、プレースホルダーテキストを検出しないことがよくあります。

このデザインでは、ユーザーがフィールドを選択するとテキストが消えるため、記憶障害のある方々にも負担がかかります。これらの一時的な指示は、ほぼすべての人にとって苛立たしいものです。 特にオンライン上のマルチタスクに集中している場合は、テキストを忘れがちです。

代わりに、フォームフィールドの上に明確な視覚的ラベルを含めます。 前の例を続けて、フォームの上に「電話番号」を挿入します。

さらにアクセシビリティにしたい場合はフィールドの上に電話番号のフォーマットの詳細も含めます。

ラベルは明確で、フォーマット手順はフィールドの外にあります。

プレースホルダー・テキストを使用して、ユーザーにより多くのコンテキストやヒントを提供することは問題ありません。フォームへの入力に不可欠な情報については、プレースホルダーテキストを避けるのが最善です。

［追加のリソース］：

Placeholders in Form Fields Are Harmful

スクリーンリーダー用のプログラムラベルをコーディングする

スクリーンリーダーのユーザーがフォームにアクセスできるようにするには、ラベルタグ（<label>および</ label>）が必要です。

支援技術は、関連するフォーム入力に到達すると、その中のテキストをアナウンスします。 ラベルタグは、明確な視覚的ラベルも作成します。

<b>Full Name</b>
<input type="text" name="name" id="full-name">

次のようにレンダリングされます。

フォームに適切なラベルを付けたように見えますが、すべてスタイルであり、実体はありません。 スクリーンリーダーは、テキストラベルをフォームフィールドに関連付けることができなくなります。 <label>タグを使用して2つを接続します。

コード内で<label>を<input>に接続する方法は2つあります。

オプション1：ラベルのfor = ""属性を入力のid = ""属性と一致させます。

<label for="full-name">Full Name</label>

<input type="text" name="name" id="full-name">

オプション2：入力を<label>タグ内にコーディングします。

<label>

    Full Name

    <input type="text" name="full-name">

</label>

どちらの方法でも、明確な視覚的ラベルが付いたアクセス可能なフォームフィールドが表示されます。

［追加のリソース］：

Labeling Controls • Forms • WAI Web Accessibility Tutorials

StackPath

フィールドセットと凡例を使用したグループ関連の入力

多肢選択式の質問に論理構造を与えると、スクリーンリーダーがフォームを明確に解釈するのに役立ちます。 ここで<fieldset>タグと<legend>タグが役立ちます。特に、チェックボックスやラジオボタンに関する質問があります。

<fieldset>タグは、入力のグループが一緒に属することをフォームに通知し、<legend>タグは、入力のグループのラベルとして機能します。 コードにこれらの要素が含まれていない場合、スクリーンリーダーを使用しているユーザーには、各オプションのラベルが聞こえますが、回答している質問は聞こえません。

適切な<fieldset>タグと<legend>タグを持つコードは次のようになります。

 <fieldset>
    <legend>Are you a cat person or a dog person?</legend>
    <div>
      <input type="radio" name="animal" value="cat-person" id="cat-person">
      <label for="cat-person">cat person</label>
    </div>
    <div>
      <input type="radio" name="animal" value="dog-person" id="dog-person">
      <label for="dog-person">dog person</label>
    </div>
    <div>
      <input type="radio" name="animal" value="both" id="both">
      <label for="both">both</label>
    </div>
    <div>
      <input type="radio" name="animal" value="neither" id="neither">
      <label for="neither">neither</label>
    </div>
  </fieldset>

コードに<legend>タグがないと、スクリーンリーダーは、猫の人、犬の人、両方の各入力のラベルのみを読み取り、どちらも読み上げません。 しかし、質問は何でしたか？ 「サンダルを履いた靴下を履く可能性が最も高いのは誰ですか？」

この問題は、「はい」または「いいえ」の質問で特に問題になります。 これらの一般的な回答を聞いた後、視覚障害のあるユーザーは、何が求められているのかを推測することさえできません。

コードで<fieldset>タグと<legend>タグを使用して、質問と考えられる応答がすべてのユーザーに明確になるようにします。

［追加のリソース］：

Creating Accessible Forms

Forms | Accessibility Guidelines

Grouping Controls • Forms • WAI Web Accessibility Tutorials

ARIAラベルを使用してスクリーンリーダーに指示を与える

ARIA（アクセス可能なリッチ・インターネット・アプリケーション）は、スクリーンリーダーの説明と情報を含む関連するHTML属性のセットです。 aria-labelやaria-labeledbyなどのこれらの属性は、Webページには何も表示されません。 WebAIMによると、ARIAは、ネイティブHTMLが十分に明確でない場合にのみ使用する必要があります。

ARIA属性は、スクリーンリーダーに依存している人がフォームを理解するために聞く必要のある情報を提供する場合に不可欠です。

たとえば、「検索」というボタンのあるフィールドがあるとします。

このフィールドは視覚的に明確ですが、スクリーンリーダーでアクセスできるようにするには、ARIA属性が必要です。

<input type="text" name="search" aria-label="Search">
  <button type="submit">Search</button>

ほとんどのHTMLと同様に、それを実現する方法は複数あります。 このW3Cチュートリアルは、ARIA属性とネイティブHTMLの両方を使用してアクセシブルなラベリングにアプローチするいくつかの方法を示しています。

ARIAを使用して、日付の書式設定などの指示を提供することもできます。

<label for="DOB">Date of birth:</label>
  <input type="text" name="birthdate" id="DOB" aria-describedby="DOB-help">
  <span id="DOB-help">MM/DD/YYYY</span>

レンダリングは次のとおりです。

属性aria-describebyは、一致するid =“ DOB-help”入力を説明として使用するようにスクリーンリーダーに指示します。 次に、スクリーンリーダーは、指定されたIDに関連付けられている値「MM / DD / YYYY」をアナウンスします。

ARIA属性は、ここで説明するものよりも複雑です。 詳細については、以下の追加リソースを確認することをお勧めします。

［追加のリソース］：

WebAIM: Introduction to ARIA - Accessible Rich Internet Applications

ARIA - Accessibility | MDN

ARIA Landmarks – IT Accessibility

アクセシブルなフォームはパズルの一部

あまりにも頻繁に、アクセシビリティはまだウェブデザインで後付けです。 多くの人々は、支援技術を使っても、依然としてWebをナビゲートするのに苛立たしい経験をしています。 幸いなことに、この記事を読んでいるなら、おそらくもっと上手くやりたいと思うでしょう。 GoogleのLighthouseまたは別のツールを試して、ウェブサイトのアクセシビリティを評価し、改善の機会を特定してください。

私も色々勉強中なので、皆さまのご意見・ご感想をお聞かせください。
お読み頂きまして、ありがとうございました。

メルボルンを拠点にプロダクトデザイナーとして働いています。 主にデジタル・プロダクトの制作に携わっています。