ヴェルク - IT起業の記録

受託開発と自社サービスの両立への取り組み

トップ > board（SaaS）のアクセシビリティー改善の取り組みの現在地（2022年10月）

board（SaaS）のアクセシビリティー改善の取り組みの現在地（2022年10月）

boardという見積書・請求書等の作成を中心とした業務管理のSaaSのアクセシビリティー改善に取り組んでいるので、その内容や現在の状況について書きたいと思います。

これまでの取り組みの流れ

2021年11月に「Webアクセシビリティー向上のための取り組みについて」というアナウンスを出しましたが、2021年夏ごろから準備をスタートし、2022年からアクセシビリティー改善に関するデプロイを継続的に行っています。

boardではこれ以前の2019年に、色覚特性を考慮した配色にするカラーユニバーサルデザイン（CUD）の取り組みを行っています。NPO法人「カラーユニバーサルデザイン機構（CUDO）」に検証を依頼し、同機構が発行するカラーユニバーサルデザイン（CUD）認証を取得していました。

tamukai.blog.velc.jp

今回の取り組みは、WCAG（Web Content Accessibility Guidelines）に沿った改善を行っていくというものです。

取り組みの体制

とはいえ、社内にアクセシビリティーの知見があるメンバーはいませんでした。

カラーユニバーサルデザインのときは、CUDOさんに支援していただいていたので、今回も同様に、外部の専門家に支援してもらいながら進めていきたいということで、ディーゼロさんにお願いすることにしました。

ディーゼロさんにお願いすることになったきっかけは、たまたま見ていたアクセシビリティーのオンラインイベントにゆうてんさんが登壇しており、「あ、受託の会社でアクセシビリティーをやっている会社があるんだ」というのを知り、登壇直後にTwitterでDMしたという流れでした。

まずは社内でのアクセシビリティーの理解度を上げていく必要がありますので、Slackでちょっとしたことを質問できるよう、アドバイザー契約をお願いするところからスタートしました。

アクセシビリティーに関する質問だけでなく、どのように進めていくかなどを含めて相談に乗ってもらいました。

取り組み開始時点での自分の理解度

改善の取り組みをスタートした時点での自分のアクセシビリティーに関する知識・理解度は以下のような感じでした。

アクセシビリティーの知識をインプットするため、以下を一通り読みました。

また、Axe DevToolsを使ってみたり、freeeさんが公開しているアクセシビリティーチェックリストを元に、いくつかの画面をチェックしてみて、「全然ダメだな」という雰囲気を理解した状況でした。

アクセシビリティー改善の取り組みの中ではWCAGのサイトを基本としていくことになるのですが、最初からこのサイトはちょっとハードルが高いので、前述の本やfreeeさんのガイドラインはとても助かりました。

ちなみにfreeeさんのガイドラインのサイトでは、「参考情報」というセクションがあり、個人的にこのセクションが結構好きで、スクリーンリーダーの設定などの記事もあり、かなり助かりました。

アクセシビリティーチェック

「Slackでの相談」というアドバイザー契約から始めて、ある程度こちらが話を理解できるようになってきた頃に、ディーゼロさんにboardのアクセシビリティーチェックをお願いしました。

boardは100画面以上あるので、それを一気にチェックしていくことは現実的ではありません。ただ、業務システムの場合、同じようなUIが多くあるので、まずは主要5画面に限定してチェックを行い、そこで見つけた問題を改善していくという進め方になりました。

ちなみにディーゼロさん曰く、「経験的に、それで8割ほどのパターンはカバーできるはず」とのことだったのですが、実際にやってみて、たしかにそうでした。

対象の5画面をチェックをし、見つかった課題をリストアップしてもらった結果、全部で約160件ほどありました。深刻度が「重大」「軽度」「参考程度」に分かれており、今回は「重大」「軽度」に絞って対応していきました。

たとえば以下のように、対応難易度は様々でした。

  • aria属性などHTML自体の修正
  • モーダルやツールチップなどのライブラリーを、アクセシビリティー対応のものに置き換え
  • ドラッグ&ドロップなど、マウス前提の操作のキーボード操作対応
  • などなど

継続的に少しずつ改善していく

量が多いですし、これだけをやっているわけにもいかないので、継続的に少しずつやっていきます。

