WordPress の DIY アクセシビリティ テストのヒント

今日の世界では、ゲームの名前はインクルージョンです。 また、Web アクセシビリティは新しい概念ではありませんが、近年、Web アクセシビリティ自体がよりアクセスしやすくなっています。

Web アクセシビリティとは、Web サイトをできるだけ多くのユーザーが機能できるように設計および構築することです。 目の不自由なユーザーは、晴眼者、色覚異常、または運動能力に障害のあるユーザーとは異なる方法で Web サイトを操作します。

2008 年にバージョン 2.0 として最初にリリースされ、World Wide Web Consortium (W3C) によって開発された Web Content Accessibility Guidelines (WCAG) は、Web アクセシビリティのゴールデン スタンダードです。 現在のバージョンである WCAG 2.1 は、Web アクセシビリティ分野のベスト プラクティスを 4 つの異なるカテゴリ (知覚可能、操作可能、理解可能、堅牢) で概説しています。 次のバージョンである 2.2 は 2022 年末にリリースされ、既存のガイドラインをさらに定義し、いくつかの新しいガイドラインを追加する予定です。

さらに、アクセシビリティは WordPress コミュニティに根付いており、アクセシビリティのベスト プラクティスをソフトウェア自体に組み込むことに取り組んでいます。 一部の WordPress 開発者は、テーマやプラグインでそれ以上のことを行っています。 たとえば、WPExplorer 独自の Total テーマはアクセシビリティを常に最前線に置いているため、開発者の AJ は頻繁にアクセシビリティの改善を自分で行っています。

WordPress のアクセシビリティは非常に重要であり、ナビゲートは以前ほど難しくありません。 Web サイトの再設計プロジェクトに取り組んでいる場合、または既存の Web サイトに新しい機能を追加するだけの場合でも、サイトを現在のアクセシビリティ基準に合わせるのに役立つ、設計および構築プロセス中に考慮すべきいくつかの項目を以下に示します。

設計と初期構築

WordPress プロジェクトの期間中は、Web アクセシビリティ標準を考慮する必要があります。 ビルド後のテスト プロセスでは、最初のビルドで見逃されたエラーが検出される可能性がありますが、最初のビルドで可能な限り "クリーン" にサイトをビルドすることをお勧めします。 Web サイト プロジェクトのこのフェーズでは、次の点を考慮してください。

色のコントラスト

アクセシビリティをテストする最も簡単な Web 要素の 1 つは色です。 WCAG 2.1 は、Web サイトの任意の 2 色 (前景と背景)に対して特定の色のコントラスト比を指定します。 コントラスト比は、通常のサイズのテキスト (18pt 未満) の場合は少なくとも 4.5:1、より大きなテキスト (18pt 以上) の場合は 3:1 である必要があります。

しかし、色のコントラスト比とはどのようにしてわかりますか? 20 年以上にわたって Web アクセシビリティの信頼できるリーダーである WebAim は、色のコントラスト比をチェックするための優れたツールを作成しました。 前景色の 16 進コードと背景の 16 進コードを追加すると、ツールがコントラスト比を計算します。 比率が十分に高くない場合は、スライダーを使用して各色の値を調整し、同じカラー ストーリー内で合格の組み合わせを決定するのに役立てることができます。

幸いなことに、Web サイトでさまざまな色のオプションを変更して試してみることは、比較的簡単なプロセスです。 WordPress のネイティブ Gutenberg ビルダーを使用すると、コンテンツ ブロック全体の色を簡単に変更したり、任意の数の特定の単語を具体的にターゲットにしたりできます。 テーマ パネルで調整を行って、全体的な色を編集することもできます。

代替色

最近では、ほとんどのサイトが大量の画像で設計されています。 しかし、さまざまな理由から、必要な情報をすばやく簡単に取得するために、サイトの画像やスタイルをオフにしているユーザーがいる場合があります。

