Webサイトのアクセシビリティにどう向き合う？ / How Should We Approach Web Accessibility?

MTDDC Meetup Tokyo 2024にて発表した際の資料です。
Google Slides版も公開しています。

freee、「合理的配慮の対応方針」公開のお知らせ　障害のあるお客様等が「合理的配慮」について相談できる専用のお問い合わせ窓口を設置
Web Content Accessibility Guidelines (WCAG) 2.2 (日本語訳)
WCAG 2.2 解説書
WCAG 2.1 達成方法集
Web Content Accessibility Guidelines (WCAG) 2.2
Understanding WCAG 2.2
All WCAG 2.2 Techniques
困った！を解決するデザイン 登場人物
インクルーシブなペルソナ拡張
ウェブアクセシビリティ導入ガイドブック
Quickly & easily test and remediate for web accessibility
色のシミュレータ
LOW VISION EXPERIENCE KIT – ロービジョン体験キット
freeeアクセシビリティー・ガイドライン
WCAG 2.1の各達成基準と当ガイドラインの項目との対応 — freeeアクセシビリティー・ガイドライン
当ガイドラインとWCAG 2.1の各達成基準のレベル — freeeアクセシビリティー・ガイドライン
全てのメンバーにアクセシビリティー研修を実施しはじめました + 研修資料を公開します - freee Developers Hub
ymrl/a11y-visualizer: A Browser Extension for Enhanced Web Accessibility Checking
駒瑠市〜アクセシビリティ上の問題の体験サイト〜
アクセシビリティカンファレンス福岡2024 - connpass
アクセシビリティカンファレンス福岡：パブリックビューイング in 東京 - connpass
アクセシビリティを考えはじめるための本：20 Hour Exception
いつでも、どこでも、誰でも「使える」へ - 『モバイルアプリアクセシビリティ入門』刊行記念イベント
第1回『モバイルアプリアクセシビリティ入門』公開読書会 - connpass

Transcript

