inertとは何だろう

HTML5などにはinert（不活性）という概念があります。イナートと読むのでしょう（たぶん）。

inertなノードとその子孫はユーザーによる操作の対象にはならない、そうです。ブラウザーによってはinertなノードを選択できなかったり、ページ内検索の対象としないかもしれません。また、inertなノードはフォーカスを受け取ることもありません。

…SVGにはpointer-eventsというプロパティがあり、pointer-events:none;を指定すると要素がマウス操作などを受け取らない（奥の要素がマウス操作などを受け取る）ように設定できますが、それを思い出しました。

それはともかく、ノードがinertになる状況として、モーダルダイアログの裏にきている時があります。dialog要素のshowModal()を使ってモーダルダイアログを表示すると、dialog要素（とその祖先要素と子孫ノード）以外のノードがinertになります。これによって、モーダルコンテンツ以外がユーザーによって不用意に操作されることを防ぐことができます。

また、HTML 5.1やHTML Living Standardではinert属性が定義され、要素を手動でinertにすることができます。

<div inert>これはinertな要素です</div>

とはいえ、inertなノードをユーザーが操作することはできないので、使い所には注意しないと本当に「使えない」ページができてしまいます。手動でinertにする場面は、あまり思いつきませんが、例えば、アニメーションしながら画面から消えてゆく要素をユーザーが不用意に操作しないようにアニメーションを始めた段階でinertにする、などがあるかもしれません。

role="navigation"はどの要素に書くのが良いのだろうか

基本

HTML5に関して言えば基本的にはどの要素にも書かない、と考えています。

もともと、role="navigation"はその要素がナビゲーションランドマークであることを示します。そしてHTML5では、主要なナビゲーションを表すnav要素が新設されました。このnav要素は暗黙的にナビゲーションランドマークとなることが仕様に書かれていますので、nav要素を使えばrole="navigation"を書く必要は基本的にありません。

もう少し明確に書くと、「暗黙的にナビゲーションランドマークとなる」は「nav要素のStrong native semantics（とdefault implicit ARIA semantics)はnavigation roleである」を指し、「仕様」も以下のものを指してます。

蛇足を続けると、Strong native semanticsは要素が本質的にもっていてrole属性で上書きできないセマンティクスのことです。つまりnav要素は暗黙のうちにrole="navigation"であり、それを変更することはできないということになります（role="presentation"という指定はできますが…）。なので、nav要素を使うかぎりrole="navigation"は基本的に不要です。

例外

基本があれば例外もあります。

nav要素は暗黙的にナビゲーションランドマークとなる、と書きましたが、この暗黙的な対応付けはブラウザーなり支援技術なりが行います。ブラウザーや支援技術が対応付けを広くサポートしていれば、nav要素にrole属性を書く必要性はありません。

しかしながら、Using ARIA in HTMLのEditor's Draft（2013年9月2日閲覧）を見ても、「nav要素の対応付けは、ブラウザーで広くサポートされているわけではないので、デフォルトのARIAセマンティクスは明示的に書く（nav要素にrole="navigation"を指定する）べき」とされています。具体的にどの実装がどう、あの実装がどうという話はしませんが、私個人としても現時点では書いた方が良いと思います。

ただ、これは現在が過渡期という例外的な時代のためであって、必ずや過渡期は終わりnav要素にrole属性を書かない時代が来るものと信じています。

その他の要素

HTML5にnav要素がある以上はnav要素を使うのが自然だと私は思います。

HTML5 スタンダード・デザインガイドで紹介されているAppleのWebサイトにはul要素にrole="navigation"が指定されていました（と、思うのですが今手元に本がないため、記憶に頼ってこの文を書きました）。しかし、ナビゲーションリストを表現するにはnav要素の子供にul要素を記述するのが自然だと私は思います。これはリンク画像を表現するには、a要素の中にimg要素を記述するのと同じことだと思っています。

