おさらい

対象ページ：「アトリエ金工やまぐち」
- Basic認証があるので、アクセシビリティ向上日誌１【各種ツール評価編】からたどってください
- @HeldaForStudy氏に了承を得てアクセシビリティチェックを行っています
チェック基準：WCAG 2.1レベルA
文中のSCはSuccess Criteriaの略で達成基準のこと
目的はどうやってアクセシビリティチェックしているのか、チェックしながら何を考えているのかを書き記すことです
- 制作ページやチェック内容にネガティブなことをいいたいわけではありません
チェックに抜け漏れ、誤りがあるかもしれません
仕様等は基本的に日本語訳を当たります

では続きに入っていきましょう。

「ABOUT」セクション

アクセシビリティチェックの経験がある人であれば、「ABOUT」「ひとつの跡にひとつのぬくもり」のコントラスト比が不足している（SC 1.4.3「コントラスト (最低限)」）ことに目が行くと思いますが、今回はレベルAでチェックしていることを思い出しましょう。また、「ABOUT」の文字の一部が隠れてしまっています。SC 1.4.4「テキストのサイズ変更」（レベルAA）では200％ズームをするわけですが、ズームすることなしに起こっているので、達成基準上の問題というよりかは、サイトの一般的な問題になってくるでしょう。

また、『「金属」という素材に、どんなイメージがありますか？』のセクションにある、下線が気になるところです。

<p class="section-about__discription1 scroll_up on">冷たい？固い？<br>
もちろんそれも金属の大きな特長です。<br>
しかしまた、<span class="section-about__discription1-under-bar under-bar">あたたかさ</span>、<span class="section-about__discription1-under-bar under-bar">やわらかさ</span>という<span class="section-about__break"></span>側面を併せ持てる素材でもあるのです。
</p>

<u>を用いて下線を引いているわけではないので、SC 1.3.1「情報及び関係性」の問題とはなりませんが、それはそれとして下線は一般的にリンクだとユーザーはすり込まれているわけで、ユーザビリティの観点から考慮してもらうとよいのかと思います。

<a href="about/index.html#introduction">鍛金のことを知る<span class="arrow">▲</span></a>

記号文字「▲」での提示について、SC 1.3.1としてマークするのは前回のその2でも述べたとおりです。

「NEWS」セクション

こちらの「NEWS」は完全に隠れてしまっているので、というのはさておき、画像にある「NEW」はレベルAAとしてSC 1.4.3「コントラスト (最低限)」*1、SC 1.4.5「文字画像」がパッと出てくるところですね。「NEW」という画像の代替テキストが存在しないので、SC 1.1.1「非テキストコンテンツ」としてマークしておきます。

アクセシビリティ上の問題ではないですが、「矢印」は押せそうに見えて押せない、「右」にスワイプすればよいように見える（私の場合）というのがあるので、こちらもユーザビリティの観点から検討いただくとよいかもしれません。なおSC 1.4.10「リフロー」も気になるところですがこちらの達成基準はレベルAAですので以下省略。

カードの中身は、

<li class="swiper-slide section-news__swiper-slide section-news__swiper-slide1 swiper-slide-active" role="group" aria-label="1 / 6" style="width: 299.25px; margin-right: 32px;">
  <div class="section-news__swiper-img-area section-news__swiper--new">
    <img class="section-news__swiper-img" src="assets/img/michiyo/vase7.jpg" alt="ギャラリー○○ グループ展" loading="lazy">
  </div>
  <div class="section-news__tag">展覧会</div>
  <div class="section-news__article">
    <time datetime="2023-01-01">XX.XX.XX.</time>
    <h3>ギャラリー○○　グループ展</h3>
    <p class="section-news__discription">○○市にあるギャラリー○○さんにてグループ展を行います。<br>
      様々な作家の作品が一堂に会するこの機会に、ぜひお気に入りの一点を見つけてください。</p>
    <div class="section-news__details">
      <a href="construction.html">詳細を見る→</a>
    </div>
  </div>