1. Webサイトのアクセシビリティに どう向き合う？ @ymrl MTDDC Meetup TOKYO 2024 2024年11⽉23⽇
2. このセッションは SNS共有OK 写真撮影OK スライドのURLはTwitterの ハッシュタグに流します
3. ⾃⼰紹介 • ⼭本伶（@ymrl） ◦ ふだんは「やまある」と呼ばれていることが多いです ◦ フリー株式会社 デザイナー/エンジニア • 2017年ごろからfreee社内のアクセシビリティの活動を始める ◦ 2019年、社内デザインシステムの構築のためにデザイナーに転⾝ • 2023年、共著書「Webアプリケーションアクセシビリティ」出版 • freeeの社外では、他社のアクセシビリティ改善の⽀援や、 アクセシビリティチェックのためのツール開発などもしています
4. 今⽇お話すること • そもそもアクセシビリティとは？どんなもの？何のためのもの？ • 法律で定められているの？ • アクセシビリティのガイドラインとは？ • そもそも何から始める？どうやって進めていく？ • 話さないこと: HTMLやJavaScriptやデザインのテクニック ◦ そのあたりは「Webアプリケーションアクセシビリティ」で
5. そもそもアクセシビリティとは？
6. 「アクセシビリティが⾼い状態」とは…… • 障害者や⾼齢者を含めて、より幅広い⼈たちが使える • ユーザーの能⼒や、操作⽅法や、デバイスやブラウザの多様さに対応できる ◦ 視覚的に⾒やすい⽂字‧⾊彩‧レイアウト ◦ わかりやすい⾔葉遣い、わかりやすいサイト構成 ◦ 動きや⾳がユーザーの邪魔をしない ◦ PCでもスマホでも使える、ChromeでもFirefoxでもSafariでも使える ◦ キーボードでも操作できる、スクリーンリーダーでも読める
7. なぜアクセシビリティが重要なのか • マイノリティを差別しないため、権利を守るため ◦ 知る、教育を受ける、働く、健康で⽂化的に⽣きる、etc… • 幅広いニーズを取りこぼさないため ◦ 顧客になるかもしれない⼈がアクセスできなかったら……？ • あらゆる⼈にとっての価値を⾼めるため ◦ ⼈によって⾒え⽅‧感じ⽅‧使い⽅は異なる ◦ あらゆるニーズに応えられるWebサイトはあらゆる⼈に使いやすい
8. アクセシビリティに 取り組むことで、 多様なユーザーの 多様なニーズに 応えられる
9. ユーザビリティとアクセシビリティ • 誰かにとっての使いやすさ: ユーザビリティ ◦ ターゲットとなるユーザーと利⽤状況を限定する ◦ その⼈にとっての効果‧効率‧満⾜度‧⽬標の達成度合い • 使える⼈‧状況の広さ: アクセシビリティ ◦ ターゲットを限定しない（障害者や⾼齢者にも限定しない） ◦ どんな⼈‧どんな利⽤状況であっても、まず使えることを⽬指す ◦ その上で、使いやすい状況になっていれば、なお良い • ⼭を⾼くするのがユーザビリティ、裾野を広げるのがアクセシビリティ
10. 間嶋 沙知『⾒えにくい、読みにくい「困った！」を解決するデザイン』（マイナビ出版）より引⽤
11. Webアクセシビリティと⼈権
12. Webアクセシビリティは⼈権である • 私たちはWebからさまざまなものを得て⽣活している ◦ 調べもの、学習、仕事、ニュース、娯楽、etc…… ◦ もはやWebは私たちの⽣活に必要不可⽋なもの • 障害者権利条約（2006年採択）では、守られるべき障害者の⼈権のなかに、 インターネットも含む情報通信機器‧サービスへの⾔及もある • 諸外国では、Webアクセシビリティに関する法律を定めている国も多い ◦ アメリカでは障害者が障害を理由に使えないWebサイトは裁判で負ける
13. ⽇本の法律では…… • 障害者権利条約によって、障害者関連の法律の整備が進んだ • 2024年4⽉に施⾏された障害者差別解消法の改正により、⺠間事業者でも 「合理的配慮の提供」が法的に義務化 • このとき「Webアクセシビリティが義務化！？」という情報が錯綜 • Webのアクセシビリティは「合理的配慮」でない、つまり義務ではないが 「環境の整備」として努⼒義務であるという⾒⽅が⼀般的 ◦ 内閣府の資料でもそういう扱いになっている
14. 障害者権利条約での「障害」の捉え⽅: 社会モデル • 従来の考え⽅: 医学的な観点から「障害者」を定義（医学モデル‧個⼈モデル） ◦ 「障害」は個⼈の側に存在する • 障害の社会モデル: 社会が不便なせいで、その⼈は「障害者」になっている ◦ 「障害」は社会の側に存在する（社会的障壁） • 社会モデルの考え⽅では、社会の不便なこと = 「障害」を解消していけば、 本⼈の状態が変わらなくても、「障害者」を減らしていくことができる ◦ 例: 階段でしか2階に上がれない建物では、⾞いすの⼈は「障害者」 エレベーターが整備され2階に上がれるようになれば「障害者」ではなくなる
15. 社会は急には変わっていかないので、合理的配慮が必要 • 障害者からの求めに応じて、過度な負担にならない範囲で、不便を解消する 調整を⾏うのが、合理的配慮（reasonable accommodation） ◦ 障害者の状況にあわせたアドホックな対応（運⽤でカバー） ◦ 例: 聴覚に障害のある⼈との会話を、筆談や⾳声認識アプリで⾏った ◦ 例: ⾞いすの⼈のために、通路を広くしたり机の⾼さを調整したりした • 必要になりそうな合理的配慮をシミュレーションしたり、研修したり、 そもそも不便な状況が起きないように改善していく: 環境の整備
16. Webサイト運営者に求められること • 環境の整備として、アクセシビリティの⾼いWebサイトを⽬指す努⼒義務 ◦ 現状を評価し、アクセシビリティに関する計画を⽴て、改善する ◦ 制作‧運⽤に関わるメンバーに向けて周知や研修を⾏う • 合理的配慮として、Webサイトを利⽤できないユーザーが申し出た場合に、 過度な負担のない範囲で対応する義務 ◦ メール、電話、対⾯、etc……（Webが頑張れば減らせる！）
17. freeeの事例: 合理的配慮に関する窓⼝の設置 • 以前からWebアプリやWebサイトの アクセシビリティ向上に取り組んでいた ◦ 本当に困っている⼈が、躊躇なく 申し出ることができるだろうか ◦ 申し出を受けたメンバーが、適切に 対応することができるだろうか • 2024年に「合理的配慮の対応⽅針」と 「合理的配慮委員会」を設置 ◦ 合理的配慮に関する⽅針と、 社外‧社内に向けた相談窓⼝ freee、「合理的配慮の対応⽅針」公開のお知らせ 障害のあるお客様等が「合理的配慮」について相談できる専⽤のお問い合わせ窓⼝を設置 https://corp.freee.co.jp/news/20240625_gouritekihairyo.html
18. Webアクセシビリティの基礎知識
19. ⽀援技術 (Assistive Technology) • 不便を抱えている⼈を⽀援するためのハードウェア、ソフトウェア • ⾒えない‧⾒えづらい →メガネ‧拡⼤機能‧スクリーンリーダー（画⾯読み上げソフト）‧点字ディスプレイ • 聞こえない‧聞こえづらい →補聴器‧⼈⼯内⽿‧⽂字起こしアプリ • ⼿や腕を動かせない‧動かしづらい‧道具を保持しづらい →キーボード操作スティック‧視線や⾳声やタイミングによる⼊⼒‧機材ホルダー • ⾔葉が難しい‧読み書きが苦⼿ →機械翻訳‧読み上げ‧⾳声⼊⼒
20. 伊原⼒也，⼩林⼤輔，桝⽥草⼀，⼭本伶 『Webアプリケーションアクセシビリティ――今⽇から始める現場からの改善』（技術評論社）より
21. ⽀援技術の代表例: スクリーンリーダー • おもに視覚障害者が利⽤する、画⾯を読み上げるソフトウェア • PC⽤のOSに搭載: ナレーター(Windows), VoiceOver (macOS) • Windows⽤: PC-Talker, NVDA, JAWSなど • スマートフォン⽤: VoiceOver (iOS, iPadOS), TalkBack (Android) freeeアクセシビリティー‧ガイドライン内に使い⽅などを掲載しています https://a11y-guidelines.freee.co.jp/explanations/screen-reader-check.html ※ ぜひ試してもらいたいのですが、終了⽅法を確かめてからにしてください
22. WCAG (Web Content Accessibilty Guidelines) • W3C（Web技術の標準化団体）によるWebアクセシビリティのガイドライン ◦ 最新版は昨年勧告となったWCAG 2.2 ◦ WCAG 2.0がJIS X 8341-3:2016やISO/IEC40500:2012と⼀致 • WCAGのほかに解説書 (Understanding) と達成⽅法集 (Techniques) がある • ⽇本語訳をWAIC（ウェブアクセシビリティ基盤委員会）が公開 ◦ WCAG 2.2の解説書と達成⽅法集は現在翻訳中 WCAG 2.2で追加された達成基準の解説のみ⽇本語版が公開されている
23. WCAGと関連⽂書のURL • WCAG 2.2 ⽇本語訳 https://waic.jp/translations/WCAG22/ • WCAG 2.2 解説書 https://waic.jp/translations/WCAG22/Un derstanding/ • WCAG 2.1 達成⽅法集 https://waic.jp/translations/WCAG21/Te chniques/ • WCAG 2.2 https://www.w3.org/TR/WCAG22/ • Understanding WCAG 2.2 https://www.w3.org/WAI/WCAG22/Unde rstanding/ • Techniques for WCAG 2.2 https://www.w3.org/WAI/WCAG22/Tech niques/
24. Webアクセシビリティの4原則 • 知覚可能: Web上の情報をユーザーが知覚できる • 操作可能: クリックや⽂字⼊⼒を受け付ける部分を操作できる • 理解可能: 書かれている内容、画⾯の変化、次にやることを理解できる • 堅牢: 将来にわたって幅広く互換性がある WCAGでは、これらの4原則に沿って達成基準が定義されている
25. WCAGの適合レベル • 達成基準ごとに、A‧AA‧AAAの3段階のレベル分けがされている ◦ レベルAの項⽬は満たしていないことが致命的になるものが多い ◦ レベルAAAには実現がかなり困難なものも含まれる • どのレベルまでを達成するか⽬標を⽴てるのに使⽤したり、 どの程度のアクセシビリティの⾼さなのかを説明するのに使⽤する ◦ 例: レベルAのすべての項⽬と、レベルAAの特定の項⽬に適合します
26. WCAGのバージョンと国際規格 • WCAGの最新バージョンは2023年10⽉に勧告となったWCAG 2.2 ◦ JIS X 8341-3:2016, ISO/IEC 40500:2012 となっているWCAG 2.0とは 互換性がある（達成基準がいくつか追加され、1つ廃⽌された） • WCAG 2.1以降スマートフォンを意識した達成基準が追加されているため、 JIS準拠を求められている場合でも、WCAG 2.2 も確認したほうが良い • W3CはWCAG 2.2の内容でISO/IECを改正するための準備をしている ◦ ISO/IEC 40500が改正されると、JIS X 8341-3:2016も改正される⾒込み
27. WCAGの達成基準の達成⽅法の例 • 画像に代替テキストをつける: 1.1.1(A) • Webサイトに埋め込まれている動画に字幕をつける: 1.2.2(A) • ⽂字の⾊をコントラスト⽐の⾼い配⾊に変更する: 1.4.3 (AA), 1.4.6 (AAA) • レスポンシブレイアウトにする: 1.4.10 (AA) • ボタンなどをキーボードで操作できるようにする: 2.1.1(A), 2.1.3(AAA) • エラーメッセージの表⽰⽅法や内容を丁寧にする: 3.3.1(A), 3.3.3(AA)
28. Webアクセシビリティのはじめの⼀歩
29. ふたつのアンチパターン • Webサイト全体のリニューアルまで放置する ◦ 困っている⼈は困ったまま、問題のあるコンテンツは増えつづける ◦ コンテンツの増加によって予算は膨らみ、スケジュールは遅延する ◦ もちろんリニューアルはアクセシビリティ⼤幅向上のチャンスではある • ボタンを置くだけでアクセシビリティ対応完了！みたいな製品を導⼊する ◦ 常に拡⼤や読み上げが必要な⼈は、個別のWebサイト上のボタンは不要 ◦ 致命的に問題のあるコンテンツは改善できず、そのまま残り続ける ◦ 便利に感じるユーザーはいるかもしれないが、根本の解決ではない
30. なにから始めるのか？ • アクセシビリティを必要としている⼈たちのことを知る • Webサイトの現状を評価する • できるところから改善をしはじめる
31. アクセシビリティを必要としている⼈たちのことを知る • 「⾒えにくい、読みにくい『困った！』を 解決するデザイン」（書籍） ◦ 様々な登場⼈物の「困った！」が紹 介されている • インクルーシブなペルソナ拡張 ◦ デザインの過程で定義するペルソナ に障害や利⽤状況の属性を付加する • どんなことに困るのか？をまずは知る • 当事者と話せそうなら話を聞いてみる ⾒えにくい、読みにくい「困った！」を解決するデザイン 登場⼈物 https://komatta-design.studio.site/persona インクルーシブなペルソナ拡張 https://accessible-usable.net/2018/05/entry_180517.html
32. Webサイトの現状を評価する • サイト全体をチェックするのは⼤変 • デジタル庁の「ウェブアクセシビリティ導 ⼊ガイドブック」を読みながら、 サイトのいまの状況をざっくり把握する • 意外とできていることも、 全くできていないこともあるはず ウェブアクセシビリティ導⼊ガイドブック https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook
33. できるところから改善をしはじめる • ⾮⼲渉の要件からやる • 機械的なチェックで⾒つかるところからやる • 知覚可能の観点からやる • キーボード操作からやる
34. ⾮⼲渉の要件からやる • すべてのページで満たさなければいけないとされている、4つの達成基準 ◦ ⾳声の制御（1.4.2） ◦ キーボードトラップなし（2.1.2） ◦ 3 回の閃光、⼜は閾値以下（2.3.1） ◦ ⼀時停⽌、停⽌、⾮表⽰（2.2.2） • どれも、ページの閲覧や他のページへの移動を困難にしてしまうもの ◦ 該当するページがある場合は、すぐに直したほうが良い • ウェブアクセシビリティ導⼊ガイドブックでは「重⼤」と記載
35. ⾳声の制御（1.4.2） • 3秒以上の⾳声を⾃動再⽣させない ◦ ⾳の出る動画を含む • ⾃動再⽣する場合には停⽌や⾳量調整が できるようにする • ⾳声が邪魔でスクリーンリーダーによる ⾳声読み上げでの利⽤が困難になる • ⾳声により、視覚コンテンツへの集中⼒を 妨げられてしまう ウェブアクセシビリティ導⼊ガイドブック https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook
36. キーボードトラップなし（2.1.2） • Tabキーによるフォーカス移動で、 抜けだせなくなる場所がないようにする • むかしはFlashによってよく発⽣したが、 今はあまり存在しないかもしれない ◦ JavaScriptプログラムのミスにより 発⽣することは有り得る • モーダルダイアログ内にフォーカスを閉 じ込め、閉じるまで抜け出せないのはOK ◦ ただしキーボード操作で閉じられる ようになっている必要がある ウェブアクセシビリティ導⼊ガイドブック https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook
37. 3 回の閃光、⼜は閾値以下（2.3.1） • 1秒間に3回以上光るものを作らない ◦ （または減光処理をする） • 光感受性てんかんの発作を引き起こす • いわゆる「ポケモンショック」 ウェブアクセシビリティ導⼊ガイドブック https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook
38. ⼀時停⽌、停⽌、⾮表⽰（2.2.2） • 5秒より⻑く動きつづけるコンテンツは、 ⽌めたり消したりできるようにする ◦ ⾃動で切り替わっていく、バナーや 写真などの画像（カルーセル） ◦ アニメーションの演出 ◦ ⾃動再⽣されている動画 • 動き続けるものが⽬に⼊ると集中⼒を奪 われてしまう障害のある⼈に影響がある ウェブアクセシビリティ導⼊ガイドブック https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook
39. 知覚可能の観点からやる • Webアクセシビリティの4原則（知覚可能‧操作可能‧理解可能‧堅牢） の最初の3つは、知覚ができなければ、操作や理解もできないことになる • 知覚可能の達成基準（1.X.X）から着⼿するのは、特に静的なページの多い Webサイトで有効 • 画像の代替テキスト、動画の字幕や書き起こし、⾊のコントラスト、 HTMLの記述順、マウスオーバーによる表⽰など……
40. 機械的なチェックで⾒つかるところからやる • Lighthouseの「ユーザー補助 (Accessibility)」で採点できる ◦ 採点に使われるaxe-coreは、axe DevToolsとして単体で使える （アクセシビリティの評価ではaxe DevToolsのほうが使いやすい） • 機械によるチェックだけでは完璧なチェックはできないので注意 ◦ WCAGの全ての項⽬をチェックできるわけではない ◦ 間違ったやり⽅でスコアを上げると、アクセシビリティをむしろ下げる
41. キーボード操作からやる • スクリーンリーダーをはじめ、キーボードによる操作をする⽀援技術は多い • 静的なページの多いWebサイトでは、「操作」をする場所は少ないはず ◦ リンク（普通にやっていればキーボードで操作できる） ◦ フォーム（普通にやっていればキーボードで操作できる） ◦ JavaScriptにより制御しているところ ▪ 開閉するやつ、カルーセル、モーダルダイアログ、etc…
42. アクセシビリティに本格的に取り組む
43. アクセシビリティを必要としている⼈のことを知る • ユーザーに会ってみる、当事者に会ってみる ◦ ⾃社のユーザー内で探す、クラウドソーシングを活⽤する • 体験してみる ◦ ⾊のシミュレータ、ロービジョン体験キット ◦ キーボードだけで、いろんなWebサイトを操作してみる ◦ スクリーンリーダーで、いろんなWebサイトを読んでみる https://a11y-guidelines.freee.co.jp/explanations/screen-reader-check.html
44. アクセシビリティを網羅的にチェックする • WCAGの達成レベルに基づいた「どこまでやる」の⽬標を⽴てて、 ⾃分たちの現在地点はどこなのかをチェックする ◦ 本当は最初にやるべきです ◦ アクセシビリティ向上を視野にいれたリニューアルでは必須 • 状況の把握が⽬的なら、代表的ないくつかのページをチェックするでも良い • ⽬標を⽴てるのもチェックするのも、いきなりやるのは難しいので、 freeeの公開しているガイドラインとチェックリストを活⽤してください
45. https://a11y-guidelines.freee.co.jp/
46. freeeのガイドラインとチェックリスト • WCAGのAAと⼀部AAAの達成基準と対応するように作られている ◦ ⼀部に基準を変更しているものがある • チェックリストはデザイナー⽤‧エンジニア⽤‧QA⽤が⽤意されている ◦ できあがっているサイトには「プロダクト」（QA⽤）を使⽤する • ツールの使い⽅など、いろいろな参考情報がガイドラインのサイト内にある • JISやWCAGへの適合が求められる場合には、JISやWCAGを使⽤してください
47. 47 UXチームがUIデザインを作成→エンジニアが開発→QAチームがテストの流れがあるので、 
 デザイナーがデザイン、エンジニアがコード、QAがプロダクトのアクセシビリティチェックを行う 
 チェックのタイミング（プロダクト開発） 
 デザイナー 
 エンジニア 
 QA
 デザイン の
 アクセシビリティチェック 
 コード の
 アクセシビリティチェック 
 プロダクト の
 アクセシビリティチェック 
 freeeの研修資料「アクセシビリティー研修 Basic」より引⽤ https://developers.freee.co.jp/entry/a11y-training
