We're looking for a user researcher to understand the needs of developers and designers. Is this you or someone you know? Check out the post: https://mzl.la/2IGzdXS

この翻訳は不完全です。英語から この記事を翻訳 してください。

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

前提知識:

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

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

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

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

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

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

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

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

身体障害者とは単に障がいのない人と別物で、よってその障がいもそれぞれです。ここでのキーレッスンは、あなたのコンピューターやウェブの使い方を超えて、他人がどうやってそれを使っているかを学習し始めることです — あなたはユーザーとは違います。考慮すべき主な種類の障がいは下記に説明されていて、ウェブコンテンツにアクセスするのに使っているスペシャリストツールもあります (assistive technologiesATs として知られるもの)。

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

視覚障がい者

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

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

統計では、WHO は「世界中で 2億8500万人が視覚障がい者で: うち 3900万人が全盲で 2億4600万人が停止力です」と見積もっています(Visual impairment and blindness を見てください)。これは単にサイトが適切にコーディングされていないために逃すユーザーとしては多くて重要です — アメリカ合衆国の人口とほぼ同じ大きさです。

聴覚障がい者

聴力障がい者や、ろう者とも知られて、このグループの人には聞こえにくい人と全く聞こえない人の両方がいます。聴力障がい者は ATs (Assistive Devices for People with Hearing, Voice, Speech, or Language Disorders を見てください)を使いますが、コンピューター/ウェブに特化した特別な AT はありません。

しかし、音声コンテンツの代替テキストを用意して、動画と一緒に簡単なテキストから、テキストトラックを読めるようにしておく(つまりキャプション)のを気に留めるという限定的なテクニックがあります。後の記事で詳しく扱います。

聴力障がい者は重要なユーザー基盤を代表しています — 「世界中で 3億6000万人が聞こえないことでのロスがあります」こう WHO の Deafness and hearing loss 報告書で言われています。

移動に障がいのある人

移動に関して障がいのある人は、純粋に肉体的な問題 (肢の切断やまひのような) と、神経学/遺伝的な病気のために足を動かすのが弱くなったり失われたりする場合があります。マウスを動かすのに必要な正確な手の動きが困難な人もいて、他にももっとひどく影響を受けて、コンピューターと相互作用する head pointer を使うくらいの人もいます。

こうした種類の障害は過去の結果でもあり、特定のトラウマや条件や、ハードウェア制限のこともあります — マウスを持っていないユーザーもいます。

こうしたことが常々ウェブ開発作業に影響する方法は、コントロールがキーボードでアクセスすべきという要求です。 — このモジュールの後の記事でキーボードアクセシビリティを扱いますが、ウェブサイトをキーボードだけで見ようとしてどうなるか試すのも良いでしょう。例えば、ウェブフォームのいろいろなコントロールをタブキーを使って移動できますか?キーボードコントロールのより詳しくは Cross browser testing Using native keyboard accessibility 節を見てください。

統計的には、有意な数の人が移動に障がいを持っています。アメリカ疾病管理予防センターの  障がいと機能 (施設に入らない 18 歳以上の大人) レポートによると USA では "肉体的な機能障がいのある大人の割合は: 15.1%" です。

認知障がい者

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

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

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

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

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

統計用語では、その数は有意です。コーネル大学ね 2014 Disability Status Report (PDF, 511KB) では、 2014年に USA の 21-64歳の 4.5% の人が何らかの認知障がいがあると示しています。

: WebAIM's Cognitive page provides a useful expansion of these ideas, and is certainly worth reading.

プロジェクトにアクセシビリティを含む

A common accessibility myth is that accessibility is an expensive "added extra" to implement on a project. This myth actually can be true if either:

  • You are trying to "retrofit" accessibility onto an existing website that has significant accessiblity issues.
  • You have only started to consider accessibility and uncovered related issues in the late stages of a project.

If however you consider accessibility from the start of a project, the cost of making most content accessible should be fairly minimal.

When planning your project, factor accessibility testing into your testing regime, just like testing for any other important target audience segment (e.g. target desktop or mobile browsers). Test early and often, ideally running automated tests to pick up on programmatically detectable missing features (such as missing image alternative text or bad link text — see Element relationships and context), and doing some testing with disabled user groups to see how well more complex site features work for them. For example:

  • Is my date picker widget usable by people using screen readers?
  • If content updates dynamically, do visually impaired people know about it?
  • Are my UI buttons accessible using the keyboard and on touch interfaces?

