こんにちは。フロントエンドエンジニアの松岡です。

この記事では、Webアクセシビリティ向上をスタートするためにカルテット開発部で行った取り組みについて紹介させていただきたいと思います。

Webアクセシビリティ

私が「Webアクセシビリティ」を認識したのは、フロントエンド界隈でアクセシビリティについての注目度が上がり、時おりブログなどでこの言葉を見かけるようになってからです。

歴史に目を向けると、Webの技術の標準を定めているW3Cが20年以上前から WCAG（Web Content Accessibility Guidelines） を公開しています。

当初は障害のある人がWebを使えるようにしましょうねという目的だったものが、昨今では人種やデバイス環境なども含めた幅広いニーズに対するインクルーシブなWebサイト作り、という広がりを見せているようです。

知識ゼロからのスタート

WCAGのドキュメントには知覚可能・操作可能・理解可能・堅牢の 原則 があり、それぞれの原則ごとの ガイドライン が設けられています。そしてガイドラインには A AA AAA の 達成基準 があります。ガイドラインは数多くあり、一番緩い A だけに注目してみても、かなり頑張らないと実現できないボリュームです。

カルテットコミュニケーションズでは、リスティング広告のレポート作成・予算管理の自動化ツール「 Lisket 」やGoogleアナリティクス自動レポート化ツール「 無限GAレポートメーカー 」をはじめ、いくつかのプロダクトを制作・公開しています。これらのプロダクトのアクセシビリティを一斉に底上げするには相当なリソースを費やす事になりそうです。

アクセシビリティ向上に取り組んでいく上で難しさを感じたのが「どんなユーザーが使いづらさを感じているのか」を可視化できない点でした。年齢や性別のような属性はアクセス解析ツールを使って推測できますが、テキストの読みづらさやボタンの押しづらさといった体感的なものは数値化する事ができません。

さらには「アクセシビリティについて言葉だけは知っている」「具体的な実践方法を少し知っている」などエンジニアにより知識のばらつきがあり、何をどうしていくのかハンドリングできる人材がいないのも悩みの種でした。

社内勉強会の開催

まず始めに取り組んだのは、認識と知識のばらつきを統一するための社内勉強会です。

Webアクセシビリティ | 社内勉強会資料

この勉強会では下記のような事について認識合わせをしました。

  • WCAGとは何か
  • どんな表現がアクセシビリティに反しているのか
  • WAI-ARIAとは何か
  • どんなケースでアクセシビリティが不足しがちなのか

かくいう私もアクセシビリティ向上を実践した事のない初心者です。事前知識として Webアクセシビリティ Advent Calendar 2020 などを読ませていただき、出てくる用語を片っ端からネットで検索して、アクセシビリティってこういう事じゃないかという持論を展開した勉強会でした。

任意参加を呼びかけての勉強会でしたが、びっくりしたのが開発部のメンバーほぼ全員が参加した事です。どちらかというとユーザーとの対話が多いフロントエンド領域の関心事かなと思っていたのですが、エンジニアとして、また人として、興味感心の高いワードなんだなと改めて認識できた機会となりました。

自分たちに今できる事

これからアクセシビリティ向上に取り組んでいく私達が最初から完璧なWCAG準拠を目指すのはとても難しい事です。また、達成基準クリアをゴールとするのか、スクリーンリーダーを各種取り揃えないといけないのか、WAI-ARIAの属性はどう書くのが正解か、書いたコードをどうやってチェックするのか、などなど問題は山積みです。

そこで私達が決めた最初のステップは「自分たちに今できるミニマムなスタートを切る」事です。「しなければいけない」ではなく「何ができるのか」を考える事にしました。

チームガイドラインの策定

勉強会の次に取り組んだのは、フロントエンドを担当するチームでのガイドラインの策定です。

外部公開はしていませんので、一部抜粋したものを紹介させていただきます。

ガイドライン

まず私達が記憶できるボリュームかつ日常的に実践可能なものをピックアップして、できる事（ルール）を取りまとめました。ドキュメントの置き場所はGitHub上のマークダウンファイルです。その後、チームのメンバーにレビューをしてもらい Must（しなければいけない） Should（することが望ましい） Optional（しても良い） の３段階の必須レベルを割り振りました。

ガイドラインのルール

それぞれのルールは、目的・テスト方法・良いコード例・悪いコード例・WCAGの参考リンクといった項目を記載した個々のドキュメントになっています。色に関する表現などはコードだけでは結果が推測しづらいので Stackblitz でサンプルコードを書き、プレビュー画面を見られるようURLを記載しました。

取りまとめたチームガイドラインの適用範囲は、今後作っていくプロダクト、または既存のプロダクトで修正を入れる部分です。チェックツールは開発環境で手軽に利用できるGoogle ChromeのエクステンションやmacOS搭載のVoiceOverを使う事にしました。

チームガイドラインのフォーマットは、Amebaさんの Ameba Accessibility Guidelines を参考にさせていただきました。

その後の反応

勉強会とチームガイドラインの策定を経て変わったのは、個々のエンジニアの意識です。「プロダクトに関わるこのサイトも対象ですよね？」「こういうコードを書いたんですがアクセシビリティ的にどうでしょう？」など自然発生的に問いかけが出てくるようになりました。

ゼロからのスタートなので、もちろん誰も正解を持ち合わせていません。都度ネット検索したり、VoiceOverを起動して画面確認したり、アナログなチェック作業を繰り返しています。

取り組み前は、アクセシビリティという言葉の存在は知っているもののネット上の膨大な情報量に圧倒されてどこから手をつけていいのか分からないというのが正直な気持ちでしたが、チーム全員でやろう！と決めた事で小さな一歩を踏み出せた実感があります。

まとめ

記事執筆とちょうど同じタイミングで、弊社で使用しているフロントエンドのフレームワークAngularの新しいブログ記事が公開されました。

Build more accessible Angular apps

Webアクセシビリティが昨今のフロントエンドのトレンドとはいえ、なんともタイムリーなブログ公開に不思議な縁を感じました 😃

私達のアクセシビリティ向上への取り組みはまだまだスタートしたばかりです。いつの日か、アクセシビリティに配慮したコードを当たり前のように書き、是非についてディスカッションできるよう知識を付けていきたいと思っています。そしてそれらがユーザーのみなさまに体験として届けられる日を、私達自身も楽しみにしています。