</li>

となっていますが、次に挙げている項目については、その1あるいはその2でも触れたポイントについての繰り返しになりますので、詳細は省略します。

swiperのこと
画像の代替テキスト
見出しの位置
記号文字「→」

なお、「詳細を見る」はリンクの目的（SC 2.4.4、SC 2.4.9）を考えるとアクセシビリティチェック上のポイントになってくるところですが、今回は<li>の塊の末尾にリンクがあるので、SC 2.4.4の「リンクのテキストとプログラムによる解釈が可能なリンクのコンテキストから判断できる」と判断します。

達成基準 2.4.4 リンクの目的 (コンテキスト内) (レベル A): それぞれのリンクの目的が、リンクのテキスト単独で、又はリンクのテキストとプログラムによる解釈が可能なリンクのコンテキストから判断できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。

お問い合わせフォーム

ここでフォームが来てしまいましたね（ふるえ）。達成基準として見るものがたくさん出てくるというのもありますし、フォームのデザインパターンが多様なこと、バリデーションが送信前と後のどちらで発生するのか（いいかえれば、フロントエンドとバックエンドでどうデータが行き来しているのか）など、複雑な様相を呈してきます。

フォーム一般として見ておくべき達成基準としては、まずエラー方面

SC 3.3.1「エラーの特定」（レベルA）
SC 3.3.3「エラー修正の提案」（レベルAA）
SC 3.3.4「誤り防止 (法的、金融、データ)」（レベルAA）

作り込みによっては出てくるコンテキストの変化

SC 3.2.1「フォーカス時」（レベルA）
SC 3.2.2「入力時」（レベルA）

コンテンツの変化として

SC 4.1.3「ステータスメッセージ」（レベルAA）

何の入力欄なのかがわかること

SC 3.3.2「ラベル又は説明」（レベルA）
SC 1.3.1「情報及び関係性」（レベルA）
SC 4.1.2「名前 (name)・役割 (role)・値 (value)」（レベルA）
SC 1.3.5「入力目的の特定」（レベルAA）
SC 1.3.3「感覚的な特徴」（レベルA）

あたりでしょうか。またフォームによってはタイムアウトすることもあるでしょうから

SC 2.2.1「タイミング調整可能」（レベルA）

も見る必要があります。マルチステップな画面ですと

SC 2.4.2「ページタイトル」（レベルA）

あたりも意外と盲点だったりします。そしてWCAG 2.2から加わった

SC 3.3.7「冗長な入力項目」（レベルA）
SC 3.3.8「アクセシブルな認証 (最低限)」（レベルAA）

あたりもあわせて見ておく必要があります。わぁい…。

気を取り直して、チェック対象ページを見ていきましょう。コード断片としてはこうです。

<form class="section-contact__inquiry-form scroll_up on" action="">
  <table>
    <tbody>
      <tr>
        <th>
          <label for="formName" class="section-contact__inquiry-form-title">お名前</label>
        </th>
        <td>
          <input class="section-contact__inquiry-form-write" id="formName" type="text" placeholder="お名前をご入力ください">
        </td>
      </tr>
      ...
      <tr>
        <th class="section-contact__inquiry-form-detail">
          <label for="formDetail" class="section-contact__inquiry-form-title">ご用件</label>
        </th>
        <td>
          <textarea id="formDetail" placeholder="ご用件をご入力ください"></textarea>
        </td>
      </tr>
    </tbody>
  </table>
  <input class="section-contact__form-submit" type="submit" value="送信する">
</form>

で、達成基準上の指摘としては特にない認識です。素晴らしいですね…（？）達成基準上の問題としては、@HeldaForStudy氏がSC 3.3.1として挙げていますが、達成基準を確認してみましょう。

