見出し画像

アクセシビリティについて本気出して勉強してみた

こんにちは!プロダクトマネージャーのひまらつ(@himara2)です。

このnoteではアクセシビリティ初学者だった私がアクセシビリティについて調べ、学んだ内容を書いています。アクセシビリティが気になる方、これから学んでみたいと思っている方はぜひ読んでみてください!


序章:Webアクセシビリティとの出会い

以前は大企業のモバイルアプリエンジニアとして働き、現在は転職してスタートアップのプロダクトマネージャーをしています。モバイルからウェブへ身を移すなかで、新しく学んだ領域のひとつがWebアクセシビリティです。
ZennやQiitaでトレンドを追っていても、Xに流れてくるポストを見ても、社内のメンバーと会話していても、アクセシビリティという言葉は頻繁に登場しました。

モバイルアプリを開発していた頃はこれほどアクセシビリティの話題は出ていなかったと記憶しています。自分のアンテナが低かったせいもあるとは思いますが、おそらくWebはその自由度ゆえに各自がより意識してアクセシビリティを担保する必要があるのかと思います。iOSやAndroidはプラットフォーマーが開発のためのキットを提供していて、基本的にはそれを使うので自然とそれなりのアクセシビリティが担保されるのかと予想しています。

アクセシビリティは奥が深く、聞きかじった知識では太刀打ちできません。例えば新機能と既存機能のアクセシビリティ改善のどちらを優先して開発するべきでしょうか?サービスの価値をあげるためには新機能?しかしアクセシビリティを無視して進み続けることはWebの良さを失う結果になります。

これは本腰入れて勉強せねばと思い、社内の詳しいエンジニアに話を聞いたり文献を教えてもらったりして学び、自分なりに整理したのがこのnoteです。2年前の自分に贈るつもりで書いていきます。

アクセシビリティとは何か?

まずは言葉の定義です。アクセシビリティとは「それを使えるかどうか」の意味で、すべての人がそのサイトやサービスを利用できる状態を目指す言葉です。

似た言葉であるユーザビリティは「それを使う人にとって使いやすか」です。アクセシビリティはスタート地点に立つ人を増やす、ユーザービリティはゴールまで辿り着ける人を増やすという整理が自分には一番しっくり来ました。

アクセシビリティとユーザービリティの違いというタイトル。人が並んでいてゴールに向かっている図。ゴールに向かう方向の矢印に「ユーザービリティ(ゴールに到達できる)」と書かれており、ゴールと直角の方向に「アクセシビリティ(スタート地点に立てる)」と書かれている
アクセシビリティはスタート地点に立てるか、ユーザービリティはゴールに到達できるか

アクセシビリティは全員にとって使えるものを目指しますが、特にフォーカスされるのは高齢者や障害者、外国人など、従来のサービス設計では考慮が足りず不便を強いてきてしまった人たちです。その方々を取りこぼさないように作ることで「全員」がアクセス可能になります。Appleはインクルージョンという言葉を使っていますが、属性や能力で分断することなく、誰もがサービスを利用してエンパワーされる世界が目指すところです。

Webとアクセシビリティは相性が良い

アクセシビリティと書きつつも、このnoteで触れる内容のほとんどはWebアクセシビリティを指します。Webは情報を伝える媒体のひとつですが、Webはとてもアクセシビリティと相性が良いです。例えば新聞は紙に文字が印字された状態で配られます。一度印刷されると変更は効かず、小さい文字が読めなかったり視覚に障害があるとその時点でアクセス不可能です。

一方Webではブラウザの機能や支援技術を使い、文字を拡大したり音声で聴いたりすることができます。受け取り手が自分の特性にあわせてコンテンツを変形して受け取れる。Webの利点のひとつです。

Webとアクセシビリティは相性が良いというタイトル。左にWebページ、右に利用者がいて、その間の矢印のなかに「音声で聴く」「拡大する」「好きなデバイスで読む」と書かれている。吹き出しに「受け取り手がフォーマットを選べる」と書かれている
Webは受け取り手がフォーマットを選べる

このようにWebはそもそもアクセシブルですが、近年のWebはとても進化して複雑化しています。Webはマークアップの自由度も高いので、各人が好き勝手に実装してしまうと非常にアクセシビリティの低いものになってしまう。そこでアクセシビリティのガイドラインなどでその概念を浸透させ、誰もが使えるサービスを目指していきましょう、というのが近年の流れです。

