参加メモ:A11y Tokyo Meetup オフライン交流会 #7 Beer Bash

最近アクセシビリティについて WWDC のセッション動画を中心に学んでいるが、障害当事者の方々と接する機会がないため、知識のインプットだけに終始している。

普段プロダクト開発をしながら、自社サービスが十分にアクセシブルでないことは明白。だがユーザーからのそうしたフィードバックは決して多くはない。それは使う以前に見捨てられている、という状況を示している可能性もあるし、より俯瞰してみるとそもそも競合他社含め、(携わっている)業界自体がアクセシブルに機会提供できず、諦めとして認識されているのではないか?という危機感もあった。

そう考えていた時に、元同僚が運営メンバーにいる A11yTokyo Meetup がビアバッシュイベントを開催すると知り、何かきっかけを得られればと思い参加を決めた。

イベントページ:https://a11ytyo.connpass.com/event/364520/

会場テーブルとラガービール

会場は港区のドイツビール・ドイツ料理屋。

参加メンバーは、聴覚、視覚障害をお持ちの方、車椅子利用者の方など障害当事者の参加があった。アクセシビリティへの関わり方についても、業務で主導している方だけでなく、自分のような情報収集をしている段階の方、博士課程で研究されている方と様々だった。また、ホワイトボードを介しての筆談や、手話で会話を取り交わし合う場面もあり、日常では中々意識する機会がないコミュニケーションのあり方に気づかされた。

学生時代ノートテイカーをされていた方、博士課程で弱視の方のスポーツ補助を研究されている方の話を聞けたのも良かった。

細かいことだが、手話にも方言があることを知れたのが驚き。同じ言葉もその表現は地方によって異なり、手話も言語のひとつといえば当たり前のことなのだろうが、そんなことも知らなかった。

ちなみに、筆者も片耳難聴を患っており、たまたま同じテーブルで聴覚障害の方とご一緒でき、日頃の不便を共感しあったりした。その方は北欧から仕事で来日されており、アメリカやヨーロッパにおけるアクセシビリティ対応の現状についても知ることができた。

この会はビアバッシュということでいわゆる飲み会中心の交流会だが、ミートアップ自体は隔月でLT会のようなこともされているとのことで、継続的に参加したいと思った。また、9月には千葉でアクセシビリティカンファレンスが開催されるとのことで、こちらもキャッチアップしたい。

アクセシビリティカンファレンスCHIBA2025

WWDC25:Make your Mac app more accessible to everyone

Mac アプリのアクセシビリティ。WWDC25:Evaluate your app for Accessibility Nutrition Labels でも実演されていたように、VoiceOver 操作を実演しながら、実装による変化を説明してくれるのでとてもわかりやすい。ホバー操作のアクセシビリティは盲点だった。


0:00 – Welcome

  • アクセシビリティは誰もがアプリを体験し愛することを可能にする
  • Mac アプリ特有の特徴:キーボード・マウスインタラクション中心、密度の高い UI 、強力なマルチタスキング
  • Mac 固有の品質が重要なアクセシビリティ考慮事項をもたらす
  • 主要な要素:レイアウトの表現、ナビゲーションの加速、インタラクションのアクセシビリティ向上

0:44 – Layout

  • アクセシビリティ要素の基本概念
    • Mac アプリは多くのスペースでコントロールとコンテンツを表示
    • 視覚的なレイアウトと同様に、アクセシビリティ技術への伝達方法も重要
    • SwiftUI は個々のビューをアクセシビリティ要素として伝達、アクセシビリティ技術がアプリを理解・操作するために必要な情報
  • VoiceOver によるテスト
    • VoiceOver は様々な視覚レベルの人々がアプリを使用できるスクリーンリーダー、インターフェースを音声として聞いたり、点字として感じることが可能
    • VoiceOver でのテストはアプリのアクセシビリティをテストする優れた方法
    • Voice Control や Switch Control など他のアクセシビリティ技術との良好な体験への道
  • コンテナによるナビゲーション最適化
    • Mac では VoiceOver は主にキーボードショートカットで制御
    • 画面上の次・前の要素への移動ショートカット
    • 一度に一つの要素ずつ VoiceOver フォーカスを移動して説明を聞く
    • SwiftUI は関連アクセシビリティ要素をコンテナアクセシビリティ要素にグループ化可能
  • Mac 特有の階層構造
    • Mac では VoiceOver はデフォルトで関連要素をコンテナにグループ化、コンテナごとを移動しナビゲーションを高速化
    • Mac のアクセシビリティは iPhone や iPad とは異なり、コンテナがネストされたコンテナを含むことが多く、ツリー構造を生成
    • 入れ子のコンテナレベルが多くなりすぎないよう注意
  • .accessibilityElement(children:) modifier の活用
    • .contain: ビューをアクセシビリティコンテナとして表現、サブビューがその中のアクセシビリティ要素
    • .combine: ビューとサブビューを一つのアクセシビリティ要素として表現、すべての属性とアクションをマージ
    • .ignore: ビューを一つのアクセシビリティ要素として表現、サブビューを完全に無視
  • 要素の順序調整
    • .accessibilitySortPriority(_:) modifier を使用してアクセシビリティ要素の順序を変更
    • デフォルトのソート優先度は 0、同じ優先度のビューは視覚的位置に基づいてソート
    • 例:Book Title を Book Author より先に読み上げるため、高い優先度を設定

