アクセシビリティを理解する: パート 5

これが私たちが議論したい最後の原則です。大まかに言えば、Web サイトのコンテンツとナビゲーションは理解しやすくなければならないと述べています。これらの推奨事項の多くを実装する責任はプラグインまたはテーマの「エンド ユーザー」 (またはコンテンツを公開する人) にありますが、これらのプラグインやテーマの開発者が実装できる推奨事項もいくつかあります。

読み取り可能(3.1)

最初のガイドラインでは、コンテンツは「読みやすく、理解しやすい」ものでなければならないと述べています。提案の多くは、コンテンツの読解レベルや、開発者には関係のない珍しい単語、略語、頭字語の使用に関するものです。

私たちが実装できる推奨事項の 1 つは、Web ページの人間の言語をプログラムで識別できるようにすることです。これを行うには、lang 属性を介して 要素で言語を指定する必要があります。さらに、コンテンツが右から左へ書くかどうかを示すために、dir 属性を使用する必要があります。

WordPress は、必要な属性を出力する language_attributes() を提供することでこれを簡素化します。テーマの header.php:

リーリー

language_attributes() この関数は言語を設定し、必要に応じて Web サイトの方向を設定し、出力をフィルタリングして、プラグイン (多言語プラグインなど) が必要に応じて属性を変更できるようにします。

予測可能 (3.2)

2 番目のガイドラインでは、Web サイトは予測可能な方法で表示および動作する必要があると述べています。推奨事項の多くは、テーマの HTML マークアップが適切に構造化され、論理的であることを確認することで実装できます。それ以外にも、「してはいけない」アドバイス、つまり Web ページの自然かつ論理的な動作を壊すような変更を加えないようにするためのアドバイスがたくさんあります。

集中行動

このシリーズの 4 番目の記事 (「アクション可能」) で、tabindex を使用しないことについて説明しました。この推奨事項は、アイテムがフォーカスを取得したときに、ページの状態に何らかの変化を引き起こすものと見なされるべきではないという声明に基づいています。

たとえば、フォーム ボタンがフォーカスを受け取るとフォームが送信されたり、リンクがフォーカスを受け取るとリンクがアクティブになったりしてはなりません。これは、対応する項目がフォーカスを受け取ったときに、ナビゲーション メニューのツールチップやサブメニューが表示されるべきではないということではありません。これらの例はステータスの変更を構成するものではありません。大まかに言えば、フォーカスされている項目は、カーソルが置かれている項目と同等です。

フォーカスを妨げないでください

フォーカスを受け取る要素からフォーカスを削除することは避けてください。たとえば、次のようなことは決して行わないでください:

リーリー

ユーザー入力が必要な場合にユーザーをサポートする (3.3)

エラーが確実に認識されるようにする

デフォルトでは、テーマ開発者に関連するフォームは、ログイン/登録、検索、およびコメント フォームのみです。これらのうち、テーマ開発者は通常、後者の 2 つにのみ焦点を当てます。フォームを検索しても「エラー」が発生することはないため、このセクションではコメント フォームに焦点を当てます。

WordPress は、ユーザーにエラーを通知し、エラーの内容を正確に伝えるという優れた機能を備えています。ただし、これは、ユーザーが元のページから移動できるようにし、「行き止まり」エラー ページを表示することによって行われます。

ユーザーが元のページに戻ると、フォームはフォーカスを失うため、フォームを再度見つける必要があります。より良い解決策は、ユーザーがフォームに正しく入力する前にフォームを送信できないようにすることです。ただし、これを行う場合は、入力された値が無効であることをユーザーに伝える必要があります。そうしないと、事実上、ユーザーを罠にはめてしまうことになります。

利用可能なクライアント側検証スクリプトが多数あり、独自の単純な検証スクリプトを構築するのは非常に簡単です。重要なのは:

1. ユーザーが無効な値を含むフィールドを離れた後 (またはフォームを送信しようとした後) に表示されるエラー メッセージは、エラーの存在とその場所 (つまり、識別フィールド) を伝える必要があります。
2. エラー メッセージは、ARIA 属性: role="alert" を使用してアラートとして識別する必要があります。
3. 必要に応じて、エラー メッセージは、入力された値が受け入れられなかった理由をユーザーにできるだけ明確に通知する必要があります。

これは、WebAIM 独自のアクセシブル フォーム検証の例 (必ず読むことをお勧めします) に基づいた簡単な例で、名前フィールドが空の場合にエラー メッセージを追加します。

リーリー

WebAIM サンプルは、ユーザーがフィールドを無効にすることを防ぎ、フィールドにフィールドを返してエラーを修正します。これを行う場合は、値が空のときに ではなく ユーザーをフィールドに戻すことをお勧めします。そうしないと、フォームを送信するつもりがなく誤ってフィールドにフォーカスを与えたユーザーをイライラさせることになります。

このシリーズの前半で述べたように、意味を伝えるために色や配置だけに頼るべきではありません。この場合、エラー メッセージは、関連するフィールドと同様に、テキストから明らかである必要があります。

タグを提供する

テーマは comment_form() を使用してコメント フォームのみを表示でき、これによりタグがアクセス可能な方法で処理されます。同様に、デフォルトの検索フォームではそれ以上の作業は必要ありません。ただし、これらのフォームをカスタマイズまたは設計するときは、次のことを行う必要があります。

ラベルが常に表示されていることを確認してください

タグは常に表示される必要があります。具体的には、プレースホルダーはタグを構成しないため、検索に使用すべきではないことを意味します。これにはいくつかの理由があります:

1. 对屏幕阅读器的支持不一致。
2. 占位符通常采用柔和的颜色，可能难以阅读。
3. 由于当字段获得焦点时占位符会消失，因此可能会给有认知障碍的人带来可用性问题。

在适当的情况下提供进一步说明

如果表单字段需要进一步的说明，可以在字段之后提供这些说明，但仍然使用 aria-scribedby 属性显式链接到该字段。该属性引用的元素的内容在field的标签后面读出。

以 W3C 网站为例：

<form> 

    <label for="fname">First name</label> 
    <input name="" type="text" id="fname" aria-describedby="fname-description"> 
    
    <p id="fname-description">A bit of instructions for this field linked with aria-describedby. </p> 

</form>

但是，您应该注意，屏幕阅读器对此的支持并不一致。

确定必填字段

必填字段应使用 aria-required="true" 属性进行标记。由 comment_form() 生成的默认 WordPress 评论表单已处理此问题，因此您需要在此处执行任何操作。但是，如果您选择自定义评论表单，则应该注意这一点。

结论

本文总结了我们关于 W3C 可访问性原则的粗略主题开发人员指南以及如何实施这些原则。在本系列的最后一篇文章中，我们将研究一些简单的方法，以进一步推动并积极鼓励和帮助我们的主题（或插件）的最终用户生成可访问的内容。

以上がアクセシビリティを理解する: パート 5の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。