暗黙的な ARIAセマンティックがある要素では role 属性を外すことが今後推奨されるようだけど、まだ外すのは時期尚早

概要

ARIA in HTML で main のように暗黙的な ARIAセマンティックがある要素では、同じ意味を持つ role 属性が非推奨になったので、ゆくゆくは外していく流れ。だけど、今現在は古いブラウザの対応などがあるので、まだまだ role 属性は外せなさそう。

<main role=”main”> という記述が非推奨に

ミツエーリンクスさんのアクセシビリティBlog で、ARIA in HTML日本語訳)というものの草案が4月14日に発表されたことを知りました。HTML5.1 において、WAI-ARIA をどのように使っていけばいいかが書かれている文書のようです。で、記事を読み進めていく中で気になった点が一つあったのでメモ。

しかし、ARIA in HTMLでは、制作者は暗黙のARIAセマンティックをrole属性などで指定すべきではない(SHOULD NOT)、また、指定することは推奨されない(NOT RECOMMENDED)ことであるとしています。つまり、<main role=”main”>ではなく<main> と記述することを推奨しています。

W3CがARIA in HTMLの最初の草案を公開 | アクセシビリティBlog | ミツエーリンクス

お!HTML5.1 では、暗黙的に ARIAセマンティックが規定されている要素に対して、それと同様の意味を持つ role 属性などを付けるのは非推奨になる流れのようです。引用した記事内では main 要素の例が挙げられています。では、<main role="main"><main> と書くという話ですが、header 要素に role="banner" をつけたり、footer 要素に role="contentinfo" をつけるのも非推奨になるのでしょうか。

ARIA in HTML で確認

どの要素に対して、どの role属性を使用してもいいか、はたまた使用すべきではないかは ARIA in HTML にちゃんと書いてあるようです。ARIA in HTML の中の 2. Document conformance requirements for use of ARIA attributes in HTML日本語訳)という項目の中にあります。3列の表組みがあって、1列目は対象となる HTML の要素。2列目が暗黙的に規定されている ARIAセマンティック。これには「SHOULD NOT be used」と書かれています。使うなと。3列目は、ARIA のロール、ステート、プロパティー。こちらは「MAY be used」なので、使ってもいいよとのこと。

先ほど例に挙げられていた main 要素を見てみると、2列目には role="main"、3列目には No role / global aria-* attributes と書かれています。「暗黙的に role="main" という ARIAセマンティックが規定されているので、使っていいロールは無いよ。aria-label とかのグローバルなステートやプロパティーは使っていいよ」ということのようです。

では、前の項で挙がった header だったり footer だったりはどうなるのか。header は2列目に If not a descendant of an article or section element role=banner, otherwise NONE、3列目は先ほどの main にもあったように global aria-* attributes と書かれています。「articlesection の子孫じゃない場合は暗黙的に role="banner"。それ以外の場合はデフォルトの ARIAセマンティックを持ちません。グローバルなステートやプロパティーは使っていいよ」ということらしいです。

articlesection の子孫じゃない場合、つまりサイトのヘッダーとして header を使うみたいな時は暗黙的に role="banner" という ARIAセマンティックが規定されるということでしょうか。逆に、articlesection の子孫の場合、例えば記事タイトルとか投稿日時などのメタ情報を記事内に記載する場合に使う header は ARIAセマンティックを持たない。暗黙的な ARIAセマンティックを持っている要素に対して、role 属性を付けるのは非推奨ということなので、サイトのヘッダーとして使う時は role="banner" を付けるのは非推奨になるようです。

footer の場合も role="banner"role="contentinfo" に変わっただけで同じです。 コピーライトや作者の連絡先を載せているサイトのフッターとしての footer には暗黙の role="contentinfo" を付けるのは非推奨になるようです。

role 属性は補助輪

先日買った書籍「コーディングWebアクセシビリティ」の P90からP99「4-2 有名なランドマーク」という節に、role 属性に関することが書かれています。特に重要だと思ったのは、暗黙的なARIAセマンティックを持つ要素に対して role 属性を付けるのは、自転車に補助輪を付けているようなものという箇所です。

role 属性無しの HTML 単体でアクセシブルな状態ならばそれでよいのですが、今現在はそのような状態ではありません。書籍内に補助輪は、補助輪なしで走れるようになるまで自転車のタイヤを支えるためにあるのです。とあります。ARIA in HTML を参照するように書かれている HTML5.1 はまだ草案段階ですし、古いブラウザのサポートもあるので、今現在はまだまだ role 属性という補助輪なしで走れるような環境ではありません。時期尚早だと思います。

ということで、role 属性という補助輪を今すぐに外せるとは全く思いませんが、後々はこうなっていくということを覚えておきたいがためのメモでした。

リンクを色だけで表現しないようにする

ブログ改善シリーズ。今回は、リンク箇所に下線を表示する改善を行いました。これ自体は全く難しいことではないのですが、何故そうしたかを書いていきます。

