社内のみんなにアクセシビリティ
自分が観測している範囲でそう感じているところもあるかもしれませんが、デジタルプロダクトやサービスにおける情報アクセシビリティを高めていこう、というのが年々広がっていると感じています。
自分が設計・開発に関わるサービスではもちろん、SNS等でもなるべく画像に代替テキストをいれる等、100％ちゃんとやれている自信はないですが努力しているつもりです。
ところで、みなさんの職場で同僚との仕事上でのやりとり等ではどうでしょうか？ドキュメントの共有や、Slackなどのテキストコミュニケーション、あるいはZoomでの会議といった機会において意識できるアクセシビリティがあります。
この記事では普段ぼんやりと感じている「仕事場におけるアクセシビリティとして気をつけること」を挙げていってみます。
色だけで情報を区別しない
社内で共有するドキュメントで「赤字は重要」「色だけで分けられた円グラフ」といった表現をすることがあります。あるいはエクセルやスプレッドシートで「赤背景はNG、緑背景はOK」のようなルールを色だけで伝えている場合もあるでしょう。
もしこうした「色だけで」で伝えている情報があるとすれば、それを受け取れていない同僚がいるかもしれません。日本人では男性の20 人に1 人、女性では500 人に1 人の割合で、先天的な色覚異常の方がいると言われています。例えば先天性で割合が多い「P型2色覚」「D型2色覚」というタイプで赤と緑の区別が付きづらくなります。実際、僕の同僚には赤と緑の区別が付きづらいエンジニアがいます。
上記の例のように「〜の場合は、赤色背景」のようなガイドがあると、相対的に区別をつけることはできるかもしれないのですが、わかりやすいものではないのは明らかです。じゃあどうすればいいかというと、この色覚に対しては青色を使う、というのはあります。ですが、一方で青色が捉えづらい色覚もあるので、ちゃんと「色以外の区別をつける」という解決が良いでしょう。補足のテキスト、太字や下線などの装飾、色々方法はあります。
ここでは色覚異常の例をあげてはいますが、白黒での印刷のことを考えても、色だけに頼った表現を避けるほうが好ましいです。
参考: 1.4.1 色だけで伝えない - Ameba Accessibility Guidelines
派手に動くカスタム絵文字を利用しない
Slackのようなテキストチャットのツールを想定して説明します。Slackではカスタム絵文字で豊かな表現で投稿へのリアクションができます。静的な画像だけでなく、アニメーションgifによる動く画像も登録することができ、何かめでたいことへのリアクションや、印象的なお知らせのために散りばめられるのを見かけます。
しかし、Party Parrotのように派手で早く動き、点滅相当のアニメーションがあるものが画面にあると直視できない人もいます。
光過敏性発作という症状があり、過去にはアニメやテレビゲームなどで過度な点滅演出によって発作を引き起こした事件がありました。そのような発作・てんかんを引き起こすまでいかなくとも、過度な演出をしてしまうと、そういう症状がなくとも直視できないことが自分にもあります。そうすると発信された内容も見られないわけですから、伝えたいことがある発信者にとっても良いことではありません。
Slackではアクセシビリティのオプションで、画像や絵文字のアニメーションを停止させることはできますが、これは自己防衛としては重要な選択ですが、それを強いるのは良いとはいえません。メッセージを伝えるための賑やかさはあって良いものとはおもいますが、度が過ぎると最悪な結果を招くこともありえることは知っておいたほうが良いでしょう。
参考: 2.3.1 画面の点滅を防止する - Ameba Accessibility Guidelines
できる限り画像だけで完結させない
画像に関するアクセシビリティについては代替テキストを提供するのを利用するツールの機能にあわせてやれると良いのですが、単純に情報を共有するときに「画像だけ」で完結しないようにするという話です。
例えば、PDFやパワーポイントのスライドからの抜粋として、そのキャプチャを投げるだけで完結するようなコミュニケーションです。もちろん視覚的表現が重要な場合などは別ですが、原則テキスト情報として共有・残すほうが好ましいでしょう。
画像だと、テキストに比べると通信環境が悪いときの受信しづらさがありますし、テキストとして残らないためにワード検索してもその内容が見つからないということがよくあります。文字情報として送る画像は、あくまで補足的に使うのが理想ではないでしょうか。
喋ってるときのBGMには気をつける
Zoomなどのオンラインミーティングで社内の月例イベントなどをおこなうときに、シーンとしているよりはちょっとした賑やかしで音楽を流したいというときがあるかもしれません。僕も、オンラインでのワークショップ等では、もくもくと個人で発散する作業時間にはBGMを流すときがありますが、ここでは「喋っているときにBGMが流れている」状況を想像してください。
もしかしたらこの記事を見ている人で「雑音の中で話が聞き取れない」という人はいないでしょうか？単純に音が大きくて誰にとっても聞き取りづらいということではなくて、ガヤガヤしていたり音楽が流れていると喋っている人の声が聞こえづらいというものです。こうした症状は、聴覚情報処理障害 = APDに該当する場合もあります。
BGMを流す側は、その場や間をつくるためにやっていると思うので、それ自体には僕も悪いとは思いません。しかし、こうした症状は「聞き取れない自分が悪いのかな（自分だけかな）」と思いがちですし、まして良かれと思ってやってることに「音を止めてください」とも言いづらいものです。
最近ではZoomやDiscord等のオプションでノイズキャンセリングの機能があるし、Krispのような専用ツールもあるので、聞き手側の制御できる範囲もありますが、完全に除去できるとは限りません。
あるいは、Discordのように他の参加者の音量を制御できる機能があるのであれば、BGMを流すだけのアカウント（ユーザー、bot）を用意して、それを聞き手が調整できると良いかもしれません。
とはいえ、やはり聞き手側にそれを強いなければいけないので、使い所には気をつけたいところです。
あとはBGMではないですが、周りに人がいる環境でのオンラインミーティングは、本人が思っている以上に周りの声がノイズになるので、そのあたりも気をつけたいですね。
みんなにとってのアクセシビリティ
この記事では取り上げていないですが、普段のデザインで気をつけているような文字サイズや色のコントラストのような話も、色々なドキュメントや資料作りで気をつけたほうが良い点です。
冒頭に書いた通り、僕も努力しつつ出来ていないことや、もっと無自覚なこともありそうですが、隣の身近なひとにとっても「アクセスできる、アクセスしやすい」情報の扱い方をしていきたいですね。
追記: アニメーションを制御できるようにする
社内っていうかアレのソレでいうと、GitHubに貼るアニメーションgifとか動画を <details open> で囲むってのをやってますね。閉じられるように。
— ますぴー (@masuP9) September 27, 2021
カスタム絵文字の例では、閃光相当の点滅するようなアニメーションをする絵文字の例を挙げましたが、ゆっくり動くアニメーションであってもそれが気になって本文に注視できない人もいます。
Twitterでますぴーさんが挙げてくれていましたが、例えばGitHubのMarkdownではdetails要素が使えるので、それを利用して「閉じられるようにする」という方法があります。
あるいはGitHubの場合だと、アニメーションgifではなく動画（.mp4, .mov）が添付できます。自動再生はされませんし、補足説明をする内容によっては動画のほうがシークバーでの操作などもできるので、ユーザビリティとしても良いかもしれません。
参考: 2.2.2 動く、自動更新するコンテンツに配慮する - Ameba Accessibility Guidelines
明日の元気の素になります。