カラーモード

アクセシビリティはあなたビリティ

Advent Calendar
accessibility

Web アクセシビリティ Advent Calendarの 24 日目。

僕にとってはウェブはだいたい HTML で、仕事もウェブ制作なので、そこ視点の話になります。あと「Web」でも「WEB」でもなく「ウェブ」派なのでそう書いてます。

これの下書きはひと月以上書いては消し書いては消し、足したり引いたりし続けました。触ってる間はずっとしんどかったです。かなりポエムになったので、あえて口語調にしてみました。喋ってるのを文字起こししたものだと思うとちょっと読みやすいかもしれません。

ちなみにこのブログの記念すべき 100 記事目です。

僕とウェブ制作

受託のウェブ制作会社でコーディングをしていると「自分がやらなかったら後ろに誰もいないやんけ」って思うことが多いんですよね。

受託のなかでも自分は、デザインが完成してからデータが降りてきて、デザインを変更できないことが多いので、アクセシブルなデザインを実装するというよりも、デザインはそのままにアクセシブルに再現する感じになる。再現魔族。

変更できないっていうのは、ボタンが小さすぎるから 44px 角以上に直したいとか、文字の大きさが 10px だと誰も読めないからせめて 12px にしたいとか、そういうのです。大抵、やるとレイアウト崩れるんですよね。崩れるというか、それに絡んでコンテナの幅や高さを増やしたりしなきゃいけなくなっちゃう。そうすると「影響が大きい変更」となって、受け入れてもらえない感じになる。実装上時間かかりすぎちゃいますって言うのは別ですけど。

一度納品すると、だいたいそのままウェブサーバーにおかれて、それ以後、誰かが書き換えることはないんですよね。解析用のタグが後から差し込まれるとか、API キーが更新されるとかはあるし、運用が入るニュースページなんかが CMS になる関係でそこら周りに手が加えられることはそりゃあありますよ。でも、納品後に書き換わるのは本文とかのコンテンツであって、例えばそのウェブサイトの主要なナビゲーションであるドロワーメニューというような「UI」が書き換わることはないわけです。

そもそもアクセシビリティ的に不完全なものが「納品」されうると言うのがあんまりわからない人もいますね。納品したんなら「完成」してるんでしょ？的な。

つまり、アクセシビリティ対応がちゃんと要件にはいっていないと、制作中のチェックもされないし、納品後のチェックもされない。だとしたら自分が納品した後に、不足しているアクセシビリティを補強する人はどこにもいないということになる。

「私はそういうワークフローじゃないな」という人にはイメージしづらいかもなんですが、僕の話で申し訳ないんですけど、僕はそうで、読んでる間だけ僕になってください。

僕を罵ってくれて一向に構わない

自分はアクセシビリティを当たり前にしたい側の製作者なんですが、じゃあどこまでを当たり前と考えるのかというと人によってかなり差がありますよね。その境目もはっきりせず、グラデーションメッシュのようだと思います。すべからく WCAG 2.1 のシングルＡ準拠でしょって言う人もいれば、見えてる情報と同じものがスクリーンリーダーでアクセスできればいいと言う人もいる。さらに、案件とかプロジェクトごとに、コンテンツの特性から最低達成ラインが変動する人もいる。周辺同業者に聞いても３番目が一番多いと思う。

僕個人はキーボード操作できないウェブサイトがすごく嫌なので、作るときはフルキーボードアクセスを目指してやってます。キーボードでアクセスできるっていうのは、まぁ一番簡単な理解だと Tab キーでクリッカブル要素にフォーカスできるっていうところなんですけど、フォーカスできる要素っていうのはスクリーンリーダーでだいたいにおいて読み上げが可能なんですよね。で、キーボードでフォーカスできるものの中をリーダブルにしておけば、違う UA にもだいたいいい感じになる。

でもキーボードアクセスっていつでも必ず実装できるわけじゃなくて、タスク量とか納期とかでどうしても間に合わない部分なんですよね。なんでって、コストだからです。

