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

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

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

アクセシビリティキャンプ東京 2019 － GAAD発起人と振り返る 「CSUN 2019」に当社スタッフが登壇


取締役 木達

2019年4月8日に開催されるイベント、アクセシビリティキャンプ東京 2019 － GAAD発起人と振り返る 「CSUN 2019」で、当社アクセシビリティ・エンジニアの畠山 帆香が登壇します。

日時
2019年4月8日（月）14:00～16:30（13:40 入場受付開始）
会場
サイボウズ東京オフィス
東京都中央区日本橋2-7-1 東京日本橋タワー27階 Bar
参加費
【会場払い】500円
共催
株式会社インフォアクシア、株式会社コンセント、サイボウズ株式会社、株式会社ミツエーリンクス（50音順）

畠山は、セッション2「CSUN参加者座談会」に登壇します。その概要を以下に引用します：

今年のCSUNカンファレンスに日本から参加したメンバーが、それぞれにとっての「CSUN 2019」をふりかえる座談会形式のトークセッションです。

CSUNカンファレンスについては、開催期間中、畠山が現地よりレポート記事を日々掲載していましたので、是非ご覧ください。

イベントへのお申し込み、詳細についてはアクセシビリティキャンプ東京 2019 － GAAD発起人と振り返る 「CSUN 2019」 - connpassをご覧ください。

パーマリンク

CSUN 2019 最終日レポート


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

最終日も聴講したセッションの中から、印象に残った点をレポートします。

Where Accessibility Lives: Incorporating A11y into your Process and Team

これまでアクセシブルなコンテンツを提供していると思っていたチームが、ユーザーから「操作できない」「欲しい色を選べない」といったフィードバックを得たときに、いったいどうすればアクセシブルなコンテンツを制作できるのか、ということを具体的なシナリオを交えて話すセッションでした。

これまでアクセシビリティの対応をしてきたつもりが、それとは反対のフィードバックをユーザーから得ると、誰でもとまどいます。どこから手を付ければ良いのかわからない、と思うこともあるでしょう。大切なのは、完璧を目指すのではなく、より良くすることを心がけることだとDerek Featherstoneさんは言っていました。

「完璧」という言葉には、完成された、もう修正が必要ない印象があります。また、完璧を目指そうとすると、あまりのハードルの高さに挫折してしまうこともあるでしょう。ですが、アクセシビリティは一度対応すればそれで終わりではありません。より良いものを提供することを目標にすることが重要ですし、デザイナーや開発者のモチベーションにもなります。

WCAGなどの基準に沿うことを求められると、すべての基準を満たすことを目標にしがちですが、それよりもより良いコンテンツを目指して少しずつ進めるようにすることが重要なのだとあらためて思いました。

Automating New and Improved United States Government Requirements

このセッションはとてもインタラクティブで、リハビリテーション法第508条（以下Section 508）のことや政府の動きなど、発表者と参加者みなさんの間でたくさんの意見や情報の共有がなされていました。

その中で特に今後に向けて注目すべきだと感じたのは、政府は今後、VPATに記載されている内容を確認するようになる、ということです。これまでは、VPATによっては、きちんとコンテンツを確認せずにすべての基準に「Supported」と記載していたものも存在していたそうですが、これからは政府による確認が入るため、VPATの内容そのものもさらに正確に記載していく必要があるでしょう。

VPATを作成する際には、Trusted Tester V5という、Section 508に適合していることを確認するテストを実施するためのドキュメントを用いることが可能だそうです。現時点ではまだドラフトですが、2019年の春に発表予定となっています。

Trusted Testerも含め、VPATやSection 508の動向には注目したいところです。

Update on the Accessible Canada Act Bill C-81, a Proposed Law

カナダでAccessible Canada Actが提案されています。提案の内容を作成したDavid MacDonaldさんのセッションを聞きました。

この法案は、連邦政府が管轄しているエリアをバリアフリーにすることを目的としています。法案の中には、Canadian Accessibility Standards Development Organization（CASDO）という、アクセシビリティ基準の検討や提案を担う組織を作ることなどが含まれています。また、組織がこの法律に従っておらず、身体的、心理的、あるいは金銭的被害を受けた場合は個人がそれを届け出ることもできるようになるとのことです。セッションでは参加者の方が、これまではこのような届けを出すことができなかったといったコメントをされていました。この法案が通過すれば、よりアクセシブルな世の中になることが期待できます。