改善前

まず改善前の画像を見ていただきたいと思います。リンクは青色、通常の文字は黒色。一応、リンクと通常の文字は見分けられる。ちなみに、もう修正済なのですが、以前はリンクにホバーすると下線が引かれるようになっていました。

改善前のブログ画面

一見何も問題ないように見えますし、このようなスタイルのウェブサイトはいくつも見てきました。が、アクセシブルかどうかでいうと、問題があるようです。

達成基準

当然、色の使用に関しても、しっかり JIS X 8341-3:2010 では達成基準が設けられています。

情報を伝える、何が起こるか若しくは何が起きたかを示す、利用者の反応を促す、又は視覚的な要素を区別する視覚的な手段として、色だけを使用してはならない。

7.1.4.1 色の使用に関する達成基準 : 富士通

前の記事でも参照させていただいた、インフォアクシアの植木さんのJIS X 8341-3:2010を『日本語訳』してみる!~Webアクセシビリティの基本の『キ』~ というスライド(PDF) の 96 ページを参照すると、上記の文章は色の違いが分からなくても理解できるようにするという意味のようです。

グレースケールでこのブログを見てみる

では、色の違いが分からない状態で、このブログを見てみるとどうなるか確認してみます。(un)clrd というブラウザの画面をグレースケールにできるアドオンがあります。Chrome 用Firefox用があります。このアドオンで私のブログをグレーにして見てみます。

グレースケールで見たブログ画面

グレースケールにすると、リンクであることがわかりづらくなります。太字にはなっているけど、これだと <strong> による強調と区別がつかないので NG 。

改善後

この状態を改善するために、リンクに下線をつけました。以下が改善後のブログをグレースケールで見た画面です。

改善後のブログ画面

これで、色の違いが分からない環境で見ているユーザーさんでも、通常の文字とリンクの違いがわかりやすくなりました。

リンクにフォーカスした時のスタイルを設定しました

ウェブサイトを利用する際の方法としてマウスやタップがありますが、tab キーを利用する方法もあります。tab キーを押すとリンクごとにフォーカスがあたっていくのですが、そのフォーカスが当たっていることを、よりわかりやすくするような装飾を、このブログで設定しました。

達成基準を確認

このフォーカスですが、アクセシビリティにおいて基準が設けられています。アクセシビリティの分野ではおなじみ、JIS X 8341-3:2010 では以下のようになっています。

キーボード操作が可能なユーザインタフェースには、キーボードフォーカスの状態が視覚的に認識できる操作モードがなければならない。

7.2.4.7 視覚的に認識可能なフォーカスに関する達成基準 : 富士通

インフォアクシアの植木さんがAccSell Meetup 008 『集まれ!アクセシビリティー・ビギナーズ!2015』というイベントで発表されたJIS X 8341-3:2010を『日本語訳』してみる!~Webアクセシビリティの基本の『キ』~ というスライド(PDF) の 85 ページを参照すると、上記の文章が言いたいことはキーボードフォーカスの位置が分かるようにするということのようです。このスライド 、難しい日本語で書いてある JIS X 8341-3:2010 を噛み砕いて解説しているのでオススメです。

ブラウザのデフォルトスタイルシート

フォーカスされた際のスタイルは、もともとブラウザが持っているデフォルトスタイルシートで設定されています。例えば、Chrome では要素が :focus された際には以下の CSS が適用されます。

outline-color: rgb(59, 153, 252);
outline-offset: 0px;
outline-style: auto;
outline-width: 5px;

Chrome のデフォルトスタイルシートだと、フォーカスされた箇所に青い枠が出る感じですね。調べてみたら、見栄えのために打ち消す指定をしている方もいらっしゃるようでしたが、私はわざわざそれを消したり変更したりすることはしませんでした。

outline: none; とかの指定をして、デフォルトスタイルシートの指定を打ち消すことをしなければ、アクセシブルではあると思うのですが、もう少しフォーカスをわかりやすくするために、ブラウザのデフォルトスタイルシートにプラスしてスタイルを指定するようにしました。

:hover と同じスタイルを設定

今回フォーカスのスタイルを指定するにあたって、どういうスタイルにしようか悩んだのですが、今回はホバー(:hover)した時と同じスタイルにしました(一部を除く)。何故、そのような指定にしたかというと、ホバーとフォーカスが同じ段階にあると考えたからです。

例えば、リンクをクリックしてページ遷移するという行動を考えた時、マウスとtab キーでは、以下のような段階を踏みます。

マウスの場合
  1. マウスを動かして、リンクにホバー
  2. マウスをクリックしてページ遷移
tab キーの場合
  1. tab キーを押して、リンクにフォーカス
  2. Enter キーを押してページ遷移

ページ遷移をする1段階前の行動という意味で、この2つは同じ段階にあると考えました。もし、:focus のスタイルに悩んだら、とりあえず :hover:focus のスタイルを一緒にしてみるのもいいかもしれません。