ウェブ・アクセシビリティはプロセスであり、すぐに解決できるものではない

デジタル・インクルージョンの推進と導入に関して、企業が犯しがちな、そして最大の過ちの1つは、アクセシビリティをWebサイトのプロセスに組み込むのではなく、開始日と終了日を決めた即効性のあるプロジェクトとしてアプローチすることです。

ウェブアクセシビリティをその場しのぎの対策にとどめてしまうと、ユーザーエクスペリエンスの低下、収益の低下、見込み客の遠ざけ、さらには罰金や訴訟などのリスクが生じます。

デジタルインクルージョンとは?

デジタルインクルージョンとは、ウェブをはじめとするデジタル技術を、利用したいと思うすべての人にとってバリアフリーにすることです。もっと広い意味もありますが、デジタル・インクルージョン戦略は、まずウェブ・アクセシビリティから始めるべきです。アクセシブルなWebサイトとは、誰もが利用できることを意味します。つまり、商品の購入、情報のダウンロード、リクエストの送信など、すべてのウェブサイト訪問者が同じようにウェブサイトを利用できるようにする必要があります。

すべてのサイト訪問者にとって真にインクルーシブなデジタル体験を実現するためには、アクセシビリティを後付けするのではなく、設計・開発プロセスに継続的に組み込むことが最適です。

ウェブアクセシビリティがプロジェクトではなくプロセスである理由

アクセシビリティは、一回限りのプロジェクトとして後からウェブサイトに「追加」できるものだという誤解が、時間の経過とともにウェブサイトのアクセシビリティが低下する主な原因の一つとなっています。また、アクセシブルであると主張しているにもかかわらず、実際にはアクセシブルではないウェブサイトが多いのもこのためです。

アクセシビリティとインクルーシブデザインの原則は、継続的なプロセスとしてすべての組織に組み込まれているべきです。しかし、多くの企業はアクセシビリティを後から追加することを選択しており、実際のユーザー体験よりもコンプライアンス上のボックスにチェックを入れることを重視しています。これでは、企業とそのウェブサイトのユーザーの両方にとって、意図しない、あるいは悲惨な結果を招くこともあります。例えば、お客様にとって重要な情報が含まれているにもかかわらず、アクセスできない何百もの長いPDFファイルを修正する必要が生じた場合などです。

多くの場合、このような方法でアクセシビリティに取り組むと、アクセシビリティの問題が初めて明らかになるのは、Webプロジェクトの品質保証やユーザー受け入れの段階、あるいは発売後になります。この時点では、複雑なアクセシビリティの問題は、すでに完了した作業を全面的に見直さなければならないかもしれません。

Webサイトの開発や再設計の初期段階からアクセシビリティを組み込むことは、既存のサイトに後から別のプロジェクトとしてアクセシビリティを改善するよりも、はるかに簡単で、費用もかからず、効果的であることがほとんどです。 -W3C

コード、コンテンツ、デザインのどれを扱うにしても、作業の後に「アクセシビリティ・チェック」をするのではなく、作業の前や作業中にアクセシビリティのベストプラクティスを追加することで、チームはプロジェクトをより迅速に、効果的に、予算内で、純粋にアクセシビリティに配慮して完成させることができます。

インクルーシブデザインの原則を最初から取り入れることのメリット