48. サイトのリニューアルはアクセシビリティ向上チャンス • サイト全体のナビゲーションや、共通のナビゲーション、テンプレートなど 単体のページだけの修正では直せないものを直すチャンス • サイトの要件定義に、具体的なアクセシビリティ要件も⼊れておく • ナビゲーション設計やコーディングなどの各所でチェックを実施する • 制作‧運⽤のプロセスを、アクセシビリティを前提としたものに変える
49. 機械的なチェックをプロセスに組み込む • axe-core（Lighthouse, axe DevTools） • markuplint, eslint (jsx-a11y, vuejs-accessibility), biome • コーディング時にチェックするほか、コンテンツの追加更新時にも使⽤する ◦ コンテンツの追加更新をするメンバーに⼿順を説明して実施してもらう • もちろん、⾃動的なチェックだけでは完璧にならない ◦ コンテンツの追加更新時に⾏うチェックについて決めておく ◦ そもそもどうコンテンツを作るべきかの指針を⽰しておく
50. スクリーンリーダーなしで、同等のチェックをする • ⾃動チェックでチェックできないものは ⼈の⼿でチェックをしなければならない • チェックするには、コードを読むか、 ⽀援技術（スクリーンリーダー）を使う ◦ 使い⽅を憶えるのが⼤変 ◦ QAしかチェックしなくなる • それらを簡単に⾒ることができる Accessibility Visualizer拡張機能を開発 https://github.com/ymrl/a11y-visualizer 画像は「 駒瑠市〜アクセシビリティ上の問題の体験サイト〜」上で Accessibility Visualizerを使⽤したもの https://a11yc.com/city-komaru/
51. 今⽇のまとめ • アクセシビリティに取り組むと、多様なニーズに応えられるようになり、 障害者や⾼齢者を含めてあらゆる⼈にとって使いやすくなる • Webサイトが利⽤できない⼈がいることは、⼈権の問題でもある。 努⼒義務ではあるが、合理的配慮を提供する義務のためにも取り組むべき。 • まずはできるところから始める。リニューアルまで放置したりしない。 いまあるコンテンツをすこしずつチェックして直していく。 • アクセシビリティを前提にした制作‧運⽤プロセスにしていけるのがベスト
52. 来週はアクセシビリティカンファレンス福岡！ 2024年11⽉30⽇(⼟曜⽇) 警固神社社務所ビル（福岡） + YouTube 13:00〜18:00 フリー株式会社オフィス（⼤崎）で パブリックビューイングをやります！ いますぐconnpassから登録！ https://fukuoka-a11yconf.connpass.com/event/322934/ https://freee.connpass.com/event/337258/
53. アクセシビリティを考えはじめるための本 技術書典オンラインマーケットにて、 「アクセシビリティを考えはじめるための本」 電⼦書籍版を800円で販売しています。 法律の解説や、⽀援技術体験のチュートリアルなど 今⽇は触れられなかったことを詳しく書いています。 https://techbookfest.org/product/2KX3LTZs66Y6v8cZZ62mDW
54. 書籍「モバイルアプリアクセシビリティ⼊⾨」発売 「Webアプリケーションアクセシビリティ」の姉妹書 モバイルアプリのアクセシビリティの本 12⽉2⽇、透明書店（蔵前）にて刊⾏記念イベント https://tomei-bookstore-event-20241202.peatix.com/ 12⽉3⽇より、公開読書会を開催 https://freee.connpass.com/event/337478/
55. ご清聴ありがとう ございました 続きはAsk The Speaker / 懇親会で