この法案はまだ通過されておらず、2019年10月21日ごろに実施予定の連邦選挙の結果によっては状況が変わる可能性があります。そのため、連邦選挙よりも前にこの法案が通ることを期待しているとDavid MacDonaldさんは話していました。

現在提案されているAccessible Canada Act Bill C-81の内容は、Government Bill (House of Commons) C-81 (42-1) - First Reading - Accessible Canada Act - Parliament of Canadaから読むことができます。

最後に

初めて参加したCSUNでしたが、12日から15日まで、あっという間でした。さまざまなセッションを聞いたり、普段なかなかお会いできない方々と直接お話しする機会を得られたりと、とても充実した4日間でした。今回得た気づきや学びを今後に活かしていきたいと思います。

パーマリンク

CSUN 2019 3日目レポート


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

昨日に続き、3月14日の一部セッションで印象に残った点についてレポートします。

The Difference Between Native Mobile and Web Accessibility Testing

このセッションでは、Webアクセシビリティの知見をモバイルアプリに完全に適用することはできないという話をしていました。

モバイルアプリのテストは、Webサイトのものとは異なります。モバイルアプリ制作の技術でできることと、Webサイト制作の技術でできることが違うためです。例えば、Webアクセシビリティでは良いとされている対応も、モバイルアプリで同等の対応をするための技術が提供されているとは限りません。その場合、Webアクセシビリティで良いとされている方法を適用するには、たくさんコードを書いて無理やり対応するといった、本来望ましくないことをしなければならなくなります。

発表者のChris McMeekingさんは、独自の方法で実装することは避けるべきで、実際そうしなければならないケースはほとんどない、と話していました。特定の技術でもともと提供されていないものを無理やり独自に実装すると、Webあるいはモバイルアプリに限らず、OSやプラットフォーム側の仕様が変わった場合に有効ではなくなる可能性があります。特にモバイルのプラットフォームはWebより速いスピードで変化します。一度独自に実装したものが1年後には使用できなくなっていることもあり得るそうです。

また、独自の方法で実装すると、コンテンツと支援技術の関わり方を保証することができません。プラットフォームが提供している仕様にそって実装されていた場合、ユーザーにとって最もアクセシブルな方法で情報が伝わるように作られています。独自に実装する場合、その部分を補う必要が出てきます。しかし、すべての支援技術の操作方法にあわせたコンテンツを作ることは難しいでしょう。ですので、プラットフォームが提供する方法を用いてアプリを実装することが、最も簡単で、アクセシブルなコンテンツ制作につながるというお話でした。

最後に、Deque Systemsからaxe-coreを使用したアプリ向けのaxeが提供されることになりました。Android版であるAxe for Android - WCAG Accessibility ScannerはすでにGoogle Playで提供されています。こちらはGoogle Playで「WCAG axe」と検索すると表示されます。iOS版も、もうすぐApp Storeにて提供されるそうです。iOS版の新着情報についてはDeque SystemsのGitHubリポジトリをご確認ください。

How W3C Checks Its Specifications for Accessibility Support

ある技術を用いた特定の機能がアクセシビリティの機能を妨げないように技術文書のレビューを行うAccessible Platform Architectures (APA) Working Group（以下「APA WG」）についての話を聞いてきました。

技術文書を作成している段階では、アクセシビリティへの配慮が足りていない機能が存在する場合があります。そのような機能を変更、削除、調整したりできるようレビューをしているのがAPA WGです。ただし、アクセシビリティの確保が難しそうな機能でも、別の重要な理由があってその機能が検討されていることがあり、削除まで至るのは難しいそうです。そういった場合はセキュリティやプライバシーに関する内容と同じように、アクセシビリティに関連したアドバイスを記載するAccessibility Impact Statementなどを載せるよう対応をしているとのことでした。

