yuheiy

egg

いや、それらについて知りたい欲求もあるだろうと考えることもできるけど、現実的に考えてキリがなく、HTMLのレイヤーで解決するのには無理があるように思う。これを実現するならば、視覚的に描画された結果をスクリーンショットのように認識してAI等で読み取るような方向性が妥当だろう。

ということを踏まえると、次のような結論になった
- コンテンツ的な画像には可能なかぎりimg要素を使用し、aria-hidden=trueは適用しない
- 装飾的な画像はimg要素でもそうでなくてもかまわないし、aria-hidden=trueを適用してもよい

時間を置いて考えが整理されたので改めて。暫定解としてどうするべきか。

img要素であればAIなどで画像の説明ができるが、background-imageやsvg要素を使うとできない（はず）。ということを踏まえると、画像的なものは可能なかぎりimg要素で描画すべきなのかという問いが浮かぶ。

しかしそう考えると、画像的なものとはどこからどこまでを指すのか。ページの背景に敷き詰めたパターン画像なんかもそれにあたるのか。とか考えると、そういう明らかに装飾的なものは違いそうだ、という一応の区別はできる。

視覚的な描画結果そのものを説明できるようになることで解決されたりなんかしたりして、仮にそうなったとすると、aria-hidden以前に、何を拠り所にしてどこに向けて実装するのが正解なのかってわからなくなる気がしました。話が飛躍しましたが…。そういうことを考えると、記事にある「どのような使い方がされても問題ないようにすること」の解釈は必ずしも一意にならないような気がして難しいなと感じた次第でした。

ふむふむ、やはりこのあたりの挙動は一貫しているわけではないのですね。altが空だとしてもAI等で説明をさせられるというのもおっしゃる通りですね。

「懸念が一般論としてあるだろう」という話をされていることはなんとなくわかっていたものの、僕の中では一般化できるほどに具体的な事例を知らなかったので参考にお聞きしたという次第でした。

ただそうなってくると、画像がimg要素で表示されているかそれ以外の方法で表示されてるかで事情が変わってきそうだとも一方で思いました。たとえば、background-imageとかsvg要素とか。でも将来的にUA/ATの進歩によっては、AOMとかも関係なく、

当エンジニアブログで実施したアクセシビリティ改善の方法についての解説 文字やアイコンのコントラスト比、focusしたときに表示されないツールチップ、重複する代替テキスト、「アクセシブルな名前」のないリンク、ターゲット領域を広げるための重複するリンク。これらの問題と解決策、その背景にある考え方についての解説。

ご指摘を踏まえてブログの内容を変更しました tech.plaid.co.jp/how-we-impro...

もっとも、スクリーンリーダーがすべてだとは考えてはいませんが（そもそもまだVoiceOverでしか調べていない）、aria-hidden=trueによってダウンロードの操作に影響を与えるケースを考えてみてもほかに存在し得る可能性が思いつきませんでした。

これって僕が何か思い違いをしていますか…？　トミーさんのお考えなどあればお聞きしたいです。

ご指摘ありがとうございます。言われてみるまで抜け落ちていた視点なので参考になりました。

ただ、これを踏まえて改めて調べてみると、VoiceOverでは画像はaltが空になっている時点でそもそもVoiceOverカーソルで選択すること自体ができませんでした。したがって、ダウンロードの操作もできないと思われます。

だとすると、画像のダウンロードを可能にしたければaltを設定することも併せて行わないと筋が通らないし、altが空になっているのであればaria-hidden=trueがついていてもそうでなくても実際は同じではないかと思い至りました。

[html-aam] Tests needed for `svg > title` when placed inside interactive elements · Issue #52459 · web-platform-tests/wpt We need tests for cases where svg > title is placed within interactive elements. According to the specification, when an svg element with a title element is placed within an interactive element, th...

とりあえずWPTにIssueを立ててみました github.com/web-platform...

UIの改善をしたいと思ったときにいろんな開発上の問題を手繰っていくと「まずはNode.jsのバージョンを上げるところから始めないといけない」みたいなことになるの仕方ないけど意味がわからない

このhoverキモ

初めて投稿したけど、Xの倍書けるので便利

- 件の記事では全体的にできるだけ端的でシンプルな説明にしたいと考えていたため、指摘のとおり「ロジックをすっ飛ばしている」結果になってしまった（という言い訳）。とはいえ、仕様を踏まえればこの説明を省くのは得策ではないことには賛同できる

というわけで、後ほど改めて記述内容を見直させていただきます。ご指摘ありがとうございました！

- 件のブログで採用されていたアイコンのライブラリの仕様上、svg要素の中身をいじれないので、aria-labelを使うほかない
- さらに言えば、記事では<svg role="img" aria-label="...">という例を紹介しているが、実際には<a href="..." aria-label="...">という実装を採用している。本当は前者の実装を採用したいが後者のようにしているのは、ライブラリで提供されるアイコンにデフォルトでaria-hidden=trueが付与されているため、これを上書きするのはコードの管理上煩雑になる懸念があると考えたため

正直この点は横着して説明を端折ってしまった部分ではあります。記事でaria-labelを採用している理由は次のとおりです。

- 記事にある通りツールチップの問題（まあこれは気にはなるけど自分としては重要ではない）
- title要素を使用するのはアクセシビリティサポーテッドの観点で十分でない（と記憶しているが、現状としてどうかはわからない）
- title要素を使用する場合はアクセシビリティサポーテッドの観点からaria-labelledbyで紐付けるのが安全だが、idの管理に手間がかかる