ウェブアクセシビリティ テストと自動化における挑戦と失敗

改正された障害者差別解消法の施行が迫りつつあり、企業にとってウェブアクセシビリティへの対応は急務といえる状況です。 また、アクセシビリティは法律だけの問題ではありません。Webサービスを展開している企業であれば、サービスを誰でも不自由なく使える状態にしていくためにも、アクセシビリティに向き合っていく必要があります。

今回は、アクセシビリティのテストと自動化における各企業の取り組み事例について、4名のパネリストにLT形式で発表していただきました。本記事では、テストの自動化やツール選定、普段の開発への組み込み方など参考になる情報が盛りだくさんだったトーク内容をご紹介します。

■パネリスト
安田 慎さん/@syasuda90
株式会社サイバーエージェント AmebaLIFE事業本部 開発局 フロントエンドエンジニア
2016年に中途でサイバーエージェントに入社。フロントエンド開発を担当する傍らアクセシビリティの向上を目指し日々精進しています。

小林 大輔さん/@sukoyakarizumu
サイボウズ株式会社 開発本部 デザインテクノロジスト
2012年、サイボウズ株式会社に新卒で入社。プログラマーとしてクラウドサービス「kintone」の実装に携わる。2014年よりアクセシビリティの啓発・改善活動を開始。アクセシブルなデザイン・実装の指導・社内ガイドラインの作成等を行う。現在はkintoneのデザインシステム構築に携わる。ウェブアクセシビリティ基盤委員会（WAIC） 作業部会1主査。

平尾 優典（ゆうてん）さん/@cloud10designs
株式会社ディーゼロ / サステナグロースチーム ウェブアクセシビリティ専門家・フロントエンドテックリード
株式会社Kaizen Platform/アクセシビリティスペシャリスト
アクセシビリティをベースに情報設計・広義のデザインから、実装、テスト、運用までのアドバイスやレビューを中心としたコンサルティングを行っている。また、社内では品質の管理やガイドラインの整備など「仕組み」による改善に取り組んでいる。HTMLリンター「markuplint」の開発者。HTMLのプロ。

odasho (Shohei Oda)さん/@odashoDotCom
mabl Inc. Quality Advocate / Product Marketing
国内SIerにてインフラやPaaS App開発まで幅広く経験。その後コミュニティ活動をきっかけにMicrosoftに入社し、EvangelistとしてAudience Marketingに従事。2022年10月にmablにJoinし、TestingやQAの啓蒙活動に取り組む。現在もDevRel Meetup in Tokyoを中心に複数のコミュニティを運営/支援。その他、書籍の執筆や大学講師等。 Most DevRel Committer 2020, TechFeed Expert for DevRel, iPhone絶対並んで買うおじさん (2011 - 2022), リングフィットアドベンチャーで激やせおじさん (-16kg/2M)

アクセシビリティのテスト・取り組みとデザインシステムを活用した浸透｜株式会社サイバーエージェント 安田 慎

本日は、Amebaにおけるウェブアクセシビリティの試験と改善、そして数年取り組んでいるデザインシステム周りについてお話しします。

サイバーエージェントでは2017年頃から全社的にアクセシビリティに取り組み始めました。Amebaではアクセシビリティのガイドラインの作成を行ったあと、アクセシビリティ試験はよりユーザーの多いページを対象として、範囲を絞る形をとりました。試験の対象範囲など細かい内容に関しては、 アクセシビリティについて というページに記載されています。

約3か月かけて試験を実施し、試験結果をGoogle のスプレッドシートにまとめました。多くの試験でツールを使用しましたが、どうしても人力で行う必要がある試験があり、それなりに時間がかかった印象です。

改善するための準備「issue化」

誰でも改善に着手できるようにしたかったので、すぐに改善に着手はせず、試験結果のissue化に取り掛かりました。毎週チームで時間をとってissueをGitHub上に作成していき、おおよそ179個のissueができあがりました。

issue化のポイントは、

・粒度は細かく、何が問題なのか分かるように
・どの適合レベルに該当しているのかが分かるように
・ラベルをつけて issueの絞り込みができるように

の3つです。あとは具体的な改善方法の検討や変更によるユーザーへの影響などにも気を配りました。

改善点が可視化されたことで、ひたすら改善を進めていくフェーズに突入しました。全員で取り組めるよう可視化したことで、副次的な効果としてAmeba に携わる新しい方へのGood First Issueとしても活用ができました。また、作業者はそれぞれメインのタスクを抱えているので、アクセシビリティの改善に期限や目標は設けず、無理せずコツコツと継続的にやっていくスタイルを取りました。3年以上かかってしまいましたが、アクセシビリティ達成基準の全項目レベルAを達成できました。

デザインシステムの活用

AmebaにはデザインシステムSpindleというものがあります。Spindleには原則の一つにアクセシビリティが組み込まれており、「Spindle 使っていれば アクセシブル」という言葉があるくらい浸透しています。

