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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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