Smart Communication Design Company
ホーム > ナレッジ > Blog > アクセシビリティBlog

Webサイトのアクセシビリティを高めるための方法や国内外の関連情報など、さまざまな角度からWebアクセシビリティに関する話題をご提供します。

当Blogの更新情報は、Twitter経由でも配信しています。興味のある方はぜひ、@mlca11yをフォローしてください。

TPAC 2019現地レポート2


チーフアクセシビリティ・エンジニア 黒澤

前回に引き続きTPAC 2019の現地レポートをお届けします。

TPACではW3Cの様々なWorking Groupなどが1カ所に集まることもあって、複数のグループによる合同ミーティングも数多く行われています。この記事では2日目、9月17日に行われたARIA Working GroupWeb 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で以下の方々が紹介され、記念品の贈呈がおこなわれました(発表順)。

壇上で紹介される3氏(左から上綱さん、中村さん、高村さん)

日本語訳を公開されている皆さまの活動には頭が下がります。いつもありがとうございます。

※ 中村は当社社員ですが日本語訳の公開は個人としての活動のため敬称をつけています。ご了承ください。

TPAC 2019現地レポート1


チーフアクセシビリティ・エンジニア 黒澤

福岡で開催されているTPAC 2019に参加しています。TPACはWorld Wide Web Consortium (W3C)の年次総会にあたるイベントで、9月16日から20日まで開催されています。

1日目の9月16日はAccessible Rich Internet Applications (ARIA) Working Groupのミーティングを傍聴しました。ミーティングでは様々なトピックが議論されていましたが、興味深かった内容を紹介します。

音声操作向けのコマンド

最近、Appleの音声コントロール(Voice Control)やAndroidのVoice Accessなど音声で端末を操作する機能が強化されてきています。

音声で操作する際、テキストが画面に表示されている場合にはテキストを発話すればよいのですが、画像が表示されている場合にはなんと発話すればよいのでしょうか。たとえば、ハートの形をしたアイコンが表示されている場合、「お気に入りに登録」と「いいね」のどちらを発話すればよいでしょうか?

また、音声読み上げ時にユーザーに伝わってほしい内容と音声操作のコマンドとして発話したい内容が異なる場合もあります。たとえば、カレンダーに「16」という日付が表示されている場合、「16」と発話する人もいるでしょうし「16日」と発話する人もいるでしょう。9月のカレンダーであれば「9月16日」と発話する人もいるでしょう。音声読み上げ用のテキストは制作者が1種類に決めうるものですが、音声操作のコマンドは理論上、ユーザーの数だけ幅があります。

そこで、AppleのJames Craigさんから