達成基準 3.3.1 エラーの特定 (レベル A):入力エラーが自動的に検出された場合は、エラーとなっている箇所が特定され、そのエラーが利用者にテキストで説明される。

現在のフォームでは、入力エラーがそもそも自動的には検出されていないという認識ですので、達成基準上の問題とはならないという理解です。それはそれとして必須であることはHTMLコード上では表せていません（疑似要素でもってテキストとして提示はされていますが）。これは、必須項目にreqired属性を提供することで手当てできるでしょう。

<input class="section-contact__inquiry-form-write" id="formName" type="text" placeholder="お名前をご入力ください" required>

こうすれば、ブラウザーが検出してくれます（釈迦に説法感がありますが…）。

このフィールドに入力してください。

このフォームはシンプルで素直なフォームですからよいのですが、世に出回っているフォームでラベルのないフォームのなんと多いことか。ラベルがなきゃ何の入力欄なのかわからないという話です。プレースホルダーテキストは、入力欄のヒントであってラベルではありません。プレースホルダーテキストを使うこと自体、あまりお勧めできるものではありません。入力フォームのプレースホルダーを使ってはいけないを読みましょう。またラベルを<label>で関連付けていないフォームも星の数ほどあります。まずはラベルを付けましょう。何をおいてもフォームはラベルです。いいですね？

フォームについてもまた、語り出すとキリがない話題ではあります。なにせForm Design Patterns ―シンプルでインクルーシブなフォーム制作実践ガイドという本が一冊書ける程度には奥深いです。こちらを目を通してみてもよいでしょう。Webアプリケーションアクセシビリティ──今日から始める現場からの改善 WEB+DB PRESS plusでも1章丸々割いて説明しています。

HTMLコードについて少し詳しく見てみましょう。多分に趣味が入ってきますが。

「必須」を疑似要素で提供しているのは違和感があるかな…と思うところです。Accessible Name and Description Computation仕様では疑似要素のテキストが追加されることになっているので、モダンな環境では伝わると思いますが、情報構造としてDOMツリーに含める方が自然かと思います。
<table>で組まなくていいのではないかな…とは。もちろんテーブル見出しセルをきちんと設定しているので誤りではないわけですが、SPで厳密には2次元テーブルにはならないことを鑑みてもレイアウトという性格が強いと思われ、<div>とCSSグリッドなり、フレックスボックスなりで整形した方が見通しがよさそうな気はします。
やはりautocomplete属性が付けられる箇所は付けた方がよいでしょう。SC 1.3.5「入力目的の特定」では事実上必須でありますが、オートコンプリートが効くというシーンに助けられることは多いと思いますので、ユーザビリティの向上にもつながるかと。
<input type="submit">よりかは<button type="submit">がよいでしょう。HTML解体新書の<input>要素の説明でもそう記載しています。

まとめ

結局3回に分かれましたね…アクセシビリティチェックをする側がどのようなチェックをしているのか、何を考えているのかを説明してきたつもりですが、いかがでしたでしょうか。WCAG 2.1にのっとってアクセシビリティを担保するとなると、WCAG 2.1解説書とにらめっこしつつ、必要に応じてHTML、ARIA仕様を眺めていく感じになってくるかと思います。結構端折ってしまいましたが、ウェブサイト上のアクセシビリティチェックの勘所が、ほんのちょっぴりでも伝わったならば嬉しいです。

また、去年にアクセシビリティスペシャリストのキャリアってどんな感じ？というイベントで登壇していましたが、じゃあどんなことを実際やってるのよ、という補足になればよいかなと（いまさら感がありますが）。こういうお仕事を一緒にしてみたいという方は採用に応募もらうと中の人が喜びます、たぶん。

最後に、アクセシビリティチェックの題材としてサイトの使用を許可してくださった@HeldaForStudy氏に改めて感謝したいと思います。どうもありがとうございました。

HTML解体新書

作者:太田良典
ボーンデジタル

Amazon