…そもそもHTML5の要素に設定できるrole属性値は、デフォルトのセマンティクスと乖離しないように制限されており、ul要素にはrole="navigation"は指定できません。詳細は「仕様」を参照ください。

新しいHTML5勧告候補（2013年8月版）で目についたところ

先日、HTML5の新しい勧告候補が公開されました。今更ですが、目についた変更点を挙げます。

要素の追加と削除

  • data要素が追加されました
  • main要素が追加されました
  • hgroup要素が削除されました
  • menu要素とcommand要素が削除されました

data要素

data要素は、要素の中身に通常のコンテンツを、value属性にコンピューターが読み取れる形式のコンテンツを、記述する要素です。

2013年8月版の勧告候補の中でも、Common idiomsの会話の例にdata要素を使ったマークアップの例が出ています。

<p> <data value="1319898155">14:22</data> <b>egof</b> I'm not that nerdy, I've only seen 30% of the star trek episodes
<p> <data value="1319898192">14:23</data> <b>kaj</b> if you know what percentage of the star trek episodes you have seen, you are inarguably nerdy
<p> <data value="1319898200">14:23</data> <b>egof</b> it's unarguably
<p> <data value="1319898228">14:23</data> <i>* kaj blinks</i>
<p> <data value="1319898260">14:24</data> <b>kaj</b> you are not helping your case

time要素ではUNIX時間を設定できないため、かわりにdata要素を使っているそうです。

先ほどの例はtime要素を使わない必然性があるのか疑問ですが、Mozilla Hacks（日本語訳）にもう少しわかりやすい例がありました。data要素の中身にユーザーの名前、value要素にユーザーIDを指定し、DOM APIを使ってユーザーIDを取り出しています（おそらく）。

<data id="user" value="humphd">David Humphrey</data>
document.getElementById("user").value; // "humphd"

要素のカテゴリの追加

Reassociateable elementsはform属性を使って、自分が属するフォームを設定できる要素です。具体的には次の要素になります。

  • fieldset
  • label
  • input
  • button
  • textarea
  • select
  • keygen
  • output
  • object

また、「Scrpit-supporting elements」カテゴリが新設されました。このカテゴリにはscript要素のみが属します（HTML 5.1の草案ではtemplate要素も含まれています）。単にカテゴリが増えただけではなくて、いくつかの要素の内容モデルが更新されています。要素の一覧（non-normative）を見ると、次の要素にScript-supporting elementsを置けるようになりました。

  • dl
  • ol
  • ul
  • table
  • colgroup
  • thead
  • tbody
  • tfoot
  • tr
  • optgroup

HTML5の段階ではあまりメリットを感じませんが、template要素が使えるようになると面白くなりそうです。

そのほか

article要素のとsection要素の使い分けに関する節（non-normative）が追加されました。が、「場合によるよ」という内容です。

main要素の追加、hgroup要素の削除にともなってCommon idioms without dedicated elementsの1つ目の例が全面的に変わりました。2012年12月版の勧告候補では「The main part of the content」（コンテンツの主要な部分）でしたが、2013年8月版の勧告候補では「Subheadings, subtitles, alternative titles and taglines」（サブ見出し、サブタイトル、代替タイトルおよびキャッチフレーズ）になりました。

まとめ

前回の勧告候補と今回の勧告候補の差分を見ると、場所によってはかなり変更されていました。2013年8月版の勧告候補公開後も、すでにText Track APIが若干変更されるなど、まだしばらくはHTML5仕様の動向に注意が必要かもしれません。

DOM Inspectorで要素のARIA role値を確認する

HTMLの要素には暗黙的に付くARIA roleが定められているものある。これってどうやって取るの？ って話

とteramakoさんが書かれていたので便乗です。言いたいことは、DOM Inspectorを使うと、nsIAccessbileオブジェクトのxml-rolesを手軽に確認できる、ということです。