現在APA WGが対応しているものはAccessible Platform Architectures (APA) Working GroupページのCurrent Work以下から確認できます。このページには記載されていませんが、セッションではCSSレイアウトとキーボード操作の関係について検討するCSS Accessibility Task Forceや、Knowledge Domain Community GroupによるMathML、化学、音楽、言語、物理など通常のテキストだけでは表現できないコンテンツの表現方法などについても検討されていると話していました。

APA WGでは協力者を募集しているとのことでしたので、興味のある方は参加してみてはいかがでしょうか。協力の方法についてはAccessible Platform Architectures (APA) Working GroupページのHow to Comment, Contribute, and Participateのセクションをご確認ください。

The Unassuming Art of Closed Captioning

キャプションは音声をテキスト化し、聴覚障害者や音を出せない環境のユーザーに対して、音声による情報を提供するために使用されます。しかし、このキャプションにはしばしば必要な情報が含まれない、あるいは不要な情報が含まれることがあります。

例えば、「(dog barking)」というキャプションが表示されたとします。こういったキャプションが表示されるときはだいたい犬が吠えている音が入っているからなのですが、この情報がどの程度重要かは、映像によって異なります。例えば、ホラーやスリラー映画などでは不気味な雰囲気を演出するために犬が吠えたり、おびえた声を出す場合があります。このような場合は「(dog barking)」などの情報を伝えることが重要になってくるでしょう。しかし、そうではない場合もあります。セッションでは、男女が食事をしている映像が例として出てきました。この映像では男女が険悪なムードの中、食事をしています。ここで重要なのは険悪なムードを音で表現することでしょう。男性がいらだったようにフォークをお皿に強く叩きつける音がしていましたので、この音を説明することが険悪なムードを表現する良い手段だと考えられます。ですが、実際の映像のキャプションでは、映像の冒頭に犬が吠えたことと、男女の会話、そして最後の（ほとんど聞こえない）鳥の鳴き声の情報のみが表現されていました。これではキャプションから男女が楽しんでいるのか、争っているのかなどの情報が伝わらない可能性があります。

それ以外にも、キャプションに情報を含めすぎて、キャプションを見ているユーザーにだけ余分な情報が伝わることもあります。例えば、映像の中に少女が出てきて、彼女のセリフのキャプションに「Young Tara」という表記が含まれていると、映像全体の中で、この後大人になったTaraというキャラクターが出てくるであろうことが予測できます。他にも何の説明もなく犬が出てきた際に「Paul the dog」といった表現がキャプション内にあると、キャプションを見ているユーザーはその犬の名前がPaulであることを理解できます。この時点でキャプションを見ているユーザーはこれからの映像の流れを予測をしたり、映像あるいは音声から情報を得ているユーザーとは異なる情報を得ていることになります。これではすべての環境においてアクセシブルなコンテンツを提供しているとは言えません。

キャプションの内容を考えるのはとても難しいことなのだろうとは思っていましたが、やはりその通りであることを確認させられたセッションでした。キャプションを考えることがあれば、こういった点も気を付けたいと思います。

The State of Web Accessibility: What We Learned Testing 1,000,000 Homepages

本日最後のセッションは、Webが一般的に現状どのレベルにあるのかを確認するため、1,000,000ものページを機械で検証した事例について聞いてきました。この検証では、サイトのトップページのみを対象に内容を取得し、WAVEというツールのAPIを使用して検証結果を出していました。トップページのみを対象にした理由は、通常、トップページは下層ページを表していることが多い（トップページに問題が多い場合、下層ページにもたくさん問題がある傾向にある）ためとのことでした。

検証をした結果としては、59,653,607個の問題が見つかり、ページでは平均60個の検出可能な問題があったという結果が出ていました。この結果からもわかるように、全体的にWCAGに適合しているサイトは少ないようです。また、85%のページはコントラストが低く、68%のページは代替テキストが不足していて、ARIAを使用しているページにはエラーがより多かったそうです。

アクセシブルなWebサイトを制作するのは決して容易ではありません。また、昨日の別のセッションでも言及されていましたが、作成したものを後から調整するにはさまざまなコストがかかります。なるべくシフトレフトすることで早い段階からアクセシブルなコンテンツを作るようにしていけると良いのかもしれないと思いました。