7:48 – Navigation

  • Rotor によるナビゲーション加速
    • VoiceOver ユーザーはすべてのページをナビゲートする必要がある
    • Rotor によりビューやテキスト範囲のコレクションを定義し、それらの間を迅速に移動可能にする
    • .accessibilityRouter(_:) modifier
  • .accessibilityDefaultFocus modifier
    • macOS と iOS 26 で、VoiceOver などのアクセシビリティ技術に初期フォーカスを提案可能
    • 新しいシーンが表示されるとき、SwiftUI はこのモディファイアを持つビューにフォーカスするよう提案

9:52 – Interaction

  • ホバーインタラクションの課題
    • ホバーによって出現する操作トリガー(ボタン)
      • VoiceOver ユーザーはポインターを動かさないためボタンにアクセス不可
    • ポインターのホバーやトラックパッドジェスチャーを必要とするインタラクションは全員にアクセシブルではない
    • .accessibilityAction(named:) modifier
      • ビューにアクセシビリティアクションを追加、VoiceOver がアクションメニューを読み上げて選択可能
    • Switch Control や Voice Control などの他のアクセシビリティ技術もこれらのアクションに依存
  • キーボードショートカットの重要性
    • アプリの一般的なタスクにキーボードショートカットを追加
    • パワーユーザー機能であるだけでなく、アクセシビリティにも大きく貢献
    • マウスを使用できない人にとって特に重要
  • カスタムコントロールの考慮事項
    • 独自のカスタムコントロールを作成する場合、他のコントロールが組み込みで持つアクセシビリティ情報を持たない可能性
    • SwiftUI Accessibility: Beyond the basics(WWDC 2021)を参照

WWDC25:Evaluate your app for Accessibility Nutrition Labels

Accessibility Nutrition Labels の解説に加えて、アクセシビリティ機能のひとつひとつを説明。以前聴講したアクセシビリティLT会の内容を思い出した。

当事者でなければ障害により生じる困りごとや不便は想像がつかないもの、、かくいう筆者も左耳難聴。某オーディオメーカー大手の某MP3プレイヤーにモノラル再生がなく驚いた経験があるが、多くの人にとってはなぜその機能が必要かは、すぐには理解できないとも思う。

かたや自らの携わるアプリが、Dynamic Type に対応できているか、Voice Over で不自由なく操作できるか、と問われると耳が痛い。このセッションビデオでは、4分以上にわたって Voice Over によるアプリ操作が実演されており、それを眺めるだけでも大きな示唆が得られた。標準的なデザインシステムに則ることが、単に視覚的一貫性をもたらしているだけではなく、その標準性を頼りにせざるを得ないユーザーがいることを、意識から欠いてはいけない。

あるアクセシビリティの専門家が、アクセシビリティ対応ができていないことは「バグ」であると声を大にして言い続けていた。しかし実情は残念ながら、多くの開発現場では「アクセシビリティ対応」に優先的に工数を割くことはない。ただ開発者が常日頃、アクセシビリティの担保を念頭に実装することはできる(レイアウトの組み方やアクセシビリティラベルの付与)。

またいきなり完璧を目指さずとも、Principles of inclusive app design のセッションでも語られていたように、できていない現状を分析し、計画立てて段階的に解消していきたい。そういう意味で、Accessiblity Nutrition Labels の存在は対応状況を可視化し、他アプリとの比較を容易とするので、対応の取り組みを後押ししてくれそうである。


