アクセシビリティとは

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

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

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

アクセシブルなサイトを構築するのは、すべての人の利益になります。

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

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

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

• 有償の商用製品、例えば JAWS (Windows) や Dolphin Screen Reader (Windows).
• 無償の製品、例えば NVDA (Windows), ChromeVox (Chrome, Windows Mac OS X), や Orca (Linux).
• OS に組み込まれたもの、例えば VoiceOver (Mac OS X と iPadOS と iOS), Narrator (Windows), ChromeVox (ChromeOS), や TalkBack (Android).

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

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

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

アクセシビリティを提供するためには、テキストによる代替手段を提供しなければなりません。動画には手動でキャプションをつけ、音声コンテンツには文字起こしを提供する必要があります。さらに、DHHの人々は[言語剥奪](https://www.therapytravelers.com/language-deprivation/#:~:text=Language%20deprivation%20is%20, therefore%20not%20exposed%20to%20language.)が高いため、テキストの簡略化を検討すべきとされています。

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

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

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

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

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

認知障碍者とは最も広い範囲の障碍をいい、最も限定された能力をもつ知的障碍者からわれわれがみな加齢とともに考えたり記憶したりが困難になることまでがあります。この範囲には 鬱病（英語）や 統合失調症（英語）といった精神疾患のほか、ディスクレシア（英語）やADHD（注意欠陥多動性障碍）（英語）のような学習障碍も含みます。重要なこととして、認知障碍の臨床的な定義が広がっていても、そうした障碍をもつ人には共通の機能不全があります。それにはコンテンツを理解し難いこと、タスクを完了する方法を記憶すること、一貫性のないウェブページレイアウトによって混乱することがあります。

認知障碍者へのアクセシビリティの良い基本事項は、次のものです。

• コンテンツを 2 つ以上の方法で配信する、例えば文字スピーチや動画
• 簡単に理解できるコンテンツ、例えば簡潔な言語標準で書かれた文章など
• 重要なコンテンツに焦点があたっていること
• 気をそらすものを最小化する、例えば不要なコンテンツや広告
• ウェブページのレイアウトやナビゲーションに一貫性をもたせる
• なじみの要素、例えば未訪問のリンクは下線つきの青で、訪問済みは紫など
• 複数の処理を論理的で本質的な手順に分けて、進捗を指すものをつけること
• ウェブサイトの認証は、セキュリティに妥協しない範囲で、できる限り簡単にする
• フォーム完了までに必要な操作はできるだけ少ないこと、例えば明白なエラーメッセージと簡潔なエラー復帰

• 認知的なアクセシビリティ (en-US)をもってデザインするのは良い習慣になります。どんな人にも利益になるでしょう。
• 知的障碍者の多くは身体的な障碍も持っています。ウェブサイトは W3C のウェブコンテンツアクセシビリティガイドラインと、その中の認知的アクセシビリティガイドライン (en-US)に従う必要があります。
• W3C の 認知と学習障碍者のアクセシビリティタスクフォースでは認知障碍者のためのウェブアクセシビリティガイドラインを制作しています。
• WebAIM の認知のページには関連する情報やリソースがあります
• アメリカ疾病予防管理センターの見積もりでは、2018 年以降、4 人に 1 人の米国市民には障碍があり、その中で、若い人には認知障碍が最もよく見られます。
• 米国では、知的障碍の一部は、過去には「精神遅滞」と参照されてきました。これで多くの人がこの言葉を軽蔑的だと考えるようになったので、使用するのは避けるべきでしょう。
• 英国では、一部の知的障碍は「学習障碍」または「学習困難」と呼ばれます。

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

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

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

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

• 私の日付選択ウィジェットをスクリーンリーダーを使う人が使用できますか？
• コンテンツが動的に更新される場合、視覚障碍者はそれについて知っていますか？
• 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 は一連のガイドラインですが、あなたの国ではおそらくウェブアクセシビリティ、または少なくとも公的に利用可能なサービスのアクセシビリティ（ウェブサイト、テレビ、物理的な空間などを含む）を規制する法律があるでしょう。あなたの法律が何であるかを調べることは良い考えです。あなたのコンテンツがアクセス可能であることを確認しようと努力せずに、障碍を持つ人々が訴えた場合、法律な責任を負うこともあります。

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

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

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

• Windows: MSAA/IAccessible, UIAExpress, IAccessible2
• macOS: NSAccessibility
• Linux: AT-SPI
• Android: Accessibility framework
• iOS: UIAccessibility

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

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

• Overview: アクセシビリティ
• 次のページ

• WCAG
  • 知覚可能
  • 操作可能
  • 理解可能
  • 堅牢
• Google Chrome released an auto-captioning extension