このレポートはThe WebAIM Millionに掲載されています。

パーマリンク

CSUN 2019 2日目レポート


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

本日よりセッションが始まります。聴講した一部セッションの印象に残った点についてレポートしたいと思います。

Gray-Box Mobile Accessibility Testing

アプリのアクセシビリティテストをグレーボックス化しようというお話でした。

グレーボックスというのは、空港のセキュリティチェックで考えると、X線を用いて荷物のイメージを画面に映し、中身の確認をするような方法のことです。アプリの場合も、同じようにそのときのアプリのコンテンツを取得し、確認できます。さらに、そのXMLコードをHTML5に変換することで、Webと同様のテストライブラリーを適用し、テストを実施できるということでした。

アプリの検証はOSによる固有の違いなどで個別のテストを組み込む必要があったり、セキュリティの問題からサードパーティーのライブラリーを組み込むことが難しかったりと、さまざまなハードルがあるようですが、このグレーボックステストによりアプリのテストがよりシンプルになることに期待したいところです。

2019 Digital Accessibility Legal Update

本セッションは2018年度からのアップデートだそうです。2018年のサマリーは発表者であるLainey Feingoldさんのサイトに掲載されています。

セッションはまず、なぜアクセシビリティに関する法律があるのかといった内容から始まりました。アクセシビリティを確保するのは、人権を守ることにつながるためであり、人権は人々が参加すること、セキュリティ、プライバシー、情報への権利、そして安全を保障します。アクセシビリティを確保しないことは、これらの人権を損害することなのだとあらためて感じました。

今後注目すべき訴訟や示談の紹介もありました。

など

※リンク先は英語です。

今後はWebサイトのみではなく、モバイルアプリケーション、動画ストリーミング、雇用者向けのサービス、キオスクなどに関連した訴訟が増えていく可能性が高いと考えているとのことでした。Lainey Feingoldさんは訴訟を避けるには、アクセシビリティの文化を浸透させることが重要と話していました。

また、本日13日にEuropean Accessibility Actが通過したそうです。アクセシブルな社会にさらに近づく一歩となったのではないでしょうか。

How to Meet 7 New Success Criteria in WCAG 2.1: Tricks and Tips

WCAG 2.1で新しく追加された基準について、わかりやすく説明するというセッションでした。本セッションの資料は発表者であるDavid MacDonaldさんのブログから確認できます。

このセッションで最も印象に残ったのは、David MacDonaldさんのWAI-ARIAを使用する際の例がとてもわかりやすかったことです。WAI-ARIAは使い方を間違えると、コンテンツが全くアクセシブルではなくなる場合があります。これを小さい子供にお手伝いを頼んだときの様子に例えていました。以下はセッションでの例の意訳です（わかりやすさのため、一部内容を調整しています）。

小さい子供にシチューを一緒に作ろうと誘ったら、よろこんでくれました。子供にスパイスを選ぶようにお願いし、5分ほど席を外しました。その間、その子供がどうするかは想像できますね。戻ってくると、シチューにスパイスがたくさん追加され、辛くなってしまっていました。これと同じように、WAI-ARIAを覚えたばかりの開発者は、WAI-ARIAをいろんなところに使用しすぎる傾向があります。実際には、熟練のフレンチシェフのように、素材の味をうまく引き出す ― Webサイトの場合、HTMLの本来の意味を活かす ― ことが重要です。そして、必要なところにだけ、必要な味（WAI-ARIA）をつけます。そうすることで、シチューはおいしく、Webサイトはアクセシブルになります。

この例に限りませんが、説明をするときにはこのようにわかりやすい例を使うことを心がけたいと思いました。

The Real Cost of Accessibility Complaints and Lawsuits

近年増加している訴訟ですが、訴訟にたどり着く前に、ユーザーは最初にサービス提供者に問い合わせるようです。その問い合わせはクレームから単純な「このサービスを使用できないのですが」というものまでさまざまだと思いますが、内容に問わず、最初の対応がとても重要とのことでした。そのユーザーの身になり、スピード感をもって対応することが求められます。このとき十分な対応がなされないと、訴訟が起こされる場合が多いそうです。

