この記事では実際アクセシビリティとは何かについてよく観察するモジュールから開始します — これには考慮が必要な人のグループや、いろいろな人がウェブとやり取りするのになぜ、どんなツールを使うのかや、アクセシビリティをウェブ開発のワークフローに取り組む方法が含まれます。

前提知識:

基本的なコンピュータの知識、HTML と CSS に関する基本的な理解
学習目標: アクセシビリティとは何か、そしてそれがウェブ開発者としてのあなたにどう関わってくるかを含め、アクセシビリティに詳しくなる

で、アクセシビリティって何?

アクセシビリティというのはあなたのウェブサイトを可能な限り多くの人に利用してもらうためにすることです。 かつては我々はアクセシビリティのことをハンディキャップを持つ人々のためのものだと考えていましたが、現在はモバイルデバイスや遅いネットワークを利用している人々のためのものでもあると考えられています。

アクセシビリティを、能力や環境にかかわらず全員を同一に扱い、同じ機会を与えることと考えることもできます。 車椅子に乗っているために物理的な建物から誰かを除外するのは正しくないのと同様に(昨今一般的に公的な建物では車椅子のスロープやエレベーターを備えています)、視覚障碍があるためにウェブサイトから特定のユーザーを除外するのも正しくありません。 我々はみんな異なっていて、しかしみんな人間であり、ゆえに同じ人権を持っています。

アクセシビリティは正しい行為ですが、いくつかの国では法律の一部でもあり、そうしなければサービスを利用したり、製品を買ったりすることなどができなかったであろう、いくつかの重要な市場を開拓することができます。

アクセシビリティとそれに伴う成功事例は、すべての人の利益になります:

  • 意味論的 HTML (これはアクセシビリティを改良します) は SEO の改善にもなり、サイトがもっと発見しやすく/市場性のあるものになります。
  • アクセシビリティへの留意は倫理/モラルを誇示することになり、公的イメージが良くなります。
  • その他のアクセシビリティ改良の事例はその他のグループ(例えば携帯電話のユーザーや、ネットワーク速度が遅い人など)にとってより使いやすくなります。 実際にすべての人がこうした改良で利益を得ます。
  • ある場所では法律となっているって言いましたっけ?

私たちが考える"不利な条件"とは?

障碍のある人は障碍のない人と同じくらい多様であり、よってその障碍も同じくらい多様です。 ここでの重要な教訓は、あなたがコンピューターの向こうでウェブをどのように使うかを考え、他の人がどのように使っているかを学習し始めることです — あなたはユーザーとは違います。 考慮すべき障碍の主な種類を、ウェブコンテンツにアクセスするために使う特別なツール(支援技術assistive technologyAT として知られるもの)とともに以下に説明します。

: 世界保健機構(WHO)の障碍と健康(英語)の報告によると、 「10億人以上の人(世界人口の約15%)が何らかの障碍を持っています」し、「1億~1億9000万人の大人に目立った機能障碍があります」

視覚障碍者

これには全盲の人や、視覚が低レベルな人、色盲の人などが含まれます。 これらの多くはスクリーン拡大鏡 (物理的な拡大鏡とソフトウェアズーム機能のいずれか — 大半のブラウザーと OS には今日ズーム機能があります) を使い、スクリーンリーダー、つまりデジタルテキストを読み上げるソフトウェアを使う人もいます。:

スクリーンリーダーに精通するのは良い考えです; スクリーンリーダーをセットアップして試してみて、その動作方法を理解するべきです。 クロスブラウザーテストのスクリーンリーダーのガイド を見ると詳しい使い方がわかります。 下記の動画も、その体験がどのようなものかの簡単な例です。

統計では、WHO は「世界中で 2億8500万人が視覚障碍者で、うち 3900万人が全盲で 2億4600万人がロービジョンです」と見積もっています(視覚障碍と盲目(英語)を参照)。 これは単にサイトが適切にコーディングされていないために逃すユーザーとしては多くて重要です — 米国の人口とほぼ同じ大きさです。

聴覚障碍者

耳の障碍者や、ろう者とも知られて、このグループの人には聞こえにくい人と全く聞こえない人の両方がいます。 聴覚障碍者は AT(聴覚、発声能力、発話能力、言語に障碍のある人のための補助装置(英語)を参照)を使いますが、コンピューターやウェブに特化した特別な AT はありません。

