@kazuhito
Kazuhito Kidachi's Personal Web Site Since 2000

Frontrend Vol.9 - 春の新人歓迎 マークアップ/アクセシビリティのキホン #frontrend

4月28日の覚え書き。オシャンティーな渋谷プライムプラザ 4F Creative Loungeで催されたイベント、Frontrend Vol.9 - 春の新人歓迎 マークアップ/アクセシビリティのキホンにブログ絶対に書くパーソン枠で参加したので、以下に感想など徒然なるままに書こうと思います。ちなみにブログ絶対に書くパーソン枠で参加しておきながらブログ書かなかったら何が起こるのかというのに個人的興味があったけど、社会人としてどうかと思うので、書きます。

継続的にアクセシビリティを高めるために 〜まずは無理なく基本を押さえる〜

サイバーエージェントでアクセシビリティおじさんを務めるますぴーさんのプレゼン。担当されているサービス、FRESH!本イベントの録画も同サービスで公開されています)での取り組みを「まずはできるところから」「みんなでやる」の2種類に大別して紹介されていました。

コンテンツとして代替テキストと共に提供すべき画像を、背景画像として表示させているダメな事例について、ちゃんとimg要素で実装し直すというのは良いと思うのですけど、object-fitプロパティに未対応なブラウザにはrole="img"を指定したdiv要素で、aria-label属性で代替テキストを指定するのは、object-fitのサポート状況を踏まえるなら、そこまでしなくても良いのでは? と思いました(実質、IE/Edge対応のためだけにそこまでするのかという)。

また、span要素で実装されていたボタンを、キーボード操作可能にbutton要素で実装し直すという事例については、スライドのaでもいいです。ただしhrefありという記述が気になりました。キーボードフォーカスを受け取れるようにする、という点に限っては等価という意味合いかも知れませんが、a要素はハイパーリンクのためのものですから、「メニュー」の表示/非表示を切り替えるボタンとしては「aでもいい」なんてことはないと思うのです。そこは誤解を与えてしまってはいないでしょうか?

ATAG 2.0をベースとした独自のガイドラインを現在作成中で、いずれはFRESH!以外のサービスにも適用するとか、他社も参考にできるよう公開する予定であるというのは、素晴らしいなと思いました。ただ、その文脈で自動ブラウザテストのお話が出てきたのですが、aXe CLIなんかの話は、「春の新人」さんにとってはちょっと耳慣れない、難解な話に聞こえてしまったのでは? 思いました。aXeA11y Command-line Toolsも、そこまでメジャーな印象はないので......時間的にも、割愛して良かったかも知れません。

概ね、サイバーエージェントの今後のアクセシビリティ対応につき、非常に期待が持てるプレゼンだったと思います。Webアクセシビリティ、まず取り組むべきはカルチャーとプロセスというのが持論ですが、まさにその通りの取り組みをされているなと。あほむさんの最近のプレゼンにしてもそうですけど、サイバーエージェントほど有名なサービス事業者が「アクセシビリティやるぞ」というスタンスを業界に、あるいは社会に向け明確に打ち出しているのは大変心強く感じますし、他社の追随も強く期待したいところ。

マークアップの最適解を見つけ出す方法

アップルップル森田さんのマークアップについてのプレゼン。以前、WCAN 2016 Winterに参加した時に森田さんのAMPをテーマにしたLTは聞いていましたが、HTMLの講演を聞くのは今回が初めて。つい先日、最終回を迎えてしまいましたが、名古屋マークアップ勉強会を主催されてきたほどHTMLにはアツい方でいらっしゃるので、お話を聞けるのを楽しみにしていたのですね。

strong要素は強調ではないのでは? とか、そういった細かいところはもんどさんが既に多く指摘をされているので(さすがです)......自分が抱いた感想として書き留めておくべきは、まずは特定の環境、たとえばスクリーンリーダーのみを対象としたマークアップの是非についてですね。もっと具体的にいうと、Bootstrapに用意されているsr-onlyクラスをどう捉えるのかというお話。