Webアプリケーションアクセシビリティ──今日から始める現場からの改善 WEB+DB PRESS plus

作者:伊原力也,小林大輔,桝田草一,山本伶
技術評論社

Amazon

Form Design Patterns ―シンプルでインクルーシブなフォーム制作実践ガイド

作者:Adam Silver
ボーンデジタル

Amazon

デザイニングWebアクセシビリティ: アクセシブルな設計やコンテンツ制作のアプローチ

作者:太田良典,伊原力也
ボーンデジタル

Amazon

*1:オレンジ色と白文字の組み合わせは、SC 1.4.3のコントラスト比を満たす上での鬼門です。「オレンジ　アクセシビリティ」で検索するといろいろと出てきます

2024-03-23

アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その2）

アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その1）の続きです。

おさらい

対象ページ：「アトリエ金工やまぐち」
- Basic認証があるので、アクセシビリティ向上日誌１【各種ツール評価編】からたどってください
- @HeldaForStudy氏に了承を得てアクセシビリティチェックを行っています
チェック基準：WCAG 2.1レベルA
文中のSCはSuccess Criteriaの略で達成基準のこと
目的はどうやってアクセシビリティチェックしているのか、チェックしながら何を考えているのかを書き記すことです
- 制作ページやチェック内容にネガティブなことをいいたいわけではありません
チェックに抜け漏れ、誤りがあるかもしれません
仕様等は基本的に日本語訳を当たります

では続きを進めていきましょう。

モーダル出現ボタン

スクリーンショットですと、

HTMLソースとしては、

<button class="js-open-modal modal-btn-kenzo" id="modalOpenKenzo" data-slide-index="1">
  <span class="section-works__modal-button">
    <img src="assets/img/kenzo/plate4.jpg" class="section-works__modal-button-kenzo" alt="山口堅造「（作品タイトル）」">
  </span>
  <h3 class="section-works__kenzo">
    <span class="section-works__name">Kenzo</span><span class="section-works__break"></span>Yamaguchi
  </h3>
</button>

になります。Nu Html Checkerが既に指摘していますが、HTML構文上、<button>の子に<h3>を置くことはできません（SC 1.3.1「情報及び関係性」）。念のためHTML仕様を当たってみましょう。

<button>のコンテンツモデル：

フレージングコンテンツであるが、インタラクティブコンテンツの子孫およびtabindex属性が指定された子孫が存在してはならない。

カテゴリー「フレージングコンテンツ」は、<h3>を含んでいませんから、HTML構文違反となります（Nu Html Checkerの指摘のとおり）。

これは完全に余談なのですが、業務でチェックしていると、稀にインタラクティブなコンテンツをネストしているサイトに遭遇することがあります…HTMLの性質上、フォーカスを持つ要素の中にフォーカスを持つことはできません…。

さておき、それでは、この問題を修正するとすればどうすればよいでしょうか。コンテンツモデルを満たすように<a>にする、という選択肢が思い浮かぶかもしれません。ちょっと雑ですが、構造だけ抜き出して書き換えるとすると、こういう感じでしょうか：

<a href="#">
  <span>
    <img src="jpg" alt="山口堅造「（作品タイトル）」">
  </span>
  <h3>
    <span>Kenzo</span><span></span>Yamaguchi
  </h3>
</a>

しかし、<button>改め、<a>の中でも問題が残っています。<a>要素の内部という区切りを設けると*1<h3>という見出しがありますが、見出しの後にコンテンツが何もないという問題があります（SC 1.3.1）。

ここでHTML仕様を思い出しましょう。h1、h2、h3、h4、h5、h6要素にはこう定義されています。

これらの要素は、そのセクションの見出しを表す。

見出しは、見出しの後ろにコンテンツがあるからこそ見出しなのです。実コードでも<h3>の直後に<h3>が来てしまっているので、情報構造として困ったことになってしまっています。

