WordPress の DIY アクセシビリティ テストのヒント
今日の世界では、ゲームの名前はインクルージョンです。 Web アクセシビリティは新しい概念ではありませんが、近年、Web アクセシビリティ自体がよりアクセスしやすくなりました。
Web アクセシビリティの核心は、できるだけ多くのユーザーにとって機能する Web サイトを設計および構築する実践です。視覚障害のあるユーザーは、晴眼者、色覚異常、または運動能力に障害のあるユーザーとは異なる方法で Web サイトを操作します。
Web コンテンツ アクセシビリティ ガイドライン (WCAG) は、2008 年にバージョン 2.0 として最初にリリースされ、World Wide Web Consortium (W3C) によって開発された、Web アクセシビリティの黄金標準です。現在のバージョンである WCAG 2.1 では、Web アクセシビリティ分野におけるベスト プラクティスを 4 つの異なるカテゴリー (知覚可能、操作可能、理解可能、堅牢) で概説しています。次のバージョン 2.2 は、既存のガイドラインをさらに定義し、いくつかの新しいガイドラインを追加するために 2022 年末にリリースされる予定です。
さらに、アクセシビリティは WordPress コミュニティに根付いており、ソフトウェア自体にアクセシビリティのベスト プラクティスを組み込むことに尽力しています。 WordPress 開発者の中には、テーマやプラグインをさらに超えたものを開発する人もいます。たとえば、WPExplorer 独自の Total テーマはアクセシビリティを常に最前線に置いており、開発者の AJ 自身も頻繁にアクセシビリティの改善を定期的に行っています。
WordPress のアクセシビリティは非常に重要であり、以前ほどナビゲートするのは難しくありません。 Web サイトの再設計プロジェクトに取り組む場合、または既存の Web サイトに新しい機能を追加する場合でも、サイトを現在のアクセシビリティ基準に適合させるために、設計および構築プロセス中に考慮すべきいくつかの項目を以下に示します。
設計と初期構築
Web アクセシビリティ標準は、WordPress プロジェクトの期間全体を通じて考慮する必要があります。ビルド後のテスト プロセスでは、最初のビルドで見逃されたエラーが検出される可能性がありますが、最初はサイトをできるだけ「クリーン」にビルドすることが常に最善です。 Web サイト プロジェクトのこの段階では、次の点を考慮してください。
色のコントラスト
アクセシビリティをテストする最も簡単な Web 要素の 1 つは色です。 WCAG 2.1 では、Web サイト上の任意の 2 色 (前景と背景) の特定の色のコントラスト比を指定します。コントラスト比は、通常サイズのテキスト (18 ポイント未満) の場合は少なくとも 4.5:1、大きいテキスト (18 ポイント以上) の場合は 3:1 である必要があります。
しかし、色のコントラスト比はどうやってわかるのでしょうか? 20 年以上にわたって Web アクセシビリティの信頼できるリーダーである WebAim は、色のコントラスト比をチェックするための優れたツールを作成しました。前景色の 16 進コードと背景色の 16 進コードを追加すると、ツールがコントラスト比を計算します。比率が十分に高くない場合は、スライダーを使用して各色の値を調整して、同じカラー ストーリー内で合格する組み合わせを決定することができます。
幸いなことに、Web サイトのさまざまな色のオプションを変更して試すのは比較的簡単なプロセスです。 WordPress のネイティブ Gutenberg ビルダーを使用すると、コンテンツのブロック全体の色を簡単に変更したり、任意の数の特定の単語をターゲットにしたりすることができます。テーマ パネルで調整を行って、全体的なカラー編集を行うこともできます。
フォールバックカラー
最近では、ほとんどのサイトが大量の画像を使用してデザインされています。しかし、さまざまな理由から、必要な情報をより早く簡単に入手するために、サイト上の画像やスタイルをオフにしているユーザーもいるかもしれません。
大きな画像とその上に白いテキストが表示されたパネルがあると想像してください。 Web ブラウザで画像がオフになっている場合、サイトの背景はデフォルトで白になります。その白いテキストは白い背景では見えなくなります。それが行動喚起や価値提案などの重要なコンテンツだった場合はどうなるでしょうか?
これらの問題を解決するには、画像の上にテキストを含むサイト上のすべてのパネルに代替カラーを必ず追加してください。前の例では、そのパネルのフォールバック色を黒に変更すると問題が解決され、白いテキストが表示されます。代替色としてどの色を使用すればよいかわからない場合は、Web Aim カラー コントラスト ツールが優れたガイドになります。
複数のナビゲーション オプション
優れたメニュー デザインはサイトで目立つ機能になりますが、複数のナビゲーション オプションを含めることも重要です。サイトのナビゲーションが別の方法で表示されていれば、探している情報をより早く見つけられるユーザーもいるかもしれません。
ウェブサイトのフッターにリンクされているサイトマップは、優れた解決策となる可能性があります。これにより、ユーザーは利用可能なすべてのページを 1 つのエリアで確認できるようになり、ユーザー エクスペリエンスが向上する可能性があります。 WP Sitemap Page プラグインは、ページ、ブログ投稿、ケーススタディ、ポートフォリオ アイテムなどをリストできるシンプルなサイトマップを簡単に追加できる確実なオプションです。
もう 1 つのオプションは、サイトに検索 機能を追加して、ユーザーが特定のキーワードやフレーズをサイト全体ですばやく検索できるようにすることです。デフォルトでは、WordPress にはサイドバーやフッターで使用できる基本的な検索ウィジェットが含まれていますが、Gutenberg (および他のほとんどのページビルダー) 内にも検索ブロックがあり、テーマ開発者はテーマヘッダーに検索ボックスやアイコンを組み込むことがよくあります。さらに、さまざまな便利なプラグインを使用して、WordPress の検索機能をカスタマイズおよび改善できます。
アクセシビリティに関するフィードバック フォーム
ウェブサイトのフッターには、アクセシビリティのフィードバック フォームへのリンクも理想的には必要です。可能な限り多くのアクセシビリティ手順を講じたとしても、ユーザーにより適切に対応するためにガイドラインとテクノロジーが進化するにつれて、常に改善の余地があります。
アクセシビリティ フィードバック フォームを含むページを含めると、何かが不足していて訪問が制限されている場合に、ユーザーは Web サイトのアクセシビリティに関する追加のコメントや懸念事項を送信できるようになります (アクセシビリティ対応の WordPress フォームを使用することを忘れないでください)。また、あなたが彼らの Web エクスペリエンスを重視していることを伝えることもできます。このフィードバックを使用して、そのユーザーや同様の対応を必要とする将来のユーザーのためにサイトを改善できます。コミュニティの意見に耳を傾け、必要に応じて調整することは、プロセスの重要な部分です。
ビルド後のテストプロセス
サイトの大部分が構築されたら、より詳細なアクセシビリティ テストを開始します。これには、自動テストと手動テストが含まれる必要があります。自動テストは、特定の問題を発見するための優れたリソースと時間を節約します。ただし、アクセシビリティは人間ベースの懸念事項であり、AI は存在するすべてのニュアンスを認識することはできません。したがって、サイトの特定の要素を手動でテストすることも同様に重要です。
自動テスト
スムーズなアクセシビリティ ワークフローを促進するさまざまな優れた自動テスト ツールがあります。自動テストに合格するだけではサイトにアクセスできるようにするのに十分ではありませんが、出発点としては優れていることを覚えておくことが重要です。
サイトが基本的なアクセシビリティ標準に合格しているかどうかを簡単に確認するには、WAVE ツールを使用します。これは基本的に Web ページをスキャンし、WCAG エラーや追加の調査が必要な項目を報告する自動評価ツールのコレクションです。ブラウザ拡張機能の助けを借りて、WAVE ツールは明らかなアクセシビリティ障害を赤色で示します。これらはエラーとコントラストエラーに分けられます。エラーは通常、サイトのコーディングに関連しています。コントラスト エラーは、配色がコントラスト標準 (記事の前半で確認した) に満たない場合に発生します。
サイトのコントラスト エラーに対処する準備ができたら、サイトのバックエンド内の調整プロセスを効率化できる Equalize Digital Accessibility Checker などのプラグイン オプションがあります。無料版のプラグインは、ページと基本的な投稿を自動的にチェックして、各ページの通常のエラーとコントラスト エラーを報告します。プロバージョンにアップグレードすると、カスタム投稿タイプのスキャンが可能になります。プラグインを使用すると、コード内のエラーを簡単に特定し、必要に応じて変更を加えることができます。
手動テスト
前述したように、自動テストに利用できる現在のツールと法的プロセスには制限があります。 WAVE ツールと Equalize Checker は自動スキャンに最適なリソースであり、時間を大幅に節約できます。しかし、人間が作成した AI には、障害を持つ実際の人間のユーザーと同じような配慮は必要ありません。
サイトを手動で確認し、障害のあるユーザーが使用している可能性のあるツールを使用して、ナビゲーションと情報収集が可能かどうかを確認することが重要です。手動で確認する必要がある項目には、ページ ズーム機能、キーボード ナビゲーション、スクリーン リーダー、代替テキストなどがあります。
ページのズーム テストでは、コンテンツや機能を失うことなくページを 200% にズームできるかどうかを確認する必要があります。これは、ブラウザのネイティブ ズーム機能のみを使用して、他の支援テクノロジを使用せずに可能です。また、ズームインするときにユーザーが両方向 (上下および左右) にスクロールする必要がないことも確認する必要があります。
一部のユーザーは、Web サイト内を移動するためにマウスを使用できない (または使用したくない) 場合があります。代わりにキーボードを使用して移動し、要素間を移動するには TAB キーとその他のいくつかのキーを使用することがよくあります。 キーボード ナビゲーション テストでは、サイト上のインタラクティブな要素がキーボードでターゲットされたときに、その要素にフォーカスのアウトラインが表示されることを確認する必要があります。また、すべてのホバー機能をチェックして、TAB で非表示のコンテンツが表示されることを確認します。このプロセスは気が遠くなるかもしれませんが、主要なページから始めて、各ページを TAB キーで移動してみてください。すべてのコンテンツとリンクに正しくアクセスできますか?
このテクノロジーはよりニッチであるため、スクリーン リーダーのテストは最も難しい場合があります。スクリーン リーダー ユーザーに対するサイトのアクセシビリティを確認する最良の方法は、スクリーン リーダーを使用してサイトを実際に実行することです。あなたのウェブページの階層は明確ですか?ヘッダーを正しく使用し、スクリーン リーダーの必要に応じて特定の要素を示していますか?
手動テストには時間がかかる場合があり、使用可能なすべての支援ツールにサイトがアクセスできることを確認するのは困難です。ただし、これは非常に重要なステップであり、そうしないとこれらの宿泊施設が見逃されてしまう可能性があります。
今日の世界では、包括性が最善の政策です。 Web サイトがアクセス可能であるということは、より多くの訪問者があなたの会社に関する情報を入手し、潜在的に連絡を取ることができることを意味します。 ADA に準拠した Web サイトに関する具体的な要件はまだありませんが、一部のユーザーが次のステップに進むために必要な Web サイト上の情報にアクセスできない場合、潜在的な顧客やクライアントを失うことになります。
この記事に記載されている情報を、アクセシビリティへの取り組みの出発点として使用してください。コミュニティにより良いサービスを提供するために標準やガイドラインが頻繁に更新されるため、Web アクセシビリティは継続的なプロセスであることを忘れないでください。オープンな心でこの世界に取り組み、それが開閉式のプロセスではないことを理解してください。結局のところ、すべてのユーザーのユーザー エクスペリエンスを向上させることが重要です。