ここから宣伝。DOM Inspectorのアクセシビリティ調査機能は、「DOM Inspectorを使ったアクセシビリティオブジェクトの調査」が詳しいです。宣伝終わり。

DOM InspectorのAccessible Propertiesペインには、Object attributesというタブがあります。このタブにはnsIAccessibleオブジェクトのattributesが列挙されます。そのため、nsIAccessbileオブジェクトのattributesにxml-rolesキーがあれば、Object attributesタブにxml-roles項目が表示され、値を確認することができます。

f:id:takenspc:20130707220334p:plain

B2GでAccessFuをそれなりに試す

B2Gのアクセシビリティ機能は常用できるレベルにはまだ達していませんが、試すレベルでもいくつかのハードルがあります。

スクリーン・リーダー（AccessFu）に関して言えば、そもそもテキストから音声に変換する機能が入っていない*1のですが、次のような問題もあります。

  • 1. SettingsにAccessFuの有効化オプションがない
  • 2. 画面に表示されていないアイテムにも仮想カーソルが移動し、どのアイテムを選択しているのかわからない
  • 3. ホームスクリーンのアプリを起動できない

1番目の「設定画面にAccessFuの有効化オプションがない」問題は、SettingsアプリのHTML（gaia/apps/settings/index.html）を編集するだけで解決します。

アクセシビリティの項目が表示されないのはhidden属性が設定されているためですので、表示させるにはhidden属性を取ります。

<li hidden>
  <a id="menuItem-accessibility" class="menu-item" href="#accessibility" data-l10n-id="accessibility">Accessibility</a>
</li>

2番目の、「画面に表示されていないアイテムに仮想カーソルが移動し、どのアイテムを選択しているのかわからない」には2つの観点があります。まず、画面に表示されていないアイテムに仮想カーソルが移動する問題から考えます。

B2GでAccessFuを起動すると、仮想カーソルが選択しているアイテムにオレンジ色の枠がつきます*2。ここまでは良いのですが、しばしば、アイテムが存在していないよう領域にも、オレンジ色の枠が移動します。これは、起動アプリの奥に存在する（z-indexの小さな）アプリの内部で、仮想カーソルが移動しているためです。画面上は、手前のアプリケーションに重なって見えないアプリケーションも、適切に作らないと、支援技術からは丸見えとなり、仮想カーソルが移動していってしまいます。

この問題の解決方法はいくつかあります。

  • display:noneを設定する
  • visibility:hiddenを設定する
  • aria-hidden属性を設定する

display:noneやvisibility:hiddenが設定された要素は、画面に描画されませんし、AccessFuからもアクセスできません（仮想カーソルが移動しません）。

描画はされているが、支援技術からアクセスできると困るものにはaria-hidden=trueを設定します。aria-hidden=trueを指定した要素（とその子孫）はAccessFuからアクセスできなくなり、仮想カーソルが移動しなくなります。Gaiaではロックスクリーンでaria-hidden属性が使われています（関連コミット）。ロックスクリーンを解除する前に、裏で起動しているアプリにアクセスできたら困ります。

もう1つの観点は、現状、仮想カーソルがどのアイテムに移動しているのかわからない、というものです。将来的には修正されるかもしれませんが、現状、端末の画面を睨んでいても、仮想カーソルがどのアイテムを指しているのか、わかりません。わからないなら、読み上げ内容を画面上に表示して、どのアイテムに仮想カーソルが移動しているかの手がかりにすれば良いと思い、AndroidのTalkbackをパクった読み上げ内容通知バーを捏造しました。

3番目の、ホームスクリーンのアプリを起動できない問題は、Eitan Isaacson（eeejay）さんが取り組まれています（885404 – Fix and enhance homescreen accessibility）。

ホームスクリーンのランチャー起動は現状ではTouch APIのイベントだけを監視していますが、clickイベントも監視することで対応するようです（Added click listener for doc items as well）。このあたりはPointer Eventsなどで綺麗に書けるようになるのでしょうか…？

