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

アクセシビリティBlog

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

当Blogの更新情報は、Twitter経由でも配信しています。興味のある方はぜひ、@mlca11yをフォローしてください。当Blogへのご意見・ご質問は、Twitter経由でも受け付けております。

MicrosoftがSonarプロジェクトでDequeのaXeを採用

取締役 木達

(この記事は、2017年11月20日に公開された記事「Microsoft selects Deque's aXe for Sonar Project」の日本語訳です。Deque Systems社の許諾を得て、お届けしています。翻訳の正確性は保証いたしかねますので、必要に応じ原文を参照ください。)

今年のはじめ、Microsoftは「Webのための検証ツール」として、Sonarプロジェクトをお披露目しました。Sonarを使うことで、開発者は開発プロセスの初期において、相互運用性やセキュリティ、パフォーマンスに加え、Dequeのaxe-coreライブラリを用いたアクセシビリティ検証を行うことができます。私たちの取り組みの成果が、GoogleやMicrosoftにおけるオープンソース・プロジェクトに取り込まれることに、私たちはとてもワクワクしています。IT界の巨人たちが、自動アクセシビリティ検証の分野における私たちの専門性を認めてくれたことを意味するのですから。既によくメンテナンスされているライブラリが存在するなら、どうして車輪を再発明する必要があるでしょう?

9月に催されたMicrosoft Edge Summitで、シニアプロジェクトマネージャーのAnton Molleda氏は、SonarがWeb開発のプロジェクトにおいてどのように機能するか、詳細のプレゼンテーションを行いました。ことアクセシビリティに関しては、DequeのオープンソースのJavaScriptライブラリ、axe-coreを採用しています。私たちはこれまで、Sonarへの対応をスムースに進めるべく、すべてのユーザー、特にWindowsプラットフォームのユーザーをサポートするよう、Github上で協働してきました。

開発者ツールの拡張APIは、Microsoft Edge用に再開発中であり、完成の暁にはDequeはEdge用のaXeブラウザー拡張を作ることができると思いますが、SonarはEdgeやChrome、jsdomでアクセシビリティ検証を行う機会を開発者に提供します。Sonarは「検証ツール」ですので、開発者はコード品質を納品前に検証する目的でSonarを使うことを意味します。SonarはWebブラウザーに接続することで、CSSやJavaScriptの有効な状態で、axe-coreのルールに則りアクセシビリティ検証を行います。これは、典型的な検証ツールにありがちな誤検知を避けるのに役立ちます。

Sonarは、同じくaxe-coreを採用しているGoogleのLighthouse監査ツールに似たプロジェクトです(訳注:GoogleがChromeのデベロッパーツールにDequeのaXeを採用参照)。Lighthouseと比べると、SonarはPWA(Progressive Web Apps)のベストプラクティスに照らすより、一般的なWeb開発向けに重きが置かれています。多様なプラットフォームをサポートするWebサイトやWebアプリケーションはさまざまありますが、それらはすべてアクセシビリティを必要としています。これらのツールは、axe-coreによるアクセシビリティ検証を検討する開発者にとって、素晴らしいきっかけになります。

手間をかけることなく、手始めにいちページを対象に、アクセシビリティ検証でaXeを試してみたいとお考えなら、無料のブラウザー拡張をaxe-core.orgでチェックしてください。複数のページの検証や、より高度な設定をお求めなら、WorldSpace Attestを用いたソリューションが適切かもしれません。

Japan Accessibility Conference vol.1 参加レポート

アクセシビリティ・エンジニア 小出

11月11日(土)に開催されたJapan Accessibility Conference(JAC) vol.1 「国内最大級のアクセシビリティカンファレンス〜アクセシビリティのこれまでとこれから〜」に参加してきました。
アクセシビリティの必要性が認識されつつあること、その機運の高まりを可視化したかったとの主催のコメント通りフロアはほぼ満席で、参加者の熱意が感じられる雰囲気でスタートしました。

基調講演+全8セッションのテーマはアクセシビリティの基本から実際に現場に導入するにあたっての事例など幅広く設定されており、いずれもアクセシビリティに取り組む上で欠かせないテーマです。資料や映像アーカイブが用意されるだけでなく、UDトークによる情報保障が用意されていたのもよい試みのひとつと感じました。

とはいえ、映像アーカイブをすべて見るにはそれなりの時間の余裕が必要になりますので、私が参加したセッションについて、簡単にレポートとしてまとめてみました。効率よい閲覧の手がかりになれば幸いです。

基調講演「UX as science」

Alan DixやNielsen NormanのUXの考察をベースにした、ユーザーがサイトから情報を得る体験についての説明や、ユーザーテストの結果を科学的に分析しYahoo Koreaのトップページを改善した手法について、講演が行われました。
デザインはビジュアルの美しさだけではなくコンテンツに即したコンテキストを持って本来の効果を発揮するものであることについて、整然と説明されており、すっきりと理解できる内容でした。

セッションA-1「アクセシビリティのインクルーシブデザイン」

アクセシビリティ先進国の韓国からの登壇者によるセッションとのことで、ウェブアクセシビリティ認証マーク(Web Accessibility Quality Mark)の交付制度など、法整備がすすめられている社会での実例についてぜひ知りたいと思っていたので迷わず選びました。
K-bankKakaobankのモバイルアプリのアクセシビリティチェックテストの結果を例に、両アプリの長所短所が具体的に紹介されました。ユーザー層の差異など両ソフトのコンセプトの違いが反映されたユーザビリティが、必ずしもアクセシビリティと結びつかなかった点など、頷く部分が多い内容でした。

参考

セッションA-2 「アクセシビリティ・ガイドラインの歩き方(初心者編)」

ガイドラインは日々確認・使用していますが、惰性や見落とし、誤解などがないよう、基本の再確認をするために選んだセッションです。
WCAG 2.0 / JIS X 8341-3:2016の概要、使い方、注意すべき点がコンパクトにまとめられており、これからアクセシビリティ対応に取り組む現場担当の方にちょうどよい導入だったと感じました。

セッションA-3 「アクセシビリティ検証ツールとしてのNVDA入門」

日頃お世話になっているツールの開発者の方によるセッションということで、個人的にテンション高く参加しました。
日々の操作でNVDAがどのように動いているのか、特に気になっていた「フォーカスモード」についてわかりやすく説明があり、よい収穫でした。 Windows環境がないとお嘆きのMacユーザーにも利用できるよう、仮想環境の導入から説明を用意される周到ぶりに、NVDAを使ってほしいという静かな熱意にさらにテンションがあがりました。みなさんNDVA使いましょう!

セッションB-4 メディア事業でのアクセシビリティ展開事例・CAではこうやってます

アクセシビリティ対応をすすめたい、でもどうやって道筋をつけたらいいかわからない、もしくは導入したいけれどさまざまなハードルに直面して困惑している方向けの内容でした。アクセシビリティ対応が必要な箇所について、デザイナーや開発者など対象別に表現を変えて説明するのはChatWorksでも実際に行っているとのことで、理解・共感を深めるのに有効だと思います。当社でも検証結果やアクセシビリティのご説明に際し、対象者にとってわかりやすくなるよう心がけています。

参考

以上です。

第二回もぜひ開催してほしいですし、その際は何か貢献できればと思います。

「電子図書館から考える!情報アクセシビリティをめぐる最新動向」に登壇

取締役 木達

先だって、11月7日から9日にかけて、パシフィコ横浜を会場に第19回図書館総合展が開催されました。事前に当アクセシビリティBlogでは告知しておりませんでしたが、その中で最終日に行われたフォーラム「電子図書館から考える!情報アクセシビリティをめぐる最新動向」に、私は登壇させていただきました。奇しくも同日、米国サンフランシスコではW3C Publishing Summit 2017が催されるというタイミングでのことでした。

冒頭、株式会社図書館総合研究所の特別顧問でいらっしゃる植村 要様より趣旨のご説明があり、Webのアクセシビリティと書籍のアクセシビリティ、両分野のあいだの距離が縮まってきた背景をお話ししてくださいました。それを受けて、私は基調講演という位置付けで「Webと出版の融合で高まる情報アクセシビリティ向上への期待」と題した講演を行いました。

以前、コラム『「EPUBアクセシビリティ診断」サービスのリリースに寄せて』でも書かせていただきましたが、電子出版物向けに今後の高い普及が見込まれるフォーマットに、EPUBがあります。EPUB出版物とは、Webコンテンツを一定のルールに基づきパッケージ化したものであり、Webのアクセシビリティにおいて培われてきたノウハウや、Webに対応した支援技術等を応用しやすいと自分は考えています。従い今後、Web技術を仲立ちとしてWebと出版が融合することにより、情報アクセシビリティは飛躍的に高まり、結果として社会全体が豊かになるはず......といったお話をさせていただきました。

基調講演に次いで、大日本印刷株式会社 hontoビジネス本部 部長でいらっしゃる盛田 宏久様に進行役を務めていただき、先述の植村様、そして大日本印刷株式会社 hontoビジネス本部の花田 一郎樣と、電子図書館サービスのTRC-DLを中心に据えつつ、電子図書館および電子書籍の現状や今後について、幅広くディスカッションを行いました。大きくは3つのテーマ、すなわちWebサイト、コンテンツ、それにビューワーそれぞれに関し意見交換をしましたが、図書館/書籍がご専門の皆様とWebが専門の私との対話を通じ、現状の電子書籍がもつアクセシビリティ上の課題について、手前味噌ながら興味深い議論ができたと思います。

中でも、私が今後特に必要と考えているのは、コンテンツの提供側のみならず、障害当事者を含むユーザー、標準化団体、そしてビューワーや支援技術(スクリーン・リーダー等)のベンダーの皆さんが、電子書籍アクセシビリティの向上という同じゴールを共有したうえで、深く連携をすることです。単に、Webがその種の連携を通じアクセシビリティを高めてきたからのみならず、そのような連携なくして、例えばコンテンツの正しい読み上げの実現に対し、どの立場がどの程度のコスト捻出を是として実現すべきかと言った落とし所を見つけにくい、と考えるからです。

なお、ディスカッションの内容については後日、書き起こしのうえ公開の予定と伺っています。当日参加された方も、そうでない方も、ディスカッションの内容に興味がございましたら、今しばらくお待ちいただきたいと思います。公開の暁には改めて、当アクセシビリティBlogでご案内します。

Firefox 57.0とスクリーン・リーダーの読み上げについて

アクセシビリティ・エンジニア 辻

11月7日にMozillaのMarco Zehe氏が公開した記事、Firefox 57 from an NVDA user's perspectiveでは、来る11月14日にリリース予定のFirefox 57.0を利用する際にスクリーン・リーダーNVDAのユーザーが受ける可能性のある影響について述べられています。

また、Jonathan Mosen氏が公開した記事、Important information for users of Mozilla Firefoxでも、スクリーン・リーダーJAWSのユーザーが新バージョンのFirefoxを使用する際に受ける影響について書かれています。

どちらの記事でもFirefox 57.0をスクリーン・リーダーとの組み合わせで使用する場合、閲覧するページによっては読み込みに時間がかかってしまうことが紹介されており、問題が解決するまでの間はFirefoxの延長サポート版の使用を進めています。

Marco氏の記事の中では、NVDAとFirefox 57.0との組み合わせでページの読み上げに時間がかかる例として、WikipediaのWorld War Iのページが紹介されていました。

一スクリーン・リーダーの利用者として、現在の最新版であるFirefox 56.02と、新しいFirefox 57.0では上記のWikipediaのページが読み上げられるまでにどれくらいの違いがあるのかが気になりましたので、Firefox Developer Edition - Mozillaをダウンロードして試してみました。

記事で述べられていたとおり、「World War I」というリンクを開いてからページの内容が読み上げられるまでには差があることがわかりました。

せっかくですので、NVDAの読み上げ音声で違いをご紹介したいと思います。

幸いなことに、スクリーン・リーダーを使用しているFirefoxの利用者がこの影響を受ける期間はそれほど長くはないようで、各スクリーン・リーダー開発者とMozillaが連携して問題解決に取り組んでいることが紹介されていました。

複数のFirefoxをインストールして使い分けるという方法もあるようですので、必要に応じて使いやすいバージョンを使用しながら、今後のリリースに期待したいと思います。

WCAG 2.1草案へのコメント

アクセシビリティ・エンジニア 畠山

先日の記事「WCAG 2.1の今後」の通り、WCAG 2.1草案へのレビューコメントを必要としているという報告を受け、WCAG 2.1草案へのコメントを検討しました。当社からは下記4つの達成基準に対してコメントしています。

※上記はWCAG 2.1草案は2017年9月12日時点のものです。
※達成基準の番号は今後変更される可能性があります。
※Success Criterionは以下よりSCといたします。

当社のコメント一覧はこちらからご確認いただけます。詳細については各コメントをご参照ください。

SC 2.2.6 Accessible Authenticationについては、現状Webサイトがこの達成基準を満たすことは難しいと考えられるため、草案では適合レベルAだったものをレベルAAあるいはAAAにあげてほしいというコメントをしています。

SC 2.4.12 Accessible Nameの内容からは達成基準1.1.1 非テキストコンテンツに適合しているテキストではないラベル(例:画像ラベルなど)がこの達成基準に適合できるかどうかが明確ではない点についてコメントしています。こちらについてはAccessibility Guidelines Working GroupのメンバーであるDavid MacDonaldさんから達成基準の内容に対する補足のコメントをいただいており、他のissueでも本達成基準に対する議論がなされているようです。

SC 2.5.1 Pointer Gesturesに対するコメントでは"pointer gesture"という言葉の定義が読み手によって異なることが想定されるため、WCAG 2.1草案で新たに提案されたSC 3.2.6 Accidental Activationで用いられているsingle-pointer activationという用語を使用することを提案しています。

SC 3.2.7 Change of Contentの達成基準では"control"という文言を用いていますが、コンテンツの変化はページ上のコントロール以外にもデバイスを傾けるなどの動作でも起こり得るため、異なる文言の使用を提案するコメントを登録しました。こちらについてはDavid MacDonaldさんから"triggering mechanism"という文言を用いる案を提示いただいています。

今後WCAG 2.1草案がどのように変わっていくのか、引き続き見守っていきたいと思います。

GoogleがChromeのデベロッパーツールにDequeのaXeを採用

取締役 木達

(この記事は、2017年9月28日に公開された記事「Google Selects Deque's aXe for Chrome DevTools」の日本語訳です。Deque Systems社の許諾を得て、お届けしています。翻訳の正確性は保証いたしかねますので、必要に応じ原文を参照ください。)

GoogleのLighthouseが、aXe-coreを搭載しました!

Chromeのデベロッパーツールが最近変化したことに気づきましたか?

監査パネルがLighthouseで動くようになり、そしてアクセシビリティの監査はなんと......(ドラムロールの音)Dequeの開発したaXe-coreルールエンジンが担うようになったのです!

Googleが、アクセシビリティの自動テストに用いるエンジンをaXeに置き換える検討をしていると知ったのは、今年サンディエゴで開催されたCSUN支援技術カンファレンスでのことでした。より具体的には、Chromeのデベロッパーツールにある監査パネルが新しくなり、それに搭載されるオープンソースの監査ツール「Lighthouse」で、アクセシビリティ監査を実行するエンジンに採用されるというお話でした。

aXeがそのように認知され、またすべてのChromeユーザーが即座に利用することのできる監査ツールとして統合されるのは、とても刺激的なことです。アクセシビリティに加えて、監査パネルはWebサイトのパフォーマンスやベストプラクティスの採用、Progressive Web Apps(PWA)としての品質についてデータやヒントを提供します。それらは、より良いWeb開発を手助けするという、Googleが目指すゴールの一部です。またそれらは、検索結果においてそのページが何位にランク付けするかをGoogleが決めるために役立てることができるものでもあります。パフォーマンスがまさにそうですが、一部は確実に検索順位に影響します。

aXeのロゴ

アクセシビリティにとっての意味とは?

これは、Googleの検索順位にアクセシビリティが影響を及ぼすようになることを意味するのでしょうか?アクセシビリティとSEOには共通する部分が多くありますから、技術的な観点からは、既に影響していると言えます。

とにかく、アクセシビリティはパフォーマンスやベストプラクティスと等しく必須であるという点で、Googleのメッセージは明らかです。

アクセシビリティ監査はあまりに基本的であるがゆえに、ブラウザの一部となったのです。

Googleはまた、アクセシビリティ監査を可能な限り取り組みやすいものにしています。まだアクセシビリティに馴染み深くない多くの開発者にとって、これは重要なことです。デベロッパーツールは、機械的に実行できる監査に限って、アクセシビリティ監査を行います。

ルールエンジンとしてaXeを採用しているからには、あくまで機械的に検知できた問題点だけが報告されます。誤検知はありません。最もよくみられる、そして最も改善が容易なアクセシビリティ上の問題点を、明確にレポートします。

デベロッパーツールを用いたアクセシビリティ監査の短所は、それだけでは十分ではないということです。Lighthouseによるアクセシビリティ監査の結果が100点満点中94点だったとしても、それは機械的な監査の結果でしかありません。実際のところは、手動でのアクセシビリティ監査を行わなければ、わかりません。

デベロッパーツールにおいて、Googleがアクセシビリティに重きを置いているのは素晴らしいことであり、もしあなたがアクセシビリティに関してこれから取り組もうとしているのであれば、デベロッパーツールはうってつけです。あなたの担当しているWebサイトで、アクセシビリティ要件を満たすことが求められているなら(あるいは単に、より高いレベルを目指してアクセシビリティやインクルーシブデザインに取り組みたいと考えているなら)、ソースを確認していただきたいと思います。

aXeでアクセシビリティ監査を行う準備はできましたか?

aXeのChrome向け拡張機能か、Firefox向けアドオンをダウンロードしてください。aXe-coreのAPIは、GitHubで公開しています。もしあなたの勤務先でアクセシビリティ要件が定められており、まとまった分量を監査できるツールが必要ならば、WorldSpace製品群をチェックしてください。最後に、アクセシビリティについてもっと学び、専門知識を身に付けたいとお考えなら、Deque Universityにアクセスしてください。

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

アクセシビリティ・エンジニア 辻

WebAIMはこのほど、7回目のスクリーン・リーダーに関する調査を開始しました。回答の期限は2017年11月1日で、調査結果は本年末に公開されるとのことです。

調査にはスクリーン・リーダーを日常的に使用している方だけでなく、評価やテストのために一時的に使用している方にもご参加いただけます。また、参加は任意であり、いつでも中止できるとのことです。

今回の調査の中で特に興味深かったのは、オンラインで手続きする場合にモバイルアプリケーションとWebサイトのどちらを選ぶかを尋ねている項目で、デスクトップ向けのスクリーン・リーダーだけでなく、モバイル向けのスクリーン・リーダーの利用者が増えてきた影響があるのではないかと感じました。

前回、6回目の調査にあった、就労状況やスクリーン・リーダーの入手先に関する質問がなくなった反面、第4回の調査(英語)にあった、Webサイトで不満や困難を感じる項目を尋ねる質問が復活していたことも印象的でした。

前回の調査から少し間が空いているので、今回はどのような調査結果が出てくるのかが楽しみです。調査結果が公表され次第、当Blogでご紹介したいと思います。

質問項目について

前回と同様に、以下に質問項目(全30問)の内容を意訳してご紹介します。調査に協力される方は、Screen Reader User Survey #7(英語)へ アクセスしてください。回答の際、個人情報は送信されないものの、お使いのオペレーティングシステムやブラウザのバージョン、JavaScriptが有効かどうかが送信されます。なお、当Blogは質問項目の翻訳の正確性を保証いたしませんので、必要に応じて原文を参照してください。

1. お住まいの地域を選んでください。

2. 障害を理由にスクリーン・リーダーを使用していますか?

3. あなたには以下の中のどの障害がありますか?(該当するものをすべて選択)

4. スクリーン・リーダーへの熟練度を教えてください。

5. インターネット利用の熟練度を教えてください。

6. 次の中で、あなたのスクリーンリーダーの使用状況を最も正確に表しているものはどれですか?

7. 普段、デスクトップまたはラップトップで以下のどのスクリーン・リーダーを主に使用していますか?

8. 昨年、あなたが主に使用しているスクリーン・リーダーは更新されましたか?

9. 主に使用しているスクリーン・リーダーと、同時に使うことの頻度が最も高いブラウザーはどれですか?

10. 以下の中でよく使用するデスクトップ用またはラップトップ用のスクリーン・リーダーはどれですか?(該当する物をすべて選択)

11. スクリーン・リーダーの点字出力を使用していますか?

12. 携帯電話、携帯端末、タブレット向けのスクリーン・リーダーを使用していますか?

13. よく使用するスクリーン・リーダーはデスクトップ/ラップトップ向け、またはモバイル/タブレットデバイス向けのどちらですか?

14. 主に使用している携帯またはタブレットプラットフォームは以下のどれですか?

15. 主に使用しているモバイル向けのWebブラウザーは以下の中のどれですか?

16. 以下の携帯またはタブレット向けのスクリーン・リーダーの中で、よく使用しているものはどれですか?(該当する物をすべて選択)

17. モバイル向けのスクリーン・リーダーを使用しているとき、どのくらいの頻度で外付けキーボードを利用しますか?

18. バンキングやショッピングなどの一般的なタスクをオンラインで実行する場合、モバイルアプリとWebサイトではどちらを使用する可能性が高いですか?

19. 現在、より高価な商用スクリーンリーダーの代替手段として、無料または低価格のデスクトップ向けスクリーンリーダー(NVDAやVoiceOverなど)があることをご存じですか?

20. 以下の中で、この1年のWebコンテンツのアクセシビリティについてあなたの考えにもっとも近いのはどれですか?

21. ウェブアクセシビリティの改善に大きな影響を与えると思われるのは次のうちどれですか?

22. 一般的に、あなたにとってソーシャルメディアはアクセシブルですか?

23. 長いWebページで情報を検索しようとする時、まず最初に行うのは次のうちどれですか?

24. 次のページの見出し構造のどれがあなたにとって最もわかりやすいですか?

25. スクリーン・リーダーでどれぐらいの頻度でランドマークまたはリージョンによる操作をしていますか?

26. ページ上に"本文へスキップ"や"ナビゲーションをスキップ"リンクがある場合、どれくらいの頻度でそれを利用しますか?

27. すべての項目があなたがWebにアクセスしてそれを使用する時に影響を与えるとした場合、次の中で最も不満や困難を感じる項目はどれですか?

28. すべての項目があなたがWebにアクセスしてそれを使用する時に影響を与えるとした場合、次(2番目)に不満や困難を感じる項目はどれですか?

29. すべての項目があなたがWebにアクセスしてそれを使用する時に影響を与えるとした場合、次(3番目)に不満や困難を感じる項目はどれですか?

30. WebAIMのスタッフにコメントやご意見がありますか?

Pick Up