以下の内容はhttps://ozaki25.hatenadiary.jp/entry/2024/08/09/230520より取得しました。
感想
- 多様なユーザや状況への対応のこと
- アクセシビリティに取り組むことで多様なユーザの多様なニーズに応えられる
- さまざまな支援技術
- メガネ/補聴器
- スクリーンリーダー/文字起こしアプリ
- キーボード操作スティック/視線入力/音声入力
- 機械翻訳
- 取り組む価値
- 障害の社会モデル
- 個人に問題があると考える視点(医学モデル)
- 社会が不便なせいで障害者になっていると考える視点(社会モデル)
- ソフトウェアの利用
- 出力装置
- 入力装置
- 装置を正確に動かしたり速く動かせない
- 出力装置からのフィードバックがわからない
- ユーザによる情報の認識
- WCAG
- 4つの原則
- 適合レベル
- A/AA/AAAの3段階
- Aが少ないものは満たしてないと致命的なものが多い
- AAAは実現が難しいものもある
- WCAGの最新は2.2(2023/10)
- JISは2.0と互換性があるがそのうち2.2にも対応される
マネーフォーワードクラウド
- 30以上のプロダクト
- 3~5名の小さいチーム
- UIや振る舞いのばらつき
- 技術スタックもバラバラ(rails, react, vue)
- 横串の知見共有が進んでなかった
フロントエンド推進グループ
- MFC Accessibility Guidelinesを作った
- WCAG2.2のシングルAに対応
- 整備して模索してる段階
共通UIライブラリ
- MFUI(Money Forward UI)
- デザイン標準の時点でアクセシビリティを考慮
- Storybookで管理
- ChromaticでVRT
Webアプリケーション開発におけるアクセシビリティテストの実践事例
- 全ての人に使ってもらいたいから
- 会社のvisionにもつながってる
- テストの際に当たり前にやることの1つ
- テストをするのはQAエンジニア
- デザインや設計の段階でアクセシビリティの視点でチェックしてる
- 実装後の試験
- スクリーンリーダー動かしてチェックしたり
- OSのカラーフィルターで色合い変えて確認したり
- axe devtoolsで確認したり
- 困ること
- 時間がない中で作業するので全画面全部やってられない
- 事前に見積もっておいて時間と人を確保する
- デザインシステムの部品を使ってれば致命的な問題は起きないはず
- 実装が終わってからじゃないとテストできない
- Windows使ってる人少ない問題
- 検知箇所が多すぎる問題
以上の内容はhttps://ozaki25.hatenadiary.jp/entry/2024/08/09/230520より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14