しかしながら、単純なテキストトランスクリプトから、動画と一緒に表示できるテキストトラック(すなわちキャプション)まで、彼らが音声コンテンツに代わって読むことができるテキストを提供するために留意すべき特定のテクニックがあります。 後の記事で詳しく扱います。

聴覚障碍者もまた重要なユーザー基盤を代表しています — 「世界中で 4億6,600万人が日常生活に支障を来すほどの聴覚障害を持っています」と WHO はろうと聴覚障碍(英語)で報告しています。

運動障碍のある人

これらの人々は、(四肢の喪失や麻痺のような)純粋に肉体的な問題や、四肢の衰弱や制御不能につながる神経学的障碍や遺伝子疾患を伴う可能性がある、運動に関する障碍を持っています。 マウスを使うのに必要な正確な手の動きが難しい人もいれば、もっと深刻な影響を受けて、コンピュータと対話するためにヘッドポインタ(英語)を使う必要があるところまで著しく麻痺している人もいます。

この種の障碍は、特定のトラウマや状態ではなく、老年期の結果であることもあります。 それに、ハードウェアの制限から生じることもあります — 一部のユーザーはマウスを持っていないかもしれません。

これが通常ウェブ開発作業に影響するのは、コントロールがキーボードからアクセス可能であることという要件です — このモジュールの後の記事でキーボード・アクセシビリティを扱いますが、どのようにやるかを見るためにキーボードだけを使っていくつかのウェブサイトを試してみることは良い考えです。 例えば、Tab キーを使ってウェブフォームのさまざまなコントロール間を移動できますか? キーボードコントロールの詳細については、クロスブラウザーテストのネイティブなキーボード・アクセシビリティを使うのセクションを参照してください。

統計では、有意な数の人が運動障碍を持っています。 米国疾病管理予防センターの障碍と機能 (施設に入らない 18 歳以上の大人) (英語)の報告によると、米国では "肉体的な機能障碍のある大人の割合は、16.1%" です。

認知障碍者

おそらく、最も広い範囲の障碍がこの最後のカテゴリーに含まれます — 認知障碍とは概して、精神疾患から学習困難まで、ADHD(注意欠陥多動性障碍)(英語)のような理解と集中の困難、自閉症スペクトラム(英語)の人々に、統合失調症(英語)を有する人々、および他の多くの障碍を指します。 このような障碍は、記憶、問題解決、理解、注意などの問題により、日常生活の多くの部分に影響を及ぼします。

そのような障碍がウェブサイトの使い方に影響を及ぼすことがある一般的な事項としては、タスクを完了する方法を理解すること、以前に達成したことを覚えておくこと、または混乱したワークフローや一貫性のないレイアウト/ナビゲーション/そのほかの機能によるフラストレーションの増大が当てはまります。

他のウェブアクセシビリティの問題とは異なり、認知障碍に起因する多くの問題を迅速に修正することは不可能です。 あなたにできる最良の選択は、ウェブサイトを論理的で一貫性があり、できるだけ使いやすく設計することです。 例えば、次のことを確認してください:

  • ページに一貫性をもたせる — ナビゲーション、ヘッダー、フッターとメインコンテンツはいつでも同じ場所に配置すること。
  • ツールが良く設計されて簡単に使えること。
  • 複数ステージの処理が論理的なステップに分割されていて、処理がどこまで進んでいるか、適切な場合は処理を終えるにはどれだけ残っているかが常にわかること。
  • ワークフローが論理的で、単純で、完了までに必要な操作はできるだけ少ないこと。 例えば、 ウェブサイトへの登録とサインインは必要以上に複雑なことがよくあります。
  • ページが過度に長過ぎたり、一度に表示する量として詰め込みすぎていないこと。
  • ページで使われる言葉を追うのが、なるべく簡潔で簡単であり、不要な専門用語や俗語ばかりにならないこと。
  • 重要な点やコンテンツが何らかの方法でハイライトされていること。
  • ユーザーエラーが明確にハイライトされ、解決法を示すヘルプメッセージと一緒に示されること。

これは "アクセシビリティのテクニック" ではありません — 良いデザイン習慣です。 サイトを使うすべての人に利益となり、作業の標準とすべきでしょう。

統計では、その数は有意です。 コーネル大学の2014年の障碍状況報告 (PDF、511KB、英語) では、 2014年に米国の 21歳から 64歳の 4.5% の人が何らかの認知障碍があると示しています。