もちろん自分も「マークアップに正解はない」と思っていますので、それを全否定するつもりはありません。ただ、10年ほど前にRe: 第18回 XHTMLの設計〜状況に合った要素選び(3)〜という記事で書いたように、特定の利用者や環境に対し歩み寄れば、それ以外では当然逆のことが起こりうる(場合によっては不便を強いることになる)というスタンスであり、故にsr-onlyクラスのような存在に頼ろうとは思いません。ユニバーサルな利用を大前提とするWebにおいては、むしろ頼るべきではないとも思うんですね。環境固有の事情を取り込もうとすればするほど、環境変化に対しては弱く、堅牢ではないフロントエンドになってしまいがちなので。

次いで、CSSで見た目の表示順を入れ替えるサンプルについて。Flexible Box LayoutGrid Layoutが利用できる今となっては、displayプロパティでtable-header-groupとかtable-footer-groupを指定するサンプルは、紹介しなくて良いのではないかと思いました。実際のところどうかまでは確認していませんが、アクセシビリティオブジェクトはDOMツリーとレンダリングツリーから作られるので......仮にtable-header-group/table-footer-groupを指定した際、マークアップ上はdiv要素であっても、支援技術にはそれらが表に関する情報として渡されはしないかという懸念をうっすらと感じました。

最後に、プレゼンの冒頭と末尾に登場する、カードデザインの見た目を伴う「お知らせ」コンポーネントのマークアップについて。li要素を使うというのが、このプレゼンにおける正解であり、自分もli要素を採用する可能性は高いと思いました。しかし本来、あらゆるマークアップ対象がそうであるように、当該要素の位置付けだとか、出現位置における前後関係(文脈)に関して仮説なり前提を置かない限り、何が正解とは言い難い。「マークアップに正解はない」と言っておきながら、なぜ「正解」を提示するのか? というブーメランにもなりかねない訳で、そこはもう少し補足が必要だったかも知れません。

加えて、その「お知らせ」コンポーネントのお話の中で、見出しが多いと良くないというようなお話が(聞き違えでなければ)ありました。自分は、数はともかく構造的にそれが見出しならば見出し要素でマークアップすべき(というかマークアップせざるを得ない)と考えています。確かに、同じページに百も二百も見出しがあったら、見出し要素だけ抜き出してきて全体のアウトラインを把握するのもつらいと思いますが......主観的には、見出しとそれが言い表しているところの後続の内容、両者のバランス次第かと。後続の内容量が少ないほど、見出しが見出しとして機能しにくくなる印象はありますし、そういうのが同じページ中にたくさんあるとなると、つらいです。

アウトラインチョットデキル

TKGでブランディング? していらっしゃる越智さんのプレゼン。アウトラインをすごく分かりやすく噛み砕いて解説されていました。特にスライドの27ページ目、セクショニング要素を使うと見出しレベルを下げた後に記述したコンテンツでも親階層に引き上げることができる、これ。つい先日、Re: プロの編集者が意識する「ドキュメント構造」――HTML仕様の欠点にひきずられちゃダメ!で指摘した内容とも被るけど、安田編集長(誰)は越智さんからセクショニング要素のなんたるかを教わるべきと思いました。

その一方で、アウトラインアルゴリズムの実装(普及)状況に言及がなかったように思われるのは残念。仕様上は、確かにセクショニング要素とh1要素の組み合わせでかなりシンプルに(Web Componentsの利用シーンを含め)マークアップできますが、逆にそれはアウトラインアルゴリズムに対応していないUAや支援技術で大問題を引き起こします。なにせ、見出しレベルを適切に解釈してくれないわけですから、ページ内の見出しが全部h1要素ならそのまま素直に全ての見出しがh1相当としてユーザーに伝えられることになります。その辺りについての考えは別途、Re: h1要素は複数回使って良いのか!? HTML5.1に関するW3CとWHATWGの主張の違いで書いているので、興味があればお読みください。

まぁしかしアウトライン大事、セクショニング要素大事、というのはこのプレゼンで十分伝わったのではないでしょうか? ありがとう越智さん、ありがとう卵かけご飯。

ほかの参加者の方の記事

現在地:ホーム > 覚え書き > 月別アーカイブ > 2017年4月 > Frontrend Vol.9 - 春の新人歓迎 マークアップ/アクセシビリティのキホン #frontrend
Google カスタム検索を利用しています