フォーカスできる要素にするのは簡単なんですよ。要素が a か button か input 系になってればいいだけ。でもキーボードアクセスってそんな簡単な話ではなくて、例えばモーダルだと、ボタンクリックでアクティブにした後にフォーカス閉じ込めをしないと、おもてにはモーダルが出てるけど、Tab キーを押すとトグルボタンの後続の要素にフォーカスが順々に当たるだけで、モーダル内にアクセスしているとはならない場合が多いんですね。

focus-trap などの JS ライブラリがあるのでコストは結構下げられているとはいえ、視覚優位のマジョリティにおいては画面の他のところも作っていかないといけないので、本当は UI ごとに機能開発したいけど、画面ごとに作る方が見た目の進行度でベロシティが上なわけです。

ほかでどう使われるか全部精査するなど、１つの UI に掛りきりになると、制作が進んでないように見えてしまう。それではマズイのでキーボードの対応する時間が後になったりして、そのうちに修正や変更に追われたりして、対応がお粗末なままになってしまったりするわけです。

フルキーボードアクセスやりたいって言ってるのに後回しにすんなよって言われたら何も言えずに顔が無になるんですけど、求められているのはフルキーボードアクセスではなく主要ブラウザと名前を言ってはいけない Internet Explorer 11 で「表示し、マウス操作もしくはタッチ操作」できることなので、そっちを先に整えざるを得なくてあーもうこれ言い訳でしかないのが本当に嫌なんだけどホントにそうなのでそうなんです。

はい、そうです。僕はフルキーボードアクセスを目指してるけど、本当に全部対応できたことは全然ないです。できたことは今までで一度しかありません。それもティザーサイトです。要件が少ないやつでしかやれたことがないです。

あれだけ言っておいてそれかよって罵ってくれて構わないです。事実ですから。でもきっとほとんどの人がそうだと思います。やりきれてる人はそうそういないと思います。やることの大事さを知っていて、やり方をわかっているのに、全部をやりきれない。

立ち位置を変えれば違う僕になれるのではという幻想、もしくは逃避

クライアントとの関係性がそういう感じの案件が連続すると、チームっていいなぁと、サービス事業会社への羨望が高まります。

規模のあるチームだと同じレイヤーの仲間が 4,5 人とかになるじゃないですか。そうすると「僕の意見」ではなくて「チームの意見」にできるんですよね。コード品質を管理しているチームの意見になれる。チームの意見として、チームが担保する品質として「フルキーボードアクセス」を要件にできるチャンスがある。

悔しいけど数が力を持っていることは明らかじゃないですか。こういう時に「何を言っているか」ではなくて「誰が言っているか」になってしまうんだなぁと。エンジニアチームみんなが言ってたら聞いてくれるのかな、とか。それはそれで遠い気持ちになっちゃうんですけどね。

でもチームはチームで苦労がないわけがないですよね。やっぱり同じように、他の何かに優先度で負けることも頻発するでしょう。コンバージョン取れる施策に埋もれたりするでしょう。アクセシビリティ対応で上がるコンバージョンて、新機能のそれと同じような数字を期待しにくいですもんね。

そんな中で、この間あったサイボウズさんのUX Cafe: チームで取り組む！サイボウズのアクセシビリティなるイベントで、

ということがあって、チームで、サービス事業でこういう流れになったのはすごいなと思って、もっかい言うけどすごく勇気付けられたのでした。

ユーザーの使いやすさを向上させるとコンバージョン上がるという実感は、実装者以外にもそれなりに認識されていて、そこに「アクセシビリティ対応がそのままユーザビリティになる」というエビデンスを作れるのって、アクセシビリティやっていき界隈だと最強モードの流れじゃないですか。ほんといいなぁって思ったんですよね。

ただ、どんなサービスにもその流れが作れるものではないのがつらいところで。それができるんだとしたら、みんなもう当たり前にやってるはずですもんね。

僕の価値観てそんなに説明が必要なの？

自分でやればいいのか、チームでやればいいのか。どっちになってもミクロでは同じだし、マクロでは別の壁がある。だとしたらウェブアクセシビリティを実現するのにどうあがいても壁があるということになる。

いやまぁそういった壁がいろいろあり、その壁を壊すために説得（説明？解説？わからせ？）が必要なのはわかるんですよ。それはわかってるんですけど、なんだかなぁってなってしまうんですよね。

