開発チームとともにアクセシビリティ向上を推進するには SmartHRが具体的な取り組みを紹介

開発チームとともにアクセシビリティ向上を推進するには SmartHRが具体的な取り組みを紹介
  • このエントリーをはてなブックマークに追加

 株式会社SmartHRで、SmartHRのプロダクトを誰もが使えるようにすることをミッションとしたデザイン組織「プログレッシブデザイングループ」、通称「プログレ」が、今まで培ってきた知見をもとに、デザインを活用したアクセシビリティ向上の取り組みを解説します。第3回は「アクセシビリティ向上を進める開発チームとの取り組み」についてです。

 はじめまして。SmartHRのプログレッシブデザイングループ アクセシビリティスペシャリストの坂巻です。本連載の初回ではSmartHR UIを、第2回ではデザインシステムを活用したアクセシビリティ向上について紹介しました。今回は、SmartHR UIやデザインシステムを活用しアクセシビリティ向上を進める開発チームとの取り組みを紹介します。

アクセシビリティに向き合う開発者の集い「アクセシビリティマスター養成講座」

 SmartHRには、私を含め現在3名のアクセシビリティスペシャリストが在籍しています。アクセシビリティ向上・推進はスペシャリストの役割である一方、私たちのみがアクセシビリティの専門知識を持っているだけでは、開発組織にアクセシビリティの意識が十分に浸透することは難しく、組織が成長するにつれて品質の確保が難しくなります。私たちはこの課題に対処するために、各開発チームのアクセシビリティ向上におけるリーダーを育てる取り組みを実施しています。それがアクセシビリティマスター養成講座です。

 養成講座という名称から、アクセシビリティ向上に必要な知識を得るための講義のようなものを想像されるかもしれませんが、講義形式のプログラムは実施していません。この講座は、実践を重ね、アクセシビリティへの理解を深めようとするメンバーが集まる活動組織として機能しています。アクセシブルな実装や支援技術の利用など、専門性の高い知識が必要な場面ではアクセシビリティスペシャリストが支援を行いますが、基本的には開発メンバーが主体となり活動しています。

 現在は、8つの開発チームから約13名のプロダクトエンジニアとプロダクトデザイナーが講座へ参加しています。全参加者に共通する活動として、週に1度オンラインで集まり、活動内容を報告する共有会があります。共有会では、活動中に発見したプロダクトにおけるアクセシビリティ観点での課題について、参加者同士で議論します。また、JIS X 8341-3:2016の統一規格であるWeb Content Accessibility Guidelines(WCAG)の達成基準やユーザー特性の観点から、アクセシビリティスペシャリストが課題を深掘りすることもあります。そして共有会での議論や検討をもとに、参加者はアクセシビリティを低下させる課題の改善に取り組んでいます。

 このようにアクセシビリティマスター養成講座の参加者たちが、SmartHRのプロダクトにおけるアクセシビリティ向上をリードする役割を担っています。

それぞれのペースで、アクセシビリティを向上する

 開発組織でアクセシビリティ向上に取り組む際、「ほかのタスクに比べて優先度が上がらず、アクセシビリティ向上に取り組む作業時間が確保できない」という課題が起こりがちです。

 SmartHRでも同様の課題を抱えることがあります。当社ではそうした場面に対し、アクセシビリティ向上に高い意識を持つ講座の参加者が中心となり、チームの状況に合った働きかけを行っています。ここからは、時間を確保しにくい状況でも、それぞれのペースでアクセシビリティ向上を推進するための具体的な取り組みを紹介します。

仕組みを利用して、アクセシビリティ品質を高める

 アクセシビリティ向上に取り組む時間が取りづらい場合でも、既存の仕組みを利用すれば効率的に改善を進めることができます。本連載の第1回第2回では、SmartHRのアクセシビリティ品質を担保する仕組みとして、SmartHR UIとSmartHR Design Systemを紹介しました。いずれもアクセシブルなプロダクトを開発するための基礎となるものです。

 このふたつを使用するだけでも高いアクセシビリティを実現できますが、当社ではアクセシビリティを最大限高めていくためのもうひとつの仕組みとして、eslintの独自ルールセット「eslint-plugin-smarthr」を活用しています。このプラグインに含まれるいくつかのルールセットは、アクセシビリティ上の問題となるコードを検出します。

 たとえば、href属性を持たないa要素を検出するa11y-anchor-has-href-attributeや、テキスト要素を持たないボタンやリンクを検出するa11y-clickable-element-has-textなどがあります。どれもアクセシブルなウェブアプリケーションをつくるための基本的なHTMLのルールですが、開発組織が拡大し続ければ、すべての開発者がHTMLの仕様を漏れなく理解してコードを書くことは難しくなるでしょう。

 このルールセットを適用すれば、時間をかけずにアクセシビリティ低下につながる問題を発見できます。実際にいくつかのチームでは、ルールセットを利用した問題の検出とエラーの解消からアクセシビリティ向上の取り組みを始めました。長く開発が続いている既存プロダクトでは、その基礎となるSmartHR UIやSmartHR Design Systemを適用することが難しい状況でも、このeslintのルールがアクセシビリティ品質を支えています。

※この続きは、会員の方のみお読みいただけます(登録無料)。