セマンティックマークアップを使用したユーザーインターフェースの作成

学習の目的

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

• コンテンツをアクセシビリティ対応にするためにセマンティックマークアップが必要である理由を説明する。
• ARIA の 3 種類の属性を定義する。

はじめに

アクセシビリティ対応のユーザーインターフェースを作成するには多くの要素が関与しますが、一般にインターフェースが複雑であるほど多くの要素について考慮する必要があります。たとえば、シンプルなブログ記事やニュース記事は、コメントやソーシャルメディア機能などのインタラクティブ機能が付いているニュース記事よりもアクセシビリティに関する考慮事項が少なくなります。レポートまたはダッシュボードビルダー、ページレイアウトエディター、または Kanban スタイルのリストビューなどの複雑な Web アプリケーションの場合は、アクセシビリティに関するニーズがより大きくなります。

Web ページやアプリケーションが複雑であるほど、障害のあるユーザーがアクセスできるようにするために多くの作業が必要になります。ただし、どのような Web ページまたはアプリケーションをアクセシビリティ対応にするとしても、まずは基本から始める必要があります。 

セマンティックマークアップ

セマンティックマークアップはすべてのアクセシビリティの根底にあります。Web ページに表示されるコンテンツは、そのコンテンツの種類を表すマークアップを使用して提示する必要があります。たとえば、表形式データを表示するには <table> ベースのマークアップを使用し、リストを表示するには <ul> ベースのマークアップを使用し、視覚的な見出しには見出しタグを使用する必要があります。

セマンティックマークアップを使用することにより、マシンやソフトウェア (具体的には支援技術) が読み込んで理解できるようになります。これはコンテンツをアクセシビリティ対応にするために必要です。レポートビルダーが適切な形式の HTML の <table> 要素を使用して作成されていれば、視覚障害のあるユーザーがスクリーンリーダーを使用して操作できます。一方、同じ内容を <div> 要素を使用してマークアップすると、視覚障害のないユーザーには同じように見えても、視覚障害のあるユーザーは操作または理解することができません。

Web ページと Web アプリケーションの HTML 構造によって、支援技術、そして支援技術を使用するユーザーはコンテンツの意味を把握します。可能な限り、セマンティック HTML5 要素を使用し、Nu HTML Checker などのチェッカーを使用してマークアップを検証することをお勧めします。

ARIA の使用開始

ARIA (Accessible Rich Internet Applications) は、HTML の拡張機能で、Web ページがマークアップや表示目的以上のことに使用されるという認識に基づいています。ARIA では、Web は複雑なアプリケーションを構築するためのプラットフォームであるとの理解から、障害のあるユーザーに支援技術を通じて高度なインタラクションを伝える方法が提供されます。

ARIA は、HTML DOM ノードに特別な属性を適用することによって機能します。ARIA には、ロール、状態、プロパティの 3 種類の属性があります。

ロール

ロールによって、<div> や <span> などの元々はセマンティックな意味を持たない HTML 要素にセマンティックな意味を与えることができます。たとえば、ARIA ロールを使用して、非セマンティック要素のセットをボタンやリンク、あるいはより複雑なコンポーネントであるメニュー、コンボボックス、モーダル、インタラクティブグリッドとして識別できます。 

ロールはユーザーに対する約束です。要素に ARIA ロールを追加する場合、たとえば <div> に role="button" を追加すると、<div> をボタンとして識別することを指定しています。この <div> は、ブラウザーのアクセシビリティツリー内で <button> として表示されます。ブラウザーのアクセシビリティツリーは、スクリーンリーダーに提示される情報のスナップショットです。つまり、この <div> にはボタンが本来持つすべての機能 (フォーカス状態、キーボード操作、マウス操作など) も提供する必要があります。<div> をボタンと呼びながらボタンとして機能するようにしなければ、ユーザーへの約束を破ったことになります。

状態

状態は、ARIA コンポーネントの状況をブラウザーのアクセシビリティツリーに対して説明する属性です。状態によって、ドロップダウンメニューが expanded (展開されている) かどうか、入力種別が disabled (無効) または readonly (参照のみ) になっているかどうか、チェックボックスが checked (オン) になっているかどうか、リストボックス内の項目が selected (選択されている) かどうかなどを説明します。ARIA を使用して複雑なコンポーネントを作成する場合は、コントロールの操作によってさまざまな状態を正確に更新することが不可欠です。これも、ロール属性を使用したときのユーザーへの約束を守ることの一環です。 

プロパティ

W3C は ARIA プロパティを「特定のオブジェクトの性質に不可欠な属性、またはそのオブジェクトに関連するデータ値を表す属性」と定義しています。これらは、オブジェクトの性質を説明する属性です。multiple 属性がある <select> 要素と multiple 属性がない <select> 要素の違いについて考えてみましょう。前者は複数項目を選択できるコンボボックスですが、後者は折りたたまれた状態からユーザーがクリックしてボックスを開き、1 つの項目を選択する必要があるコンボボックスです。この場合、multiple はネイティブ要素である <select> のプロパティです。 

同じように、ARIA にはプロパティ属性が多数あります。これらは、オブジェクトを説明するために使用されますが、必ずしもオブジェクトの状態を更新するために頻繁に変更されるわけではありません。

どの ARIA 属性をいつどのように使用するかを知るのは非常に難しい場合があります。一般に、Salesforce Lightning Design System (SLDS) のコンポーネントブループリントに従うことを強くお勧めします。SLDS には HTML のブループリントが 900 以上含まれていて、マークアップ、属性、キーボード操作の詳細なアクセシビリティガイドラインが用意されています。これらのブループリントには、適切な ARIA ロール、プロパティ、状態が適切な場所に含まれています。さらに、ブループリントにはアクセシビリティ情報も含まれていて、作成しているコンポーネントの状態とプロパティを正しく関連付け、管理する方法が詳しく説明されています。 

SLDS コンポーネントブループリント内の ARIA は、支援技術でテスト済みで、『ARIA Authoring Practices Guide (ARIA 作成手法ガイド)』に基づいています。このドキュメントは定期的に更新されていて、ARIA と多くの一般的な設計パターンについての最新の情報源です。 

必要なインタラクションパターンが SLDS コンポーネントブループリントに見つからない場合があります。Salesforce の設計システム内に情報が見つからない場合は、『ARIA Authoring Practices Guide (ARIA 作成手法ガイド)』と ARIA 仕様自体を参照してください。インターネット上のその他のすべての情報は信用しないでください。最新のアクセス可能なソリューションと見せかけたアイデア、探索や、単純に不良でアクセスできないコンポーネントが多数存在します。

アクセシビリティ対応ユーザーインターフェースの作成の基本がわかったところで、次はアクセシビリティのナビゲーションについて見ていきましょう。 

リソース

• ドキュメント: ARIA Authoring Practices Guide (ARIA 作成手法ガイド)
• ドキュメント: Accessible Rich Internet Applications (WAI-ARIA) 
• ツール: Nu HTML Checker
• Salesforce ヘルプ: Salesforce Lightning Design System