ではどうすれば良いのでしょうか。セッションでは、以下のことが推奨されていました。

など

問い合わせの段階に比べて、訴訟が起きる段階になると、それだけその件にかかる総合的な金額が異なります。なるべく早い段階からアクセシビリティ対応を開始し、問題のないコンテンツを提供することは、ビジネスの面からもメリットがあることがわかります。

Understanding the User Experience Behind the New WCAG 2.1 Requirements

WCAGは基準を提供するため、技術に依存しない、テスト可能にする、といった基準を作成する際のルールが存在します。それにより理解しづらい状態になってしまっています。ですが、どの基準ももともとはコンテンツを使えずに困っているユーザーがいたからこそ基準として設けられています。そのユーザーエクスペリエンスを理解することで、WCAGの各基準の理解が深まります。セッションではWCAG 2.1で新しく追加された基準を取り上げていましたので、そのうちの1つを紹介したいと思います。

ユーザーの中には読字障害などで、コンテンツを読む場合にフォントを変更しているユーザーがいます。実際に調査をしたところ、60%の人はサンセリフ体、40%の人はセリフ体を好んだという結果が出たと発表者のShawn Henryさんは話していました。この時点ですでに、すべてのユーザーにとって読みやすいフォントを指定することが不可能であることがわかります。

このユーザーエクスペリエンスから生まれたのが、1.4.12 Text Spacingという基準です。最初はフォントを変える必要があるので、ユーザーがフォントを変更してもコンテンツや機能が失われないようにする基準を設ければいいと思うかもしれません。ですが、これは果たしてテストできるのでしょうか。どのフォントを指定すれば良いのでしょうか。全く見た目の異なるフォントを指定しても問題が起きない保証はあるのでしょうか。フォントを変える、というだけでは、コンテンツに問題が発生しないことを確認できません。すなわち、この基準はテスト可能とは言えません。そこで検討を重ねて作られたのが、Text Spacingという基準でした。Text Spacingで求められている文字の間隔についての基準を満たすことができれば、フォントを変えても問題ないことがわかったのです。

このように、コンテンツを使えなくて困っているユーザーの経験をもとにしているため、ユーザーエクスペリエンスを理解できれば、基準の理解につながります。

Web Accessibility Initiativeは以下のページでユーザーのさまざまな閲覧環境を動画で紹介しています。ユーザーエクスペリエンスを理解するため、Web Accessibility Perspectives: Explore the Impact and Benefits for Everyoneもあわせてご参照ください。

パーマリンク

CSUN 2019 初日レポート


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

CSUN 2019に初めて参加しています。今年の開催地、カリフォルニア州アナハイムより毎日レポートを書きたいと思います。

CSUNとは、CSUN Assistive Technology Conferenceの略称で、世界最大級のアクセシビリティに関する国際会議のことを指しています。今年は34回目だそうです。今年は3月11日から15日までの開催で、11日、12日はカンファレンス前のワークショップや、キーノートのみが実施されます。12日はキーノートに参加しましたので、今回はその様子をお伝えしたいと思います。

キーノートについて

私は30分ほど前に会場に入室したのですが、その時点ですでに何名か参加者の方が座っていました。

個人的に印象に残ったのは、スライドを表示するメインのスクリーンの他に、左右に1つずつスクリーンが用意され、そこにライブキャプションを表示していたことです。アクセシビリティのカンファレンスなのであって当たり前といえば当たり前なのかもしれませんが、発表している内容にキャプションをつけるというのは、決して簡単なことではありません。動画のキャプションと言われて想像しやすいのはYouTubeのものだと思いますが、これは正確ではないことが多々あり、なかなか実現させるのは難しいのではないかと感じていました。このような場で正確なライブキャプションを見ることができたのは貴重な体験でした。

キーノートスピーカーのJohanna Luchtさんのトークテーマは、支援技術とは何か、でした。法律などでは支援技術は障害を持つ人のサポートをするための技術として定義されることがほとんどです（※）。ですが、支援技術は障害を持つ人をサポートするためだけのものなのでしょうか。Johanna Luchtさんは、そのようなことはないと考えている、とお話しになっていました。

