CMS管理画面のアクセシビリティ

Transcript

1. CMS管理画面のアクセシビリティ 伊原 力也 @magi1125 2025-06-28 1
2. 伊原 力也 / @magi1125 プロダクトデザイナー、 デザインリサーチャー、 アクセシビリティエキスパート ビジネス・アーキテクツ→freee Studio、 CULUMUなどで アクセシビリティコンサルティング 共著・監訳 Webアプリケーションアクセシビリティ モバイルアプリアクセシビリティ入門 2
3. CMS管理画面のアクセシビリティ ウェブにおける、 閲覧と発信が行き来するコンテンツの生態系を考えたとき、 制作されたコンテンツがアクセシブルなだけではなく、 そのコンテンツを作るしくみも また、 アクセシブルであるべきでしょう。 CMSの管理画面やエディタのアクセシビリティが高ければ、 多くの人、 そして多くの 状況で、 コンテンツの制作・運用が可能になります。 それは、 何かを伝えるチャンスが 得られることや、 仕事の幅が増えることに繋がります。 逆に言うと、 CMS管理画面がアクセシブルでなければ、 限られた人だけしか コンテンツに携われなくなる、 ということでもあります。 今回、 いくつかのCMSをピックアップし、 現状の管理画面のアクセシビリティが どうなっているか、 どのように改善していくのが望ましいかを考えてみます。 3
4. 今日は話さないこと アクセシビリティ自体の詳しい解説 ゼロから学ぶWebアクセシビリティ～導入編～ CMSのアクセシビリティチェック機能、 CMSテーマのアクセシビリティ、 CMSから 出力されたWebページのアクセシビリティ CMS関連ブースやワークショップで聞いてみよう！ アクセシビリティの組織推進 C2A： 「自律的に学び合う組織文化の作り方　ウェブアクセシビリティで コンテンツを届けるために経営層と現場で取り組んだこと」 をチェック！ 4
5. Webの大半はCMSでできている 全世界のウェブサイト、 約2億弱。 うち71.1%にCMSが導入 「ウェブに関わる ≒ CMSに関わる」 と言っても過言ではない では、 CMSは 「多様な人が使えるツール」 になっているか？ 5
7. ATAG・WCAG・UAAG Essential Components of Web Accessibility Authoring Tool Accessibility Guidelines (ATAG) 2.0 パートA: オーサリングツールのユーザーインターフェースをアクセシブルに する ウェブベースのCMSなら、 管理画面自体にWCAGが適用される パートB: アクセシブルなコンテンツの制作を支援する 7
8. 業務ツールたるCMSへの要求 JIS X 8341-3:2016 この規格が適用されるウェブコンテンツとは， 支援技術を含むユーザエージェントに よって利用者に提供されるあらゆる情報及び感覚的な体験を指す。 例えば， インターネット又はイントラネットを介して提供されるウェブサイト， ウェブアプリケーション， ウェブシステムなどのコンテンツ， 及びCD-ROMなどの 記録媒体を介して配布される電子文書が挙げられる。 みんなの公共サイト運用ガイドライン 業務アプリケーション （例：文書管理、 財務会計、 住民情報管理など） のうち、 ウェブ技術で作成され、 ウェブ上で利用されるもの 8
9. グローバルを見据えるならアクセシビリティ必須 WordPress Drupal Plone Craft CMS 9
10. CMS管理画面で見るべきアクセシビリティ観点 1. 適切なナビゲーション設計 2. 適切なUIライティング 3. キーボード操作可能 4. 条件を満たすタップ・ホバー・ドラッグ操作 5. 勝手に動かない・時間制限がない 6. OSやブラウザで表示調整可能 7. 情報が色や形などに依存しない 8. コントラスト比が基準値以上 9. 妥当なマークアップ （＝スクリーンリーダー等で操作可能） 10
11. 参考：WCAG 2.2 達成基準 適切なナビゲーション設計：2.4.5, 3.2.3, 3.2.4, 3.2.6 適切なUIライティング：2.4.2, 2.4.4, 2.4.6, 3.3.2, 3.3.3 キーボード操作可能：2.1.1, 2.1.2, 2.1.4, 2.4.3, 2.4.7, 2.4.11 条件を満たすタップ・ホバー・ドラッグ操作：2.5.8, 1.4.13, 2.5.1, 2.5.7 勝手に動かない・時間制限がない：2.2.1, 2.2.2, 3.2.1, 3.2.2 OSやブラウザで表示調整可能：1.3.4, 1.4.4, 1.4.10, 1.4.12 情報が色や形などに依存しない：1.4.1, 1.3.3 コントラスト比が基準値以上：1.4.3, 1.4.11 妥当なマークアップ：1.1.1, 1.3.1, 1.3.2, 1.3.5, 2.4.1, 2.5.3, 3.1.1, 3.1.2, 3.3.1, 4.1.2, 4.1.3 今回の確認対象画面に含まれてない：1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.4.2, 1.4.5, 2.3.1, 2.5.2, 2.5.4, 3.3.4, 3.3.7, 3.3.8 11
12. 今回のレビュー対象 a-blog cms HTMLの書きぶりを気にしながら作っている 配信イベントではデモサイトのアクセシビリティチェック回もあり 今回、 進んで題材になっていただき感謝！ CMSでのコンテンツ更新運用で必要になるコア部分をレビュー ログイン ダッシュボード エントリ一覧 エントリ編集 チェック結果まとめ 12
13. 全体的な所感：よい点 「適切なナビゲーション設計・適切なUIライティング・情報が色や形などに 依存しない」 はほぼ問題なし、 グッド! 幅320pxでもおおむね問題なく表示が可能なのはナイス! ターゲットのサイズも最低限の基準はクリアできている コントラスト比もいくつか調整すれば大丈夫そう マークアップにおいては、 見出しやリストを使う、 リンクやボタンをdivでなくa hrefや buttonにする、 inputにはlabelをつけるなどの意識を感じた 13
14. 全体的な所感：もう一声！な点 ホバーやドラッグ動作において改善余地がありそう トースト的な表示や通知まわりで改善余地がありそう ラベルの無いアイコンボタンがある(スクリーンリーダーでは用途不明になる) コンボボックスやメニューやダイアログなどにおいて、 おそらく使っている UIライブラリ由来の、 WAI-ARIAのミスっぽいのがある 特に記事編集周りで、 キーボード操作できない箇所がいくつかある 特に記事編集周りで、 スクリーンリーダーでは操作ができない箇所がある 14
15. ログイン・ダッシュボード ログイン user-scalable=no, hoverの時の色 ダッシュボード キーボードとhover：ナビのツールチップとメニュー残存、 検索結果の フォーカス、 幅狭時のメニューを閉じる スクリーンリーダー：ボタンにaria-hidden, 検索結果の通知・フォーカス・ テーブル、 メニュー裏に貫通 本文エリアのレイアウトテーブル 15
16. エントリー一覧 コンボボックス：コントラスト、 ×ボタン、 通知が過剰かつ英語 フォーカス表示：子ブログを含めるチェック、 一覧の列ヘッダ 並び替え・表示項目設定のドラッグ操作 ボタンラベル：高度な絞り込みボタン、 編集右の▼ボタン トースト：一括操作結果や表示順変更結果のメッセージが一定時間で消える アイコンの呼び出しが残る：その他ボタン、 並び替えを終了するボタン altがないと存在がない：一覧のメイン画像のalt labelがないinput/select：高度な絞り込み内、 表示件数、 一括操作、 表示順 aria-haspopup=""dialog"か：その他ボタン、 ▼ボタン 結果の通知：一覧の検索結果と一括操作結果が無言、 並び替え実行中の通知 16
17. エントリー編集 ページロード時やダイアログのautofocus キーボード操作：[？]アイコン、 日時選択・メイン画像アップロード ラベルのないselect：詳細設定＞概要内、 メディア一覧の 「月」 「選択してください」 、 最下部の保存オプション タイトルや概要文の文字数が通知されない メディア一覧の画像のaltがカラ （画像の存在がわからない） divにaria-label （ユニットの入力が始まります」 /ユニットが追加されました） 各ユニットの 「配置 おまかせ グループ2カラム 属性枠付き」 コントラストが 基準値以下 「以下のユニットが〜」 のバーのドラッグ動作 （キーボードでは詳細設定＞概要で 設定できる） 17
18. テキストユニット キーボード操作 リンクダイアログの裏にフォーカスが移動できてしまう 文字を選択してリンクを付ける際、 途中にid欄があるとフォーカスが移動する ため選択が解除される WYSIWYG （Trumbowyg） のツールバーにキーボードでアクセスできない スクリーンリーダー操作 abc/< >ボタンにラベルがない＆選択状態が不明、 selectにラベルがない リンク・強調・重要の使用有無がわからない （ボタン状態、 指定されている箇所） WYSIWYG （Trumbowyg） がスクリーンリーダーの考慮がなく操作できない 参考：CKEditor 18
19. 画像ユニット 「新規メディアを追加/またはファイルをドロップ」 のコントラスト タブのフォーカス表示 （メディア編集・メディア挿入） 画像編集 切り抜き範囲の移動操作・中心点操作がジェスチャ依存 画像の回転の結果が通知されない パーマリンクのコピー時のメッセージが一定時間で消える/通知されない 画像選択削除のhover依存 （メイン画像/画像ユニット） 19
20. テーブルユニット 列追加削除のメニューにキーボードではアクセスできない 編集系ボタンにラベルがない selectにラベルがない 20
21. ブロックユニットのキーボード操作 （1/2） 編集エリアにフォーカスが入ったことがわかりにくい [＋] （新規ブロックを追加） 出現がhover依存 メニューが出た際、 tabキーで抜けてもメニューの表示が残る メニューの下の方にキーボードではアクセスできない （表示されない） [︙︙] （ブロックメニュー） tabキーで行ける範囲と上下キーで行ける範囲が混在 ブロックタイプ変換のサブメニューにキーボードで入れない 21
22. ブロックユニットのキーボード操作 （2/2） 文字列選択時メニューへのアクセス [＋][︙︙]があるとフォーカスが取られてしまう リストがある場合、 tabキーを押すとインデントが優先され入れない リンクを選択した際、 同時に出現したURL欄が優先され入れない 文字列選択時メニューの挙動 ブロックタイプを選び直すとフォーカスが消滅 ボタンを押すと文章側にフォーカスが移ってしまいトグルできない 決定でスペースキーを用いると、 同時にスクロールが発生してしまう キーボードで閉じるのが難しい （操作中でもESCで消したい） そのほか カラム分割がhoverでしか確認できない テーブルのメニューにキーボードでアクセスできない 22
23. ブロックユニットのスクリーンリーダー操作 どこからどこまでが編集エリアかが判別しづらい 選択時メニュー上での 「現在の選択状態」 がわからない、 選択結果が通知されない [＋]のメニュー内容が読み上げられない [︙︙]のaria-haspopup=""dialog"は適切でなさそう テーブル挿入が操作できない （行数や列数を正しく読み上げない） カラム分割状態がどうなっているか読み上げない 23
24. エディタのタイプ ユニット型 a-blog cmsのこれまでのエディタ WYSIWYG型 a-blog cmsのテキストユニットに存在 （Trumbowyg） Drupal Editor (CKEditor) WordPress Classic Editor ブロック型 a-blog cmsの新しいエディタ noteのエディタ WordPress Gutenberg 24
25. ユニット型の特徴 明示的な構造：見出し・本文・画像などが明確 キーボードでの操作が比較的しやすい アクセシビリティを確保しやすい 25
26. WYSIWYG型の特徴 いわゆるワープロスタイル 見たまま編集できる快適さ 操作が視覚依存になりやすく、 アクセシビリティ面で課題 ただしCKEditorなど、 がんばっているものも存在 WordやGoogleドキュメントとの互換性を活かしたカバー方法もアリ CMS側エディタのアクセシビリティが低くても、 WordやGoogleドキュメントで 下書きしてCMSのエディタに貼り付けるスタイルで運用可能 26
27. ブロック型の特徴 「見たまま」 だが、 要素ごとのブロックの構造を持っている ブロックを挿入する or 選択した要素を変換する シンプルな見た目だが、 操作の手がかりが常時表示されない。 ゆえに状態通知や 操作UI制御が難しく、 アクセシブルにしづらい 参考：noteのエディタ WordやGoogleドキュメントからの貼付けができれば、 こちらもいったんの 問題回避は可能 27
28. 編集スタイルと移行の難しさ それぞれのエディタで作ったコンテンツは、 それぞれの形式で保存される 相互の変換はできない ユニット型で作ったコンテンツをWYSIWYG型やブロック型にコピペすると、 その形式で保存され、 ユニット型には戻せない エディタ形式がアクセシビリティに影響するため 「どのエディタの形式で編集するか」 の運用ルールが必要 28
29. どこから始めればよい？ 小規模な改善にトライする アクセシビリティを広報⁠⁠ ・プレスリリースによって社外へつなげる アクセシビリティを新規開発の 「当たり前」 に組み込む 29
30. 「誰のためなのかわからない問題」 を脱するために ユーザーインタビューを実施する X(Twitter)での募集の様子 noteの 「アクセシビリティ」 に関するインタビューに協力してくださるかたを 募集します 問い合わせ窓口を設置し、 「声を聞くつもりがある」 という姿勢を表す アクセシビリティ | freee SmartHR製品のアクセシビリティに関するフィードバック サイボウズ製品のアクセシビリティ改善に協力 そしてCMSユーザー側は、 問い合わせや改善要望を上げる 30
31. 本当の意味で公平な社会をつくるには 本当の意味で公平な社会をつくるには、 障害のある人がモノやサービスの受け手に 留まっているのではなく、 つくり手として社会に参加し、 自分たちの物語を 生みだしていく必要がある。 『誰のためのアクセシビリティ？』 はじめに／田中みゆき 31
32. 終わりに CMSは、 つくり手として社会に参加し、 自分たちの物語を生み出すための、 強力な ツールである WebはCMSでできている。 そうであるならば、 CMSが扱えることは、 Webという 社会に参加できること、 そのものである CMSベンダーとユーザーが互いに協力することで、 Webはアクセシブルになる 32
33. 宣伝：アクセシスタディーズ 社会の当事者みんなでアクセシビリティを考え・つくる 「アクセシスタディーズ」 という イベントをはじめます。 2025/07/24(木)に開催の第0回では、 NPO法人アイコラボレーションの 板垣さんをゲストに、 電動車いすを利用する日常や、 さまざまなアクセシビリティに ついて知り、 考え、 対話します。 会場 （freee東京オフィス） とオンライン配信のハイブリッド開催です。 オフライン参加は抽選で、 7/18(金)申込締切です！お申し込みお待ちしています！ 33
34. CMS管理画面のアクセシビリティ 伊原 力也 @magi1125 2025-06-28 34