また、見出しに先行して、見出しに関連する画像があるという問題もあります（SC 1.3.2「意味のあるシーケンス」）。見出しに関連する要素は、見出し要素の中で提供するか、見出し要素よりも後で提供するようにします。

ちなみに、この画像は装飾的なのではないかと思われますので、alt=""とするのが適当かと思われます。思われる、というのはチェックする人間（ここでは私）はコンテンツオーナーでもコンテンツ制作者でもないので、どういう意図でここに画像を置いたのかがわからないからです（その意味で条件付きのSC 1.1.1「非テキストコンテンツ」としてマーク）。

情報設計の時点で、どういう意図でここに画像を置くのか？目立たせて視覚的な誘導をしたいだけなのか、画像自体が意味を持つ・情報を提供するからここに置くのか…というのを考えて画像を置く必要があると言ったところでしょうか。これは裏を返せば、現場のコーダーが必要に迫られて代替テキストを適当に入れればよい、というものではないということですね…。

脇道にそれました。話を元に戻すと、つまるところ、<h3>とすることがそもそもの問題となっている、と捉えることができるわけですね。ですから、もろもろを勘案すると下記のようになるのがよさそうでしょうか。

<button>
  <span>
    <img src="plate4.jpg" alt="">
  </span>
  <span>
    <span>Kenzo</span><br class="sp-only">Yamaguchi
  </span>
</button>

名前と苗字の間で改行したいのであれば素直に<br>を使えばよいかと。SP（スマートフォン）幅の場合だけ改行を設けたいのであれば、PC幅でdisplay:noneを噛ませておいて、ブレークポイントでdisplay:noneを解除すればよいだけ、ということですね。素のCSSだとこれでよかったんでしたっけ*2。

@media (max-width: 600px) {
  .sp-only {
    display: none;
  }
}

こうすると<h3>がなくなってページ全体のアウトラインとしてどうなんでしょう、というのはありますが、先行して

<div class="section-title__wrapper">
  <h2 class="section__title" id="works">WORKS</h2>
</div>

とあるので特段の問題は起きないでしょう。

とまあ、こんな感じで1つのモジュールであれやこれやと検討できてしまうのがアクセシビリティチェックの恐ろしいところ（？）でもあります*3。裏を返せば、アクセシビリティを担保したウェブサイトを提供するのであれば、モジュール設計時にアクセシビリティチェックを行う必要があるということになります。ちなみに勤務先の業務では、自社制作で高度なアクセシビリティが要求されるときは、アクセシビリティ専門の部門が都度チェックを行ってたりしてます。

モーダル

随分とボタンの話が長くなってしまいましたが、ボタンを押した時に出現するモーダルの話に移っていきましょう。

@HeldaForStudy氏の立てた方針として、

2. works部分のモーダルを削除し、別途worksのページを設けてリンクとして遷移するようにする

とありますが、仮にモーダルを存続させて、達成基準を満たすのであればどうなるのか、を念頭に置いて現状把握をしていきたいと思います。

キーボード操作をすればわかりますが、「Kenzo Yamaguchi」のボタンを押してTabキーで移動していくと、すぐにモーダルの中にフォーカスが移動しない、というのは@HeldaForStudy氏がSC 2.4.3「フォーカス順序」の問題として挙げているとおりです。ただこの根本の原因としては（例によっていろいろ省いたHTMLですが）、

<button>>Kenzo Yamaguchi</button>
<button>>Michiyo Yamaguchi</button>
<div><a href="construction.html">作品一覧を見る</a></div>
<!-- 堅造モーダル -->
<div class="section-works__modal" id="jsModalKenzo">...</div>
<!-- みちよモーダル -->↩
<div class="section-works__modal" id="jsModalMichiyo">...</div>

というHTMLソースの出現順序に根本的な問題があるということですね（SC 1.3.2「意味のあるシーケンス」）。モーダルも大雑把に言ってしまえば結局開閉するコンテンツですから、ボタンの直後に置くのが適切でしょう。

