← エピソード一覧に戻る Episode 188 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 使えないUIは、見えないまま売上を削る
タカシ
今日は SaaS デザインのアクセシビリティです。優しい配慮の話に見えますが、実はかなり経営の話です。見えない、押せない、読めない、追いつけない UI は、導入率も継続率も静かに削っていきます。
ミカ
アクセシビリティって、どうしても公開サイトの話に聞こえがちです。でも SaaS だとログイン後の画面こそ本番ですよね。そこで詰まると、毎日の業務がずっと重くなる気がします。
タカシ
その通りです。WebAIM の 2025 年調査では、トップ 100 万サイトの 94.8% に WCAG 違反が検出され、平均 51 件のエラーがありました。しかも多いのは低コントラストやフォームラベル欠落のような、かなり基本的な項目です。
ミカ
94.8% は、ほぼ全員ですね。高度な技術課題というより、基本が崩れたまま積み上がっている感じです。だからこそ SaaS でも、後回しにするとあとで全部に効いてきそうです。
Chapter 2 原則 ― アクセシビリティは福祉ではなく、品質と販路の基準
タカシ
アクセシビリティの土台は W3C の WCAG 2.2 です。Perceivable、Operable、Understandable、Robust の四原則で、見えるか、操作できるか、理解できるか、技術的に壊れないかを整理します。SaaS ではこの基準が品質の共通言語になります。
ミカ
なるほど。見た目だけじゃなく、キーボード操作や読み上げ、通知の出し方まで含めて品質なんですね。たしかに、毎日使う業務ツールでそこが壊れていたら、じわじわ効くどころか毎日つらいです。
タカシ
しかも今は販路の話でもあります。European Accessibility Act は 2025 年 6 月に効力を持ち、EU では e-commerce など対象サービスに共通要件が求められています。米国でも Section 508 を背景に、公共調達では VPAT の提出が重い意味を持ちます。
ミカ
つまり『あとで直します』では済まないんですね。使いやすさの問題でもあるし、そもそも商談のテーブルに乗れるかどうかの問題でもある。アクセシビリティって、想像以上に売上の入口なんだなあ。
Chapter 3 実務 ― SlackとAsanaに学ぶ、日常業務を止めない設計
タカシ
Slack の実装は、共同作業 SaaS らしい観点があります。スクリーンリーダー利用者が Home や Activity を F6 で移動し、⌘または Ctrl と K で会話へ飛び、矢印キーでメッセージやスレッドを追える。つまり会話量の多い UI を、操作の流れごと設計しているんです。
ミカ
チャット系って情報が流れ続けるから、アクセシビリティが難しそうです。でも Slack は移動だけじゃなくて、通知の受け取り方まで調整できるんですよね。そこまでやって初めて仕事が止まらなくなる気がします。
タカシ
ええ。Slack は message verbosity、会話中のアナウンス、既読の振る舞いまで個人設定できます。これは単なる読み上げ対応ではなく、認知負荷の制御です。良い SaaS は、同じ情報を全員に同じ密度で浴びせません。
ミカ
それ、すごく SaaS っぽいですね。見えるか見えないかだけじゃなく、処理しきれるかどうかまで設計する。通知が多いプロダクトほど、その発想がないと『機能はあるけど疲れるツール』になりそうです。
タカシ
Asana も面白いです。WCAG 2.2 AA への複数年の取り組みを公開しつつ、color-blind mode、dark mode、zoom 調整、一時ポップアップの表示時間調整、Skip to main content を提供しています。つまり機能追加ではなく、働き方の違いに合わせているんですね。
ミカ
表示時間を変えられるのは地味だけど大きいですね。SaaS って確認トーストや一瞬の通知が多いから、そこを読み切れないだけで不安が積もる。アクセシビリティって、安心して操作できる感覚にも直結するんですね。
Chapter 4 複雑UI ― Figma、Atlassian、GitHubが示す運用の差
タカシ
複雑な UI ほど学びが大きいのが Figma です。Figma はオブジェクトのキーボード選択や UI スケール変更に対応し、プロトタイプでは accessibility mode でデザイン要素を HTML に変換してスクリーンリーダーが理解しやすい形にしています。
ミカ
キャンバス型の UI は、普通の画面よりずっと難しそうです。だから Figma は『そのまま読ませる』じゃなくて、読み上げに向く形へ変換しているんですね。アクセシビリティって、別の表現を設計する仕事でもあるんだなあ。
タカシ
その通りです。FigJam では装飾オブジェクトをタブ順から外して冗長さを減らす設定まであります。情報量が多い SaaS ほど、全部を平等に読ませるより、何を優先して伝えるかを決めるほうが大事なんです。
ミカ
たしかに、読み上げでも全部が等価だと逆につらいですね。『見えるようにする』ではなく『仕事が進む順番で伝える』まで考えないと、複雑な SaaS は使える状態にならない気がします。
タカシ
運用面では Atlassian が分かりやすいです。WCAG 2.2 AA 準拠を掲げ、accessible components を含むデザインシステム、公開バックログ、60 日と 120 日の SLO を置き、FY25 には critical と high の課題を 6,000 件超修正したと開示しています。
ミカ
そこまで公開するのは強いですね。『うちは大事にしています』ではなく、残課題と修正速度を見せる。GitHub も keyboard-only、JAWS、NVDA、axe での評価方法を ACR に出していましたし、信頼って証拠の量で決まるんですね。
Chapter 5 まとめ ― 先に設計する会社だけが、大きな顧客を取れる
ミカ
今日の失敗パターンをまとめると、公開サイトだけ整えてアプリ本体を後回しにする、色や alt だけ直して操作性を放置する、個人設定を持たない、複雑機能を例外扱いする、商談用の説明資料がない、このあたりですね。
タカシ
ええ。まずは自社で WCAG 2.2 AA と支援技術の対応範囲を決め、登録、検索、承認、管理者設定、請求のような主要フローを毎月点検してください。さらにデザインシステムへ組み込み、VPAT や方針文書まで整える。アクセシビリティはコストではなく、売れる品質です。
ミカ
使える人を選ぶ SaaS は、結局選ばれにくくなるんですね。皆さんのプロダクトでも、まずは一番重要な業務フローをキーボードだけでたどってみてください。そこで詰まる場所に、次の成長のボトルネックが隠れているはずです。