Webに関わっている方だったら一度は見たことがあるであろうPaginationというコンポーネント。このコンポーネントをアクセシブルにするために、私たちはチェックリストを活用しています。

使い方はいたってシンプルです。まずテンプレートをコピーした後に、もともとあるガイドラインの対応方針に対してこれから作るコンポーネントにどう適用するかを記載していきます。

たとえば、Paginationコンポーネントにはページを移動するためのアイコンが存在しています。 代替テキストがないアイコンの場合、ラベルを指定する必要があるため、 Paginationコンポーネントではチェックリストの達成基準1.1.1は必須です。

そういった一つひとつの項目を判断していくと、最終的にPaginationのチェックリストが完成します。Amebaでは一つひとつの部品をまずはアクセシブルにすることで、画面に組み込んだ際には、アクセシビリティが担保されているという状態を作っています。

継続的な改善ー無理せずコツコツ継続的に

最後に、アクセシビリティのテストと自動化に取り組む際のポイントをお伝えします。

アクセシビリティテストを一人でやるのは大変なので、チームで取り組みましょう。改善は無理せず継続的にコツコツと取り組みましょう。

そして、アクセシビリティは実装する前からある程度意識するのがおすすめです。

アクセシビリティ自動テストツールの導入と現状の取り組み｜サイボウズ株式会社 小林 大輔

今日は私が所属するkintone開発チームが自動テストツールを導入したときの課題についてお話しします。

最初はユニットテストツールとしてDeque Systems社 社のaxe-coreというツールを導入していました。しかし、いくつかの問題がありました。

一つ目は修正が間に合わないことです。当時は静的解析ツールを導入していなかったので、ユニットテストの実行が実装の途中や終盤になりがちでした。

次に修正方法がわからないことです。メンバーによってツールの習熟度が異なるため、「警告が出るがどんなふうに直したらいいかわかりません」などの問い合わせが増えていました。

三つ目は正しく利用されないことです。メンバーによって理解がまちまちで、網羅的にテストをかけている場合もあれば、テストの網羅性の低い場合もありました。

静的解析ツールの導入はチームで議論を

課題を踏まえて導入を検討したのが静的解析ツールでした。ユニットテストツールの時と同じ轍を踏んでしまうのを避けるために、ツールの導入方法について検討する場を設けたのです。プロダクトチームのほかに、アクセシビリティの専門家を集めて一つひとつのルールの必要性を吟味しました。

静的解析ツールを導入するときは、その効果をチームで議論することが大事です。ルールの必要性や、そのルールにどういう効果があるのかを開発メンバーと一緒に判断することがポイントです。

ユニットテストツール選定のポイント

ライブラリをReactに刷新していくリアーキテクトプロジェクトのさなか、ユニットテストツールの選定も行いました。

・ルールが柔軟にカスタマイズできる柔軟性
・チームで運用しているテスト環境との親和性
・動作の安定性

この3つの観点から選定した結果、jest-axeというツールを採用しました。これは国際的なアクセシビティガイドライン（WCAG）をサポートしていて、どのようなルールに適応するかを細かくオプションで指定できる柔軟性があり、今のテスト環境とも親和性が高かったのです。

現在はこの jest-axeをテストに活用しています。また jest-axe以外にもアクセシビリティの自動テストは充実させるようにしているところです。

アクセシビリティの問題を検出する前に予防したい

今までお話しした内容は、実装のフェーズでアクセシビリティの問題を検出して対応する取り組みでした。しかし、実際にはそれで十分とはいえません。現実では、実装のタイミングでアクセシビリティの問題を検出しても、回収が間に合わないことがあるからです。Deque Systems社の調査によると、アクセシビリティの問題の67％がデザイン時に起因しているとのことです。※1

なので私は、実装で問題を検出すると同時に、問題を早めに予防する仕組みが必要なのではと常々思っています。

たとえば自分のチームでは、

• デザイナーと一緒にデザイン・デザインレビューを行ってアクセシビリティの問題を早めに見つけておく
• HTMLのプロトタイプを実装前に作ってHTMLでのアクセシビリティの問題をそもそも発生させないようにしておく
• デザインシステムを活用してアクセシビリティがあらかじめ確保されたコンポーネントを再利用する

といった取り組みをしています。

問題を見つけて改修するというプロセスに頼るのではなく、そもそも問題を予防する、問題を発生させない方法を一緒に考えるのも大事なのではないでしょうか。

※1 Auditing Design Systems for Accessibility より

ウェブ制作会社におけるウェブアクセシビリティ テストと自動化への考え方｜株式会社ディーゼロ 平尾 優典(ゆうてん)

今日はWeb制作会社におけるウェブアクセシビリティテストと自動化に対する考え方についてお話しします。

できることを増やすために自動化を導入した

ウェブアクセシビリティは本当にやることが多いです。Webサイト制作の戦略から運用まで、すべてのフェーズでアクセシビリティについて考慮する必要があります。関わらないところはないです。