<button>>Kenzo Yamaguchi</button>
<!-- 堅造モーダル -->
<div class="section-works__modal" id="jsModalKenzo">...</div>
<button>>Michiyo Yamaguchi</button>
<!-- みちよモーダル -->↩
<div class="section-works__modal" id="jsModalMichiyo">...</div>
<div><a href="construction.html">作品一覧を見る</a></div>

また、フォーカスの順序という意味では、モーダル内でキーボードフォーカスが封じ込められていないという問題もあります。そして、このモーダルがモーダルだということを支援技術に伝えられていません（SC 4.1.2「名前 (name)・役割 (role)・値 (value) 」）

そのあたりのARIAの都合、フォーカスの制御はARIA APGのModal Dialog Exampleにあれそれ書いているので、自前でモーダルを書くというのであれば、ARIA APGを参考にすればよいかと。もっとも、もしかしたら<dialog>を使ってしまったほうが早いのかもしれません。

モーダルの「ガワ」の話はこんなところでしょうか…。

さて、モーダルの中身としては、スクリーンショットとしてはこういう感じになっているわけですが

上・中・下段、どれもマウスで操作できてしまうのですよね…。これは、アクセシビリティというよりかはユーザビリティの視点で検討いただいた方がよい…のかもしれません。

アクセシビリティの観点としては、コンポーネントが操作できるということは、コンポーネントの名前を持つ必要がある、というところに留意いただければと。

モーダル上段のスライド1枚目に戻ってみましょう。中身はこんな感じです。

<div class="section-works__swiper-prof">
  <div class="section-works__swiper-prof-img">
    <img src="assets/img/kenzo-prof.jpg" alt="山口堅造" loading="lazy">
  </div>
  <div class="section-works__swiper-prof-box">
    <h4>＜略歴＞</h4>
    多摩美術大学 大学院修士課程終了　1982年<br>
    茨城県に工房移設（アトリエ金工やまぐち）　1998年<br>
    <br>
    <h4>＜主な発表活動＞</h4>
    池袋西武・玉川高島屋・松屋銀座にてグループ展　1980年～<br>
    ...
    日本煎茶工芸展　［文部科学大臣奨励賞］「銅鎚起錫彩茶托」　2005年
  </div>
</div>

まず目に付くのが、見出しで装飾の目的で不等号「＜」「＞」を用いていることでしょうか（SC 1.3.1）。そのような記号で装飾せずに、CSSでいい感じに見出しを装飾してもらえれば。

また、連続する<br>を余白を設ける目的で使用しています（SC 1.3.1）。HTML仕様でbr要素は、

br要素は改行を表す。

と定義されています。余白のためにはCSSで制御するようにします。

SC 1.3.1としてマークするのがよいのかは微妙なラインですが、「略歴」と「主な発表活動」は情報構造上、リストであると言えます。どうマークアップするのかはかなり趣味の領域になってくると思いますが、素直に<ul>を用いるパターン、

<div class="section-works__swiper-prof-box">
  <h4>略歴</h4>
  <ul>
    <li>多摩美術大学 大学院修士課程終了　1982年</li>
    <li>茨城県に工房移設（アトリエ金工やまぐち）　1998年</li>
  </ul>
  <h4>主な発表活動</h4>
  <ul>
    <li>池袋西武・玉川高島屋・松屋銀座にてグループ展　1980年～</li>
    ...
    <li>日本煎茶工芸展　［文部科学大臣奨励賞］「銅鎚起錫彩茶托」　2005年</li>
  </ul>
</div>

<dl>を用いるパターン1（見出しを変更）、

<div class="section-works__swiper-prof-box">
  <dl>
    <dt>略歴</dt>
    <dd>多摩美術大学 大学院修士課程終了　1982年</dd>
    <dd>茨城県に工房移設（アトリエ金工やまぐち）　1998年</dd>
    <dt>主な発表活動</dt>
    <dd>池袋西武・玉川高島屋・松屋銀座にてグループ展　1980年～</dd>
    ...
  </dl>
