2019年10月4日 TPAC 2019参加報告

TPACではARIA（Accessible Rich Internet Applications）などアクセシビリティに特化したミーティングもありますが、CSSやWeb Componentsなどの要素技術に関するミーティングのほうが多く行われています。私が傍聴した限りでは要素技術のミーティングでもアクセシビリティに関する議論が自然と行われるようになったと感じました。もちろん、常にアクセシビリティを議論しているわけではありませんが、必要に応じて当たり前のものとして議論されているという印象を受けました。

• いくつかのCSSやSVGの仕様にはアクセシビリティに関する注意事項が記載されている
• Web Componentsの標準化ではフォーカスや要素の役割（ARIAのroleに相当）に関する議論がなされている

過去を振り返ると、Appleの独自拡張として始まったHTMLのcanvas要素は当初アクセシビリティのことは考えられておらず、アクセシビリティのための機能の標準化はcanvas要素が広く使われるようになった後で行われた事例などを踏まえると、標準化の現場で初めからアクセシビリティが考えられていることはとても心強いことです。

一方で、アクセシビリティに特化したミーティングでは要素技術の理解が十分でない点も目につきました。例えば、障害当事者からユーザーがアニメーションを望まなかったときにオフにするための技術が欲しいという話がありましたが、既に要素技術（CSS）では標準化されており（prefers-reduced-motion）、多くの環境で実装されています。当社も折に触れて紹介してきました（Safariに関する記事、Firefoxに関する記事、Google Chromeに関する記事）。また、ユーザーCSSが制作者CSSを上書きできないという問題提起もありましたが、要素技術（CSS）は上書きできることを担保しています。Stylusなどのブラウザー拡張機能がユーザースタイルシートをユーザーCSSではなく制作者CSSとしてページに注入していることは問題ですが、標準化の問題ではありません。

要素技術に関わる人がアクセシビリティへの理解を深めている今こそ、障害当事者をはじめとしてアクセシビリティに関わる人が要素技術への理解を深めることが重要であると感じました。

ARIAに関するミーティングで興味深かったのはWebで点字ディスプレイへの出力や音声入力をより扱いやすくするための議論です。

近年、iOSやAndroid、Windowsなどのプラットフォームはアクセシビリティに力を入れており、ネイティブアプリケーションはこれまでよりも支援技術と連携しやすくなっています。一方、Webでは技術が標準化され、ブラウザーなどへの実装を経て、開発者が使えるようになるのに時間がかかります。もちろん、WebにはWebのメリットがありますが、単純な支援技術との連携のしやすさで言えばネイティブアプリケーションに軍配があがるでしょう。ただ、いつまでもその状況が続けば、Webのメリットの1つである、始めるための敷居が低くユーザーから開発者になることが容易であること（例えば、皆さんがお使いのブラウザーに開発者向けのツールが同梱されています）が、アクセシビリティの文脈では、活かせないのではないかと感じています。私もはじめてWeb技術に触ったのは自分で使うもの（ごく簡単なゲーム）を作るためでした。支援技術を使っているユーザーが、自分で使うものを自分で作ることを通して開発者になろうと思うとき、普段使っている支援技術とスムーズに連携できる技術を選ぼうとするのではないでしょうか。

TPAC 2019における前述の議論は始まったばかりであり、すぐにWebページで使えるものではありませんが、未来の開発者にとって役立つものであってほしいと考えています。