要約
十分にフォームデータを検証し、ユーザーによって送信内容を確認できるようにし、意図しないデータが送信されないようにします。
テクニック
-
フィールドへの入力を簡素化するために、
autocomplete
属性を使用します。[[WCAG-1.3.5]] -
入力エラーを識別し、説明します。[[WCAG-3.3.1]]
-
入力エラーを修正する方法を提案します。[[WCAG-3.3.3]]
-
送信前にユーザーがデータを確認し修正できるようにします。[[WCAG-3.3.4]] および [[WCAG-3.3.6]]
-
ユーザーがデータの送信を取り消せるようにします。[[WCAG-3.3.4]] および [[WCAG-3.3.6]]
解説
フォームへの入力については、必須フィールドをすべて入力したかの確認から、すべてのフィールドに正しく入力されているかの確認まで、ユーザーにとってはいくつもの課題があります。障害を持つユーザーは、フィールドの未入力やエラーが発生した場合に、問題を見つけたり、どこを修正すべきかを把握するのは簡単ではありません。
検証するタイミング
ユーザー入力がデジタル出版物内でのみ行われる場合、データの検証はデータを要求しているページ内で行われます。
サーバー側の検証が行われるのは、コンテンツ製作者が外部のWebアプリケーションにデータを送信するようにした場合です。ただし、このような場合にはコンテンツ製作者はXmlHttpRequestなどのスクリプトAPIを使用し、ページを更新せずにエラーを報告するようにするでしょう。通常、フォームは新しいウィンドウを生成せずにWebサーバーに直接送信することはできません。返されるページが出版物のリソースとして認識されないためです。
したがって、このドキュメントでは、デジタル出版物内からエラーを検証および報告する方法についてのみ扱います。Webアプリケーションから返されるページでのエラーの処理の詳細については、ユーザー通知に関するWebアクセシビリティチュートリアルを参照してください。
組み込みチェック
入力を検証するための最良のオプションは、HTMLに組み込まれているメカニズムを使用することです。
たとえば、 required
属性は、ほとんどのフォーム入力要素で使用できます。これは、ユーザーが入力しなければならないフィールドを識別するためのプログラム的な手段です(目の見えるユーザーには、視覚的な手がかりも必要です)。
required
属性が設定されている場合、ユーザーは、フィールドが入力されるまで、対応したリーディングシステムでフォームを送信できません。送信しようとすると、リーディングシステムから、必須情報が不足していることが警告されます。
pattern
属性を使用すると、コンテンツ製作者は入力を検証するための正規表現を指定できます。この属性は、入力が特定の形式に一致しなければならない場合に便利です。
コンテンツ製作者は、 placeholder
属性を使用して、期待される値のヒントも提供できます。これは、特定のパターンが期待される場合に特に便利です。ただし、この値はユーザーがデータを入力し始めると消えてしまうため、フィールドの適切なラベルや説明の代わりとして使用しないでください。
autocomplete
属性は、ユーザーが正しい情報を入力できるようにするためのもう一つの潜在的な簡易手段です。この属性を設定すると、ユーザーは保存されたフォームデータを自動的に挿入できます。
出版物におけるこの属性の欠点は、ほとんどのフォームがユーザー情報を収集しないこと、一般的にテスト用であること、さらにアプリケーションベースのリーディングシステムが以前に送信されたデータを再利用のために保存しないことです。この属性は、限られた情報に対してブラウザーで実行されるリーディングシステムでのみ機能する可能性があります。
最小と最大の値や、入力する文字数の最小値と最大値を指定する属性、また、正規表現を使用してユーザーが入力したテキストを検証する属性もあります。
input
要素のtype
属性は検証では見落とされがちですが、これによりコンテンツ製作者は入力するのが電話番号や電子メールアドレスなどの一般的なフィールドであることを識別できます。
これらの特殊な入力タイプには、独自の組み込み検証がよくあります。たとえば、電子メールフィールドが指定されている場合、ユーザーエージェントはユーザーが有効な電子メールアドレスを入力したかどうかを確認します。これらの組み込みタイプを使用すると、一般的なテキスト入力フィールドに対して複雑で冗長なパターンチェックを記述する必要がなくなります。
入力エラーの特定
組み込み検証のメカニズムを使用すると、リーディングシステムはエラーがある場合にユーザーに通知できますが、すべてのデータ検証にこれらのメカニズムを使用することはできません。カスタムデータフィールドを検証する場合、ユーザーにとってエラーを見つけて修正するプロセスを可能な限り容易にする必要があります。
手動検証の一般的なアプローチは、見えやすく明確にラベル付けされた、フォームの上部にあるボックスに、入力エラーのリストを書き込むことです。この手法は一般的には問題ありませんが、支援技術を使用するユーザーを支援するために、エラーを含む要素は、ARIA ロールのalert
を使用してライブ領域としてマークする必要があります。これにより、要素に新しいテキストが書き込まれたときにそれをアナウンスできます。
エラーをリストする唯一の手段としてJavaScriptアラートボックスを使用するのは避けてください。ダイアログが閉じられると、通常、ユーザーはリストにアクセスできなくなります。認知障害や学習障害のあるユーザーにとって、修正が必要な複数のフィールドを覚えておくのが困難な場合があります。
より良い方法は、アラートは、送信内容に修正が必要なエラーが含まれていることをユーザーに通知するためだけに制限し、ダイアログが閉じたときにページ上のリストにユーザーを誘導する方法です。
エラーをリストするときに、無効なフィールドへのリンクを提供すると役立ちます。
デジタル出版物の場合は、ユーザー入力を入力時に検証する方がよい選択肢となる場合が多いです。これにより、エラーの動的なリストを追加および削除する必要がなくなります。
もちろん、無効なフィールドは視覚的に識別され、目の見えるユーザーがデータを確認する際に見つけられるようにする必要がありますが、ARIAには無効なフィールドをプログラムでマークするためのaria-invalid
属性があります。
aria-invalid
属性を設定すると、ユーザーは支援技術によってエラーのあるフィールドに簡単に移動できるため、ユーザーはエラーのリストに依存したり、フォーム内のすべてのフィールドを手動で確認して何が失敗したかを調べる必要がなくなります。
ユーザーがエラーを修正したら、必ずaria-invalid
属性を更新または削除してください(aria-invalid=""
が設定されていると、フィールドが無効ではないことを意味するので注意してください)。
エラーの説明
エラーの特定に加えて、フィールドが無効とマークされている理由の説明もユーザーには役立ちます。ARIA aria-errormessage
を使用すると、コンテンツ製作者は問題の説明を無効なフィールドにリンクできます。
aria-errormessage
は、aria-describedby
と機能が似ていますが、添付された説明が問題の説明であることをより明確に示します(aria-errormessage
は、 aria-invalid
のある要素でのみ使用できる点に注意してください)。
エラーメッセージにaria-live
属性を設定して、エラーメッセージが追加されたときにユーザーに通知するようにもできます(前の例を参照)。個々のエラーフィールドがこのように識別される場合には、問題の全リストを追加するときにユーザーに警告するのは推奨しません(ユーザーはすべてのエラーを二回聞くことになるため)。
場合によっては、入力したデータが無効であることだけをユーザーに伝えることもできますが、データが無効である具体的な理由が特定できる場合は、エラーメッセージにできるだけ正確な内容を含めることをお勧めします。ユーザーに提供する情報が多いほど、エラーを修正しやすくなります。
提出内容の確認
フォームデータがコンテンツ製作者の期待どおりに検証されることと、ユーザーが意図した情報を入力することは、別です。たとえば、ユーザーは情報を入力するときにタイプミスに気付かない場合や、気付かないうちにフィールドが誤って変更される場合があります(たとえば、矢印キーを押すと、選択ボックスやラジオボタンの選択が誤って変更される場合があります)。
フォームデータを送信する前に確認するオプションをユーザーに提供することは、情報がユーザーの期待と一致していることを確認するのに役立ちます。特に、入力用のフォームデータを詳細に確認することは、すべてのユーザーにとって難しいことがあります。
確認を提供することはテストデータのレベルAAの要件であるため、教育出版社は、デジタルに埋め込むテストやクイズにこの達成基準が適用される場合、ユーザーのためにデータを修正するか、元に戻して再送信できるようにする必要があります。これについては次のセクションで説明します。
ただし、デジタル出版物内でこの種の独立した検証を提供することは、多くの場合困難です。これは、フォームと同じページに情報を動的に書き込む必要があり、すべてのリーディングシステムがこれを適切にサポートしているわけではないためです。同様に、JavaScriptアラートを使用すると、非常に小さなデータセットでは機能するかもしれませんが、大量のデータを送信するとすぐに読みにくくなります。
ユーザーがフォームをサーバーに直接送信できることがコンテンツ製作者に判っている場合(つまり、リーディングシステムが JavaScript API経由でデータを送信するのではなく、新しいブラウザーウィンドウを開いてデータを送信する場合)、確認ページはサーバー側で提供できます。通常この方法は、ユーザーがアクセスできるリーディングシステムが制限されている特定の場合に限り利用できます。
注記
デジタル出版物内にのみ残るデータは、外部ソースに送信されるデータよりもレビューの重要性が低いことがよくあります。これは、間違いによってユーザーに生じる潜在的な損害がそれほど大きくない傾向があるためです。たとえば、デジタル出版物内で採点された模擬試験をレビューすることは、学校のサーバーに送信されたコースの演習をレビューすることよりも重要性が低くなります。
提出を元に戻す
前のセクションで述べたように、元に戻したり修正したりするオプションを提供するよりも、送信前にユーザーがデータを確認できるようにする方がはるかに優れています。
これは特にデジタル出版物の場合に当てはまります。フォーマットの制限により、データの取得と修正の手段が複雑になるからです。たとえば、デジタル出版物内で情報を保持するのは、ストレージオプションが限られているため容易ではありません(つまり、出版物を閉じた場合、ユーザーは後でフォームの送信を取り消すために簡単に戻ることができません)。同様に、データが送信された後、ネットワークの問題により出版物側では送信の確認を受信できず、ユーザーが元に戻せない場合があります。
ユーザーが提出を取り消すことを許可する必要がある場合、コンテンツ製作者は情報収集のための他のオプションを真剣に検討する必要があります。たとえば、可能な場合は、フォームを埋め込むのではなく、出版物の外部にあるフォームにユーザーを誘導して情報を収集します。
提出をデジタル出版物を通じて行わなければならない場合、提出の取り消しや修正については、ユーザーの身元確認ができる外部Webサイトを通じてのみ行うのが現実的です。たとえば、コースポータルによって、出版物自体を通じて取り消しや間違いの修正を行うのではなく、取り消しや間違いの修正を行う方法を提供できます。
関連リンク
- HTML —一般的な
input
要素の属性 - HTML —
type
属性のステート