アクセシビリティー
企業にとってウェブサイトの重要性が増し続ける中、これまでになく大切になっているのが、あらゆる訪問者にウェブサイトのコンテンツを利用してもらえるようにすることです。米国では、これは508条コンプライアンスと呼ばれることがよくあります。これは連邦政府関係機関が障害者に電子情報や情報テクノロジーへのアクセスを可能にすることを要求する1998年の改訂リハビリテーション法の条文を指します。508条コンプライアンスも適切ですが、ウェブ上でアクセシビリティー対応コンテンツを作成するための標準としては次第にWeb Content Accessibility Guidelines（WCAG）が使用されるようになっています。
法的な側面が、訪問者に優れたユーザーエクスペリエンスを提供する動機付けであってはなりません。CDCの報告によると、米国の4人に1人が何らかの障がいのある人です。ユーザーエクスペリエンスを向上する上で、訪問者の25％を無視することは、実店舗に例えれば4人の買い物客のうちの1人に対して入店を拒否するような行為です。このような顧客は不満に感じるだけでなく、再び来店することも、その店のサービスを他の人に薦めることもないでしょう。
開発者の間で使われる「アクセシビリティーは機能ではない」というフレーズがあります。これはアクセシビリティーを付加的な要素として扱わないこと、つまりプロジェクトの最後に対処するものと捉えないことを意味します。
アクセシビリティーを確保するには、思慮、共感、理解が必要です。プロジェクトの早い段階でアクセシビリティーに対応すれば、後で設計し直す必要に迫られずに、ソリューションを設計して開発できます。
多くの場合、アクセシビリティーに対応すると、開発者としての他の優先事項にも対処できます。ユーザーエクスペリエンス、パフォーマンス、SEOなどの懸念事項はアクセシビリティーと直接関係するからです。1つの改善が他の改善にもつながることは珍しくありません。
共感はアクセシビリティーを確保する上で重要な部分であるものの、失念されがちです。開発者は全てを自動化しようとします。何かを処理するのが難しい、または処理に時間がかかる場合、自動的に処理できるツールや、正しい処理方法を示してくれるツールを求めます。けれども残念ながら、こうしたツールはあくまで表面的な対応に過ぎません。ツールは人間ではなく、人間と同じ体験を共有することはできないからです。ほとんどの自動アクセシビリティーテストに合格するウェブページを作成するのは、技術的には可能です。しかし、技術だけを頼りに作成したウェブページは、視覚や聴覚に障がいのある人、色盲の人、運動機能が限られているか運動機能に障がいのある人も含めた万人にとって、使い物になりません。要件を技術的に満たすことはできても、使いにくく、操作が苛立たしいウェブページは訪問者から敬遠されてしまいます。重要な点は、ツールへの依存をやめて、成果物をテストし、ユーザーに共感し、フィードバックを集めることです。
決して完全なガイドではないかもしれませんが、ここではコンテンツをアクセスしやすいものにするための措置と、詳細に関する資料を紹介します。
メッセージ性がある、またはインタラクティブな全ての画像、アイコン、動画、ボタンには、代替テキストが必要です。これは、スクリーンリーダーを使用してコンテンツを利用している訪問者に適していることに加え、検索エンジン対応にも有効です。代替テキストでは、画像の内容について説明する必要があります。サイトのほとんどの画像はページエディターで編集することが可能です。ページエディターでは簡単に代替テキストを設定できます。ただし、カスタムモジュールとテンプレートの内部で、ページエディターで指定された代替テキストが使用されることを確認する必要があります。
つまり、ユーザーが入力した代替テキストが実際に使用される<img>要素が存在することを確かめる必要があります。
何らかの理由でページエディター上で画像を編集できない設定にしている場合は、代替テキストのハードコードが必要になります。
代替テキストに関するこのルールには例外が1つあります。画像に追加のコンテキストを用意せず、その画像をプレゼンテーション目的でのみ使用する場合は、alt属性を省略するよりも、"null" alt text値を使用することが望まれます。
画像の遅延読み込みは、ウェブサイトの構築に広く使用されているパフォーマンス向上手法です。どのような遅延読み込み方法を使用するかが、アクセシビリティーに影響します。
JavaScriptソリューションでは、画像のsrc属性に、画像の真のソースではなく、代わりとなるもの（小さな.gifファイルなど）が使われることが一般的で、ユーザーがスクロールしたビューが画像の近くに来るまではdata-src属性に保持されています。つまり、ページを閲覧するスクリーン リーダー ユーザーにとって、このような画像は当初、アクセス不可能になっています。特にローターを使用して、スクロールすることなくページ全体の内容を確認する場合に当てはまります。さらにJavaScriptがページに読み込まれない場合には、この遅延読み込みソリューションは正常に機能しないため、補助テクノロジーを必要とするユーザーにとって、ページ上に適切な画像がない状態になります。
画像の遅延読み込みのネイティブ機能を使用すれば、JavaScriptが読み込まれるかどうかにかかわらず、画像のマークアップが同じ状態に保たれるので、前述の問題を回避できます。
HubSpotのカスタムモジュールでは、ブラウザーベースの遅延読み込みがサポートされています。ご活用ください。
リンク、ボタン、フォームなどの全ての要素には、その機能や移動先を示すテキストが必要です。テキストがない場合、スクリーンリーダーを使用してユーザーが選択したリンクまたはボタンが読み上げられても、何のためのものかが分かりません。
アイコンを使用している場合は、スクリーンリーダー用テキストを用意してください。例えば、一部の標準HubSpotテンプレートではアイコンショートコードが使用されています。
フォームラベルなどの説明文を非表示にするための'display: none'は使用しないでください。これを使用すると、視覚障がいのあるユーザーにテキストが読み上げられません。また、テキストは見えても、プレースホルダーのテキストとのコントラストを認識できないためにテキストを見分けにくいユーザーにとっては苦痛になります。ユーザーがフォームに入力していない場合やフォームが自動で入力される場合は言うまでもなく、フォームのフィールドラベルが見にくいと、フォームが正しく入力されているかどうかがユーザーには分かりません。
テキストを非表示にしなければならない場合、またはテキストを非表示にすると、視覚障がいのないユーザーには不要なコンテキストが追加される場合は、CSSを使用してスクリーンリーダーに対してはテキストを隠すことなく非表示にすることや、'.screen-reader-text'クラスを追加することができます。
訪問者がナビゲーションのためにスクリーンリーダーを使用している場合、または単に自分のキーボードを使用している場合、ページの繰り返し部分（ヘッダーなど）をスキップする方法があると非常に役立ちます。これはページの主要なコンテンツをポイントするリンクを追加することで実現できます。
ヘッダーに、以下の内容のHTMLを追加します。
次に、全てのテンプレートにコンテンツのID属性を持つ要素が含まれていることを確かめます。この例では、テキストとして移動先の記事のタイトルを使用しています。これにより、検索エンジンによってリンク先の内容が認識されるようになります。意味に基づいてコンテンツに進むことが可能になります。
セマンティックマークアップとは、要素の意味を伝えるHTMLのことです。セマンティック要素の例としては、<header>、<main>、<footer>、<nav>、<time>、<code>、<aside>、および<article>が挙げられます。
セマンティックでない要素の例としては、<div>や<span>が挙げられます。セマンティックでない要素にも一定の意味はありますが、これらの要素は主にプレゼンテーション目的で使用し、意味を伝えるためには使用しないでください。
セマンティック要素は、検索エンジンによって意味が認識されるので、SEOの面で効果を高めるためにも、ユーザーエクスペリエンスの向上にも役立つテクノロジーです。
aria属性によって優れたユーザーエクスペリエンスを実現できる場合を除き、<div>要素はインタラクティブ要素（ボタン、タブ、リンクなど）として使用しないでください。
リンク（<a />）や<button />は適切に使用してください。
リンクは、同じページ内のセクションにリンクする場合や他のページに移動する場合に使用します。
ボタンは、ページを離れたりIDに移動したりすることにならない操作に使用します。
テーブルを使用する場合、テーブルにその内容を説明するタイトルがあれば、そのタイトルを<table>要素の直後にある<caption>要素に含めます。
テーブルの列と行の見出しには、テーブルの適切なscope属性を設定した<th>要素を使用し、各セクションを示すには<thead>、<tbody>、<tfoot>を使用します。
<th>要素にはscope属性を設定して、行または列のどちらの見出しであるかを示します。
アコーディオンが必要な場合は、<details>要素<summary>要素を使用すると、アコーディオンの機能のほとんどを無償で使用できるだけでなく、使いやすいアコーディオンにすることができます。古いブラウザーをサポートする必要がある場合は、必ずポリフィルまたはフォールバックを追加してください。
一部のユーザーは、ウェブページやフォームの閲覧にキーボードを使用します。訪問者によっては、ウェブサイトの閲覧にキーボードを使用しなければならない場合や、キーボードをエミュレートするサポートデバイスが必要になる場合があります。
- ':focus'スタイルが設定されていることを確かめてください。これにより、ユーザーがキーボードを使用して閲覧する際にフォーカスの位置を確認できます。CSSのoutlineプロパティーを無効にするのは、許容できる別のビジュアルインジケーターを提供する場合に限ってください。:focus-withinはユーザーの注意喚起に役立つ場合に使用します。
- ':hover'またはJavaScriptを使用してページの一部の表示／非表示を切り替える場合、ユーザーがJavaScriptを使用してそのコントロールを操作できること、また、情報へのアクセス方法が他にもあることを確認してください。
- サイトのメインナビゲーションでキーボード操作がサポートされていることを確かめてください。ドロップダウンとフライアウトがアクセシビリティー対応になっていないという問題が失念される傾向にあります。このような問題があると、ウェブサイトの重要な部分にユーザーが到達できなくなります。
- スクリーンリーダーがさまざまな要素の状態を適切に処理できるように、必要に応じて
hidden、aria-expanded、aria-current、aria-selectedなどの状態属性を使用し、最新の状態に維持してください。
テンプレートやコードファイルを作成する際には、ウェブブラウザーとスクリーンリーダーに対し、要素にどのような内容が含まれているかを伝えるために、適切なセマンティック要素（<header>、<main>、<footer>、<nav>、<dialog>など）を使用してください。
セマンティック要素では意味が十分に伝わらないと考えられる状況では、role（役割、ロール）属性を追加してください。
ランドマークを追加すると、スクリーンリーダーを使用しているユーザーがウェブページの主要なセクションの間を移動しやすくなります。HubSpotのメニュー、シンプルメニュー、Google 検索のモジュールには、role属性があります。
- ユーザーがブラウザーのズーム率を200%にしても、コンテンツが表示されたままの状態で読みやすいことを確かめてください。
- フォントサイズは16pxよりも極端に小さくしないことが推奨されます。訪問者がコンテンツを読みにくくなるためです。
- 色だけで情報を伝えようとしないでください。色盲の方が世界の人口に占める割合は少なくありません。
- 視力の弱い方がコンテンツを読めるように、テキストの色と背景色には十分なコントラストを確保してください。
- 素早く（1秒あたり3回以上）点滅するアニメーションは使用しないでください。訪問者によっては発作の原因となる恐れがあります。
- サイトでアニメーションを使用する場合は、prefers-reduced-motionをサポートすることを検討してください。
- 現在、レスポンシブなウェブサイトの構築は必須と考えられています。全てのインタラクティブな要素がモバイル上で正常に機能することを確かめてください。インタラクティブな要素は簡単にタップできるように、タップ領域の間には十分なスペースを確保してください。
テキストコンテンツでもアクセシビリティーを考慮する必要があることは忘れがちです。
- 「左側のサイドバーを参照」のような指示は使用しないでください。ユーザーがモバイルデバイスを使用している場合は通常、コンテンツが画面内に積み上げた状態に表示されるため、説明の意味がなくなります。
<h1>、<h2>のような見出しを使用して、見出しを連続的にネストしてください。視覚効果のために見出しを省略しないでください。- リンクを追加する場合は、「ここをクリック」というリンクテキストを使ってもスクリーンリーダーに意味は伝わりません。また、タッチスクリーンやその他のタイプのデバイスでは意味がありません。代わりに、テキストでそのリンク先の内容を説明してください。検索エンジンによってリンク先の内容も認識されるため、SEOの効果も期待できます。
- テキストに特殊なスタイルを設定して意味を伝える場合は、一部の訪問者に意味が伝わらなくなるため、
<mark>、<strong>、<em>、<sup>などの適切なセマンティックタグを使用してください。 - 世界中の訪問者をターゲットにする場合は、地域に固有の冗談を避けます。翻訳されるサイトの場合、語呂合わせの使用は避けます。気の利いた冗談が好ましくても、適切には翻訳されないことが大半です。
- 文法やスペルの誤りを回避するためのツールを使用してください。これによりテキストを理解しやすくなるだけでなく、翻訳もしやすくなります。
- サイトのオーディエンスに合わせてコンテンツを作成してください。物理学者向けの天体物理学を、小学5年生にそのまま説明することはしないはずです。響きが良いというだけの理由で難しい言葉を使うのではなく、分かりやすさを優先してください。
アクセシビリティーを向上するための作業の多くは、HubSpotに固有ではありません。とはいえ当社としては、開発者や制作担当者の皆さまにビジネスの成功に向けてHubSpotを活用していただくことを願っています。開発や制作の業務においてユーザーエクスペリエンス向上のためにできることを紹介します。
モジュールまたはテンプレートをマーケットプレイスからインストールする、自分で開発する、誰かに作成してもらう、といったどのケースについても、適切なのはアクセシビリティー（a11y）のベストプラクティスに従うことです。カスタムモジュールは特に、サイトのアクセシビリティーに大きな影響を与えることがあります。例えば同じページ内だけでも、繰り返し使用されるからです。同様に1つのサイト上で、同じテンプレートが何百回あるいは何千回も使用されることがあります。サイトのアクセシビリティー対応が不十分な場合は、利益が損なわれることにもなりかねません。広告の場合と同じように、ウェブサイトを幅広いオーディエンスに利用してもらえるように、さらなる対応に取り組むことは有意義です。モジュールには、ガイドラインやベストプラクティスの発展に合わせて、コードを改良し、そのモジュールを利用している全てのページのアクセシビリティーを素早く向上できるメリットがあります。
HubSpotのマーケットプレイスでは、アクセシビリティーに配慮し、WCAG要件を満たすことが説明に明記されているモジュールやテンプレートを探してください。開発者と連携して作業している場合は、当初から、アクセシビリティーを重要視していることを開発者に伝えてください。全ての開発者が初めからアクセシビリティーを考慮しているわけではありません。プロジェクトが進んでからでは、最初から検討することに比べて代償を伴います。優先事項として考慮していなかった場合、過去にさかのぼってアクセシビリティーの問題を修正することが必要になるからです。
開発者の方は、制作担当者がアクセシビリティーのガイドラインに準拠しやすくなるモジュールやテンプレートを作成してください。適切な見出しやセマンティックHTMLを採用し、インタラクティブな要素には適切な役割とコンテキストを提供します。アクセシビリティーの課題を認識している制作担当者は、包摂性に配慮したモジュールやテンプレートのために作業が増えても歓迎してくれます。ただし、アクセシビリティーを考慮してモジュールを開発したことは説明しておきましょう。テンプレートにスキップリンクを含め、テンプレート内で使用するグローバルグループやグローバルパーシャルをアクセシビリティー対応にします。これはウェブサイト全体に使用され、サイトのユーザビリティーに大きな効果をもたらすことが期待できます。
HubSpotマーケットプレイス向けの開発では、コンテンツが、ウェブ上の膨大な数のページに使用されることがある点を十分考慮してください。コンテンツを公開したり共有したりする際には、包摂性への配慮の有無にかかわらず、多くの人に影響を及ぼすことになります。
「このスクリプトをウェブサイトに追加するだけでアクセシビリティーを実現」のように宣伝しているツールが数多く提供されています。
こうしたツールの中には、ページのさまざまな部分に意味を付加し、htmlと属性を変更することにより、問題の修正を試みるものがあります。しかし、あくまで推測による処理に過ぎないため、間違いがあったり、サイトの機能を損なったり、ユーザーにとって状況が悪化したりする場合があります。
こうしたツールは、期待通りに動作するとは限らず、場合によっては専用のスクリーン リーダー システムが提供されていることもあります。ウェブサイトのUIが複雑な場合は、さらにツールが組み込まれることで、動作が困難になることもあります。
このような問題があるため、アクセシビリティーに対応したサイトを構築するための代用にはなりません。全てのユーザーに最適な体験を届けるためには、時間もコストも必要になります。ワンストップソリューションを採用しても、適切な開発を行う場合と比べて、コストは同程度か、割高になる可能性があります。テストおよび構築の際にアクセシビリティーを考慮する場合は、顧客に対する共感や理解が得られるメリットもあります。
なお、ここで指摘しているのはテストツールではなく、アクセシビリティーの課題が解決されると宣伝しているツールです。テスト用としては優れたツールが提供されていますので、手動テストの補助として活用してみてください。
アクセシビリティースクリプト／オーバーレイの詳細については、こちらをご覧ください。
アクセシビリティーに配慮したウェブサイト構築について、優れた資料が提供されています。ぜひ参照してください。
- A11Yプロジェクト（英語）
- MDNのアクセシビリティーに関するドキュメント
- Web Accessibility Initiative（英語）
- WebAIM（英語）
- 簡易版WCAG 2チェックリスト（英語）
- 508条チェックリスト（英語）
- WCAG 2.2勧告の詳細（英語）
- DequeのAXE（英語）
- WAVE - ウェブページのアクセシビリティーをテストするためのツール（英語）
- ウェブアクセシビリティー完全ガイド（英語）
貴重なご意見をありがとうございました。