修正が完了すれば、Gaia本家に取り込まれると思いますが、当面はeeejayさんの作業ブランチをビルドするのがてっとり早いでしょう。repoコマンドが使うリポジトリの情報はXMLファイル（.repo/manifests/*.xml）に記述されていますので、自分がビルドする端末用のXMLファイルを編集して、通常のGaiaではなくeeejayさんの作業ブランチをビルドするようにしました。Peakの場合、XMLファイルは.repo/manifests/peak.xmlとなります。

<manifest>
<!-- 追加 -->
<remote fetch="git://github.com/eeejay/" name="eeejay"/>
<!-- 略 -->
<!-- 通常のGaiaの設定をコメントアウトして、以下の設定を追加 -->
<project name="gaia" path="gaia" remote="eeejay" revision="homescreen-a11y-tweaks"/>
<!-- 略 -->
</manifest>

これで、B2GでAccessFuをそれなりに試せる状態になりましたが、いくつか問題が残っています。

  • アプリが立ち上がっても、新しいアプリに仮想カーソルが移動しない
  • テキスト入力ができない
  • 音声出力ができない

アクセシビリティの設定項目からhidden属性が取れるのはまだ先のようです。

*1:少なくとも私は見つけられていません

*2:Android版Firefoxと同様です

GeeksPhone PEAKのAccessFuを30秒で有効化する方法

本当は他に書くべきことがあるのですが、これすら書かないと本当に何も書かなくなってしまう気がしたので、今はこれを書きます。

AccessFuはJavaScriptで書かれたMozillaの支援技術です。Android版Firefoxの読み上げサポートなどで使われていますし、デスクトップ版Firefoxにもこっそり含まれています*1。そして、ここが重要ですが、Firefox OSにも含まれています。

が、Firefox OS 1.0ではAccessFuは無効化されています。Firefox OSの「Settings」アプリケーションの中にはAccessFuの有効、無効を切り替える設定画面があるのですが、これも無効化されています。該当li要素のhidden属性を取れば「Settings」に「Accessibility」の項目が出てきますが、Gaiaアプリを上書きするのは30秒で終わらないと思うので、より高速な方法を紹介します。

準備

adb pull /data/b2g/mozilla/(プロファイル名)/prefs.js
echo 'user_pref("accessibility.accessfu.activate", 1);' >> prefs.js

AccessFuを30秒で有効化する

さあ、準備はいいですか。では、有効化しますよ。

  • adb push prefs.js /data/b2g/mozilla/(プロファイル名)/prefs.js
  • PEAKを再起動（30秒）

画面にオレンジ色のフォーカスリングが出てくればAccessFuが起動しています。フォーカスリングは左右スワイプで前後の項目に移動し、ダブルタップで項目をアクティベートします。なお、現時点では、Firefox OSに含まれているAccessFuは喋りません。

f:id:takenspc:20130624233918j:plain

ちなみに、画面ロックの解除方法がよくわからなかったので、AccessFuを有効化する前に、画面ロックは無効化しました。あと、左右のホーム画面に移動する方法がわかりません（2本指スワイプでも移動しない）。それと、ホーム画面でアプリを起動する方法もわかりません（ダブルタップしても起動しない）。

無効になっているのにはそれなりの理由があるわけですね。でも、きっとそれが、Developer Phoneを買う楽しみの一部でもあるのでしょう、たぶん。

参考

*1:アドレスバーにresource://gre/modules/accessibility/AccessFu.jsmと入力して移動するとJavaScriptファイルを確認できます

「Colour Accessibility」を読みました

電子書籍「Colour Accessibility」を読みました。色のアクセシビリティを多方面から取り上げられています。英語ですが、わかりやすく、読みやすかったです。
覚え書き@kazuhi.toの記事（記事作成時には404 Not Foundになっていますが）もどうぞ。

Colour Accessibility

Colour Accessibilityの内容からいくつか気になったことを挙げます。

導入

Webサイトの閲覧やアプリの利用、ゲームのプレイに影響する障害というものを私達が考えるとき、最初に思い浮かぶことはしばしば極端（extreme）です。例えば全盲であったり、身体障害によってマウスのようなポインティングデバイスが使えないであったり。

もちろん全盲であったり、ポインティングデバイスを使えない環境を考えなくて良いというわけにはなりませんが、それだけしか考えない、取り上げないというのも考えものですね、ということだと思いました。

また、色というのはとても相対的なもので、デバイスによって見え方が異なるでけではなく、人によっても見え方が異なりますが、

私達の多くはたった1つの色覚（color vision）だけを考慮してデザインしています。

1. 色弱について学ぶ

色弱（color blind）という言葉は誤解を与えかねません。色を全く認識できない人やグレースケールで認識している人を指すことはほとんどありません。実際には色を見る（see）能力や色を区別する能力の低下です

2. 適切な色を選ぶ

色を区別する能力は3つの属性（色相、彩度、明度）によっていますが、

視力障害（a visual impairment）をもった人にとって、コントラストはページの要素の可読性を上げる最も重要な要因の一つです。

とのことです。この章ではコントラストの種類が4種類挙げられていますが、アクセシビリティを考慮した場合は明度差によるコントラストが最も重要とのことです。

  • 明度によるコントラスト
    • 明度に差のある色を選ぶ、ということだと思います。
  • 補色によるコントラスト
    • 色相環で反対の色を選ぶ
    • 明度によるコントラストの調整が必要
  • 寒色と暖色によるコントラスト
    • 寒色から明度の低い色、暖色から明度の高い色を選ぶと、寒色同士、暖色同士より良いコントラストを提供できるだろう（will）
  • 彩度によるコントラスト
    • 彩度に差のある色を選ぶ
    • 明度によるコントラストほど効果的ではない

また、色をつける（introduce color）前にグレースケールでデザインする方法があげられていました。

グレースケールでデザインすると重要な要素間のコントラストにフォーカスできるでしょう。

具体的なフローは紹介されなかったのですが、明度だけを調整してビジュアルデザインを進めるということなのでしょうか？この方法が効率的なのか、効果があるのか私には判断できませんが、興味深いと思いました。

3. ヒント（Tips and Tricks）

  • 色のサンプルには名前も一緒に提供する
    • 可能な限り色相の名前を使う（「グレープ」で想起する色は人によって異なるため）
  • リンク
    • 本文の中にあるリンクに下線を引かずに色の違いだけで表現する場合
      • 色の違いを識別できないユーザーはリンクであることに気が付かない可能性がある
        • ホバー時に下線を引くだけでは効果がない
          • ユーザーがこれはリンクかなという期待をいだいてホバーすることを製作者は期待できない
          • モバイル端末にはホバー状態がない

4. 確認方法

各種シミュレータの紹介などがありました。

5. 代替物を提供する

最初からアクセシブルにするのが一番ですが、すでにリリースしてしまったものがある場合は、代替スタイルを提供したりユーザーが色を変更できる機能を用意する、ということでゲームなどでの例が紹介されていました。

調べた単語など

読み進める上で調べたことなどです。

sex-linked trait
伴性遺伝形質
pupil
瞳孔
receptor cells
受容細胞
rod
桿体
cone
錐体
photopigment
光色素
trichromat
3色覚者
dichromat
2色覚者
monochromat
1色覚者
Protanopia
1型2色覚（本文中ではred-blindnessという表記も）
Deuteranopia
2型2色覚（本文中ではgreen-blindnessという表記も）
Tritanopia
3型2色覚（blue-blindnessという表記はなかった）
.ASE export function
Adobe Swatch Exchangeファイルエクスポート機能