boardでは、ほぼ週1ペースでデプロイをしているので、その中で、何かしら必ずアクセシビリティー改善のものを入れていくようにしました。

アクセシビリティーチェックは2021年10月末ごろに完了し、2022年頭から本格的に改善に着手しました。

社内の体制としては、エンジニア1人が5ヶ月間ほど、アクセシビリティー改善をメインで担当しました。理解度を深めるためにも、ある程度集中してアクセシビリティー改善の対応をやってもらいました。

合わせて僕も、他の開発はしつつ、対応が難しいものを考えたり、毎週小ネタの改善を対応したりしていました。

チェック対象は5画面でしたが、たとえばモーダルやツールチップなど、共通のUIになっている部分は、同時に全画面に展開していきました。

ある程度大きい課題は片付き、あとは粛々とやっていくだけになってからは、担当していたエンジニアも別の開発をメインにしつつ、週1日程度、アクセシビリティーに割くという割合で進めました。

という感じで進めていき、チェック結果の重大・軽度の140件ほどを約7ヶ月で対応完了しました。

対応を保留にしたもの

チェック結果の大半は対応したのですが、いくつか対応を保留・後回しにしているものはあります。

そのうちの1つが、色のコントラスト比です。

大まかに書きますが、文字の場合は4.5:1、アイコンの場合は3:1というコントラスト比の基準があります。

boardは前述の通り、カラーユニバーサルデザインに対応しているのですが、CUDとコントラスト比の両立が非常に難しく、本当に苦労しました。

典型的な例では、赤が黒に見えてしまい黒との識別ができないため、CUDでは赤にオレンジを入れた赤橙を使うことが多いのですが、オレンジが入ると、コントラスト比の4.5:1を満たせなくなってしまいます。
赤は注意書き等の警告色で使われるため、これが識別できることはとても重要なポイントですので、コントラスト比を優先してCUD視点で識別がしにくくなってしまっては本末転倒です。

また、CUDの対応では、識別できる色の種類が少ないため、濃淡で違いを識別できるようにする事が多いような印象で（これは個人的な印象なので、実際にはそういうわけではないかもしれないです）、そうすると、淡い色の多くがコントラスト比不足になってしまいます。

色々と試行錯誤し、色覚特性のシミュレーターを使って識別できつつコントラスト比を満たせる色を探したのですが、やはりシミュレーターと実際の見え方ではそれなりに差があるため、CUDOさんのチェックは通りませんでした。

それを受けて、CUDOの担当の方とお話をする中で、コントラスト比の計算ロジックの正確性に関する話になりました。

これに関して色々と議論があることは認識しているのですが、個人的には「基準として規定されているのだからそれに沿って対応しておき、今後、より改善された基準になったらそれに対応すれば良い」という考えで取り組んでいました。
＊コントラスト比に関する議論については、ここでは詳しく書かないので興味がある方は検索してみてください。

ただ、現在策定中の新しい基準（APCA）だと、前述のCUD用の赤橙もクリアするらしく、「現行の基準の正確性に議論がある中で、それに合わせるために、すでに対応済みのCUDに悪影響が出たら意味がない」という考えに至り、コントラスト比については一旦対応を保留にしました。

もちろん、コントラスト比が低いと見にくいことには変わりないですので、全面的に保留にするというよりは、CUDに影響がないような、たとえば「グレーの文字が薄い」などは改善するようにしました。

新しい基準が正式バージョンになるのはまだまだ先になりそうですし、現在の基準でまったく無意味なわけではないので、対応できるものはした方が良いと思いますが、そういう背景もあるので、無理があるところは一旦保留にしつつ、他の改善を進めていく方が良いのかなという気がしています。

現在と今後の取り組み

7月末までに、対象5画面の修正と再チェックが終わり、8月以降、それらを他の画面に展開していっています。100画面以上あるのでなかなか大変ですが、毎週のデプロイの中に必ずアクセシビリティー改善を入れて、地道に進めていっています。

来年、あらためてディーゼロさんに他の画面のアクセシビリティーチェックをお願いすることになっているので、年内にある程度対応を完了できるように進めています。

ここまで完了すると、「スクリーンリーダーで致命的に使えない」みたいな状況はだいぶなくなるんじゃないかなと思います。