: WebAIM の認知(英語)のページは、これらのアイデアの有用な拡張を提供し、確かに読む価値があります。

プロジェクトにアクセシビリティを実装する

よくあるアクセシビリティ神話は、アクセシビリティはプロジェクトに実装するための高価な「余分な追加」であるということです。 この神話は、実際には次のいずれかの場合に当てはまります。

  • 重大なアクセシビリティ問題を抱えている既存のウェブサイトにアクセシビリティを「組み込んで改良」しようとしています。
  • プロジェクトの後期段階で、アクセシビリティとそれに関連する問題を検討し始めたばかりです。

ただし、プロジェクトの開始時からアクセシビリティを検討している場合は、ほとんどのコンテンツをアクセス可能にするためのコストはごくわずかなはずです。

プロジェクトを計画するときは、他の重要な対象観客セグメント(対象とするデスクトップやモバイルのブラウザーなど)のテストと同様に、アクセシビリティのテストをテスト体制に組み入れます。 早期に頻繁にテストし、理想的にはプログラムで検出可能な欠けている機能(画像の代替テキストの欠落、リンクテキストの不良のような — 要素の関係とコンテキストを参照)を検出するための自動テストの実行し、より複雑なサイト機能が障碍のあるユーザーのグループに対してどの程度うまく機能するかを確認するために、それらのグループでいくつかのテストを行います。 例えば、

  • 私の日付選択ウィジェットをスクリーンリーダーを使う人が使用できますか?
  • コンテンツが動的に更新される場合、視覚障碍者はそれについて知っていますか?
  • 私の UI ボタンは、キーボードとタッチインタフェースを使ってアクセスできますか?

コンテンツをアクセス可能にするための作業が必要なコンテンツの潜在的な問題領域をメモしておくことができ、またそうすべきで、徹底的にテストしていることを確認し、解決策や代替案について考えます。 次の記事で見るように、テキストコンテンツは簡単ですが、マルチメディアコンテンツや、最先端の 3D グラフィックはどうでしょうか?  あなたはプロジェクトの予算を見て、現実的にそのようなコンテンツをアクセス可能にするために利用可能などんな解決策があるかついて考えるべきです。 あなたはマルチメディアコンテンツすべてを転記するために支払うことができます。 これは高価になることがありますが、行うことができます。

現実的にもなりましょう。 「100% のアクセシビリティ」は達成不可能な理想です — あなたは常にある種の最先端のケースに出くわすことになり、その結果特定のユーザーが特定のコンテンツを使いにくいと感じることになります — しかしできる限りはするべきです。 WebGL を使用して作成した最先端の 3D 円グラフのグラフィックを含めることを計画している場合は、データのアクセス可能な代替表現としてデータ表を含めることができます。 あるいは、表だけを含めて 3D 円グラフを取り除くことをお勧めします — 表には誰でもアクセスでき、コード作成が早く、CPU 使用率が低く、保守が簡単です。

これに反して、興味深い 3D アートを展示したギャラリーのウェブサイトで作業している場合、それが完全に視覚的な媒体であることを考えると、すべてのアートが視覚障碍者にとって完全にアクセス可能であることを期待するのは不合理でしょう。

あなたがアクセシビリティに関心があり、考えていることを示すために、あなたのサイトに、アクセシビリティに向けた方針と、サイトをアクセス可能にするためにどのようなステップを踏んだかを詳しく記載した、アクセシビリティに関する声明を発表してください。 あなたのサイトにアクセシビリティの問題があると誰かが文句を言ってきたら、彼らと対話を始め、共感し、そして問題を解決するために合理的なステップを踏みます。

: よくあるアクセシビリティの問題を扱うの記事では、より詳細にテストするべきであるアクセシビリティの詳細について説明しています。

要約すると、

  • プロジェクトの最初からアクセシビリティを考慮し、早期に頻繁にテストしてください。 他のバグと同じように、アクセシビリティの問題は、後で発見されたものほど修正が高くつきます。
  • アクセシビリティに関するベストプラクティスの多くは、障碍のあるユーザーだけではなく、すべてのユーザーに役立つことを念頭に置いてください。 例えば、意味論に頼ったマークアップは、スクリーンリーダーに適しているだけでなく、読み込みや実行が高速であるため、すべての人、特にモバイルデバイスを使用している人、および/または遅い接続に適しています。
  • あなたのサイトにアクセシビリティの声明を発表し、問題を抱えている人々と関わり合いましょう。