インクルーシブデザインをウェブデザインや開発プロセスの原則とすることは、倫理的には当然のことですが、それ以外にもメリットがあります。

  • アクセシビリティを含めたユーザーエクスペリエンスを考慮したデザインは、障害のある人だけでなく、すべてのユーザーにとってより良いユーザーエクスペリエンスをもたらします。また、他のマーケティング施策と連携させることで、特に検索エンジン最適化の取り組みにプラスの影響を与えることができます。画像にaltテキストを追加したり、読み込み時間を短縮したり、論理的なナビゲーションを実現するなど、インクルーシブデザインを実践することで、Googleなどの検索エンジンにポジティブに認識されるからです。
  • アクセシブルなサイトは、より幅広いターゲット層を対象としています。米国では、疾病対策予防センター(CDC)の報告によると、6,100万人の成人アメリカ人が何らかの障害を抱えて暮らしています。さらに大きな規模では、世界の人口の約10億人(15%)が何らかの障害を抱えています。
  • アクセシブルなウェブサイトは、ブランドの差別化につながり、競争力を高めることができます。
  • インクルーシブデザインをワークフローの中心に据えることで、問題が早期に発見・解決され、できれば本番前に解決できるため、より効率的でコストのかからないウェブサイトのプロセスが実現します。
  • 国内のアクセシビリティに関する法令を適切に遵守することで、法的リスクを低減します。即効性のあるアクセシビリティソリューションの欠点については、以下をご覧ください。
  • アクセシビリティオーバーレイでは解決できません。その理由は以下の通りです。

    ウェブ・アクセシビリティに取り組むには、相当な時間と労力が必要です。これは、ウェブサイトの規模や複雑さに応じて増加します。

    このような市場ニーズを満たすために、クイックフィックスオーバーレイやアクセシビリティウィジェットを使ってウェブサイトをアクセシブルにすることを約束する企業がアクセシビリティシーンに登場しました。これらのソリューションは、最小限の労力で(多くの場合、1行のコードを挿入するだけで)サイトのアクセシビリティを即座に「修正」し、米国障害者法(ADA)、リハビリテーション法第508条、欧州ウェブ・アクセシビリティ指令、ウェブコンテンツ・アクセシビリティ・ガイドライン(WCAG)などの法律に即座に完全に準拠することを約束します。さらに、Webサイトのワークフローにアクセシビリティを追加したり、サイトのコードを修正したりといった面倒な作業も必要ありません。これは素晴らしいことだと思います。

    残念ながら、オーバーレイをめぐる法的・技術的な問題は深刻で、多岐にわたります。問題の核心は、オーバーレイを使っても、実際には、サイトに真の意味での長期的なアクセシビリティを実現することはできないという事実です。オーバーレイは、スクリーンリーダーなどの支援技術との競合により、サイトに新たなアクセシビリティの問題を引き起こすことが知られています。その上、組織がオーバーレイ・ベンダーの使用をやめた瞬間に、そのサイトの「アクセシビリティ」は消滅してしまいます。

    さらに悪いことに、訴訟を回避する目的でオーバーレイソリューションに投資した企業は、契約したつもりの保護レベルを得られないことが多いのです。2020年には、ウィジェットやオーバーレイに投資した後、約100社が訴訟を受けました。これらの訴訟の中には、ウィジェット機能が障害のあるWebサイトユーザーにとって余計な負担になると指摘するものもありました。

    ウェブサイトのプロセスにアクセシビリティを適切に組み込む方法

    誤解のないように言っておきますが、ウェブアクセシビリティに「終わり」はありません。ですから、ウェブアクセシビリティを1回限りのプロジェクトと考える罠にはまらないでください。コンテンツやコードを変更すると、ウェブサイトに新たなアクセシビリティの問題が発生し、ユーザーエクスペリエンスに悪影響を及ぼす可能性があります。

    ウェブアクセシビリティが決して限定的なプロジェクトであってはならない理由を理解したところで、効果的かつ効率的に取り組むための最良の方法を学ぶことにしましょう。ここでは、インクルーシブデザインをウェブサイトのプロセスやワークフローの中心に据える方法をご紹介します。

    自動アクセシビリティ・チェッカーを使用して、ウェブサイトにエラーがないか定期的にスキャンする。

    Siteimprove Accessibilityのように、自動および手動のアクセシビリティ・サービスを提供する信頼できるアクセシビリティ・パートナーがいれば、デジタル・アクセシビリティの理解、実装、そして重要な維持が容易になります。

    進行中のものであれ、デジタルインクルージョンの初心者であれ、すべてのアクセシビリティの取り組みは、サイトのアクセシビリティの状態を監査することから始める必要があります。最も一般的に使用されている世界的なアクセシビリティ基準に準拠しているかどうかをスキャンするツールを使用することを強くお勧めします。WCAGです。

    アクセシビリティ監査では

    • Webサイトのアクセシビリティ・エラーを検出
    • 適切なチームへのタスクと責任の割り当てを支援
    • アクセシビリティの向上を測定するための基準値の設定
    • 同業他社のサイトとの比較が可能

    何千ページ、何万ページもあるWebサイトを定期的に監査するのは、時間がかかるのはもちろんのこと、大変なことです。幸い、自動化されたアクセシビリティツールは、何千ものページを同時に監査することで、このプロセスを簡素化し、スピードアップすることができます。また、これらのツールは、通常のウェブサイトのメンテナンス、デザイン、および開発プロセスに適合するように設計されています。

    Siteimproveのお客様であるFirst Tech Federal Credit Unionは、自動アクセシビリティ・テストを開発プロセスに組み込むことで、デザインを一新したサイトの立ち上げ前にアクセシビリティの問題を発見することができたと説明しています。

    Siteimproveのアクセシビリティ・チェッカー・プラグインは、サイトのページ作成時に見落としていたいくつかの項目を発見し、それらを解決するためのヒントを示してくれました。 -First Tech Federal Credit Union

    Tips:ヒント PDFスキャン機能を備えたアクセシビリティツールをお探しください。真にインクルーシブなデジタル体験を提供するためには、マルチメディアファイルやPDFを含むすべてのコンテンツがアクセシブルである必要があります。

    プロセスにマニュアルテストを追加する

    多くのアクセシビリティの問題は、自動化されたアクセシビリティ・ツールを使って検出することができますが、中には人間による評価や検証が必要なものもあります。これらの問題には、キーボードのみのコマンド、さまざまな支援技術との互換性、ウェブブラウザの色調整プラグインとの調整などが含まれます。 

    だからといって、外部のコンサルタントや代理店に依頼する必要はありません。ただし、特に大規模で複雑なWebサイトの場合は、手動によるアクセシビリティテストの訓練を受けたアクセシビリティの専門家やパートナーを利用することが正しい判断となる場合もあります。小規模で簡単なチェックであれば、Siteimprove Accessibilityのような自動化されたツールを使えば、WCAGへの適合性を確認するために手動チェックが必要な問題を特定することができます。また、ツール内のヒントを利用すれば、ページタイトルがどれだけ説明的であるかをチェックするなど、段階的に問題を解決する方法をチームに伝えることができます。

    自動化されたテストの結果を再確認したり、自動化されたツールでは見つけられない問題を発見したりすることは、設計や開発のプロセスに手動テストを追加する2つの良い理由です。手動でしか検出できないアクセシビリティブロッカーには、次のようなものがあります。

    • 情報量の多いページタイトルがあること。マニュアルテストでは、ページタイトルがユニークで、意味があり、簡潔であることを確認しています。
    • ナビゲーションをスキップするオプション。手動テストでは、繰り返されるナビゲーション要素をスキップするオプションが存在し、正しく表示されることを確認します。 
    • HTML5とWAI-ARIAの要素を使用しています。これらは、修正が必要なエラーではなく、デジタルアクセシビリティのためのベストプラクティスです。手動テストでは、これらの要素が正しく使用されていることを確認します。

    自動アクセシビリティ・スキャンを定期的に実施するように、手動アクセシビリティ・テストもウェブサイトのメンテナンス・プロセスの一環として定期的に実施する必要があります。

    アクセシビリティのベスト・プラクティスについてチームを教育する

    アクセシビリティは、あるチーム、特に一人の個人が担当するものではありません。Webサイトのすべての関係者がデジタルインクルーシブを正しく理解することで、Webサイト、ひいてはお客様にメリットをもたらすことができるのです。

    アクセシビリティは開発者だけのものではなく、あなたのチームもそれを知る必要があります。つまり、ウェブサイトにデジタルインクルージョンの文化を築くことです。責任者から、長期的にサイトがアクセシブルであることを保証するための変更を実行する人まで、様々な人が関わっています。例えば、「ここをクリックしてください」などの表現に注意を払うべきコンテンツライター、ソーシャルプラットフォームにアクセシビリティを拡大すべきソーシャルメディアマネージャー、ユーザーフレンドリーなコードを構築する必要のある開発チーム、単に色のコントラストが十分な画像を作成するだけでなく、ビジュアルデザイナー、UXデザイナーなどが含まれます。

    ここでもアクセシビリティ・パートナーの助けが必要となります。自動化されたツールの支援を受ければ、アクセシビリティの専門家でなくても、アクセシビリティ・ガイドラインを理解することができます。WCAGガイドラインの遵守を支援するアクセシビリティ・ツールを利用するのがよいでしょう。アクセシビリティのコースやトレーニング、自助努力のためのリソースに加えて、サイトのアクセシビリティ・エラーを理解して解決するための説明や実行可能なガイドラインを提供するツールを探してください。

    ウェブアクセシビリティに関するベストプラクティスを学び、実践することで、将来のアクセシビリティ違反を回避できる可能性も高くなります。インクルーシブデザインのベストプラクティスといえば、WCAGが代表的です。開発者など、ウェブサイトを包括的に扱う人は、WCAGに慣れ親しんでおくとよいでしょう。より広いチームでは、少なくともウェブサイトの4つのアクセシビリティ原則を知っておく必要があります。

    • 知覚可能であること :ウェブサイト上の情報は、ユーザーが容易に認識できる方法で提供されるべきです。 これは、テキストが容易に読めること、マルチメディアコンポーネントに代替手段があること、ウェブデザインが明快で応答性があることを意味します。 
    • 操作可能であること: Webサイトのすべての構成要素およびユーザーインターフェイスは、さまざまなツールを使って簡単に操作できるものでなければなりません。 インターフェースは、シングルモードの入力、複雑なインタラクティブ要素、時間制限のある要素など、障害のあるユーザーが実行できない操作を必要とすべきではありません。    
    • 理解できること :サイトに表示される情報は、すべてのユーザーが容易に理解できるものでなければなりません。そのためには、シンプルなプロセスの設計、サイト上でのさまざまなアクションの予測可能性の向上、ユーザーへの入力支援などが必要です。 
    • 堅牢性:ウェブサイトは、支援技術を使用しているユーザーを含め、さまざまなユーザーが確実に解釈できるようになっていなければなりません。  

    カリフォルニア大学サンタバーバラ校(UCSB)は、組織全体のデジタルインクルージョン教育への取り組みについて、このような話をしてくれました。

    "私たちは、UCSBのスタッフや教員がアクセス可能なコンテンツやアクセス可能なシステムを作成するためのトレーニングに取り組んでいます。アクセシビリティは、ウェブサイトやアプリケーションを構築する際のプロセスの一部です。新しいUC Santa Barbaraブランドに移行する際には、各ユニットがアクセシビリティについての知識を深め、Siteimproveを活用してサイトのユーザーエクスペリエンス、コンテンツの質、検索エンジンの最適化を向上させる方法を学ぶ機会を提供したいと考えています。これを実現するために、個人およびグループでのトレーニングや、キャンパス・コミュニティ内での質問の場を提供しています。また、新しいキャンパス・アクセシビリティ・ポリシーの策定、年間を通してのワークショップ、グローバル・アクセシビリティ・アウェアネス・デイの推進など、アクセシビリティに関する意識向上にも力を入れています。"

    ヒント:組織全体のアクセシビリティ・ポリシーを作成することは、アクセシビリティへの取り組みに全員が参加するための良い方法です。このポリシーには、目標とその達成方法を記載し、従業員がアクセシビリティに関する質問や懸念を提起できる相手を明示する必要があります。このポリシーは、デザインガイドやスタイルガイドにも反映させる必要があります。これらの文書は、合わせて、Webサイトのプロセスを導くアクセシビリティ・インフラストラクチャのバックボーンを形成します。

    ARRMフレームワークによるアクセシビリティの役割分担

    アクセシビリティはすぐに解決できるものではないと認識すると、それを継続的に適切に管理するための構造化されたプロセスが必要であることが明らかになります。

    真のデジタル・インクルージョンは、デザイナー、ソーシャルメディア・マネージャー、開発者、コンテンツ・ライター、経営陣など、ウェブサイトに関わるすべての人が協力して取り組むものです。しかし、指針となるフレームワークなしにウェブアクセシビリティに取り組もうとすると、アクセシビリティへの取り組みを妨げ、さらには台無しにしてしまうような以下のような問題が発生する可能性があります。

    • 役割と要件の不確実性
    • コミュニケーションやチームワークの欠如
    • やるべきことに対するオーナーシップがない 
    • アクセシビリティ要件の解釈の違い 
    • 競合する優先事項 

    誰が、何を、どのように、いつ、行うのかを明確にするためには、明確な構造が必要となります。幸いなことに、World Wide Consortium(W3C)は、まさにそのためのツールとして、Accessibility Roles and Responsibilities Mapping(ARRM)フレームワークを開発しました。

    ARRMは、役割に基づいて、アクセシビリティに関する責任とタスクを定義します。要するに、ARRMは、アクセシビリティ・プロセスに構造を追加し、アクセシビリティに関する知識の共有を促進し、非効率性を低減します。

    ARRMを使用してWebアクセシビリティに取り組む方法については、このブログ記事で詳しく説明しています。

    障がい者をプロセスに組み込む

    アクセシビリティは、単なる法令遵守だけではありません。あなたのウェブサイトが障害者にとっても使いやすいものであることを確認する必要があります。そのため、ユーザビリティ・テストには、Webサイトを障害者に対応させようとしている人たちも含める必要があります。

    障害者がどのようにWebサイトを利用しているかを時間をかけて理解することで、認識されているニーズではなく、実際のニーズに合わせてWebサイトを設計することができます。これは、目の不自由なユーザーだけではありません。ウェブを自由に利用することを妨げる可能性のある他の障害を持つ人のことも考慮する必要があります。これには、認知障害、腕の骨折などの一時的な障害、さらには加齢による障害などが含まれます。

    障がい者を採用することには、障がいに関して本物の視点を持つことができる人を、特にデザインや開発の職務で採用することも含まれます。また、初期段階のユーザーリサーチと組み合わせるのも良いアイデアです。つまり、ユーザーへの働きかけやテストにさまざまな人を参加させ、ウェブサイトの開発に役立つ洞察を提供するのです。

    アクセシビリティの進捗状況を長期的に把握

    ウェブ・アクセシビリティへの進捗状況を追跡し、文書化することは、コンプライアンスのレベルを測定し、よりインクルーシブなデザインのベストプラクティスを実施できる領域を発見し、チームのモチベーションを維持して軌道に乗せるために重要です。

    アクセシビリティ・ツールの中には、解決したアクセシビリティの問題をリストアップすることで、進捗状況のモニタリングを支援するものがあります。パフォーマンス・ダッシュボード、レポート機能、および目標設定機能を備えたツールを探してください。

    ウェブアクセシビリティに「終わり」はない

    ウェブアクセシビリティは、決して楽なものではありませんし、ウェブサイト上で「完成」するものでもありません。しかし、すべてを網羅する必要も、扱いにくい必要も、困難である必要もありません。

    あまりにも多くの組織が、アクセシビリティについて、WCAG準拠のレベルAAのような、一定の法的レベルのアクセシビリティ準拠を達成するという観点から考えています。これは良い出発点ではありますが、最終目標にすべきではありません。むしろ、これは、すべてのユーザーが本当に満足できるWebサイト体験を提供するために、より広範かつ段階的に考えるための出発点となります。

    アクセシビリティのガイドラインや法律に準拠することは、デジタル・アクセシビリティを追求する正当な理由ですが、デジタル・インクルージョンに真摯に取り組むことは、正しいことであるだけでなく、ブランドの評判を高め、市場へのリーチを拡大することにもつながることを覚えておいてください。そして、これを達成する唯一の方法は、インクルーシブデザインと開発のベストプラクティスをウェブサイトのプロセスの中心に据えることです。

各種お問い合わせやご要望は下記よりお願いいたします。

関連記事

前の記事へ

強力なウェブサイトのセキュリティがもたらすビジネス上のメリット

次の記事へ

手動、自動、およびハイブリッドのアクセシビリティ・テストについて知っておくべきすべてのこと