0:00 – Welcome

  • Accessibility のソフトウェアエンジニアとデザイナーによる、Accessibility Nutrition Labels の評価方法について紹介
  • アプリのアクセシビリティを App Store の商品ページでハイライトする方法
  • コアとなるアプリアクセシビリティの原則と、サポートできる機能の説明
  • VoiceOver, Voice Control でのテスト方法、アクセシブルなメディアの提供方法をカバー

0:58 – Meet Accessibility Nutrition Labels

  • 最高のテクノロジーは誰もが使えるものであるという信念
  • Accessibility を考慮したアプリデザインにより、より多くの人々にアプリを提供
  • Accessibility Nutrition Labels は App Store でアプリがサポートする機能を紹介
  • ユーザーが依存する重要な機能をサポートしているかを知ることができる
  • アプリの common tasks(主要機能)すべてをユーザーが実行できなくてはならない
    • 主要機能を定義する
      • ダウンロードしたきっかけとなる機能
      • それ以前に不可欠な機能(e.g. 初回起動、ログイン、購入、設定)
    • 基本タスクに対し Accessibility Nutrition Labels の機能ごとにアプリを評価する
    • 対応できている機能/できていない機能を特定する
  • アプリがサポートするすべてのデバイスでテストする必要がある
  • 機能がアプリの機能に関連しない場合は、サポートを示さない
  • 正確性を確保するため、Accessibility Nutrition Labels のドキュメントを参照

3:06 – Evaluate your app

  • アクセシビリティはデザインから始まる(Design for everyone)
  • アクセシビリティ機能について理解する(Learn accessibility features)
  • 障害者コミュニティとつながる(Connect with community)
    • 障害当事者によるテストが、アプリのアクセシビリティを知る上で重要
    • “Nothing about us withou us”(私たちのことを私たち抜きに決めないで)
  • Sufficient Contrast: 前景色と背景色の間に十分なコントラストが必要、Increase Contrast 設定でも確認
    • Light/Dark mode 両方で対応が必要
  • Dark Interface: 光に敏感な人や暗い背景を好む人のため、dark mode 設定をサポート
    • Smart Invert の有効時に、どのメディアの色も反転しないように
  • Larger Text: テキストサイズを少なくとも 200% 大きくできるように設計、Dynamic Type の使用を推奨
  • Differentiate Without Color Alone: 色だけでなく、形状、アイコン、テキストも使用して情報を伝達
  • Reduced Motion: めまいや吐き気を引き起こす可能性のあるアニメーションを特定し、変更または削除
    • ズーム、スライドトランジション、フラッシュ、点滅、自動再生アニメーション、視差エフェクト
    • Reduced Motion 設定をオンにして、上記アニメーションがないか確認
  • Voice Control: 音声コマンドでアプリのすべての部分とインタラクションできるようにする
    • ボタンタップ、スワイプジェスチャー、文字入力、といった操作がもれなくできるか確認
    • accessiblityLabel に設定されたボタン名をシステムがオーバーレイ表示、その名前が読み上げられたら Voice Control が操作してくれる(e.g. ボタン名)
  • VoiceOver: 画面を見ずにインターフェースをナビゲートできるようにする
    • 使い方:VoiceOver を有効にし、右スワイプしてボタンをひとつずつフォーカスしてみる(名前と要素タイプが読み上げ)
    • 指をドラッグして VoiceOver に読み上げさせ、画面のレイアウトを把握する
    • (VoiceOvevr で特定タスクの完遂を実演)
  • Captions: 動画や音声コンテンツにキャプションを提供
  • Audio Descriptions: 視覚コンテンツの説明を音声で提供
    • ADアイコン

21:44 – Indicate feature support

  • App Store Connect で商品ページに Accessibility Nutrition Labels を追加
  • アプリのアクセシビリティに関する追加詳細を提供するウェブサイトへのリンクも追加可能
  • サポートする機能を選択し、準備ができたら公開
  • 障害を持つ人々とパートナーシップを組み、VoiceOver, Voice Control などの機能の使い方を学ぶ
  • デザイン段階からアクセシビリティを考慮し、common tasks を通じて各機能をテスト
  • アプリのアクセシビリティサポートを Accessibility Nutrition Labels で紹介