だって「使えない人」がいるのを「みんな使える」にするのに、なんで説明が必要なのってなりません？　逆に、使えない人がいるままでいいという説明が欲しいよボカァ。使えない人はユーザーじゃないっていうこと？？

根本的な違和感はこれなんだろうなって思う。これが価値観の相違ってやつですかね。

説明できないから腕力で魅せるって言ってもさ

解決手段の１つに、息を吐くようにリーダブルでアクセシブルなものを作れるようになる、いわゆる「実装腕力」っていうのがありますね。相手が求めている「見栄え：10」に対して、見栄えの割合そのままに「アクセシビリティ：10」も一緒にやっちゃう的な。

10 の数字は別にいくつでもいんだけど、つまりアクセシビリティ対応がオプション的な「負担」にならなければいいっていう話です。

でもこれって生存バイアスっぽくて、自分が言うのはわかるけど他人にはなかなか言えないよね。@masuP9 もそれはわかってるのにスライドにしたのは勇気が要ったろうなと思う。

じゃあ腕力をつけましょうとなると、だいたいは労働時間外の可処分時間を利用することになると思うんですけど、これがまたむずいんですよね。ちょっと前にツイッタランドで燃えた自己研鑽のやつです。

それもやっぱりなんかなー、て思いません？　仕事に必要なことがわかっているのに仕事としてやる予算とスケジュールを与えられていないって、なにそれってなる。

実案件の中でちょっとずつ仕込んでいく方法もありますね。技術的達成をグラデーションに分解して、「すぐできる」を増やしていく。僕は基本これです。でもそれもそうできる人ばかりじゃないですよね。案件ごとにできるできないもありますし。

やれる人間がやる以外にやっていくことはできない

憤りや歯がゆさはたくさんあるんですけど、一気に全部解決できないんで、変えていくしかないよなぁと。僕は最終的には「当たり前」にしたい。当たり前になるというからには、「ウェブコンテンツを作る」すなわち「アクセシブルなウェブコンテンツを作る」と言う意味になってほしいし、制作そのものがアクセシビリティを作っていると同義になるくらいにしたい。

このツイートの「コーディングの〜」とは「コードを書いている作業中の〜」という意味です。

そのためには、当事者性 という言葉を改めて推していこうと思います。

ここで僕が言う当事者性とは、アクセシビリティを当たり前にするのは、アクセシビリティを知っているあなた以外にいないという自覚です。

知っているなたが品質を担保する。あなたの後工程にどれほどの製作者が関わろうと、今あなたがやらなければなりません。これはコーディングする人だけじゃないです。社長も、執行役員も、プロダクトオーナーもマネージャーも、ディレクターもデザイナーもエンジニアもみんなです。他の誰かがやるのではなく、あなたがやるんです。

かつ、あなたじゃない誰かのためではなく、あなたのためにやってほしい。

あなたが感じやすいようにする。あなたが受け取りやすいようにする。あなたが使いやすいようにする。あなたが親しみやすいようにする。あなたが伝わりやすいようにする。あなたがキーボード操作できるようにする。あなたがスクリーンリーダーで読み上げられるようにする。あなたが、どんな職域の、どんなアビリティのあなたでも使えるようにする。だって、あなたもユーザーなんですから。

それって未来のあなたを救うことにもなるはずだと思うんですよね。未来のあなたっていうのは十年後、二十年後に老眼になったあなたではなくて、今夜事故で利き腕を失うかもしれないあなたです。今夜不運にも視力を奪われるかもしれないあなたです。明日のあなたを、今のあなたが助けることができるわけですよ。

アクセシビリティ対応が当たり前になったら、オプショナルなコストじゃなくて、必須のコストになれるんじゃないかなと思うんですよね。今よりお金も時間もかかるかもだけど、当たり前に必要なことなんだから、それでいいんじゃないのかなぁ。

今はまだ当たり前になっていないアクセシビリティ対応を当たり前にするのは、あなた以外にいないんですよ。それがウェブアクセシビリティを実現するために何度でも強く認識すべき考え方だと、僕は思います。

題して、アクセシビリティはあなたビリティ。

ご清聴ありがとうございました。みなさま良いお年をお迎えください。