Web アクセシビリティと呼ばれているものと Web アプリ開発現場に思いを寄せて
Posted: Updated:
捉え方と考えの整理
Web アプリケーション開発屋として Web アクセシビリティをどのように捉え、どのように付き合っていくべきかの考えを書いてみます。昨今の Web サービスにおいてアクセシビリティは Web の領域だけで果たされるものではなくアプリとかも含めてだよね、という向きはありますが話が広がりすぎるので今回は Web の中に留めます。
Web アクセシビリティと呼ばれているもの
自分が Web におけるアクセシビリティとは何なのか？と考えるときは「多様なクライアント環境に対する配慮」と「制限をもつユーザーに対する配慮」の2面で捉えています。前者はあくまで Web に関する技術的な配慮であり、後者は Web に限らず包括的なアクセシビリティとしての配慮またはその社会的要請です。
多様なクライアント環境や Web に対するニーズへの配慮
Web ページを参照できるユーザーエージェントやデバイスの数が多いのは言うまでもなく、これらは将来的にも増え続けています。デバイスだけでなく、いつ・どこで・だれが・どのように使うかによってもクライアント環境は無限とも言えるほど多岐に渡ります。この点の配慮が欠けると、Web ページをユーザーエージェントが解釈できなかったり、特定のデバイスで使えなかったりと言った問題が発生しやすいでしょう。
例えば :hover のみで表現された UI は、マウスやトラックパッドを使っていれば問題ありませんが多くのタッチパネルでは役に立たず、キーボードでも操作できません。見た目のために独自実装されたチェックボックス UI が click イベントにしか反応せず <label> 相当の振る舞いもないときなども、同様に不都合が生じます。
このようなケースはユーザー側の制限がどうこうという問題ではなく、 多様性を配慮するというクライアントサイドの基本を欠いている状態と言えます。実装や UI デザインひいては開発者の仕事の問題だとも言えますし、すべてのユーザーに対する配慮であるべきです。技術的に「Web は本来アクセシブル」という言葉が表現しているのは、このあたりのことを指していると理解しています。
余談。PageSpeed Insights や WCAG のようなチェックリスト型の品質チェックは、この段階までは非常に有効に働くでしょう。まずは最低限の品質を担保するために、あるいは作業者の効果的な学習を促すために、チェックリストで管理するのは正しい。ただし管理コストが低くないのと、必須要件にでもなってない限り現場の努力だけでは維持しづらいのが難点と言えます。
制限をもつユーザーに対する配慮と社会的要請
多様なクライアント環境の中でも特に、何らかの制限をもつユーザーに対して高いレベルでアクセシビリティを提供するためには、高齢者や障碍者さらに拡げると学習、認知障害など様々なユーザーに対する理解が必要になります。これには法律に基づいた社会的要請であったり、何らかのビジネス要件であったり、もしかしたら個人の良心であったり色々ですが、それなりに強い理由が必要ではないでしょうか。
WCAG や JIS X 8341-3を最低限のガイドラインとして遵守しても、その対策が本当にユーザーにとって不都合のないものに仕上がっているかどうかは分かりません。iOS や Android のアクセシビリティに関するガイドラインでも、とにかく自分でも触ってテストすることを推奨しています。ラベリングや情報の文脈などは色や文字サイズよりも定量的な評価が困難であり、本当に認知可能なものであるかはテストしなければ評価できないはずです。
アクセシビリティ領域に限らずデザインやプロダクト一般に言えることですが、百聞は一見にしかずということでユーザーテストを重んじる流れがあります。プロダクトが本当に利用可能な出来映えなのかは、ユーザーテストの観察を通して検証するしかありません。この方法論に高齢者や障碍者だとか健常者だとかの差異はないのですが、技術的な配慮の先に検証と改善というプロセスや、スペシャリストの専門性があるのは自然なことと言えます。
Web アクセシビリティを支えているもの
もちろん、理想は全てのユーザーがアクセスできるコンテンツを提供することですが、前述のとおり技術的な配慮だけでは恐らく真なる実現は難しいでしょう。しかし技術的な配慮として適正と思われる実装を最大限提供できていれば何とかなる確率は高められます。
- コンテンツが提供するアクセシビリティの品質
- ユーザーの習熟度とユーザーエージェントの性能
Web コンテンツにアクセスできるというのは、開発者が提供するコンテンツのアクセシビリティだけで支えられるのではなく、ユーザー側の習熟度やユーザーエージェントの性能によっても支えられています。双方が高い水準にあれば十全ですが、片方が低くても片方が高ければやはり何とかなる確率が高くなります。開発現場としては、片側をなるべく高い水準で提供できていれば、そこにちゃんと価値はあります。
そのためにもまずは「多様なクライアント環境や Web に対するニーズへの配慮」の意義を理解し、開発現場の視野を広げていくことが重要ではないでしょうか。
Web アプリの開発現場で出来ること
残念ながら自分の観測範囲だと、Web アプリの開発現場ではアクセシビリティの問題を多く抱えてしまっています。そんな中で、開発現場はどのようなことが出来るのか、どのように始めればよいのでしょうか。
仕事の一環として善悪なくやるものと認識するのが良い筋と考えてる派。
— あほむ (@ahomu) November 9, 2016
高速な回線、高い解像度、高性能なデバイス、そしていつもの使い方...という状況では、Web アクセシビリティの問題は開発現場で顕在化されません。これは Web のパフォーマンスやセキュリティについても同じ事が言えますが、顕在化しづらいイコール、意識的な取り組みの必要があります。
最初から、高齢者や障碍者向けのために取り組む必要はない
クライアント企業の中で障碍者が働いているかもしれない、公共系の事業なのでアクセシビリティ指針を満たさなければならない etc ... ビジネス的な意味を見つけようと思えばいくらでも見つけられます。しかし、そのような理屈で考えてしまうと転がし方によっては、そういうプロダクトではないから一切無視して良い、という思考へも容易に転落できてしまいます。
上にも書きましたが現場においては、まずアクセシビリティをクライアントサイドの多様性に対応するために開発者が守るべき仕事の品質という前提から始めて、後からアクセシビリティによって助かるユーザーやシチュエーションにも考えを深めるというプロセスでも良いのではないでしょうか。技術的な配慮を通して、それがどのように役立つかという気付きは作業するだけでも得られます。
アクセシビリティは高齢者や障碍者等のためだけのものではなく、誰もがどんな環境でもアクセスするためのもの...とは言われますが「誰もが」の中でも「高齢者や障碍者など」が特別な重みをもつことは否定できません。目標をどこに置くか次第ですが、ここでは導入としてこのように述べています。
絶対に 100% の完璧である必要もない
例えばパフォーマンスは高い、低いなどとは言いますが決して対応、非対応とは言いません。アクセシビリティもパフォーマンスと同じように品質の高い低い、つまり程度の状態で表現できます。
例えばユニットテストのカバレッジは多くの場合、必ずしも 100% ではありませんが、決して意味がないわけではありません。アクセシビリティも同じで完璧でなくても、より良くあろうと取り組み続けることに十分意味があります。そもそもテストカバレッジと違って 100% というゴールすらありません。
継続的なプロセスとして手間をかける必要はある
一時的に品質を向上させても運用していく中で、品質はいずれ下がってしまいます。
継続的なプロセスとして成立させなければ保守は果たされません。例えば基礎のコンポーネント単位でアクセシビリティを担保してなるべく再利用したり、アクセシビリティが考慮された実装のコンポーネントを使ったり、自動テストのツールを CI に導入したり、継続的なプロセスとして成立するように取り組む必要があります。
Web サイト制作で HTML ないし HTML テンプレートを書いている分には、妥当性の高い HTML さえ書いていれば「本来 Web はアクセシブル」と教示できるのかもしれません。ところが Web アプリの現場では JavaScript や JSX が飛び交い Web ページの中の状態は常にめまぐるしく変化する性質のものが多いです。素直な HTML のほうが珍しいとさえ言えるかもしれません。単純に実装の複雑性が高い分の手間は増えると考えて良いでしょう。
普段のコードレビューの観点をひとつ増やす。いっそこれだけでも現場の品質は高まるはずです。
個人的な向き合い方
ここからは話が個人的な観点に大分偏ります。
とりあえず自分としては、自分の関わっている仕事の品質が低いのが我慢ならないという矜持と、会社として Web アクセシビリティに取り組むことで十分に価値を生み出せるという判断とが同居しています。現職が抱えるサービスはユーザー数もそれなりに多いし、それこそ障碍者の方からの要望ももらっているということもあり、技術的な配慮をこえてユーザーテストの結果や専門家の意見も踏まえた、本当に使える Web プロダクトが理想です。
取り組みをスケールさせるための評価
自分の中で（アクセシビリティだけではなく） Web プロダクトの品質を向上させる理由は成立しています。
次にこれをスケールさせるためには何が必要かといえば、理解者を増やす社内啓蒙をするというのは当たり前として、それを能力として評価する仕組み作りが必要です。以前の勉強会レポートでも書きましたが、開発者の善意に依存せず評価されることが保証されないと頭打ちがきてしまいます。評価されうる他のこと...色々あるでしょうけれども、それらに専念したほうが良いということになります。
Web ブラウザの外側にある体験
今どきの Web サービスを作ったり使っていると、やはりユーザーのスマートフォンのホーム画面を何とかして占有して、エンゲージメントを高めるべく Web からのアプリ誘導は非常に太い導線になっています。
となると、クライアントサイドの体験を提供する者としては Web だけでなくアプリも、ユーザーと接するすべてのクライアントサイドの品質を向上させなければ片手落ちといえるという自覚があります。その点、ネイティブアプリの分野にどうやってリーチしていくかというのは今後の課題と言えるでしょう。
おしまい
ということで、Web アプリ開発屋の立場からみたアクセシビリティについて私見をまとめてみました。微妙に気を遣うネタに感じるところもありつつで、結論っぽいことはあまり書けませんでした。品質って、どうやったら意識高く煽れるんでしょう..。
踏まえて。やはり「アクセシビリティが当たり前」って推しは無理だと思う。マーケティングとして悪手というか。それにかける工数の意味づけを、各方面に対して言語化しないとダメぽい。
— あほむ (@ahomu) May 8, 2016
動機付けの深掘りや、外的要因に押し潰されないためのネゴシエーション、分業を超えるための越境戦略など、色々考えるところは他にもありますが今回はここまでとします。