WWDC25:Principles of inclusive app design

インクルーシブデザインの中でも障害(disability)に焦点を当てたセッション。インクルーシブデザインやアクセシビリティデザインの文脈において、身体的に永続的な障害に目が向けられがちだが、環境要因で誰しもその状態に当てはまりうることは常々意識したい。またインクルージョンへの考慮は果てしないものだと思っていたが、現状理解と計画を持って解決していくこと、ギャップをイノベーションの機会と捉え取り組むことというメッセージに心に火がついた。


0:00 – Introduction

  • アクセシビリティデザイナーによる、障害を持つ人々を含むインクルーシブなアプリデザインについて紹介
  • 世界の約 7 人に 1 人が何らかの障害を持っており、障害は人間の普遍的な部分
  • 障害をデザインに含めることで、より多くの人々にアプリを提供し、創造性も向上
  • インクルーシブデザインにはアプリ多言語の翻訳、人種、民族への影響への配慮、世界中の文化の包摂などの観点もあるが、今回は障害に絞る
  • 大音響後の一時的難聴、大声の会話ができない、多言語環境に身を置くといった環境的要因で障害を経験することもある
  • Vision, Hearing, Motor, Speech, Cognitive の 5 つのカテゴリで障害を考える
    • 障害の有無は全か無かだけでなく、その間の「いくらか」の程度が存在する

3:55 – The inclusion gap

  • 障害は身体や心の特性ではなく、環境に大きく依存
  • 社会が期待することと個人が実際にできることの間にギャップが生じる
    • 生まれて死ぬまでの能力の曲線は人により様々
    • この「インクルージョンギャップ」が障害を生み出す
  • 人のできることは、環境のデザイン、構築により左右される→「できる力」を与えるモノ作り
    • エレベーター、マイク、メガネ、curb cuts など、多くのイノベーションがこのギャップから生まれた
  • 「Nothing about us without us(私たちのことを私たち抜きに決めないで)」の原則で、障害を持つ人々を意思決定に参加させる重要性
  • アプリをよりインクルーシブにするための4つの実践を紹介

8:55 – Support multiple senses(複数の感覚に配慮する)

  • 複数の感覚を通じてアプリとインタラクションできる方法を提供
    • 動画のキャプション、視覚的な情報、音声での体験など、様々な方法で情報にアクセス可能に
  • 情報の取得方法、入力方法を多様化(視覚、聴覚、触覚、声、認知能力)することが、インクルージョンギャップを埋める第一歩
    • Accessibility Reader の例:視覚的テキスト、音声読み上げ、ハイライト付き読み上げの 3 つの方法
    • Crouton アプリの例:画像、カメラ、テキスト、Hands Free モードなど多様な入力方法

12:36 – Provide customization(カスタマイズ性を持たせる)

  • UI とインタラクションを個人のニーズに合わせてカスタマイズ可能に
    • Accessibility Reader の例:テキストサイズ、色、フォント、音声設定の調整
    • Carrot Weather の例:データ豊富なレイアウトからシンプルなインターフェースまでカスタマイズ可能
  • アプリが人に適応するのではなく、人がアプリに適応することを期待しない

14:27 – Adopt Accessibility API(Accessiblity API を採用する)

  • アシスティブテクノロジーと連携するために Accessibility API を採用
  • VoiceOver, Switch Control, Voice Control, Larger Text などの機能をサポート
  • Accessibility API により、開発者が独自に実装することなく、障害者インクルージョンを簡単にサポート
  • アクセシビリティリーダー:Accessibility API を統合、スイッチコントロールにより画面に触れずに操作可能(iPhone とペアリング可能な物理ボタンにアクション割り当て)
  • Blackbox ゲームの例:オーディオや触覚デザインに加えて VoiceOver API で視覚障害者もパズルを解けるように設計

18:46 – Track inclusion debt

  • インクルージョンは旅であり、一度限りのものではない
  • inclusion debt(インクルージョン不足)を認識し、計画を立てて意識的な決定を行う
  • アプリに存在するギャップを理解し、障害を持つ人々と協力してギャップを埋める
  • インクルージョンギャップは創造性とイノベーションの機会
  • App Store でアプリのアクセシビリティをハイライトすることで、ユーザーが重要な機能をサポートしているかを知ることができる

WWDC25:Customize your app for Assistive Access

