Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

アクセシブルな Web ページの要素について

学習の目的

この単元を完了すると、次のことができるようになります。

  • よく考えられた設計によって、Web のアクセシビリティがどのように高まるかを説明する。
  • 設計のアクセシブルな見出し構造を作成する。
  • 視覚障害のあるユーザーに意味を伝えるために使用される戦略を挙げる。

アクセシビリティはイノベーションの障壁ではなくイノベーションのきっかけ

設計とアクセシビリティに関する最も大きな誤解の 1 つは、アクセシブルな製品は見た目が悪くて、つまらなく、ごちゃごちゃしていると思われていることです。このモジュールでは、この事実が実は逆であること、そしてアクセシビリティとアクセシブルデザイン制約に対する理解を深めることですべてのユーザーにとって使いやすく一貫性のある製品を設計できることを説明します。アクセシブルデザインに関する知識を身に付けることで、革新的な設計を生み出す機会が広がります。

設計チームとアクセシビリティチームは、製品をすべてのユーザーにとって使いやすいものにするという共通の目標を持つパートナーです。設計者は調査チームと協力して、特定のユーザーペルソナが考慮されていることを確認します。また、アクセシビリティチームとも協力して、設計のアクセシビリティについての情報を得られる人格についても考慮します。

マウスだけではありません

わかりきったことかもしれませんが、設計者はマウスクリックと画面上のコンテンツの視覚的な配置だけを担当しているわけではありません。マウス操作や設計のビジュアルレイアウトを考慮することも重要ですが、他にも次の要素について考慮する必要があります。 

  • フローの完全なインタラクションモデル。
  • キーボードだけで機能をどのように使用できるか。
  • タッチ対応ラップトップやタブレットの考慮。
  • 入力モードをマウスとキーボード、タッチ、音声入力との間で切り替えるユーザー。

このモジュールを読み進めながら、設計は同僚のためではなくユーザーのために行うということを忘れないでください。製品を使用する多様なユーザーに考慮した設計を心がけましょう。ユーザーはさまざまな方法で製品を操作し、さまざまな方法で製品から情報を受け取ります。 

多様なユーザーには、視覚障害 (色覚障害や弱視を含む) のあるユーザー、聴覚障害のあるユーザー、一時的または永続的な運動障害のあるユーザー、認知障害のあるユーザーが含まれます。若者から高齢者まで、パワーユーザーから初心者まで、良質なエクスペリエンスを楽しむすべてのユーザーに向けて設計しましょう。

設計からアクセシビリティ重視の制約を意図的に除外することは、製品から意図的に人々を除外することと同じです。他の設計制約と同じようにアクセシビリティガイドラインを尊重しましょう。このガイドラインは、優れた製品を作りあげるための課題であると同時に推進力でもあるのです。 

ユーザーインターフェース (UI) の理解

ユーザーは Web サイトや Web アプリケーションを初めて見るとき、少し時間を取って画面上のすべての情報を確認します。何が可能であるかを知ることで、次のステップがわかります。目が見えるユーザーは、ページをざっと見て全般的なレイアウトを把握し、どこから始めるかを決め、アプリケーションの特定の部分を詳しく掘り下げていきます。このときに見えるのは、さまざまな視覚的グルーピング、大きな見出し、リストに加えて、カード、タブセット、テーブル、ツリーなどの馴染みのあるユーザーエクスペリエンス (UX) パターンです。 

視覚的なユーザーは、Lightning Experience ホームページを下のスクリーンショットのように分類して見ていると考えられます。ここでは、ナビゲーション項目は黄色、大きなグラフは緑、いくつかの情報カードはピンクで強調表示されています。 

Lightning ホームページには構造化されたナビゲーション、グラフ、カードセクションがあります。視覚障害のあるユーザーがページを全体的に理解するには、見出しやランドマーク、その他のセマンティック構造を取り込んだ適切なページ構造が必要です。下の図では、同じ Lightning Experience ページのメインページナビゲーションと明確な視覚的見出しが赤で強調表示されています。最終的にはエンジニアがユーザーにこの情報を公開しますが、設計者が明確なランドマークや見出しを取り入れ、その目的を理解し、エンジニアリングチームに要件として伝えることが重要です。 

ナビゲーションは強調表示され、ページの各セクションは [四半期パフォーマンス]、[今日の行動]、[今日の ToDo]、[最近のレコード]、[主要な商談 - 最近使った商談]、[アシスタント] と明確な表示ラベルが付いています。

レイアウト

目が見えるユーザーが新しい Web サイトに慣れるためのさまざまな手法を使うのと同じように、スクリーンリーダーユーザーにもさまざまなアプローチがあります。スクリーンリーダーユーザーの中には、たとえ時間がかかっても、初めて Web サイトやアプリケーションを表示するときにはあえてページ全体を読み上げるユーザーもいれば、すべての見出しやランドマークに移動することでページの概要をざっと確認するユーザーもいます。

本の章や、雑誌の記事、研究論文の概要セクションを確認するのと同じように、見出しによって Web ページの構造がわかります。ただし、ローマ数字、文字、数字を使用する代わりに、Web ページでは見出しタグの <h1> から <h6> を使用してこの構造をプログラム的に作成します。 

