Webサイトのアクセシビリティを高めるための方法や国内外の関連情報など、さまざまな角度からWebアクセシビリティに関する話題をご提供します。
当Blogの更新情報は、Twitter経由でも配信しています。興味のある方はぜひ、@mlca11yをフォローしてください。
企業がWebアクセシビリティに取り組むべき理由
去る10月8日、Global Business Hub Tokyoで行われたシックス・アパート株式会社主催のイベント「SAtisfaction 2019」で、私は企業がWebアクセシビリティに取り組むべき理由と題した講演をさせていただきました。
そしてつい先日、同講演のレポート記事、「ビヨンセの公式サイトも訴えられた」企業Webサイトがアクセシビリティに取り組むべき理由とは？がWeb担当者Forumに掲載されました。当日お話しした内容をかなり精緻に書き起こしていただいており、スライドを見ただけでは伝わらない・わかりにくい部分も、同記事をお読みいただくことで解消できるかと思います。
改めてイベントにご参加くださった皆様、イベントを主催されたシックス・アパートの皆様には、厚く御礼申し上げます。ありがとうございました。
講演の冒頭で触れた、アメリカでのWebアクセシビリティ関連訴訟について若干補足させていただきますと、比較的最近にも注目に値するニュースがありました。Webサイトやモバイルアプリから好みのピザを注文できなかったために全盲のGuillermo Robles氏より訴訟を受けたドミノ・ピザ社が、WebやアプリはADAの適用対象外とするよう合衆国最高裁判所に求めていた訴えが、退けられたのです（U.S. Supreme Court Won't Hear The Domino's Case (Hooray!) - Law Office of Lainey Feingold参照）。
企業がWebアクセシビリティに取り組まないでいることで、訴訟を起こされるリスクが高まることは今後ますます、避けられないでしょう。それはインターネットの、Webの普及と密接にリンクしています。障害の有無にかかわらず、誰もがさまざまな状況でWebにアクセスできる・アクセスする必要のある時代だからこそ、Webサイトを運用する側がアクセシビリティ向上に取り組む必要性が強まっているのです。
もちろん法令を遵守し、訴訟リスクを下げることだけがWebアクセシビリティ向上の目的、動機とはなり得ません。そこには多くのメリット、とりわけ機会損失を最小化し、コンバージョンの取りこぼしを減らすという、ビジネス的に極めて前向きな理由もあります。企業のWeb担当者の皆様には、是非その点をご理解いただいたうえで、それぞれに取り組みを始めるなり、維持・強化していただければありがたく思います。
Webにおける数式と数式の読み上げを取り巻く環境について
Webで数式の表現をするにあたっては、仕様上はMathML（現在のW3C勧告はMathML Version 3.0 2nd Edition）と呼ばれるマークアップ言語で表現できることになっています。かつては、MathPlayerのようなプラグインを別途インストールしなければ表示することができなかったことや、古いXHTMLでは専用のDOCTYPE宣言を用いなければならなかったこともあり、マイナーな存在であったと言えます。しかし近年、実装面では昨年にIgalia社が米国の標準化団体であるNISOから資金援助を受け、ChromiumへのMathMLの（再）実装を試みており、いよいよ実装目前のところまで差し掛かってきました（MathML in Chromium: Upstream process started）。また、ブラウザーのMathML実装状況については、同じくIgaliaのMathML and Browsersのレビュー記事が参考になります。
また、仕様面においては、W3C HTML5勧告の時点でSVGと同様にMathMLが既に取り込まれています。そして、Igalia社のエンジニアFrédéric Wang氏がMathML in HTML5 - Implementation Noteを公表したことを1つのきっかけとして、W3CでMathML Refresh Community Groupが立ち上がり、現在ではこのグループでMathML 3をブラッシュアップした仕様群の議論が行われています。
ところで、数式をスクリーンリーダーで読み上げさせるとどうなるのか？というところも興味深いところであります。二次方程式の解の公式をWindows10のナレーターと、NVDAに読み上げさせてみました。
MS Word + ナレーターの環境では次のように読み上げました。
x イコール 分子 マイナス b プラスマイナス 平方根の b二乗 マイナス 4ac 最後平方根 最後分子 割る 2a
Firefox + NVDA + MathPlayerでは次のように読み上げられました。（NVDA 2019.2.1 User Guideの7章では、MathPlayerのインストールが必要とのことです）
x イコール ス ザ フラクション ウィズ ニューマレーター ネガティブ b プラス オーアール マイナス b スクエアード マイナス 4ac アンド デノミネーター 2a
NVDAスピーチビューアーでは次のように出力されました。（改行を調整しています）
x equals the fraction with numerator negative b plus or minus the square root of b squared minus 4 ac and denominator 2 a
残念ながら、英語として出力されてしまっています。
MS Word + NVDAや、Firefox + ナレーターの例が記載されていないことに気づいた方もいるかもしれません。これらの組み合わせについては筆者の環境でうまく読み上げを行うことができませんでした。試したのはWindows上のナレーターとNVDAという限定された組み合わせではありますが、スクリーンリーダーによるそもそもの読み上げが環境に依存する状況であることは言えそうです。
さて、ナレーターではうまく数式を読み上げているように見えますが、本当にうまく読み上げられていると評価することができるのか、という疑問があります。振り返ってみると体系的に数式の読みというのを教育機関で習った記憶が少なくとも筆者はありません。そこで、山口ら(1996)による『日本語による数式読み上げ法の基本構成について』をあたってみました。
この論説では、視覚障害学生が理数系の高等教育を受けるに当たって、日本語での数式の読みが確立されていない問題を指摘し、10項目による読み上げ法の提案を行っています。その詳細についてはここでは紹介しませんが、前述の二次方程式の解の公式ですと、2つの読みを提案しています。1つは墨字を併用できる学生を想定した「簡略読み上げ」で、
x イコール マイナスb プラス・オア・マイナス 平方根・オブ bの2乗 マイナス4ac オーバー 2a
となります（読みやすさのためにスペースを設けています）。もう1つは「厳密読み上げ」で、分数などの記号の範囲を明示するもので、
x イコール 分数 マイナスb プラス・オア・マイナス 平方根・オブ bの2乗 マイナス4ac 根号終了 オーバー 2a 分数終了
となります。ナレーターの読みはどちらかというと、「厳密読み上げ」に近しいものであると言え、もっともらしい読み上げであると言えそうです。
山口らによれば、米国の多くの大学では、初年次に"College Algebra"（代数学）が設置されており、初等的なものを含めすべての数学記号に対し、英語による読み方が示されている、とのことです。College Algebraで検索すると出てくるサイトのとあるページでは"In words"というフレーズがあり、確かにどう読むのかということが解説されているようです。
まとめますと、Web上の数式の扱いは、ChromiumにMathMLが再び実装されるまで秒読みとなっており、大きく前進する気配があります。その一方で、スクリーンリーダーによる読み上げはまだまだ途上であり、また日本語固有の問題として、どのように読み上げればよいかが確立されていないという問題があります。山口らが主張するように、視覚障害のあるなしにかかわらず、数式の読み上げの統一は教育に一定の効果があると考えられます。日本語による統一的な数式読み上げ法の確立が望まれるところです。
axe-core 3.4がリリースされました
axe-core 3.4.0がリリースされました。
つい先日axeのブラウザー拡張機能にベータ版の新機能が登場したことを本ブログでご紹介したばかりで、こんなにすぐにまた新しいニュースをお届けできることを嬉しく思います。
axe-coreについては、以下の記事もあわせてご参照ください。
本記事では、axe-core 3.4の変更点をいくつかご紹介します。
ローカライゼーション
axe-core 3.4から、さらに使用可能な言語が増えました。現時点では、以下の6つの言語を使用できます。
- 英語（デフォルト）
- フランス語
- ドイツ語（一部サポートのみ）
- 日本語
- スペイン語
- ポルトガル語（ブラジル）
この中でもスペイン語とポルトガル語（ブラジル）は新しく追加された言語です。日本語訳に関わる一員として、使用可能な言語が増えていくことはとても喜ばしいです。
新ルール：aria-roledescription
aria-roledescriptionという新しいルールが追加されました。
これまでaria-roledescriptionという属性に関するテストは、aria-allowed-attrというルールに含まれるテストで実施されていました。個別のルールとして追加されたことで、より正確にaria-roledescriptionに関するテストを実施できるようになります。
廃止されたルール
axe-core 3.4からは、以下の3つのルールが廃止されました。
checkboxgroupとradiogroupは、関連するチェックボックスやラジオボタンをグループ化することを求めるルールです。このルールではグループ化にfieldset要素を用いることを推奨していましたが、他の方法がより適している場合もあるため、axe-coreが不正確な結果を報告しないよう廃止したとのことです。
video-descriptionというルールはvideo要素にtrack要素による音声解説をつけることを求めるルールです。映像などのメディアコンテンツに音声解説が必要であるという前提は変わりませんが、ブラウザーによるtrack要素のサポートが不十分であるため、今回廃止となりました。
これらの廃止されたルールはaxe-core 3.4の時点ではデフォルトで無効化されています。また、axe-core 4.0からは完全に削除されるそうです。
まとめ
axe-coreはオープンソースで開発されており、今も世界中の方々が貢献しています。興味のある方はぜひ貢献してみてはいかがでしょうか。
今回ご紹介した点以外の変更については、axe-core 3.4.0のリリースノートをご確認ください。
axeのブラウザー拡張機能にベータ版の新機能が登場
Chrome版のaxeブラウザー拡張機能に、axe Proというベータ版の新機能を誰でも追加できるようになりました。日本時間の本日、Deque Systemsによるニュースリリースが発表されています。
axeのブラウザー拡張機能については、「axeのブラウザー拡張機能を日本語で利用できるようになりました」をご参照ください。
axe Proとは
axe Proは、これまでaxeのブラウザー拡張機能で提供されていた機械による自動検証に加えて、ガイド付きの目視検証を提供しています。ガイド付きの目視検証では、画像の代替テキストなどの人による判断が必要な部分を見つけ、その部分が適切かどうかをユーザーが判断します。
その他にも、機械と目視の両方の検証結果を保存したり、検証する範囲を制限したりすることが可能です。
ベータ版に参加するには
ベータ版に参加する方法はいくつかあります。
Deque Systemsのaxe for Webというページの「Upgrade to axe Pro」というボタンから登録用フォームに遷移できます。また、axeのブラウザー拡張機能を開くと、「Deque news」が表示されています。Deque newsに記載されている「Upgrade for free for a limited time.」というリンクから、直接登録用フォームに移動できます。
フォーム送信後、指定したメールアドレスにaxe Proを使用するための手順が書かれたメールが届きますので、あとはメールの手順に従うだけです。
最後に
機械検証で検出できる問題は、アクセシビリティに関する問題の一部です。開発者が自ら、人による判断が必要な問題を解決することで、よりスピーディーに、よりアクセシブルなコンテンツを制作できるのではないでしょうか。
axe Proは今のところベータ版として無料で公開されていますので、誰でも試すことができます。ぜひ実際に触ってみてはいかがでしょうか。
WebAIMがスクリーン・リーダーに関する調査（8回目）の結果を公開
今年8月13日に公開した記事、WebAIMが8回目のスクリーン・リーダーに関する調査を開始で触れた調査の結果が公開されました（WebAIM: Screen Reader User Survey #8 Results）。
有効回答数は1,224件で、過半数が北アメリカにお住いの方からのものでしたが、その割合は過去の調査より減っているそうで、結果的にグローバルな調査結果として捉えやすくなっているとのこと。ちなみにアジアに居住している方からの回答も、5.8%含まれていました。
今回の調査結果で目を引くのは、主に使用しているスクリーン・リーダーとしてNVDA（NVDA日本語版 ダウンロードと説明も参照）を挙げる人の割合が、2009年の調査開始以来で初めてJAWSを抜いたことでしょう。両者の差は極めて僅かではありますが、NVDAの人気の高まりを如実に表した結果と言えます。ちなみに障害の有無で結果には差があり、障害当事者がJAWSやNVDAを好む傾向にある一方、そうでない方はAppleのVoiceOverを好むようです。
スクリーン・リーダーと一緒に使われるWebブラウザについても、やはり前回（2017年）とは異なる調査結果が見られます。Internet Explorer（IE）やFirefoxの利用率が下がり、トップに躍り出たのがChromeです。この変化は、スクリーン・リーダーと併用しているかどうかに関係なく、広く一般的なブラウザの利用動向と合致して映りますけれど、それでもなおIEの利用率が14.5%というのは、個人的にはやや高く映ります。
モバイル環境の利用動向について見ますと、プラットフォームの利用率ではiOSが圧倒的のようです。しかし、前回調査と比べiOSがマイナス7ポイントだったのに対し、Androidはプラス6%となっており、iOSの人気に若干の陰りが感じられます。常に右肩上がりで伸びてきたiOSの割合が今回初めて減少に転じたというのは、先のNVDAがJAWSを追い抜いた結果と同じくらい、印象的です。
また、ARIAランドマークロール/リージョンの利用率が過去5回、連続して減少しているのに対し、見出しジャンプのような機能を使って情報を探すという回答が7割弱あったほか、見出しレベルを有用と回答したのが8割以上を占めた結果からは、スクリーン・リーダーのユーザーにとって見出しのつけ方が極めて重要ということが読み取れます。
スクリーン・リーダーを使用している旨をWebサイトないしその運営者に知らせることにどの程度寛容かたずねた設問に対しては、7割以上がComfortable、つまり心地よいと答えていました。これは、そうすることがよりアクセシブルな体験をもたらす前提があってこそと思われますが、オンライン上でのプライバシーを守る動きが高まり続けるなか、そうした前提を設けずにたずねたら結果はどのようになっただろう、というのが個人的には気がかりです。
PDF文書のアクセシビリティについて、重大な問題に遭遇する程度をたずねた設問については、合計すると4分の3近くが問題に遭遇する可能性があると回答。理由や背景は不明ながらも、アクセシビリティが十分に確保されぬまま公開されているPDF文書が少なくない実態が、明らかになったと言えるでしょう。
調査結果の詳細は、ぜひWebAIM: Screen Reader User Survey #8 Resultsをご確認ください。
TPAC 2019現地レポート2
前回に引き続きTPAC 2019の現地レポートをお届けします。
TPACではW3Cの様々なWorking Groupなどが1カ所に集まることもあって、複数のグループによる合同ミーティングも数多く行われています。この記事では2日目、9月17日に行われたARIA Working GroupとWeb Componentsの合同ミーティングなどから興味深かったものを紹介します。
カスタム要素のフォーカスの挙動
通常のHTML要素はフォーカスを受け取るかどうかがOSの一般的挙動を反映したものになっています（OSの一般的な設定を反映できるようにブラウザーがOSごとに調整しています）。たとえば、macOSのネイティブアプリケーションではテキスト入力欄はフォーカスを受け取りますが、ボタンはフォーカスを受け取りません。SafariやFirefoxなどのブラウザーはmacOSの挙動と一致するようにHTMLの要素に対して調整を行っています。通常設定では<input type="text">はフォーカスを受け取りますが、<input type="button">はフォーカスを受け取りません。OSの設定を変更するか（Firefox）、ブラウザーの設定を変更する（Safari）ことでボタンなどもフォーカスを受け取れるようになります。
このような挙動を再現することは現在のカスタム要素の仕様では実現できません（既存のWeb技術では再現できません）。tabindex属性を指定するとOSやブラウザーの設定とは一貫性のない挙動になります。
そこで、GoogleのRakina Zata AmniさんからElementInternalsに専用のプロパティを追加する提案がありました（Default focus behaviors for custom elements）。
class MyButton extends HTMLElement {
constructor() {
super();
this._internals = this.attachInternals();
this._internals.matchFocusBehaviorOf = "input[type='button']";
}
}上記のように記述することで、<my-button>のフォーカスに関する挙動をmatchFocusBehaviorOfで指定した要素（<input type="button">）と同じにするというものです。
この提案は方向性については受け入れましたが、具体的な方法については議論がありました。提案ではmatchFocusBehaviorOfの指定方法はCSSセレクターで表現することになっていますが、それよりはフォーカスの挙動をカテゴリ化し、カテゴリを指定できるようにしたほうが良いだろうということになりました。
この提案は興味深いのですが、ある要素がキーボードで操作できるのかを外から判断することが（より）難しくなるため、キーボードトラップを実装する際などに、フォーカス可能かどうかを簡単に判断できる方法が別途必要になるだろうと考えています。
Shadow Treeを超えて要素を参照する方法
WAI-ARIAにはaria-activedescendant属性など、参照したい要素をid属性値で指定する属性が複数あります。
<div role="combobox">
<input aria-activedescendant="opt1">
<ul role="listbox">
<li role="option" id="opt1">Option 1</li>
<li role="option" id="opt2">Option 2</li>
<li role="option" id="opt3">Option 3</li>
</ul>
</div>しかし、この参照方法はShadow DOMでは機能しません。Shadow DOMではid属性値はShadow Treeの中で閉じていて、外側のid属性値は参照できないためです。
<custom-combobox>
#shadow-root (open)
| <!-- aria-activedescendantはOption 1を参照できていない -->
| <input aria-activedescendant="opt1">
| <slot></slot>
<custom-optionlist>
<x-option id="opt1">Option 1</x-option>
<x-option id="opt2">Option 2</x-option>
<x-option id="opt3">Option 3</x-option>
</custom-optionlist>
</custom-combobox>そこでGoogleのAlice BoxhallさんはからShadow Treeの中から外の要素を参照できるAPIの提案がありました。
前述のようなShadow Treeを含んだDOMがある場合、Shadow Treeをまたいで
const input = comboBox.shadowRoot.querySelector("input");
const optionList = comboBox.querySelector("custom-optionlist");
input.activeDescendantElement = optionList.firstChild;上記のように要素を参照できるようにする、というものです。
この提案はShadow DOMのカプセル化モデルに直結するため、実装側（ブラウザーベンダー）は実装を考えればどうしても難しいと回答せざるをえないし、提案側はユースケースを考えれば何らかの方法を標準化せざるをえない、というジレンマに陥っているように感じます。この議論がなされたのは今回が初めてではありませんが、今回も解決策は見つけられず、議論継続となりました。
現時点では制作側でShadow DOMをまたがるような参照を避けるしかないと考えています。
W3C Developers Meetup in Fukuoka参加レポート
今年のTPACでもサイドイベントとしてDeveloper Meetupが開催されました。Meetupではアクセシビリティに関する発表が2つ、VR、WebXR、WASMに関する発表が1つずつ行われ、最後にW3C仕様の日本語訳をされている方々の紹介などがありました。この記事ではアクセシビリティに関する発表の1つと日本語訳をされている方々の紹介セッションを紹介します。
Finessing forced-colors: tailoring the High Contrast experience
MicrosoftのMelanie Richardsさんはハイコントラストモードに関する発表を行いました。
近年、CSS WGではダークモードへの対応（prefers-color-scheme）のようなユーザーの設定に応じてサイトの見た目などを調整する機能の標準化に取り組んでおり、発表では主にハイコントラストモードに関する対応が紹介されました。
※ 発表ではダークモードに関する内容もありましたが、すでに様々な場所で紹介されている内容ですのでこの記事では省略します。当社フロントエンドBlogの「近づくダークモード対応の足音」などもご覧ください。
一般に背景と文字の色のコントラスト比が高いほうが読みやすいと感じる傾向がありますが、読みやすさはユーザーや状況によって変わります。白背景に黒い文字と黒背景に白文字のコントラスト比は同じ21:1ですが、黒背景に白文字のほうが読みやすいと感じる人もいます。また、読みやすさは状況によっても変わり、昼と夜では異なる配色を読みやすいと感じるかもしれません。
ユーザーのニーズに合わせた配色でサイトを表示するために、IEやEdgeなどのブラウザーはOSの設定（具体的にはWindowsのハイコントラストモード）を自動的に認識し、背景色や文字色をユーザーが指定した色で上書きします（上書きされるCSSプロパティのリスト（現時点でのEditor's Draft））。
とはいえ、商品の色見本（color swatch）のように特定の色で表現したほうが良い場合もあります。そのような調整を行うためにforced-colorsメディアフィーチャー（現時点でのEditor's Draft）やforced-color-adjustプロパティ（現時点でのEditor's Draft）が提案されています。forced-colorsを使うとハイコントラストモードかどうかに応じてCSSを設定でき、forced-color-adjustを使うとハイコントラストモードでもブラウザーが色を変更しないように指定することができます。
@media (forced-colors: active) {
.class {
forced-color-adjust: none;
}
}のように指定すると、ハイコントラストモードでも.classの背景色や文字色を維持することができます。
今のところforced-colorsを実装したブラウザーはなく、IEとEdgeが標準化のもとになった独自拡張を実装しているのみですが、今後、標準化された仕様をMicrosoftがChromium（Blink）に実装する予定とのことです。
なお、アクセシビリティに関するもう片方の発表はGoogleのAlice Boxhallさんによる「Accessibility and Innovation」で、アクセシビリティ対応がイノベーションを生んできた事例をWebに限らず紹介されていました。
Recognizing the W3C Japanese translators community
MeetupではW3C技術文書の日本語訳を行っている方々の紹介と記念品贈呈も行われました。
W3Cの仕様は英語で公開されており、英語が母国語でない人にとってはそのまま読むのが難しいのも事実です。実際には、ボランティアの方々を中心に数多くの仕様に対して日本語訳が公開されており、私も一度ならずお世話になっています。日本語訳は世界的に見ても突出して多く、W3C勧告の1/3にあたる数（90前後）に上るとのことでした。Meetupで表示されていたスライドを見る限り2位はフランス語で30前後ですので、日本語訳の数が非常に多いことがわかります。
このような日本語訳を公開している方として、今回のMeetupで以下の方々が紹介され、記念品の贈呈がおこなわれました（発表順）。
- 上綱秀治さん（@omnidirect）
- 中村直樹さん（@momdo_）
- 高村吉一さん（@y_takamu）
壇上で紹介される3氏（左から上綱さん、中村さん、高村さん）日本語訳を公開されている皆さまの活動には頭が下がります。いつもありがとうございます。
※ 中村は当社社員ですが日本語訳の公開は個人としての活動のため敬称をつけています。ご了承ください。
Pick Up
アクセシビリティ障害者差別解消法への対応が気になるかた必見、これから取り組むWebアクセシビリティとは