アクセシビリティを学び始める

アクセシビリティのガイドラインには「JIS X 8341-3:2016」という規格があり、JIS規格のひとつになっています。A、AA、AAAの3つの適合レベルに分ける形で必要となる対応がまとめられていますが、個人的には初学者にはいきなり実践的すぎる印象を受けました。

まずは全体感や、アクセシビリティを無視すると何が起きるのかを理解したい。それを満たしてくれるのがデジタル庁の「ウェブアクセシビリティ導入ガイドブック」です。アクセシビリティ対応の必要性にはじまり、よくある間違いや改善策などが分かりやすく示されています。

デジタル庁のウェブアクセシビリティ導入ガイドブックのサンプル。サンプルの内容ではスクリーンリーダーで読み上げたときに意味が通じる順序になるように注意しようと書かれている。
デジタル庁が公開するウェブアクセシビリティ導入ガイドブック

デジタル庁のガイドブックを読んだあとは各社のアクセシビリティガイドラインを読みました。特に参考になったのはサイバーエージェントさんとfreeeさんのもので、どちらも実装的な観点で参考になりました。

アクセシビリティに優先度をつける

さて、当初の疑問「新機能と既存機能のアクセシビリティ改善はどっちを優先すべき?」に答えてみます。

まずは現実世界の話をします。過去に建てられた駅に後付けでエレベーターをつけようとすると費用と工数が大きくかかりますが、最初からエレベーター込みで設計すればそこまで費用は嵩まないそうです。最初に考慮されていない拡張をするのには高いコストがかかる。これはWebサービスの設計でも同じことがいえます。

例えばWebサービスを運用していて、まったく考慮できていなかった機能を後から追加するのは大変ですよね。後になって困らないように、サービス設計時にどんな拡張性を持たせておけば柔軟かを考えるはずです。アクセシビリティも同じです。

アクセシビリティを担保するための具体的なプラクティスは情報としてはあり、ひとつひとつの導入の難易度が特段高いわけではありません。どういう点に気をつけるべきなのか、どこのアクセシビリティが欠けがちなのかを事前に知っておき、最初から設計に組み込みましょう。規模が小さいうちに導入しておけば拡大はしやすく、問題が小さいうちに対処できます。新機能かアクセシビリティかではなく、新規サービスの場合は最初に設計に盛り込んでおいて両取りするを自分は選びます。

既存サービスの場合はどうするか?

すでにサービスが提供済みで、アクセシビリティが不足している場合はどうでしょうか。いきなり全部対応しようとせず、小さく始めて順次リリースしていくのが良いかと思っています。

巨大に出来上がったサービスに後からアクセシビリティを導入するのは時間がかかり、その期間ずっと他の開発ができないのは多くの組織で受け入れられないでしょう。まずはサービスのコア機能だけ対応する、キーボード操作で処理が完結できるように改善する。機能や属性別に小さく分け、通常の機能改善と同じようにリリースしていくのが良さそうです。

この場合は機能開発とアクセシビリティ改善で優先度をつけることになります。どういう判断をするかは人によってかなり異なりそうですが、自分としてはアクセシビリティ改善は優先度を高めにおいて良いと思っています。Webの登場でせっかくアクセスできるようになった情報を、私たちがまた分断させてしまうのは世界の進歩にブレーキをかけることになるので。ここらへんは個人の感覚が大きいです。

障害はグラデーション。でも一般化しすぎない

障害といっても一括りではなく、例えば視覚の障害でもまったく目が見えない状態からロービジョン、一時的に怪我をして片目しか見えないなど、様々な状況があります。あるラインで区切れるものではなくグラデーションのように分布しているので、障害者にとって使いやすく改善することは誰もが使いやすいサービスに繋がります。

例えばキーボードですべて操作できるようになると視覚障害者の方が使えるようになりますが、同時にマウスを使わず効率的に操作したい人にも役立ちます。出先でマウスを忘れてしまった場合にも便利かもしれません。画像に代替文字(alt)をつけておくと通信環境が悪くて画像を読み込めない環境でも記事を読み進められます。誰でも使える状態にすると、誰もが使いやすい状態にもなるのです。

