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に掲載されています。