※ ADAでのAssistive Technologyの定義

Johanna Luchtさんはキャプションを例にあげ、聴覚障害者以外のユーザーもキャプションに助けられているということを話していました。私自身も音を出せない環境でキャプションがあれば、と思ったことは何度もあります。そのほかにも、洋画を見る際、英語の字幕がついているととても助かることがあります。

それ以外にも、人間は空を飛べない代わりに、飛行機で移動するという例を出されていました。極端な例ではありますが、「できないことを補う」という点では飛行機も確かに支援技術の一部としてとらえることができるかもしれない、と思いました。

Johanna Luchtさんのスピーチを聞き、支援技術は決して障害を持つ人のサポートのためだけのものではないことをあらためて感じました。Johanna Luchtさんはスピーチの中で、assistive technology（支援技術＝障害がある人のサポートのための技術）ではなく、access technology（アクセス技術＝できないことを補うための技術）ではないか、とおっしゃっていましたが、確かにその通りだと思います。支援技術という言葉の意味にとらわれず、今存在するそれぞれの技術がどのような場面でどのようなユーザーをサポートすることができるのか、を意識していきたいと思いました。

13日からはセッションが始まります。さまざまなセッションを聞いて、新しい知識や視点を得られることを楽しみにしています。

パーマリンク

DequeとMicrosoftのコラボレーションを振り返って


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

（この記事は、2019年3月12日に公開された記事「Reflecting on the Deque-Microsoft collaboration」の日本語訳です。Deque Systems社の許諾を得て、お届けしています。翻訳の正確性は保証いたしかねますので、必要に応じ原文を参照ください。）

訳注：外部リンクのほとんどは英語のページにリンクしています。

「Deque Systems to expand open source accessibility tools in collaboration with Microsoft」という、つい最近発表したMicrosoftとの共同プレスリリースについて、さらなる彩りを添えつつ個人的な見解を追加したく、私はこの記事を書いています。

アクセシビリティ業界と呼ばれるものができる前から取り組んできた者として、Microsoftのアクセシビリティへのコミットメントはとても画期的だと考えています。Microsoftのようなソフトウェア大手が、同社の実施しているレベルでインクルーシビティを支持することはまれです。

DequeがMicrosoftと共に歩み始めたのは、Microsoftが社員教育のためにDequeのアクセシビリティ教育コースの採用を決めた数年前にさかのぼります。当時、私たちのコースが広範に展開される計画に感銘を受けたものです。それが以後に続く旅路の始まりにすぎなかったことを、私たちは知りませんでした。その後すぐに、MicrosoftはDequeのオープンソースルールエンジン「axe-core」を社内の開発者に使用してもらうこと、そして最終的には彼らの新しいAccessibility Insightsという自動チェックツールに採用することを決めました。プレスリリースをすでに読んでいる方であれば、それらが私たちを現在ある姿へと導いたことをご存じでしょう。Microsoftがaxeのコミュニティに参加し、Windowsのルールをaxe for Windowsとしてオープンソース化することは、リリース以来強化してきたaxeのコミュニティをさらに強化する重要なステップです。axeのコミュニティは今後、Windowsベースのアプリケーションに対するアクセシビリティテストに貢献することができます。

また、私たちはこの決断が、iOS向け（近日公開予定）およびAndroid向けのaxeルールライブラリーをオープンソース化し、それらのルールに基づいたアプリケーションを無料でリリースすることにより、コミュニティへの貢献を拡大するというDequeのコミットメントと一致することもうれしく思います。

私は、アクセシビリティテストがすべてのフロントエンド開発者の中心的な責務になると信じています。今日という日は、私たちがaxeのユーザーならびに貢献者のコミュニティを拡大し、すべての人々が共通のルールセットを異なるプラットフォーム間で使用のうえ、アクセシビリティテストを以前よりさらに自動化することを可能にするためのマイルストーンです。

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