先日の Recap イベントにて、LTのひとつで取り上げられていた Assistive Access。発表者の方とお話しし、超高齢化社会を迎えるこれからの日本でこそ有用な機能であると伺いなるほどと思った。Dynamic Type を使って文字を拡大して使われている方は多いが、一定大きくなると表示との整合性を取ることが難しくなる。一定以上の文字サイズ設定のレイアウトを Assistive Access と分離すると良いかもしれない。


0:00 – Welcome

  • Assistive Access は Apple が iOS と iPadOS で提供する 認知障害のある人向けのシンプルな体験
  • アプリやコントロールを本質に絞り込み 誰でも簡単かつ自立してデバイスを操作できるように設計されている
  • iOS と iPadOS 26 では Assistive Access scene type を使ってアプリをこの体験に統合できる

0:59 – Meet Assistive Access

  • Assistive Access は iOS と iPadOS 17 で導入された
  • 認知負荷を減らすために シンプルなインターフェースと一貫したデザインを提供
  • Camera や Messages などのビルトインアプリは 大きなコントロールや視覚的な要素を重視した共通スタイルを持つ
  • 最適化されていないアプリは 画面下部に常に表示される戻るボタンのために縮小フレームで表示される
  • 認知障害向けに設計されたアプリは UISupportsFullScreenInAssistiveAccess キーを Info.plist で true に設定することでフルスクリーン表示が可能
  • SwiftUI や UIKit で Assistive Access セッションの検出も可能
  • フルスクリーン対応アプリは Accessibility 設定の Optimized Apps リストに表示される
  • 一般的なアプリは iOS と iPadOS 26 で Assistive Access scene を作成し 専用の UI 体験を提供できる

4:09 – Create a scene

  • UISupportsAssistiveAccess キーを Info.plist に true で追加し Optimized Apps に表示されるようにする
  • Assistive Access scene を追加し シンプルな UI 階層を設計
  • Assistive Access で起動時 この scene がアタッチされる
  • SwiftUI コントロールは自動的に大きく明確なスタイルで表示され grid や row レイアウトも自動適用
  • SwiftUI preview macro で Assistive Access trait を渡してレイアウトをテスト可能
  • UIKit アプリでも SwiftUI scene を定義し scene delegate でアクティブ化できる

7:08 – Tailor your app

  • アプリの体験を本質に絞り込み 理解しやすくサポート的な UI を設計することが重要
  • 主要な1〜2機能に絞り 他の機能は Assistive Access 外で提供する
  • 画面上の選択肢や要素を減らし 誤操作や混乱を防ぐ
  • 隠れたジェスチャやネストした UI は避け 明確で目立つコントロールを使う
  • タイムアウトによる UI の自動消失や状態変化は避ける
  • ステップバイステップのガイドフローを設計し 一度に多くの選択肢を提示しない
  • 取り消しや削除など回復困難な操作は極力排除し 必要な場合は二重確認を行う
  • テキストだけでなく アイコンや画像など視覚的な情報も併用する
  • SwiftUI の assistive access navigation icon modifiers でナビゲーションタイトルにアイコンを追加
  • ユーザーからのフィードバックを重視し Assistive Access コミュニティでテストを行う

聴講メモ:アクセシビリティLT会 #2 with Mix Leap Study

多様な視点からアクセシビリティについて知れて有意義だった。視覚過敏の方、発達障害(ディスレクシア)の方の登壇があり、それぞれの経験・観点からアクセシビリティが語られることで、その意義や身近さを説得力高く感じた。加えてインフラ・バックエンドエンジニアでありながらフロントエンド領域に染み出してアクセシビリティ向上に取り組んでいる事例がとても印象的だった。

イベントページ:https://yumemi.connpass.com/event/328775


見えない部分のウェブアナリティクス

ゆめきちさん

  • Semantic HTML→アクセシビリティ改善、SEO対策
  • WCAGチェックシートの活用
  • Lighthouse (Google) の活用

テストから始めるWebアクセシビリティ

すずきゆーだいさん

“聴講メモ:アクセシビリティLT会 #2 with Mix Leap Study” の続きを読む

This website stores cookies on your computer. These cookies are used to provide a more personalized experience and to track your whereabouts around our website in compliance with the European General Data Protection Regulation. If you decide to to opt-out of any future tracking, a cookie will be setup in your browser to remember this choice for one year.

Accept or Deny