noteのアクセシビリティ向上 2024年まとめ
ぼくはUXエンジニアとして、noteでデザインシステムやアクセシビリティ向上に取り組んでいます。
noteでは2021年ころからアクセシビリティ向上プロジェクトが始まっていて、有志の集まりから始まったチームは、正規のプロジェクトとして推進するようになり、組織や開発のフェーズに並走して取り組みを変化させながら、さまざまなカイゼン活動を続けています。
これは昨年に引き続き、2024年の活動内容を振り返る記事です。
🎄この記事は note株式会社 Advent Calendar 2024 の14日目の記事です。
目標を決める
2024年は障害者差別解消法の改正がトピックとして話題に上ることが多く、いろいろなところで引用され意識されていました。
そのような情勢や雰囲気を感じながら、noteのミッションやバリューの視点にたった上で、品質にラインを引いて動いてみようと考えました。デジタル庁や各社のアクセシビリティ方針を参考にしつつ、WCAG AA一部準拠〜準拠を目指して、取り組んでいくことにしました。
また、いままではアクセシビリティ向上のプロジェクトメンバーで行っていた活動を、フロントエンドエンジニア全員で取り組める内容・体制にしました。これは関わるひとを横軸に増やすことで、リソース面だけではなく、それぞれのチームやプロジェクトに還元する目的があります。
取り組み
アクセシビリティ定期チェック会
活動の中心として、週に1度の定例を設け、アクセシビリティチェック会を企画しました。
これはまず、AA相当を達成するためのチェックシートを、目的のページや機能に対して、フロントエンドエンジニア全員で手分けして調査し、課題を洗い出します（30分）。
そして、出てきた課題を整理しつつ、どのように解決するか実装方針を決め、それぞれできそうなタスクを消化していく、もくもくタイムを取ります（30分）。
ある種、愚直で淡々としていますが、週の1時間を使って課題を見つけ出し、ひとつずつ解消していくというアプローチは、ちりつも効果でそれぞれのスキルもプロダクトの品質も向上していくのがしっかりと実感としてあり、充実したものになりました。
みんなで同期的で定期的に一緒に取り組むのは、一見非効率でだれてしまう感じもしますが、その場で相談・共有しながら集中できる時間を作るのは、かなり効率がよかったように思います。
また、こういうデバッグは初めてなメンバーもいたので、まずは周辺知識のドキュメントを作って解説したり、スクリーンリーダーの操作を共有したり、ブックマーク集を作ったり、オンボーディングを整えました。チェックシートの各項目ではAmeba Accessibility Guidelinesを引用しました。わかりやすいgood&badが参照できて、チェックとカイゼンのイメージが掴みやすいです。
チェック観点としてシートの項目だけでなく、ライティングやデザインの揺れなど、「こうした方が体験いいよね」という気づきも課題化して、視野をひろげて、プロダクトの体験を高める活動として進めていくことが自然とできています。
コンポーネントライブラリの品質管理
冒頭で述べましたが、ぼくはデザインシステムチームにも所属していて、主にコンポーネントライブラリを開発しています。そこでアクセシブルなコンポーネントを配れるように、いくつか意識して取り組んでいることをまとめます。
まず、コンポーネントのアーキテクチャは「スタイルと構造」「振る舞い」「状態」の3つに分けて設計しています。
「スタイルと構造」はTailwind CSSで描いたTSX、「振る舞い」はコンポーネントに期待するロジックとアクセシビリティのhooks、「状態」は主にコンポーネントローカルに閉じるuseStateのhooks、というように役割を分けます。
これにより、「振る舞い」のhooksにアクセシビリティの責務を寄せて、コンポーネントの構造から剥がすことになり、ヘッドレス的に利用側でアクセシビリティのみを参照できます。これらの構成はとくにadobeのspectrumを参考にしています。
また、コンポーネントの品質管理としては、
propsごとのstories定義
play functionでインタラクションテスト
stories資産を利用したテスト
keyboard操作のテスト
biome - commit hook
chromaticでのリグレッション管理
PRごとにstoriesをaxe-playwrightにかける
など、主にstorybookを軸にした品質チェックを行っています。
ちょっと小煩くなってしまいますが、開発時の警告やエラーの表示もコンポーネントに含めています。たとえば、labelもaria-labelもないフォームや、placeholderの使用を警告するなど、完全にブロックするわけではないですが、開発時に適切な使い方を気づけるようにしています。また、型でよくないpropsの組み合わせをブロックする場合もあります。
StorybookにはコンポーネントすべてにMDXでドキュメントを書き、それぞれにアクセシビリティ項目を設け、正しい使い方や発展した使い方などを説明していて、コンポーネントの使い方で迷った場合に、参照できるようにしています。
成果と実感
みんなの成長とモチベアップ
取り組み部分でも触れていますが、メンバー間でまちまちだったアクセシビリティに関する知識が深まりました。実装やコードレビューの段階でも意識が向上したという声や、新規のプロダクトでもはじめから意識して取り組みたいという声もあり、個人的にはこれまでアクセシビリティチームに閉じていたものが、おなじ視野や目線で取り組める仲間の増えた感覚がとても嬉しかったです。
また実際、当初参加していたメンバーとはベつに、 この取り組みを知って参加するようになってくれたメンバーがいたことで、地道に継続した活動で輪が広がっていくようすを感じられました。ここをさらに広げていきたい・いけそうかもという気持ちになりました。
よくあるパターンの理解
チェック会を進めていくにつれ、コンポーネントの使い方で出てくる不具合や、ライティングや色の使い方など、よくあるパターンを認識できました。ドキュメントや揺れをすべて吸収してしまうなど、穴を塞ぐ手立てさえあれば、一気に解消できるパターンに見つけ対応できました。
ただそのなかで、根本解決に時間を割くのがむつかしく、現在行なっているアーキテクチャ変更での解消に持ち越すパターンなどもあり、すぐに解決できないものもありました。
ライブラリの充実
コンポーネントライブラリを開発し始めて3年弱くらいが経って、内容と質が良くなってきたのもあり、ライブラリを使用して新しく作った画面に関しては、ほとんど問題点がないように実装できていました。また、チェック会のなかでフィードバックしてもらうことで、すぐにカイゼンするよう取り組めるタイミングを作れたのも良かったです。
アクセシビリティを意識して開発することは大切ですが、意識せず実装できることも大切だなと実感しました。
また、note.comのライブラリという立ち位置はもちろんですが、新規事業での利用シーンも出てきていて、開発生産性や品質の影響を広く打ち出せるようになってきたのも良かったことです。
褒めてもらえる環境
これはほんとにありがたいことなのですが、noteでは約4年間アクセシビリティ向上と向き合ってきた結果、今にいたるまでクリエイターからの反響を途切れることなくいただいていて、いつも大きなモチベーションになっています。
過去には支援を必要とされているいろいろな当事者の方にインタビューをする機会もあり、実際の声を聞いたり見たりする経験が、体験を開発するのにもっとも必要なことなんじゃないかなと感じることもありました。
ポジティブな声を裏切らないよう、教えていただける課題感の期待に応えていくよう、まだまだカイゼンできるポイントはたくさんあるので、これからも活動を続けていきたいです。
これから
来年やりたいこととしては、アクセシビリティ方針の策定を視野に入れつつ、アクセシビリティをあたりまえの品質としてプロダクト全体で取り組んでいける環境を作りたいと思っています。
そのため、今年はフロントエンドチームで注力してきましたが、各プロダクトチームのデザイナー・エンジニア・PdMなどに輪をひろげることを目的に、それぞれに興味を持ってもらえるようなワークショップや勉強会の企画を考えています。
また、ウェブだけでなくアプリの品質もチェックしてカイゼンしていける体制を作れるように、動いていきたいと思っています。まず、開発面ではデザイントークンの共有から始めようとしています。
最後に
noteではアクセシビリティについての記事をたくさん書いていただいていて、デザインチームのマガジンとしてまとめています。
たくさんの知見が集まっていて、すごく勉強になりますし、こういう発信がそれぞれ開発者のモチベーションになっている部分も大きいかなと思います。noteのアクセシビリティチームも発信を頑張っていくぞ、を来年の目標に追加しつつ、今年を締めていきましょう。
noteのミッションは、
だれもが創作をはじめ、続けられるようにする。
です。アクセシビリティ向上は欠かせない、つねに必要な要素です。この取り組みを推進してくれるメンバーも募集しています！だれもが創作ができる世界を一緒につくりあげていきましょう。