一方で、この「他の人にも便益がある」を強調しすぎるのも危険です。韓国では美的な理由から点字ブロックの色が目立ちにくい灰色に変更され、視覚障害者にとって使いづらいものになってしまいました。テレビの手話つき放送も音が聴こえる人にとってはプラスな要素はないでしょう。「アクセシビリティは全員にとってプラス」としすぎるとこの辺りの判断を極端にしてしまいそうなので、「全員が便利になるものもあるが、それとは別で特定の属性の人にだけ刺さるものもある」くらいでバランスしていこうと思っています。

当事者に聞く

私たちは似ているもの同士がつながりやすい世界で生きているので、広い世界を知るには意識的に動かなければなりません。心がけたいのが「当事者に聞く」ことです。

以前職場に視覚障害をもつ同僚がいて、自分が書いた技術記事をレビューしてもらう機会がありました。その時のフィードバックで「画像にaltをつけてください」と言われました。画像にはaltをつけるべき、図表の場合はその説明をテキストで書くべきだ、というのは知識としてはあったのですが、この時初めて本当の意味で自分ごとになりました。それからは自分が書くnoteやZenn、Xのポストの画像にはすべてaltをつけるようにしてます。altがなくて困る人の声を実際に聴いた、というのが自分にとっては大きな出来事でした。

趣味で日記アプリを作っているのですが、最近iPadで手書きで日記を書ける機能をつくりました。ページ送りをスワイプでする仕様だったのですが、「そういえばスワイプが難しい人もいるよな・・」と思ってボタンでもページを切り替えられるようにしました。これは改善としては悪くないものですが、自分は実際にスワイプできなくて困ってる人を見たわけではありません。叙述したaltに比べると腹落ち感は低く、当事者に話を聞きたくなりました。

当事者に聞かないと考えが及ばないこともあります。たとえばエディタを作っていて、アクセシビリティを考慮して作ったつもりが試してもらうとまるで使えなかったりする。キーボードでの操作を滑らかに磨いていましたが、そもそもその改善の方向ではなく、慣れたテキストエディタを使ってマークダウンで書いてもらい、それをインポートする機能を作った方が良かったかもしれません。観点が足りてない状況では自分の狭い視野で深掘りすることになります。一人でも先に話を聞けば最適なルートが見つけられたかもしれません。

ちなみにその同僚が最近書いていたnoteがとてもよかったので紹介させてください。文体もさることながら生活のリアルが描写されていてとても興味深いです↓

本の紹介コーナー

アクセシビリティを学ぶうえで面白かった本を紹介します。

1. Webアプリケーションアクセシビリティ

実際のコードを例示しながらアクセシビリティのNGケース、改善方法を章ごとに説明。エンジニアはバイブルとして手元に一冊置いておいて良さそうです。また後半で触れられている様々な障害、組織での取り組み方、当事者を尋ねる方法なども他になくとても面白かったです。

ちなみにモバイルアプリ版が来月出るようです。みなさん買いましょう!

2. 目の見えない人は世界をどう見ているのか

目の見えない人の世界の見え方に触れられます。例えば富士山は見える人は二次元でイメージするが、視覚障害者は三次元で捉える。視覚でみることは対象を平面化して捉えることに近く、さらに触れてきたイラストのイメージでそれが増強されているとか。こういう風に物事を考えることはあまりなかったので面白かったです。「違いを無くそうとするのではなく、違いを活かしたり楽しんだりする知恵の方が大切である場合もあります」は覚えておきたい言葉。

3. サイボーグになる テクノロジーと障害, わたしたちの不完全さについて

障害当事者である2人が、自身の身体と技術について交互に書くエッセイ本。二人とも作家なので言語化が大変うまく、当事者のリアルに触れられます。技術が発展したら障害を克服できるみたいな、障害を欠けている状態とみなす見方について意見されており興味深かったです。

おわりに

Webアクセシビリティについて学び、考えたことを書いてみました(5,000字も書いてしまった)。アクセシビリティの世界は当初思っていたよりもさらに奥が深く、間違えているところもあるかもしれません。気になる箇所があれば優しく指摘してもらえるとうれしいです。

最後に、障害は人が持つものではなく「人と社会の間にあるもの」という考え方を支持します。社会は変えられるので、いろんな人がいろんな環境で使いやすいものを作れるよう精進していきます。



プロダクトマネージャーをやりながら学んだことを「PdM日記」と名付けて書いてます。よければ読んでみてください:)

X (Twitter): @himara2


いいなと思ったら応援しよう!

この記事が参加している募集