大きな画像と白いテキストが上部にあるパネルがあるとします。 Web ブラウザーで画像をオフにすると、サイトの背景がデフォルトで白になります。 その白いテキストは、白い背景では見えなくなりました。 それが行動を促すフレーズや価値提案などの重要なコンテンツだったとしたらどうでしょうか?

これらの問題を解決するには、サイトのすべてのパネルにフォールバック カラーを追加し、テキストを画像の上に配置してください。 前の例では、そのパネルの代替色を黒に変更すると問題が解決し、白いテキストが表示されます。 フォールバック カラーとして使用する色がわからない場合は、Web Aim のカラー コントラスト ツールが役立ちます。

複数のナビゲーション オプション

優れたメニュー デザインは、サイトの際立った機能になる可能性がありますが、複数のナビゲーション オプションを含めることも重要です。 サイトのナビゲーションが別の方法で提示された場合、一部のユーザーは探している情報をより速く見つけることができる場合があります。

Web サイトのフッターにリンクされたサイトマップは、優れたソリューションになる可能性があります。 これにより、ユーザーは利用可能なすべてのページを 1 つの領域で見ることができ、ユーザー エクスペリエンスを向上させることができます。 WP サイトマップ ページ プラグインは、ページ、ブログ投稿、ケース スタディ、ポートフォリオ アイテムなどを一覧表示できるシンプルなサイトマップを簡単に追加するための確実なオプションです。

もう 1 つのオプションは、サイトに検索機能を追加して、ユーザーがサイト全体をすばやく検索して特定のキーワードやフレーズを検索できるようにすることです。 デフォルトでは、WordPress にはサイドバーまたはフッターで使用できる基本的な検索ウィジェットが含まれていますが、Gutenberg (および他のほとんどのページ ビルダー) 内にも検索ブロックがあり、多くの場合、テーマ開発者は検索ボックスまたはアイコンをテーマ ヘッダーに組み込みます。 さらに、さまざまな便利なプラグインを使用して、WordPress の検索機能をカスタマイズおよび改善できます。

アクセシビリティ フィードバック フォーム

ウェブサイトのフッターは、理想的にはアクセシビリティフィードバック フォームへのリンクでもあるべきです。 可能な限り多くのアクセシビリティ対策を講じたとしても、ガイドラインとテクノロジーが進化してユーザーにより適切に対応できるようになるにつれて、常に改善の余地があります。

アクセシビリティ フィードバック フォームを含むページを含めると、ユーザーは、Web サイトのアクセシビリティに関する追加のコメントや懸念事項を送信できます (アクセシブルな WordPress フォームを使用することを忘れないでください)。 また、あなたが彼らの Web エクスペリエンスを気にかけていることを彼らに知らせます。 次に、このフィードバックを使用して、そのユーザーと同様の宿泊施設を必要とする将来のユーザーのためにサイトを改善できます。 コミュニティの声に耳を傾け、必要に応じて調整することは、プロセスの重要な部分です。

ビルド後のテスト プロセス

サイトの大部分が構築されたら、より詳細なアクセシビリティ テストを開始します。 これには、自動テストと手動テストを含める必要があります。 自動テストは、特定の問題を検出するための優れたリソースであり、時間の節約にもなります。 ただし、アクセシビリティは人間に基づく問題であり、AI は存在するすべてのニュアンスを認識できません。 したがって、サイトの特定の要素を手動でテストすることも同様に重要です。

自動テスト

スムーズなアクセシビリティ ワークフローを促進するためのさまざまな優れた自動テスト ツールがあります。 自動化されたテストに合格するだけでは、サイトをアクセス可能にするのに十分ではありませんが、それは素晴らしい出発点であることを覚えておくことが重要です。

サイトが基本的なアクセシビリティ基準を満たしているかどうかを簡単に確認するための WAVE ツールは、基本的に Web ページをスキャンし、WCAG の失敗と追加の調査が必要な項目を報告する自動評価ツールのコレクションです。 ブラウザ拡張機能を利用することで、WAVE ツールは明らかなアクセシビリティ障害を赤で示します。 それらは誤差とコントラスト誤差に分けられます。 エラーは通常、サイトのコーディングに関連しています。 コントラスト エラーは、配色がコントラスト基準を満たしていない場合に発生します (記事の前半で説明しています)。