MicrosoftとDequeがアクセシビリティツールのオープンソース化で協力することは、アクセシビリティの世界を大きく変えます。axeが誕生する前は、アクセシビリティのルールは黒魔術のようでした。多くのルールは個人の解釈に依存し、透明性を欠き、改善したり使用するにはコミュニティのサポートが不足していました。世界中のすべての人が知識や利便、コンピューターやインターネットなどの増え続けるイノベーションを用いることのできる、印刷機以来の偉大なイコイライザーとしてのデジタル世界を、その期待に沿うようにするといった本当に重要なことに集中することなく、WCAG基準の異なる実装結果を比較するために、貴重な時間が失われていました。どのツールが正しい、あるいは間違った答えを出すかといったことに、何週間も費やされたのです。また、基準や不備のある実装に対する終わりのない議論に使う時間がないことから、最終的な影響を与える開発者によりアクセシビリティが放棄されるところも目にしました。

axeのルールを細かく精査できるよう「無数の目」に呼びかけ、外部からの貢献を受け入れてきたことが、axeを今日の姿である「自動化されたアクセシビリティテストの事実上の標準」にしてくれました。Dequeはこのプロジェクトをコミュニティと共に育てるため、すばらしい開発者のチームを割り当てました。コミュニティはそれに応え、Google、Facebook、eBay、そして他の多くの企業も貢献してくれました。

アクセシビリティへの道のりを歩み始める理由が企業ごとに異なろうとも、それは最終的には、あらゆる多様なユーザーに対し最高のカスタマーエクスペリエンスを提供するためのものです。

自分自身に質問してみてください：あなたは目先の利益に重きを置く企業と、道徳的重要性や長期的な利益機会を重視しオンライン体験をできる限り広範に提供する企業、どちらで働きたいですか？世界には10億人もの障害者が存在し、その一人一人がデジタルサービスにアクセスする権利を同じように持っています。それらを無視する口実は減ってきています。

Dequeのお客様にとっての意味

axeという旗印のもと、オープンソース化した私たちのWebのルールエンジンが事実上の標準になっていくことは、Dequeの「デジタルの平等性」というミッションにとって有益です。しかし、それだけではありません。私たちのお客様は、WorldSpace製品で満たそうとしている必須要件を数多くお持ちです。WorldSpace製品にaxeルールライブラリーが搭載されていることで、私たちのお客様はaxeの拡大やコミュニティの恩恵を受けることができます。サポートやセキュリティ、企業の必須要件は私たちの提供する有償ツールで確実に満たしながら、axeルールエンジンによって自動化を一層進めることの恩恵を得ることもできます。

皆さんはたくさんのすばらしい質問をお持ちだと思います。お気軽にコメントを寄せていただくなり、直接お問い合わせいただければお答えします。

ツールの場所とプロジェクトの取り組みに参加するには

オープンソースの取り組みに参加したいとお考えの場合、関連するプロジェクトは以下から見つけることができます。それぞれ近日公開予定です。

訳注：リンクテキストは参照可能にするため翻訳していません。

パーマリンク

axe-core 3.2で検証結果を日本語化する方法


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

先日、畠山が案内したとおり、axe-core 3.2がリリースされました。

axe-core 3.2の全体的な変更点は畠山の記事を確認いただくとして、この記事では別の変更点を紹介します。それはaxe-coreの検証結果を日本語化する方法です。

axe-coreはこれまでも検証結果を日本語化することはできましたが、npmで公開されているパッケージをそのまま使えないなど、複雑な手順を踏む必要がありました。しかし、3.2からは次のように比較的簡単に日本語化することができます。

const axe = require('axe-core');
const AXE_LOCALE_JA = require('axe-core/locales/ja.json');

axe.configure({
    locale: AXE_LOCALE_JA
});

axe.run().then((results) => {
   if (results.violations) {
       console.error('問題が発見されました。');
       // ...
   }
});

日本語化するには、axe.configureの引数オブジェクトのlocaleに、翻訳用のデータが入ったオブジェクトを指定します（APIの解説（英語））。翻訳用のデータはaxe-coreパッケージ内に入っており、GitHubでも一覧を確認できます。記事執筆時点でドイツ語（de.json）、フランス語（fr.json）、日本語（ja.json）、オランダ語（nl.json）が利用できます。

「axe-core 3.2で検証結果を日本語化する方法」の全文を読む

パーマリンク

Pick Up