every Tech Blog

株式会社エブリーのTech Blogです。

トモニテのウェブアクセシビリティ向上に向けて

トモニテの ウェブアクセシビリティ向上に向けて

トモニテのウェブアクセシビリティ向上に向けて

この記事は every Tech Blog Advent Calendar 2024 の 3 日目の記事です。

はじめに

こんにちは!トモニテにて開発を行っている吉田です。 今回は最近私が少し気にするようにしている(今更?とは言わないでもらえると嬉しい...)ウェブアクセシビリティについて、所属しているトモニテを対象に記事にします。

そもそもアクセシビリティとは?

「アクセシビリティ」という言葉は、Access(近づく、アクセスするの意味)と Ability(能力、できることの意味)からできています。近づくことができる」「アクセスできる」という意味から派生して、「(製品やサービスを)利用できること、又はその到達度」という意味でも使われます。

Access + Ability -> Accessibility

ウェブアクセシビリティは、ウェブにおけるアクセシビリティのことです。利用者の障害などの有無やその度合い、年齢や利用環境にかかわらず、あらゆる人々がウェブサイトで提供されている情報やサービスを利用できること、またその到達度を意味します。

なぜウェブアクセシビリティを意識する必要があるのか

現代社会でウェブサイトは老若男女が利用する重要な情報収集源の 1 つとなっています。 しかし、ウェブアクセシビリティに配慮して作られていないと利用者によっては情報を得ることが難しくなってしまいます。 そんな状況を防ぐためにウェブサイトで提供している情報やサービスを誰もが利用できるようにウェブアクセシビリティを確保する必要があります。

ウェブアクセシビリティを確保できているとは

ウェブアクセシビリティを確保できているとは以下の状態を指します。

  • 目が見えなくても情報が伝わること・操作できること。
  • キーボードだけで操作できること。
  • 一部の色が区別できなくても得られる情報が欠けないこと。
  • 音声コンテンツや動画コンテンツで、音声が聞こえなくても話している内容が分かること。

3 ウェブアクセシビリティが確保できている状態とは?より

上記を満たしたウェブサイトであれば視覚障害のある人、聴覚障害のある人、色覚特性のある人など、ウェブサイトの閲覧にお困りの症状をお持ちのかたでもウェブサイトを介して情報を入手したり、サービスを利用できたりするようになります。

そこでエンジニアとしてウェブアクセシビリティにどう貢献できるか考えてみました。 私が考えたのは以下 2 点が開発業務において関わってくることではないかと考えました。

  • 目が見えなくても情報が伝わること・操作できること。
  • キーボードだけで操作できること。

(ここまではウェブアクセシビリティとは? 分かりやすくゼロから解説!を参考に記載)
https://www.gov-online.go.jp/useful/article/202310/2.html

記事では 1 つ目の「目が見えなくても情報が伝わること・操作できること」に焦点を当てます。

スクリーンリーダーを使ってトモニテ web をさわってみた

今回は目が見えない人やロービジョンの人を想定してスクリーンリーダーを使ってトモニテ web を使ってみました。 スクリーンリーダーに利用したのは Mac に標準搭載の VoiceOver です。

スクリーンリーダーを利用してみて気になったのが alt 属性の設定漏れです。

alt 属性は周知の通り<img>要素で指定された画像が読み込まれない場合に表示する予備(代替)テキストを指定します。 それだけでなく alt テキストはスクリーンリーダーや他の支援技術によって使用され、音読されたり、点字出力端末に送られたりコンテンツを十分に活用できるようサポートする役割があります。 mdn にも alt 属性の指定には以下のような記述がありました。

画像の alt 文字列を選ぶときは、ページ上に画像があることに触れずに、電話で誰かにページを読み聞かせるときのことを想像してみてください。

HTMLImageElement: alt プロパティより

では 実際に存在した alt 属性の設定漏れについてふれていきます。 こちらはトモニテのアプリストアへのリンク画像です。 スクリーンショット内、下部の四角い箱内のテキストは Voice Over で読み上げられるテキストです。 スクリーンリーダーで読み込んでみるとリンクが設定されているが画像だということはわかりますが画像についての説明がありません。 ユーザーからしてみればそこに何かはあるのに内容がないとなっているのは不自然で、しかしその領域をタップするとストアに遷移するという状況です。
トモニテのアプリストアへのリンク画像(編集前)
原因はシンプルで画像の alt が指定されていなかったことでした。

<img alt src='https://~~'

alt 属性を props に渡す形で修正しました
トモニテのアプリストアへのリンク画像(変更後)

どの画像に alt 属性の設定漏れがあるのか特定したいのですが、スクリーンリーダーを使って調べるには数が膨大ですし、コード上で検索をかけるにしても全ページを対象に調べるのは少し骨が折れそうです...

トモニテでは Next.js を利用しているのですが何か良い方法がないかと調べたところeslint-plugin-jsx-a11yパッケージが有効だということが分かりました。

eslint-plugin-jsx-a11y利用手順

eslint-plugin-jsx-a11y を利用するには前提として ESLint のインストールが必須になります。

# npm
npm install eslint --save-dev

# yarn
yarn add eslint --dev

eslint のインストールが完了したら eslint-plugin-jsx-a11y をインストールします。

# npm
npm install eslint-plugin-jsx-a11y --save-dev

# yarn
yarn add eslint-plugin-jsx-a11y --dev

インストールが完了したら.eslintrc.js の rules に'jsx-a11y/alt-text'を追加します。

'jsx-a11y/alt-text': error

「これで alt 設定漏れが検知できる!」とリンターを走らせてみたのですが何も検知できません...(alt が設定できていないコンポーネントがあるのは確認済)

ドキュメントをよく見ると以下の記載がありました。

By default, this rule checks for alternative text on the following elements: <img>, <area>, <input type="image">, and <object>.

jsx-a11y/alt-textより

そのため実装内に<img>要素が存在しない場合、検知できません。

そのため alt-text ルールにオプションを加えることにしました。

    'jsx-a11y/alt-text': [
      'error',{
      'img': ['componentA', 'componentB']
      }
    ],

これは img をラップしている componentA と componentB に Props として alt が渡っているか確認することができます。 改めてリンターを走らせると以下のようにエラーとして alt 属性の設定漏れを検知することができました!

/app/src/pages/example.js
  20:13  error  componentA elements must have an alt prop, either with meaningful text, or an empty string for decorative images  jsx-a11y/alt-text

まとめ

今回は alt 属性にのみ焦点を当てましたが、アクセシビリティを向上させるにはその他にも改善することはたくさんあります。 引き続きアクセシビリティを確保できるよう改善を進め、トモニテをよりたくさんの方に利用してもらえるサービスにしていきたいと思います!

参考資料

https://www.gov-online.go.jp/useful/article/202310/2.html

developer.mozilla.org

www.npmjs.com

github.com