You can and should keep a note of potential problem areas in your content that will need work to make it accessible, make sure it is tested thoroughly, and think about solutions/alternatives. Text content (as you'll see in the next article) is easy, but what about your multimedia content, and your whizzy 3D graphics? You should look at your project budget and realistically think about what solutions you have available to make such content accessible? You could pay to have all your multimedia content transcribed, which can be expensive, but can be done.

Also, be realistic. "100% accessibility" is an unobtainable ideal — you will always come across some kind of edge case that results in a certain user finding certain content difficult to use — but you should do as much as you can. If you are planning to include a whizzy 3D pie chart graphic made using WebGL, you might want to include a data table as an accessible alternative representation of the data. Or, you might want to just include the table and get rid of the 3D pie chart — the table is accessible by everyone, quicker to code, less CPU-intensive, and easier to maintain.

On the other hand, if you are working on a gallery website showing interesting 3D art, it would be unreasonable to expect every piece of art to be perfectly accessible to visually impaired people, given that it is an entirely visual medium.

To show that you care and have thought about accessibility, publish an accessibility statement on your site that details what your policy is toward accessibility, and what steps you have taken toward making the site accessible. If someone does complain that your site has an accessibility problem, start a dialog with them, be empathic, and take reasonable steps to try to fix the problem.

: Our Handling common accessibility problems article covers accessibility specifics that should be tested in more detail.

To summarize:

  • Consider accessibility from the start of a project, and test early and often. Just like any other bug, an accessibility problem becomes more expensive to fix the later it is discovered.
  • Bear in mind that a lot of accessibility best practices benefit everyone, not just users with disabilities. 例えば、 lean semantic markup is not only good for screen readers, it is also fast to load and performant, so better for everyone, especially those on mobile devices, and/or slow conections.
  • Publish an accessibility statement on your site and engage with people having problems.

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

There are numerous checklists and sets of guidelines available for basing accessibility tests on, which might seem overwhelming at first glance. Our advice is to familiarize yourself with the basic areas in which you need to take care, as well as understanding the high level structures of the guidelines that are most relevant to you.

  • For a start, the W3C has published a large and very detailed document that includes very precise, technology-agnostic criteria for accessibility conformance. These are called the Web Content Accessibility Guidelines (WCAG), and they are not a short read by any means. The criteria are split up into four main categories, which specify how implementations can be made perceivable, operable, understandable, and robust. The best place to get a light introduction and start learning is WCAG at a Glance. There is no need to learn WCAG off by heart — be aware of the major areas of concern, and use a variety of techniques and tools to highlight any areas that don't conform to the WCAG criteria (see below for more).
  • Your country may also have specific legislation governing the need for websites serving their population to be accessible — for example Section 508 of the Rehabilitation Act in the US, Federal Ordinance on Barrier-Free Information Technology in Germany, the Equality Act in the UK, Accessibilità in Italy, the Disability Discrimination Act in Australia, etc.

So while the WCAG is a set of guidelines, your country will probably have laws governing web accessibility, or at least the accessibility of services available to the public (which could include websites, television, physical spaces, etc.) It is a good idea to find out what your laws are. If you make no effort to check that your content is accessible, you could possibly get in trouble with the law if people with diabilities complain about it.

This sounds serious, but really you just need to consider accessibility as a main priority of your web development practices, as outlined above. If in doubt, get advice from a qualified lawyer. We're not going to offer any more advice than this, because we're not lawyers.

アクセシビリティの API 群

Web browsers make use of special accessibility APIs (provided by the underlying operating system) that expose information useful for assistive technologies (ATs) — ATs mostly tend to make use of semantic information, so this information doesn't include things like styling information, or JavaScript. This information is structured in a tree of information called the accessibility tree.

Different operating systems have different accessibility APIs available :

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

Where the native semantic information provided by the HTML elements in your web apps falls down, you can supplement it with features from the WAI-ARIA specification, which add semantic information to the accessibility tree to improve accessibility. You can learn a lot more about WAI-ARIA in our WAI-ARIA basics article.

まとめ

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

このモジュール内

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

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