アクセシビリティのガイドラインと法律

アクセシビリティテストの基礎となる多数のチェックリストと一連のガイドラインがあります。 これは、一見すると圧倒的に思われるかもしれません。 アドバイスとしては、あなたが注意を払う必要がある基本的な分野に精通すること、そしてあなたにとって最も関連性のあるガイドラインの高いレベルの構造を理解することです。

  • はじめに、W3C は、アクセシビリティ適合のための非常に正確な、技術に依存しない基準を含む、大きくて非常に詳細なドキュメントを公開しました。 これらは Web Content Accessibility Guidelines(WCAG)と呼ばれていますが、決して短く読むことはできません。 基準は4つの主なカテゴリに分けられます。 これらは、実装を認識可能、操作可能、理解可能、そして堅牢にする方法を指定します。 簡単に紹介して学習を開始するのに最適な場所は、WCAG の概要(英語)です。 丸暗記で WCAG を学ぶ必要はありません — 主な関心分野に注意し、WCAG の基準に適合していない分野をハイライトするために、さまざまなテクニックやツールを使用します(詳細は下記を参照)。
  • あなたの国はまた、彼らの人口に役立つウェブサイトがアクセス可能であることを規定する特定の法律を持つかもしれません — 例えば、EU の EN 301 549(PDF、英語)、米国のリハビリテーション法のセクション 508(英語)、ドイツのバリアフリー情報技術に関する連邦条例(英語)、英国のアクセシビリティ規則 2018(英語)、イタリアのアクセシビリティ(イタリア語) 、オーストラリアの障碍者差別禁止法(英語)など。 W3C は、国ごとのウェブアクセシビリティの法および政策(英語)のリストを保持しています。

そのため、WCAG は一連のガイドラインですが、あなたの国ではおそらくウェブアクセシビリティ、または少なくとも公的に利用可能なサービスのアクセシビリティ(ウェブサイト、テレビ、物理的な空間などを含む)を規制する法律があるでしょう。 あなたの法律が何であるかを調べることは良い考えです。 あなたのコンテンツがアクセス可能であることを確認しようと努力せずに、障碍を持つ人々がそれについて不満を言えば、あなたはおそらく法律に悩まされることでしょう。

これは深刻に思えますが、実際には、上で概説したように、アクセシビリティをウェブ開発の最優先事項として考慮する必要があります。 疑問がある場合は、資格のある弁護士に相談してください。 私たちは弁護士ではないので、これ以上のアドバイスは提供しません。

アクセシビリティの API 群

ウェブブラウザーは、支援技術(AT)に役立つ情報を公開する(基礎となる OS によって提供される)特別なアクセシビリティ API を利用します —  AT は大抵は意味論的情報を利用する傾向があるので、この情報にはスタイル情報や JavaScript のようなものを含みません。 この情報は、アクセシビリティツリーと呼ばれる情報のツリーで構成されています。

次のように、OS が異なれば、利用可能なアクセシビリティ API も異なります。

  • Windows: Microsoft Active Accessibility(MSAA) / IAccessible、UIAExpress、IAccessible2
  • Mac OS X: NSAccessibility
  • Linux: AT-SPI
  • Android: Accessibility framework
  • iOS: UIAccessibility

ウェブアプリにおいて HTML 要素によって提供されるネイティブな意味論的情報が足りない場合は、あなたは WAI-ARIA の仕様(英語)の機能でそれを補うことができます。 これにより、アクセシビリティツリーに意味論的情報が追加され、アクセシビリティが向上します。 WAI-ARIA の基本の記事で WAI-ARIA についてもっと多くを学ぶことができます。

まとめ

この記事では高いレベルでアクセシビリティの概要を説明し、それが重要である理由と、ワークフローに取り込む方法を見てきました。 サイトをアクセシブルにするための実装の詳細について学ぶことを渇望する人もいるでしょう。 それでは次の記事では、HTML がアクセシビリティの良い基礎である理由を見ていきます。

このモジュール内の文書

 

関連情報

 

ドキュメントのタグと貢献者

このページの貢献者: mdnwebdocs-bot, Wind1808, silverskyvicto, Uemmra3, yuheiy, karaage-kun
最終更新者: mdnwebdocs-bot,