ページが適切にコーディングされると、ユーザーは一般的なスクリーンリーダーの機能を使用してページ上のすべての見出しのリストを取り出すことができます。また、ショートカットキーを推すことで、個々の見出しに移動することもできます。下のスクリーンショットは、スクリーンリーダーユーザーがページのすべての見出しのリストを要求した様子です。1 つのレベル 1 の見出し [Home (ホーム)] があり、他の見出しはレベル 2 です。この Lightning Experience ページの各カードにはレベル 2 の見出しがあります。 

[ホーム] が見出し 1 で、残りのサブ項目が見出し 2 となっている見出しリストビュー。サブ項目は [四半期パフォーマンス]、[今日の行動]、[最近のレコード]、[今日の ToDo]、[主要な商談 - 最近使った商談]、[アシスタント]。

論理的な見出し構造があれば、ユーザーはページのコンテンツのアウトラインを理解できます。さらに、明確で視覚的な見出しがあることで、ユーザーはページの階層も理解できます。これは特に認知障害のあるユーザーに役立ちます。 

論理的な見出し構造に加えて、エンジニアはセマンティックな HTML ランドマークを使用することで、ユーザーがページ内で現在位置を特定しやすくする必要があります。その具体的な内容は次のとおりです。

  • ヘッダー
  • ナビゲーション
  • メインコンテンツ領域
  • 記事
  • 補足 (サイドバーやコールアウトに使用されることが多い、浅く関連しているコンテンツ)
  • 本文
  • フッター

スクリーンリーダーによってランドマークが識別されるため、ユーザーはキーボードショートカットで範囲ごとに移動することが可能になります。設計者ができることは、エンジニアが適切にコードに含めることができるように、明確なランドマークを設計してエンジニアに示すことです。 

下の例では、ページにあるランドマークは [グローバルナビゲーション] ナビゲーション範囲の 1 つだけです。

VoiceOver の [Landmarks (ランドマーク)] パネルが表示されており、現時点では [グローバルナビゲーション] ナビゲーションだけがリストされている Lightning Experience ホームページ。

それ以外の検索、ヘッダー、メイン、記事などの役に立ちそうなランドマークが含まれていません。

アイコンと画像

一部の視覚障害のあるユーザーはスクリーンリーダーやデジタル点字キーボードを使用していますが、この支援技術ではテキストが読み上げられるだけで、アイコンや画像が自動的に読み上げられることはありません。そのため、設計者はアイコンや画像を適切に作成する必要があります。 

アイコンには 2 種類あり、スクリーンリーダーでの処理方法が異なります。装飾アイコンはスキップされ、情報アイコンはユーザーに内容が伝えられます。設計者はこの違いを理解して、使用事例に適した方を選択し、必要に応じてコンテンツエクスペリエンスの仮ラベルを記述し、エンジニアが正しくアイコンをコーディングできるように伝える必要があります。 

装飾

装飾アイコンや装飾画像を使用しても、関連性のある情報や機能は追加されません。冗長なアイコンや画像もこのカテゴリに分類されます。隣接するテキストの意味を強調することはあっても、新しい情報が追加されることはないからです。ユーザーにとっては冗長で不要な情報が追加されるだけですから、スクリーンリーダーで読み上げられないようにする必要があります。アイコンには「装飾」ということを特にマークする必要はありませんが、画像には空の alt タグが必要です。これでスクリーンリーダーによる読み上げから除外することができます。空の alt タグがない画像が検出されると、その画像の src タグ (/images/weji2362iofweio6.png など) がスクリーンリーダーで読み上げられます。

下の画像の [取引先責任者の役割]、[商品]、[メモ & 添付ファイル] アイコンは冗長であるため修飾アイコンです。各アイコンに隣接するテキストが同じ情報を説明しています ([メモ & 添付ファイル (0)] の横のファイルアイコン)。

[取引先責任者の役割]、[商品]、[メモ & 添付ファイル] アイコンと同じ情報を説明する隣接するテキスト ([メモ & 添付ファイル (0)] の横のファイルアイコンなど) が表示されているインターフェース画像。

情報 

情報アイコンと情報画像は、周りのテキストが伝達しない重要な情報を伝達します。アイコンボタンやスタンドアロンアバターが一般的な例です。アイコンには補助テキストまたは aria-label が必要で、画像には alt 説明が必要です。アイコンや画像の見た目ではなく機能を記述します (たとえば、「ペーパークリップ」ではなく「ファイルのアップロード」)。

下のスクリーンショットでは、上部のグローバルナビゲーション内のアイコンボタンはすべて情報アイコンで、使用するにはアイコンの機能を知る必要があります。

情報アイコンの星 (お気に入り)、プラス記号 (追加)、疑問符 (ヘルプ)、ギア (設定)、アラームベル (通知)、写真 (ユーザーのアバター) が表示されているグローバルナビゲーション。

次のアイコンはどうでしょうか? 隣接するテキストがありますが、これも情報アイコンです。このアイコンはオブジェクトが取引先であることを示していて、テキストは取引先名であるためです。このアイコンがなければ、ユーザーはこれが取引先責任者なのか、商談なのか、その他の種類のオブジェクトなのかを知ることができません。

取引先を表す紫の建物のアイコンとその横に表示された取引先名「Acme」。

まとめ

設計チームとアクセシビリティチームは、製品をすべてのユーザーにとって使いやすいものにするという共通の目標を持つパートナーです。設計の構造とレイアウトを考慮し、画像やその他の非テキストコンテンツの代替テキストを含めることで、障害のあるユーザーのための強力な足場を提供できます。次の単元では、ユーザーが設計内のコンテンツをより適切に認識して理解しやすくするための方法について説明します。 

リソース

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む