という提案がありました(#1038)。ミーティングでは特に反対意見はありませんでしたが、ARIAの新しい属性を追加する場合、テキストのリストをどうやって記述するのかという議論がありました。たとえば、HTMLのclass属性には空白区切りで複数の値を指定できます(class="a b")が、今回は同様の方法は使えません。なぜなら、英語などでは音声操作のコマンドには空白が含まれるのが一般的なためです。たとえば、ハートマークに「Like」(いいね)と「Add to favorites」(お気に入りに登録)を指定する場合に、

aria-新しい属性="Like Add to favorites"

と記述すると「Like」と「Add」「to」「favorites」の4つのコマンドが登録されてしまいます。

ミーティングではHTMLのdata-*属性がdatasetプロパティに展開されるような仕組みを導入してはどうかという話がありました。

aria-新しい属性-1="Like" aria-新しい属性-2="Add to favorites"

この提案は初期段階のもので、いますぐ仕様に反映されるわけでもブラウザーなどに実装されるわけでもありません。しかし、音声でも操作しやすいUIを実現するための模索は今後も続くでしょう。

Firefox Nightlyで色覚シミュレーションが可能に


アクセシビリティ・エンジニア 中村(直)

@FirefoxDevTools2019年9月6日のツイートによれば、Firefox Nightlyで特別なアドオンをインストールすることなしに、開発ツールで色覚のシミュレーションができるようになったようです。

開発ツールの[アクセシビリティ]タブを選択すると、画面上に「Simulate」が出現します(画像参照)。

Firefox Nightlyの開発ツールでアクセシビリティを選択し、Simulateをクリックしてメニューを展開している様子

1型2色覚(P型)、2型2色覚(D型)、3型2色覚(T型)について、それぞれの強弱の6種類と、視界が暗く見えるContrast lossの7種類が現在シミュレーションできるようです。また、「ドキュメント...」はMDNへのリンクになっていますが、今のところ該当URLについては記事の中身は何もない状態のようです。

実際に1型2色覚のシミュレーションとなるProtanopia (no red)を動作させた例は次の画像のようになります。

当社サイトのページをProtanopia (no red)に設定してレンダリングさせた様子

このように、赤色の色成分がまったくない状態でレンダリングされていることがわかります。

現時点でのNightlyのバージョンは71ですが、71のリリースにこの機能が導入されるとすると、今年12月には安定版のFirefoxでこの機能が利用できるようになっているかもしれません。

CAPTCHAのW3Cノートについて


アクセシビリティ・エンジニア 中村(直)

Updated CAPTCHA Note Published | W3C Blogで告知されているように、W3C Working Group NoteであるInaccessibility of CAPTCHAが2019年8月23日付けの文書として更新されました。2005年にW3C Working Group Noteとして発行されて以来、14年ぶりの更新となります。

従来のCAPTCHAはユーザーがロボットでないことを確認するために画像にノイズを加えた文字を埋め込み、ユーザーに読み取らせるものですが、Webアクセシビリティの観点から問題があることが知られています。また、ロボットの画像認識能力の向上に対抗して、より難解な画像を用いるサイトもあります。その結果、正規のユーザーにも判読が困難になることがあり、結果的にサイトにアクセスできなくなることがあります(参考:IPA セキュア・プログラミング講座 CAPTCHA)。

その一方で、ロボットと人間を判別する様々なアプローチが開発されてきています。その中で最も有名なものの1つがGoogleのreCAPTCHAですが、このW3C Working Group NoteではreCAPTCHA v2とv3を含めた、次のようなアプローチについて有効性とアクセシビリティの問題について検証しています。

なおこの文書には結論として4章のConclusionが用意されています。概要を知りたい方は、この章だけ読んでみるのもよいかもしれません。

WebAIMが8回目のスクリーン・リーダーに関する調査を開始


取締役 木達

都合8回目となるスクリーン・リーダーに関するアンケート調査を、WebAIMが開始していました(WebAIM: Screen Reader User Survey #8)。回答期限は今年9月13日となっており、同月中には調査結果の概要が公開されるとのことです。

同調査は、当アクセシビリティBlogでもたびたび触れてきたもので、前回、2017年10月に実施したときにも質問項目を意訳してご紹介しました(WebAIMが7回目のスクリーン・リーダーに関する調査を開始参照)。8回目の質問項目の多くは7回目と重複していますが、後半には違いも少なからず認められます。

例えば22番目の質問。Which of the following do you think is the primary reason that many developers do not create accessible web sites?とあり、開発者がアクセシブルなWebサイトを制作しない主たる理由を4つの選択肢(気づきの欠如、スキル/知識の欠如、見た目や機能への影響、予算/リソース不足)から選ぶことを求めています。

29番目の質問も興味深いです。How comfortable would you be with allowing web sites (and thus web site owners) to detect whether you are using a screen reader if doing so resulted in a more accessible experience?とあって、スクリーン・リーダーを使用していることをWebサイトないしその運営者に知らせることがよりアクセシブルな体験をもたらす前提において、知らせることにどの程度寛容かをたずねています。この質問の背景には、先だってAppleが支援技術の有効/無効を検知する機能を一度は導入したものの取り下げ仕様を変更した経緯があるように思います(かつてのAccessibility Events、現在のAccessibility Object Model機能)。

また31番目、32番目の質問ではそれぞれ、PDF文書やWord文書のアクセシビリティについて、重大な問題に遭遇する程度をたずねています。これらも前回には無かった質問です。

調査結果の概要が公開されましたら、またご紹介したいと思います。

テクニカルコミュニケーションシンポジウム2019に登壇


取締役 木達

来たる2019年8月27〜28日、東京学芸大学 小金井キャンパスにてテクニカルコミュニケーションシンポジウム2019【東京開催】が催されます。これは一般財団法人テクニカルコミュニケーター協会(以下「TC協会」)の主催するシンポジウムで、31回目を数える今年は「共に育つ」を全体テーマとしています。

同シンポジウムにおいて、私は特別セッション『Web デザインの「今」と「これから」 ~Web デザインに見るトレンドとアクセシビリティ~』を担当させていただきます。

イベント
テクニカルコミュニケーションシンポジウム2019【東京開催】
日時
2019年8月27日(火)、28日(水)
会場
東京学芸大学 小金井キャンパス
(東京都小金井市貫井北町4-1-1)
参加費(入場券)
TC協会会員:15,000円(非課税)
非会員:21,600円(消費税込)
学生:3,240円(1日、消費税込)
(※ 特別セッションに参加希望の方は、入場券とは別途、特別セッション券が必要です)
参加費(特別セッション券 ※1枚1講座)
TC協会会員:10,000円(非課税)
非会員:16,200円(消費税込)
学生:5,400円(1日、消費税込)

特別セッション『Web デザインの「今」と「これから」 ~Web デザインに見るトレンドとアクセシビリティ~』 詳細

日時
2019年8月27日(火)10:15〜12:45
対象者
ディレクター、ライター
講義のポイント
前半では、Web デザインのトレンドを広く浅く紹介。普段、Web デザインに従事していない方にもご理解いただけるよう、できるだけ噛み砕いて解説する。近年高まってきたWeb アクセシビリティの重要性も言及する。 後半では、2018 年にアップデートされた国際的なアクセシビリティのガイドライン、Web Content Accessibility Guidelines(WCAG)2.1 を紹介。ビジュアルデザインに関連する達成基準に特化して、個々の要点や、それを守ることでどんなユーザーにどんなメリットをもたらすかを解説する。

イベントの詳細、また参加のお申し込みにつきましては、テクニカルコミュニケーションシンポジウムのWebページをご覧ください。

Pick Up