サイトのコントラスト エラーに対処する準備ができたら、Equalize Digital Accessibility Checker などのプラグイン オプションを使用して、サイトのバックエンド内で調整プロセスを効率化できます。 プラグインの無料版は、ページと基本的な投稿を自動的にチェックして、各ページの通常のエラーとコントラスト エラーを報告します。 プロ版にアップグレードすると、カスタム投稿タイプのスキャンが可能になります。 プラグインを使用すると、コード内のエラーを簡単に特定し、必要に応じて変更できます。

手動テスト

前述のとおり、自動テストに使用できる現在のツールと法的手続きには制限があります。 WAVE ツールと Equalize Checker は、自動スキャンの優れたリソースであり、時間を大幅に節約できます。 しかし、人間が作成する AI は、障害を持つ実際の人間のユーザーと同じ配慮を必要としません。

サイトを手動で確認し、障害のあるユーザーが使用している可能性のあるツールを使用して、ナビゲーションと情報収集が可能かどうかを確認することが重要です。 手動で確認する必要があるいくつかの側面には、ページ ズーム機能、キーボード ナビゲーション、スクリーン リーダー、代替テキストなどがあります。

ページ ズーム テストでは、コンテンツや機能を失わずにページを 200% までズームインできるかどうかを確認する必要があります。 これは、ブラウザーのネイティブ ズーム機能のみを使用して可能であり、他の支援技術は使用しないでください。 また、拡大するときにユーザーが両方向 (上下と左右) にスクロールする必要がないことも確認する必要があります。

一部のユーザーは、マウスを使用して Web サイトをナビゲートできない (または使用したくない) 場合があります。 代わりにキーボードを使用してナビゲートし、多くの場合、TAB キーとその他のいくつかのキーを使用して要素間を移動します。 キーボード ナビゲーションのテストでは、キーボードがその要素をターゲットにしたときに、サイトのインタラクティブな要素にフォーカス アウトラインが表示されることを確認する必要があります。 また、すべてのホバー機能をチェックして、TAB が非表示のコンテンツを明らかにすることを確認します。 このプロセスは困難な場合がありますが、重要なページから始めて、各ページをタブで移動してみてください。 すべてのコンテンツとリンクに正しくアクセスできますか?

スクリーン リーダーのテストは、テクノロジがよりニッチであるため、最も難しい場合があります。 スクリーン リーダー ユーザーのサイトのアクセシビリティを確認する最善の方法は、実際にスクリーン リーダーを使用してサイトを実行することです。 ウェブページの階層は明確ですか? ヘッダーを正しく使用し、スクリーン リーダーの必要に応じて特定の要素を示していますか?

手動でのテストは時間がかかる可能性があり、使用可能なすべての支援ツールがサイトにアクセスできることを確認するのは困難です。 ただし、これらの宿泊施設は見過ごされがちなので、非常に重要なステップです。

今日の世界では、包括性が最善のポリシーです。 アクセシビリティの高い Web サイトは、より多くの訪問者があなたの会社に関する情報を入手し、潜在的に手を差し伸べることができることを意味します。 ADA に準拠した特定の Web サイト要件はまだありませんが、一部のユーザーが次のステップを実行するために必要な Web サイト上の情報にアクセスできない場合、潜在的な顧客や顧客を失うことになります。

アクセシビリティの旅の出発点として、この記事に記載されている情報を使用してください。 コミュニティにより良いサービスを提供するために標準とガイドラインが頻繁に更新されるため、Web アクセシビリティは継続的なプロセスであることを忘れないでください。 心を開いてこの世界にアプローチし、それがオープンとクローズのプロセスではないことを理解してください。 結局のところ、すべてのユーザーのユーザー エクスペリエンスを向上させることがすべてです。