はじめに
この記事は Uzabase Advent Calendar 2025 の 15 日目の記事です。
これはなに？
エンジニア組織のアクセシビリティ力を底上げするべく開発している playa11y というライブラリについて紹介する記事になります。
ちょっと背景
弊社ユーザベースでは Gauge というテスティングフレームワークを使ってE2Eテストを記述しています。テストシナリオを自然言語で書けるようにするため、ブラウザを操作するコード（ステップ）を分離して実装するのが特徴です。Ruby や Rails に馴染みのある方であれば Cucumber が似た開発体験を持つフレームワークとして挙げられます。
Uzabase Advent Calendar 2025 の10日目、nikkieさんのユーザベースの playtest2 が CI で examples を実行できるヒミツ 〜Python ポートでの再現を添えて〜でも紹介されている通り、弊社ではGauge用のライブラリ playtest2 を公開しており、Gaugeで行うConsumer-Driven Contract (CDC) Testing をサポートする play-cdc もあります。
私は数年前からWebアプリケーションにおけるアクセシビリティに興味を持って自社プロダクトへの適用を続けてきましたが、大量に存在する既存の画面、日々開発される機能に個人で立ち向かうのは到底不可能なボリュームです。一方でエンジニアにとって日々の開発の中でアクセシビリティに意識を向けるというのは、ある意味では開発組織のカルチャーのようにも思えます。
前置きが長くなりましたが、アジャイル開発を組織カルチャーとして日々の開発でE2Eテストを書いている私たちにとっては、E2Eテストを書くことでプロダクトのアクセシビリティが自然と向上すると理想的なんじゃないか？と考えたのが発端になります。
なにができるの？
playa11yをひとことで言うなら「ロールベースのSelenide用ロケーター拡張ライブラリ」になります。ロケーター、つまりWebページから様々な手段でDOM要素を特定する機能です。
Selenide標準の機能で検索ボタンをクリックするには、例えば以下のように書けます。
`$$`(".button").find(exactText("検索")).click()
playa11yを使うことで以下のようにWAI-ARIA ロールを使って要素を取得できます。
Locator.getByRoleFirst(Role.Button, "検索").click()
なにが養成ギプスなのか？
ここまで読んだだけだとDOM要素を特定するためのコードの書き方が変わっただけで、なにが嬉しいのかという疑問が湧くと思います。そこでエンジニアなら誰でも一度はやってしまうアクセシビリティ上のよくある失敗例で説明します。
例えばボタンを押したらカウンターの数字がカウントアップする機能を考えます。機能的には非常に簡単ではありますが、こういったコマンドボタンの実装でアクセシビリティを意識せずに、div要素にonClickハンドラを指定して実装されるケースがあります。私はこれを「div要素onClick問題」と呼んでいます。
<div class="button" onClick="countUp()">カウントアップ</div>
このような実装に対してGaugeでE2Eテストを書く場合、Selenideでは以下のようにdiv要素実装のボタンを取得することになります（先ほどの検索ボタンの取得と同じです）。
`$$`(".button").find(exactText("カウントアップ")).click()
一方でplaya11yを使った場合はどうなるでしょうか？ なんと取得できません！
Locator.getByRoleFirst(Role.Button, "カウントアップ").click() // エラー！
前述のとおりplaya11yではWAI-ARIA ロールを使って取得します。今回の例であれば Button ロール を指定していて、サンプルコードのdiv要素は明示的にも暗黙的にも Button ロールを持っていません。その結果として取得できずエラーとなります。
playa11yで要素を取得できない、となるとさすがに実装がよくなかったと気づいて、本来使うべき要素であるbuttonやinputに置き換えるはずです。
慣れてくると取得できずにエラーとなる前に適切な要素を意識するようになり、自然とアクセシビリティの高い実装が身につきます。
最後に
playa11yは試験的にリリースしており、一応使える状態にはなっています。ただ、対応しているロールがまだ多くないことと、ネストしたWeb Componentsに対応していないため、社内でもまだ広くは適用できていません。
ネストしたWeb Componentsへの対応に苦戦していましたが、直近で光が見えてきたためもうひと踏ん張り頑張ろうというフェーズです。
以上、ライブラリでアクセシビリティ向上のためのカルチャーを醸成してみようという試みのご紹介でした。こういったアプローチの取り組みが参考になれば幸いです。