role 属性は、要素が示す役割を明確にするための属性です。 例えば、header 要素はコンテンツの header か、あるいはサイト全体の header を示すことなどができますが、 どちらの header であるかを明確に区別する手段はありません。 しかしながら、role 属性の値 banner によって、コンテンツ固有の header ではなく、サイトの持つ header であることを示すことができます。

HTML5 以降の HTML は、ある役割を示す要素が多く存在しますが、role 属性はより強く役割を示します。

role によって役割を明確にする意味

role 属性は HTML などで使いますが、role 属性に与える値や役割は HTML とは切り離された ARIA と表記される区分に定義されています。

ARIA の主な目的は、あらゆる障害を持ったユーザに適切に情報を伝えることです。 つまり、障害を支援するシステムがページの情報を正確に解析できるほど、 障害を持ったユーザに正しい情報を提供することが出来る、という考えです。

したがって、Web サイトの運営者が role 属性を設定することによって得られる基本的なメリットは、障害を持ったユーザを獲得できる、ということです。

SEO の効果が得られるか

システムに正しい情報を伝えることを目的としていることから SEO の効果が期待できそうですが、 これについては定かではありません。公開された資料は執筆時点では見つかりませんでした。

障害を持ったユーザを獲得することによって副次的に掲載順位が上昇することはあるかもしれませんが、それ以上の効果はないでしょう。 後の項目で言及しますが、HTML5 以降の HTML のいくつかの要素は、role 属性を暗黙的に示すことがあります。 したがって、多くのサイトが基本的な role 属性には対応していることになります。

role 属性の種類

role 属性の値は数多くあります。次の公式ページから、カテゴリ別か一覧して確認することができます。

多くの role 属性に対応することは、特に障害を持ったユーザを対象とした Web サイトや、企業向けのサイトを作るとき以外には現実的ではありません。 個人が管理する Web サイトでは負担が大きすぎます。ここでの負担とは、role 属性を理解し、HTML に正しく設置し、更新の際にその整合性を確認する負担です。

幸いなことに、HTML5 以降の HTML に定義されるいくつかの要素は、暗黙的な role 属性が定義されています。 また、暗黙的な role 属性を持つ要素に対しては、それと同じ role 属性は指定するべきではない、とされています。 したがって、あらゆる要素に role を指定する作業コストは必要になりません。

例えばこのページの冒頭で例を示した header 要素は、article 要素や section 要素の子孫ではないとき、role 属性 banner を暗黙的に持っていると見なされます。 他に、頻繁に使われる li 要素などは listitem を示すようにされているので、すべての li を逐次指定する必要はありません。

要素が持つ暗黙的な role 属性と、要素に設定できる role 属性は、W3C の HTML5(以降のHTML) のページから確認することができます。 Default Implicit ARIA Semantics のテーブルが一番見やすいでしょう。

landmark カテゴリの role を確認する

"landmark" カテゴリに分類される role 属性は、サイト全体の大まかな構成を示すためのものです。

サイト全体の大まかな構成を伝えることができれば、個人の管理する Web サイトの体制としては十分ではないかと思います。 一般に、全体の構成は変更されることが少ないので、暗黙的な role との重複を確認したり、整合性を管理することも容易でしょう。

特に要素が暗黙的に示す role と重複する可能性がある landmark カテゴリの role は次のものです。

• aside 要素は complementary を示します。
• main 要素は main を示します。
• form 要素は form を示します。
• nav 要素は navigation を示します。
• article/section 要素の子孫でない header 要素は banner を示します。
• article/section 要素の子孫でない footer 要素は contentinfo を示します。

Web サイトの構成やマークアップの方法に依存しますが、HTML5 以降の HTML でマークアップされたページの場合には、 実質的には application, form, search 以外を指定する機会は少ないと思います。

complementary の補足

一般には、complementary は 同じような位置にあるドキュメントの内容を補足するために用います。 しかしながら、主要なコンテンツ(main)と切り離されているものの、そのコンテンツを補足するようなコンテンツのコンテナにも使うことができます。

公式にはポータルサイトにおける天気やカレンダー、時間などが例に挙げられています。 "主要なコンテンツ(main)と切り離されている" を言い換えれば、中央に置かれる主要なコンテンツと、 それとは分離されたサイドバーにあるコンテンツのような関係と言えるでしょう。

main の補足

role="main" は main 要素に設定することが W3C によって推奨されています。 これは、先に示した "暗黙的な role 属性を持つ要素に対しては、それと同じ role 属性は指定するべきではない"、に矛盾します。

ドキュメントを読む限り、ユーザエージェント(ブラウザ)が、main 要素の(暗黙的な) role が正しく処理することが保障されるまでは、任意に role を示しましょう、ということのようです。 main は特に重要なコンテンツを示しますから、role の指定を明示するべきである、という考え方なのだと推測します。

一方で main 要素そのものがページに 1 つしか設定することができない要素ですから、role を使ってまで明示する必要があるかどうかは疑問です。 また、特に古いユーザエージェントに対する措置としての措置と考えられますが、そのようなブラウザは role="main" にも上手く対応しないと思われます。

結論として、main 要素に対してわざわざ role="main" を指定する必要はなさそうです。

UI 関連の role

一般的な Web ページの構成と異なるサイトや、Web アプリケーションを提供するようなページでは、 UI(ユーザインターフェース)に関する role の導入を積極的に検討する価値があると思います。 UI が正しく操作できない場合、サービスを提供する、利用することができないためです。

menu の設定

menu は landmark カテゴリの role ではありませんが、landmark カテゴリの role のように、 ページ全体の構造に関する情報をスクリーンリーダに提供する可能性があります。

nav 要素は landmark カテゴリの role, navigation を暗黙的に示しますが、 nav 要素が TOC(Table of Contents) のような情報を示すものなのか、 あるいはサイト全体のメニューを示すものなのかは定かではありません。

もしもサイト全体のメニューに対して menu が指定されていれば、 nav 要素が暗黙的に示す navigation 以上に明確な情報をユーザーエージェント(スクリーンリーダ)に提供することになります。

一方で、role="menu" の設定がスクリーンリーダによって理解されないとき、 role="navigation" が設定された状態の方が、障害を持ったユーザにとって有益である可能性があります。

menu 以外の UI に関する role

Widget カテゴリには、 tab, scrollbar, statuc などの UI を示すための role が存在します。 情報が膨大に膨れ上がってしまうため、詳細は公式の資料を確認してください。

他のカテゴリの role と同じように、個人が管理する Web サイトに含まれるすべての UI に対して role を設定することは現実的ではありません。 ただし、同じように、暗黙的な role が定義されています。例えば type="radio" が 設定された input 要素は、暗黙的に role="radio" を示します。 特にその Web サイトやアプリケーションに重要な UI にのみ、明示するようにすれば十分でしょう。