blog
初学者のひとりごとメモ
カテゴリ： 制作日誌
タグ：アクセシビリティ, アトリエ金工やまぐち様
アクセシビリティ向上日誌２【目視試験編】
投稿日：2024年3月20日
←「アトリエ金工やまぐち様アクセシビリティ向上日誌１【各種ツール評価編】」の続きです。
使用した補助ツール
今回は有限会社時代工房様が提供してくださっているGoogle Spreadsheet用拡張機能「COB-CHA」を利用して目視チェックを行った。
なお、今回はコンテンツが少なく学習途上の試験であるため、レベルはA、チェックリストは「COB-CHA式（簡易）」を採用している。
達成できていない問題点
| 達成基準 | 該当箇所 | 内容 |
|---|---|---|
| 1.1.1 | works | 「画像の付近、あるいは別のページ等に記述された長いテキストを読むことで、画像で提供している情報を理解できる」：作品についてのテキストが不十分 |
| 1.3.1 | TOP | 「段落、見出し、リスト、強調されたテキスト等は、セマンティックなマークアップをしている」：キャッチコピー「日常に火を灯す」は構造的には見出しではないのでh1は不適当 |
| 2.1.1 | ページ全般 | 「すべての機能をキーボードで操作できる」：一部操作できない箇所あり |
| 2.1.1 | ページ全般 | 「キーボードフォーカスは可視である（簡易版のみ。本来は2.4.7）」：一部コンテンツで不可視 |
| 2.2.2 | TOP | 「動きやスクロールのあるコンテンツは、一時停止可能であり、一時停止させたところから再開できる」：スライダーが一時停止不可（左右への操作は可） |
| 2.4.1 | ヘッダ | 「メインコンテンツエリアへ直接移動するリンクがページの先頭に存在する」：ブロックスキップなし |
| 2.4.1 | 各セクション | 「見出しタグで内容を識別でき、直接移動できる（支援技術依存）」：直接移動不可 |
| 2.4.3 | メインメニュー、works | 「操作によって新たなコンテンツが展開したときに、次のキーボード操作で新たなコンテンツにフォーカス移動ができる」：途中から表示されるメニューにフォーカスが入っていけない。モーダルにすぐ入らない |
| 2.4.3 | works | 「操作によってコンテンツが収納されたときに、フォーカスは論理的な順序に返っている」：モーダルが閉じたあとのフォーカス順が意図しない順番になる |
| 2.4.4 | 右上部固定バナー2つ | 「リンクテキストは、リンクの目的を説明している。imgはaltがリンクの目的を説明している」：バナーリンクの動作説明が不十分 |
| 3.3.1 | contact | 「必須項目を空欄で送信すると、未入力の項目を特定できる説明文が表示される」「無効なデータを送信すると、エラーのある入力欄を特定できる説明文が表示される」：エラーが表示されない |
| 4.1.1 | ページ全般 | 「HTMLの一般的な技術を使っているので、フォームコントロールの名前、役割、状態を理解できる」：divがh1の子要素になっている、sourceにaltを指定しているなど |
問題点を受けての改善方針（優先度順）
- メニューをサイドバーではなくヘッダとして設置
- works部分のモーダルを削除し、別途worksのページを設けてリンクとして遷移するようにする
- HTML構造の見直し
- テキスト部のマークアップを文書構造に従って再検討
- スライダーをSplideにし、コントローラーコンポーネントを設置する
- 送信ができ、適宜エラー表示が出るフォームを設置
- 操作可能な箇所は全て可視化されたフォーカスリングでフォーカスできるようにする
- ヘッダのブロックスキップを設置
- 各セクション見出しへの直接移動
- 固定バナーのリンクに動作の説明を入れる
サイトマップ～ワイヤーフレーム～デザインから見直すこととする。
追記（2024/03/25）
なんと『HTML解体新書 仕様から紐解く本格入門』を著された@momdo_氏が、「普段どのようにアクセシビリティチェックに取り組んでいるのかを説明する」という目的のもと、私のサイトを題材としてチェックしてくださった。本当に有難うございます！
- アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その1）
- アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その2）
- アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その3）
あのミツエーリンクスのアクセシビリティの大家の方に見ていただけること自体が僥倖であるばかりか、自分が勘違いしていた部分や見落としていた点を知ることができた上に、具体的な改善案までいただくことができ、本当に頭が上がらない。是非とも改修に活かしていきたいと思う。
解説を踏まえた上での改修方針変更・追加・再検討
まず、機械検証のaxe DevtoolsとLighthouseは同じコアエンジンaxe-coreで動いているということを初めて知ったので、次に行う時は拡張機能どちらかとNu Html Checkerで確認していく。
以下太字が追加・再検討部分。
- メニューをサイドバーではなくヘッダとして設置
- works部分のモーダルを削除し、別途worksのページを設けてリンクとして遷移するようにする
- 作家プロフィールをworksに含むのではなく別ページor別セクションに設ける
- Newsセクションをカルーセルからグリッド整列に変更
- HTML構造の見直し：右上バナーのソース上の位置など
- alt属性内容の見直し：
「画像だけでは作品名が伝わらない（画像には作品名が含まれていない）ので、代替テキストが視覚以上の情報を含んでしまう。作品名を提供したい場合は目で見えるようにテキストとして提供したほうがよい」という指摘の通り、「作品名などを情報として伝えたい場合、どのように提供するか」「どの画像を単なる装飾画像と捉えるか」を再検討する - テキスト部のマークアップを文書構造に従って再検討
- スライダーをSplideにし、コントローラーコンポーネントを設置する
- 送信ができ、適宜エラー表示が出るフォームを設置
- 【フォーム】tableではなくdivに
- 【フォーム】「必須」を情報構造としてDOMに含め、オレンジ×白のカラーリングを再検討
- 【フォーム】必須項目にはrequired属性を付与
- 【フォーム】autocomplete属性の付与
- 【フォーム】送信ボタンはinputではなくbuttonに
- 操作可能な箇所は全て可視化されたフォーカスリングでフォーカスできるようにする
- 各セクション見出しへの直接移動
- 固定バナーのリンクに動作の説明を入れる
- 見出し装飾の「＜＞」やリンクの「▶」などの再検討
- aboutセクションの「あたたかさ」などの字の目立たせ方
- ヘッダのブロックスキップを設置：「h1がある時点でブロックスキップに関しては自動的に満たされる」ということだったので、ひとまず優先度を下げる（余力があればfocusで出現するものを設置予定）
