この記事は コネヒトAdvent Calendar 2025、08日目の記事です。
コネヒトで働く人たちがお届けするアドベントカレンダーです。
コネヒトは「あなたの家族像が実現し続けられる社会へ」をビジョンに掲げ、「ママリ」などの家族向けプロダクトや事業を展開しています。
過去2年のアドベントカレンダー
こんにちは、コネヒトAndroidエンジニアの中島(id:nacatl)です。 今までAndroidに関する記事ばかり書いていた自分ですが、今回はちょっと違う分野としてアクセシビリティをテーマにした取り組みを紹介します。
背景
コネヒトはKDDIグループウェブアクセシビリティ方針に基づき、アクセシビリティの確保に取り組んでまいります。
というわけで、コネヒトでは会社としてアクセシビリティの確保に向けて活動を開始しています。 推進委員会的なメンバーが3名おり、その末席に自分がいるという形です。
しかし、一口にアクセシビリティと言ってもさまざまな項目があります。 今まで普段の作業の中で気にしていたメンバーも少なく、推進と言ってもどこから手をつければいいか五里霧中でした。
この記事では、どうやってメンバーにアクセシビリティを推進しているか、実際に行なった取り組みの一つである社内ワークショップの内容を紹介します。
基礎知識としてのアクセシビリティ
はじめに少し、予備知識としてアクセシビリティとは何かについて、自己解釈も含めて軽く触れておきます。 有識者の方は、この節は読み飛ばしていただいて構いません。
アクセシビリティとは
アクセシビリティはよくユーザビリティと比較されます。 どちらもユーザーフレンドリーにするという意味では同じですが、アプローチは真逆です。 その違いについて、筆者は下記の資料の8pにある表現が最もしっくり来ているので、ここで引用させていただきます。
ユーザビリティは山の頂点を高める活動
特定のユーザー（状況）に響く
アクセシビリティは山の裾野を広げる活動
幅広い層の人々にとって使える
アクセシブルなコンテンツ
言葉遊びのようですが、「アクセシビリティを確保する」とは、「コンテンツをアクセシブルにする」ことです。 ここでは「アクセシブルなコンテンツ」とは何かを軽く解説します。
ユーザーがコンテンツを利用する際には、時と場合によりさまざまな障壁が立ちはだかります。 ここでいう障壁とは、いわゆる障がい者の方々についてのものだけではありません。 高齢者や他言語利用者、怪我をしていたり手が塞がっていたりするシーン等の、一時的なものも含まれます。
- 身体的なもの
- 目が見えない
- 耳が聞こえない
- 老眼 / 遠視 / 色弱など
- 手指が使えない（怪我なども含む）
- 状況的なもの
- 乗り物が揺れて小さい文字が読めない
- 旅行先などで言葉が通じない / 文字が読めない
- デバイス的なもの
- タッチパネルじゃない（スマホアプリだと忘れがち）
- etc......
こういった状況下にあるすべての人に対して場所やシーンによらず、どのような状況でもサービスの価値を提供できる状態が、完璧な「アクセシブルなコンテンツ」と言えるでしょう。 （もちろん、完璧に対応するには相応の努力が必要になりますし、現実的にはかなり難しいと思います）
「アクセシビリティの確保を推進する」とは、「アクセシブルなコンテンツ」としての完成度を上げていく活動と言えます。
カーブカット効果
「アクセシブルなコンテンツ」になることで恩恵を受けるのは、障壁があるユーザーだけに限りません。
車椅子の移動のために歩道の縁石に簡素なスロープを作ったことにより、車椅子利用者だけでなくベビーカーや台車、スーツケースなどの利用にも恩恵がもたらされた現象があります。
このことから、裾野を広げることで一般的にも恩恵がある、という概念はカーブカット効果（Curb Cut Effect）と呼ばれています。
WCAG
Web Content Accessibility Guidelines の略で、 World Wide Web Consortium（W3C) の下部組織が打ち出している、Webコンテンツ用のアクセシビリティガイドラインです。
WCAGでは以下の4大原則が掲げられています。 ここでは紹介に留めますがより詳しいことが知りたければ、検索すればもっと詳しい記事が見つかると思いますので、そちらを参照していただければと思います。
- 知覚可能
情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
- 視覚 / 聴覚 / 色覚 など、それぞれ一つだけに依存した提示でないことが求められます。
- 操作可能
ユーザインタフェース コンポーネント及びナビゲーションは操作可能でなければならない。
- タッチパネルやマウスに依存せず、キーボードだけなどの入力デバイスでも操作ができることが求められます。
- 理解可能
情報及びユーザインタフェースの操作は理解可能でなければならない。
- 知覚したものに対して、例えば「それが何をするボタンであるのか」などを理解できる必要があります。
- 堅牢
コンテンツは、支援技術を含む様々なユーザエージェントが確実に解釈できるように十分に堅牢 (robust) でなければならない。
- 表示するブラウザや端末に左右されないことが求められます。
また、WCAGでは項目ごとに対応レベルが設定されており、以下のような定義となっています。
- A（最低レベル）
- AA
- AAA（最高レベル）
コネヒトでは執筆時の最新である WCAG 2.2 に基づき、AAレベル の項目までの対応を目標としています。
コネヒトでの取り組み -社内ワークショップ-
先にも述べたように、アクセシビリティ確保と言ってもまず何をすればいいのか、という段階から始まるのがほとんどかと思います。 正直な話、人間、ただ「やれ」と言われても普通は身が入りません。自分もそうです。 なぜ何をやるのか、やって何が良くなるのかを知り、納得を得ることが、当人のパフォーマンスを十全に発揮する近道だと自分は考えています。
ですので、まずは「なぜ必要なのか」「何をやるのか」を知ること、情報と知識の社内浸透が必要かと考えました。
コネヒトでは普段の仕事から少し離れた視点で考える取り組みとして、マンスリーでワークショップを開いています。
その場を借りてアクセシビリティに関するワークを全社員メンバーに行なってもらい、まずは触れてもらおう、知ってもらおうと考えました。
第1回「スクリーンリーダー体験会」
2025年02月、第1回を開催しました。
目的
目的は「今まで知らなかった世界のママリを知ってもらう」としました。 まず具体的な内容より前に、普段と違うものがあることを知ってもらう狙いです。
内容
内容は「スクリーンリーダーを用いてママリアプリを触ってみる」です。
Androidユーザーには TalkBack、iOSユーザーには VoiceOverをそれぞれオンにして、その状態でママリアプリを触ってもらいました。 自由にアプリを触ってもらい、使おうと思ってできなかった機能や、こうだったらわかりやすい / やりやすいと思ったことを書き出すまでをワークとしました。
工夫点
スクリーンリーダーはスマホの操作方法が完全に変わるため、動かし方がわからないなどのトラブルが多く起こることを想定しました。 そのため、対応策を事前に考え以下のような対策を取りました。
- 先に少数メンバーを集めて要望を聞く
- オフラインで開催し、推進委員会メンバーがトラブル対応のために待機する
- スクリーンリーダーの基本動作を先に説明、マニュアルも紙で作成して配る
結果 / 改善点
事前準備を厚めにしたことで、基本的には大きなトラブルはなく終えられました。 ほとんどのメンバーが初めて触れたこともあり、知らない世界に触れてもらうという意味では成功したと言えるでしょう。
ただやはりスクリーンリーダーは難しかったとの意見は多く、ワーク内容の操作指示などをより細かく指定した方が良かったかもしれません。
第2回「アクセシビリティを満たさないウェブサイトを触る会」
2025年11月、第2回を開催しました。
目的
今度の目的は「具体的な対応項目の例を知ってもらう」としました。
コネヒトではアクセシビリティの対応をする際、「サービスとしてまず優先して対応する予定の項目」を10項目ほど定めています。 それらを具体的に体験することで対応内容のイメージを掴んでもらうことが狙いです。
以下、優先対応予定とした項目の一例を抜粋します。
- 自動で動くものは全て一時停止を可能にする
- キーボードトラップ（キーボード操作で抜け出せなくなるUI）を作らない
- 画像の代替テキストを適切に追加する
- 色だけで情報を伝えない
- コントラスト比を十分に確保する
- etc......
内容
内容は「アクセシビリティの項目をわざと満たさずに作成された悪い例のWebサイトを触ってみる」としました。
今回はママリではなく、 駒瑠市〜アクセシビリティ上の問題の体験サイト〜 というWebサイトを用いて、ある項目が満たされなかった場合に何が問題なのかを考えてもらいました。 前述の対応すべき項目を先に提示し、各項目について満たされないことで何が問題なのかを書き出してもらうワークとしました。
工夫点
今回はオフライン / オンライン混合で開催されることが先に決まっており、スクリーンリーダーの時のような対面でのサポートは全員にできないことが想定されました。 また、対応すべき項目の中にキーボードトラップ排除などがあることもあり、キーボードが使える環境でのワークを考える必要がありました。外部キーボードでスマホアプリを触ってもらうといった形では、Bluetooth接続機器などの所持を全員に求めることになってしまいます。 そのため、全員が使える機器でできることを念頭に置き、普段から業務で利用しているPCで触れるWebサイトでワークすることを決めました。
結果 / 改善点
ワーク終了後、参加者にアンケートで「アクセシビリティのために、サービスにどのようなことが必要かイメージすることはできましたか？」について答えてもらいました。回答は、「1(全くイメージできなかった)」から「5(イメージできた！)」までの5段階としました。
| 回答 | 回答者数 | % |
|---|---|---|
| 5 (イメージできた！) | 11人 | 40.7% |
| 4 | 13人 | 48.1% |
| 3 | 2人 | 7.4% |
| 2 | 1人 | 3.7% |
| 1 (全くイメージできなかった) | 0人 | 0% |
アンケート結果では対応内容がイメージできたという返答が多く、目的は達成できたかなと思います。
改善点としては、前回に続き「難しい」「スパルタ」といった感想をいただいてしまったことです。 これに関しては明らかに失念していたことがあって、駒琉市には「全て対応した困らない市」のリンクもあることを伝え忘れていました……
最初から「対応済みがあるからこれと比較もしてみるとよさそう」と伝えていれば、もう少し難易度が下がっていたかもしれません。
おわりに
今回の記事では、コネヒトにおけるアクセシビリティの確保推進について、社内での取り組みを紹介しました。 筆者もこの分野では知見が浅く、計画もまだまだ途上の段階なので、何が正解なのか今も手探りな状態です。
この記事が、同じようにアクセシビリティの確保や社内への浸透を考えている方々の一助となれば幸いです。