</div>

<dl>を用いるパターン2（亜種として、明示的に「年」と「内容」を構造化する）、

<div class="section-works__swiper-prof-box">
  <h4>略歴</h4>
  <dl>
    <dt>1982年</dt>
    <dd>多摩美術大学 大学院修士課程終了</dd>
    <dt>1998年</dt>
    <dd>茨城県に工房移設（アトリエ金工やまぐち）</dd>
  </dl>
  <h4>主な発表活動</h4>
  <dl>
    <dt>1980年～</dt>
    <dd>池袋西武・玉川高島屋・松屋銀座にてグループ展</dd>
    ...
  </dl>
</div>

などがあるでしょうか。まあこのあたりは趣味ですので、スタイルシートの当てやすさを勘案してお好きなのをどうぞ、というところでしょうか…。

あと、人名の代替テキストは、スクリーンリーダーのユーザーには伝わって、視覚で見ているユーザーには伝わらないという意味でSC 1.1.1「非テキストコンテンツ」としてマークするかもしれません。

それを踏まえて、1つの情報構造の形として、

<div class="section-works__modal" id="jsModalKenzo" role="dialog" aria-labelledby="modal-heading-1" aira-modal="true">
  <h3 id="modal-heading-1">山口堅造</h3>
  <div>
    <div class="section-works__swiper-prof-img">
      <img src="assets/img/kenzo-prof.jpg" alt="" loading="lazy">
    </div>
    <div class="section-works__swiper-prof-box">
      <h4>略歴</h4>
      ...
    </div>
  </div> 
</div>

としてしまえば、モーダルの内外でアウトラインとして見出しの階層構造を崩さずに済みますし、モーダルの名前を見出しで提示できます（SC 1.3.1、SC 4.1.2の観点から）。こうすることで、「略歴」は<h4>でも<dt>でもよくなります。

さんざっぱらモーダルの場合を仮定してあれやこれやを書きましたが、

2. works部分のモーダルを削除し、別途worksのページを設けてリンクとして遷移するようにする

というのが改修方針でした。そもそもモーダルダイアログを選択した方がよいのかについては、Webアプリケーションアクセシビリティ──今日から始める現場からの改善 (WEB+DB PRESS plus)の8章でかなり厚く書かれているので、一読するとよいでしょう。

小まとめ

あれ、モーダルの話しかしてないような…（ふるえ）。

脇道にそれたり、私の趣味というか好みに走っている面も多分にありましたが、達成基準としてSC 1.3.1「情報及び関係性」とSC 4.1.2「名前 (name)・役割 (role)・値 (value) 」が多くのウェイトを占めています。マシンリーダブルの1つの考え方としては、主にDOMツリーから生成される、堅牢なアクセシビリティツリーを作ることにありますから、必然的にそうなってくるものと思っています。

また、実装した後でアクセシビリティに取り組むのでは遅いということもうっすら感じてもらえれば幸いです。実装よりも前のビジュアルデザイン、さらにその前のワイヤーフレームを描く段階でアクセシビリティの闘いが始まっている、と言えるでしょう。

その3に続きます。

*1:セクショニングという意味では、厳密には怪しい区切り方でしょうが、それは脇に置いて

*2:メディアクエリーすらまともに書けないのがバレる回

*3:アクセシビリティチェックに限らず、フロントエンドでHTMLを検討し出すと止まらないというのはある程度共感してもらえるかしらとは

*4:最近話題の改正障害者差別解消法は、「環境の整備」に位置づけられるウェブアクセシビリティを法的に強制するものではない点に注意。

水底の血

アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その3）

おさらい

「ABOUT」セクション

「NEWS」セクション

お問い合わせフォーム

まとめ

アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その2）

おさらい

モーダル出現ボタン

モーダル

小まとめ