なかなかアクセシビリティを推進できないのはなぜか、と考えたとき、答えの一つとして「全部人の手でやろうとしているから」だと思い当たりました。アクセシビリティはやることが多いので、できることを増やすためには自動化を導入する必要があると考えています。

戦略などの考える部分を自動化するのは難しいですが、チェックであれば自動化できる部分が多いです。要件定義と情報設計の部分でWebサイトはコモディティ化しているので、抜け漏れをチェックするような仕組みを導入できるのではないでしょうか。

抜け漏れのチェックについては、仕組みによる解決が効果的です。たとえば、アクセシビリティのガイドライン（WCAG）の適合レベルはAなのか、AAなのか、まず決定しないと見積もりが作れない、というように意思決定のプロセスに仕組みを入れることができます。

「勝手にできてた」が理想

私の考える理想は、「アクセシビリティのことを考えなきゃ！」ではなく、いつも通りの制作フローでやっていたら「勝手にできてた」という状態です。実装の部分でもリンターやE2Eテストで仕組み化できることはあるでしょう。リリースや運用でもE2EテストやLighthouseなどで抜け漏れのチェックの仕組みは導入できます。

また、UIデザインのツールやCMSの機能などにAIを積極的に活用していくこともできそうです。

小林さんの話にもありましたが、結合テストのときなど後から問題に気づくより、手前の段階で問題に気づくほうが修正しやすいものです。私はTypeScriptが好きなのですが、TypeScriptはランタイムエラーではなく型エラーで問題に気づくことができます。手前で気づけるのは開発者体験としてとても重要だと思っています。

モチベやマインドセット「だけ」に頼らない

アクセシビリティを推進するにあたって、個人個人のマインドセットやモチベーションは重要です。しかし、それだけに頼ることはできません。チーム・組織で進める場合は、そこまで興味が強くない人でも勝手にアクセシビリティをやってもらえるような自動化の導入、ツールの活用が必要なのではないでしょうか。

私はこれからも、制作や開発のタスクを細かく分けて自動化できる部分を探していきたいと思っています。LLMやAIなどを惜しみなく活用して、よりアクセシビリティを向上させるような制作を目指したいです。

品質を制する者がCXを制す！ローコード/ノーコード非機能テストのインパクト｜mabl Inc. おだしょー

2022年10月にmablにジョインしました。プライベートではDevRel Meetup in Tokyoというコミュニティの運営をやっております。

mablはQAを支援するツールなどを提供している会社ですが、その中にアクセシビリティのテスト機能があります。今日はその話を中心に皆さんにお話ししてまいります。

品質向上とアクセシビリティの重要性

アクセシビリティも含めて、品質が高いプロダクトはご利用いただいているエンドユーザーに満足してもらえるので、結果的に顧客ロイヤルティが上がっていきます。

PwCの調査でも、「一度でも嫌な体験をしたら好きなブランドでも離れる」「ポジティブな経験のほうが広告よりもサービス選定に影響がある」と回答した人の割合が高かったです。サービスのクオリティを重視している企業ほど、顧客満足度が高い傾向があるといえるでしょう。

アクセシビリティで意識しなければならないのは、すべての人に平等に、公平にサービスを提供していくことです。世界中で何かしらの障害を持っている人は全人口の15％もいて、サービスをより多くの人に使ってもらうのに当然無視できない数字です。

またアメリカでは、アクセシビリティ周りでの訴訟件数が急激に増加しています。これは海を渡った遠くの国の話ではありません。日本でもアクセシビリティへの対応が義務化されることになり、我々も意識していかなければならない状況です。

アクセシビリティテストの難しさ

アクセシビリティテストに踏み込むまでに、やり方がわからない、どうやって周りを巻き込めばいいのかわからない、どうやって経営層を説得すればいいのかわからない、といった課題に直面します。

それから、本日何度か話にも出ていましたが、使っているツールがバラバラだとテストはなかなか進みません。本日の登壇者の皆様は、ツールを統一する、皆で話し合いをする、合意を取ってそれに沿って進める、という正しいやり方をされているなと感じました。

SSOT※をきちんと揃えないと、あれが正しいのかこれが正しいのか、どっちが正かわからなくなる事態が起こり得ます。

※Single Source of Truth：信頼できる唯一の情報源のこと

チームをうまく巻き込もう

ビジネスではステークホルダーがたくさん存在します。何かを変えようとするとき、ステークホルダーの中にはコードを書けない人も多いです。mablではそういった方でも簡単にテストが作れるサービスを提供しています。

アクセシビリティを含めた品質向上は担当者だけが取り組むのではなく、チームでやること、そしてチームをうまく巻き込むことが重要になってきます。mablのようなノーコード・ローコードツールを活用して、ステークホルダー内でなるべく会話のプロトコルを合わせ、同じものを見て会話できるようになると理想的ではないでしょうか。

今回ご紹介いただいたテスト自動化ツール “ mabl” についてはこちらから

アーカイブ動画も公開しております。詳細はこちらもご確認ください。