ハクソク

世界を動かす技術を、日本語で。

アクセシブルなUIを構築する自己中心的な理由

343日前原文(nolanlawson.com)

概要

  • アクセシビリティ は道徳的理由だけでなく、 自己利益 の観点からも重要性を持つ。
  • セマンティックなマークアップは デバッグ性 や テスト性 を大きく向上。
  • ARIA属性やロール の活用で、UI設計や命名も明確化。
  • キーボード操作性 の向上は、開発者自身にも恩恵。
  • アクセシブルなUIは、 自分自身の作業効率化 にも直結。

アクセシビリティを自己利益で考える理由

  • アクセシビリティ は「道徳的に正しい」だけでなく、 開発者自身のため にも役立つ要素。
  • 「野菜を食べなさい」的な説得は効果が薄く、 自己利益 に基づく理由の方が行動変容を促進。
  • 本記事では 指摘や説教なし で、アクセシブルなUI構築が自分のためになる理由を解説。

デバッグ性の向上

  • divタグ乱用 （div soup）は、DevToolsでの 構造把握 が困難。
  • セマンティックな tableタグ や ARIAロール の利用で、 要素の役割 が明確化。
    • 例：<table>, <th>, <td>やrole="table", role="row", role="cell"などの活用。
  • CSS-in-JSなどでHTMLが煩雑化しても、 構造の意図が読み取りやすい。

命名の明確化

  • UIコンポーネントの命名 は難題だが、 WAI ARIAガイドライン で標準化可能。
    • 例：「autocomplete」「dropdown」→「combobox」。
  • ARIA属性やロール を使うことで、 一貫した命名 や CSSセレクタ としての利用が可能。
    • 例：[aria-selected="true"]でスタイリング。
  • ロールやARIA属性 に沿った思考で、 変数名やCSSカスタムプロパティ も直感的に設計。

テスト性の向上

  • アクセシブルなUI は、 テストコード の記述も簡潔・堅牢に。
    • 例：PlaywrightでgetByLabelやgetByRoleの活用。
  • divタグだらけ のUIでは、 テスト対象要素の特定 が困難かつ脆弱。
  • セマンティクスに基づくテスト は、UIのクラスや構造変更にも強い。

パワーユーザーへの配慮

  • キーボード操作 （Escでダイアログ閉じる、Enterで送信など）の未対応は 作業効率低下 の原因。
  • プロダクティビティツール （例：Slack, GMail）では、 Tabやフォーカス制御 の正確さが必須。
  • 開発者自身 もパワーユーザーであることが多く、 自身の体験向上 にも直結。

結論と今後への期待

  • 個人的理由 として、筆者は視覚障害の家族や知人の体験からアクセシビリティの重要性を痛感。
  • WebAIM調査 では、平均51件/ページのアクセシビリティエラーという現状。
  • アクセシブルなUI構築は 難易度が高いわけではない。最低限の対応で十分な効果。
  • 将来的には AIツール による自動化にも期待。
  • 「野菜を食べなさい」的な啓発 は限界。 自己利益 を動機としたアプローチが有効。
  • アクセシブルなUI構築 は他者のためだけでなく、 自分自身の作業効率化・快適化 にも繋がる。

Hackerたちの意見

自己中心的な理由でアクセシビリティに頼らざるを得ないなんて、悲しいよね。ほとんどの人が、もっとアクセスしやすい世界から恩恵を受けるってことを考えれば、"それだけの価値はない"って言うのを聞くと、本当に悲しくなる。これは、"私たちのシステムにはバグがあるけど、盲目のユーザーだけがそれを体験してほしい"って言ってるのと同じだよね。なんか、世界をそんな風に見るのは暗い気持ちになる。

└

"それだけの価値はない"って言うのを聞くと、本当に悲しい。企業はそのうち痛い目に遭うだろうね。私は大企業で働いていて、アクセシビリティに関して多くの企業や個人から連絡が来てる。これは、彼らがアクセシビリティの問題を抱えたアプリやサイトを作った結果、修正や全面的にやり直す時間が必要になるってこと。今や、いくつかの州ではADAにオンラインやデジタルなものが含まれているから、CAやNYのいくつかの法律事務所がアクセシビリティの訴訟を起こしてる。2024年だけで4,000件以上の訴訟があったけど、そのほとんどは州レベルでのもの。企業がオンラインアプリやサイトのアクセシビリティを無視するのはリスクだっていうのは、今や非常に現実的な脅威だと思う。やっとトレンドが変わりつつあって、企業がアクセシビリティをもっと真剣に考えるようになってきた感じがする。

└

希望を持たせるために言うと、今のアクセシビリティに関する情報の質と量は過去最高だと思う。ウェブ開発の環境が変わっても、アクセシビリティを正しく実現する難しさを軽視するコメントを見たことがあるけど、ウェブ標準が能力に追いついていなかったのも一因だと思う。でも、オープンソースコミュニティがアクセシビリティを優先事項として扱う意識があまりなかったのも大きい。今は、アクセシビリティを犠牲にすることなく、あらゆる種類のウィジェットを使った高品質なパッケージが見つかるよ。

└

全く同感だよ。毎日支援技術を使う障害者として、これは二つの問題だと思う。1. 企業や個人がソフトウェアを設計する際にアクセシビリティを考慮しない。私の経験では、いつも後から付け足す形になってる（これがさらに難しくする要因になってる）。例外もあるけど、私の経験では稀だね。2. 教育システムが、ほとんどの人にこのことを教えていない。特に障害者と関わるために教育システムに入らない限り、普通の学生が通常の授業を受けているときには、全く触れられない。少なくとも、私が学校にいたときは、先生がちょっとした話の中で触れることはあったけど、専用の授業はなかった。確かに、後半は「開発者」の問題だけど、障害者について全く知らない人や、ツールやスキルを与えれば何ができるかを知らない人が多いのも大きな問題だよ。誤解しないでほしいけど、興味を持って質問してくれる人には教えるのは嬉しいし、積極的に奨励もしてる。でも、そんなことをしなくてもいいはず。これは私たちの教育システムが教えるべきことだと思う。アクセシブルな世界は、ほとんどすべての面でみんなにとって良いものだよ。

└

さて、私の視点から世界がどう感じられるか想像してみて（100%盲目）。20代の頃は熱心だった。Debianに参加して、Debianアクセシビリティプロジェクトを立ち上げた。 obscureな支援技術ソフトウェアのパッケージをたくさん作った。EclipseやQtのような主要製品にa11yのバグを提出して、実際に修正してもらったこともあった。少なくとも少しは変化をもたらせると思ってたんだ。でも、時が経つにつれて経験が積み重なっていった。実際、貢献者のほんのわずかな部分しか、アクセシビリティのようなニッチな分野を手伝うことにやる気がないことを学んだ。「自分の痒いところを掻く」っていうFLOSSの態度が、アクセシビリティが進まない理由だってことも分かった。そして、GNOME3が登場して、残っていたやる気や無邪気さが一気に消えた。IBMとSunは2008年末にアクセシビリティの取り組みをやめてしまったし、CORBAからDBusへの移行はアクセシビリティの取り組みを数年後退させた。私は打ちひしがれたし、たくさんのことを学んだ。その後、ウェブアクセシビリティはどんどん悪化していった。最近のほとんどのモダンウェブは、私のような人にはアクセスできないし、機能するアプリやサイトはほんの一握りだけ。廊下はどんどん狭くなっていってる。40歳以上の盲目の人が、会社のIT再編成で仕事を失う話をたくさん知ってる。デジタルデバイドはここにあって、誰も本当にそのことを話さなくなった。正直言って、「知っている人たち」はほとんど諦めてしまったんだ。悲しい話だよ。資本主義は小さなマイノリティに対しては全く配慮しようとしない。これは事実で、私が完全に受け入れるのに20年以上かかった。

└

100%同意だし、どんな理由でも改善は大歓迎だよ。ほとんどの人が「アクセシビリティ」の恩恵を受けるなら、それは本当のアクセシビリティじゃない。壊れたUIを直してるだけだよ。デザイナーは、普通の人にすら使いやすいUIを提供しないことを恥じるべきだし、ましてや障害者のことなんて考えてないよね。

└

それよりひどいよ。アクセシビリティは実際にはビジネスが望むこととは逆のことなんだ。文化的な背景や（時には）法的な支援が、ユーザーの自律性を守る最後の防衛線になってる。支援ソフトはただの別のユーザーエージェントで、ベンダーが意図したのとは違う方法でページを解釈する非標準ブラウザなんだ。スクリーンリーダーが盲目の人を助ける機能は、他の人が広告やアップセルを見つけてカットするのを助けたり、「ウェブデザイン」と呼ばれる濃い汚水から逃げたり、本来の目的に直行するのを可能にするんだ。アクセシビリティがなければ、ウェブはまたFlashみたいになって、自動的には解析できないものになっちゃう。もし文化的や法的な理由で障害者に配慮しなければ、私たちはすでにウェブ上で完全に自律性を失って、テーマパークの中で何かを買うためにお金を払うだけの存在になってたよ。段差をなくすって？ユーザーが「旅」を早く終えて、あまりお金を残さないために？ -- 最近、LLMがこの状況を変えたけど、今のところ私たちに有利に働いてる。短期的には、ベンダーが何をしようと、どんなウェブサイトも機械で解釈可能にできるから。でも、これは始まりに過ぎない。ベンダーがGenAIを使ってユーザーを妨害する方法はまだわからない。

└

これらは素晴らしい人間的な感情だけど、価格の話になると変わってくるね。価格が関わると、専門的なアクセシビリティソフトのアプローチが多くの場合、はるかに効果的に思える。理想的なシナリオを考えてみて。真に素晴らしい、啓蒙されたリーダーシップの下にあるSaaS。チームリーダーは、1人の集中した開発者が2週間のスプリントで、全員にとって本当にアクセシブルにするための最後の一歩を踏み出せることを知っている。そうした開発者の時間の完全なコストは、非常に楽観的なシナリオで1000ドル、アメリカのチームなら4,000〜8,000ドルに近い。まず、アクセシビリティに向けたその追加のステップは、果たして元が取れるのか？次に、もしそうなら、それはその開発者がその2週間のスプリントでできることの中で、実際に収益を最大化する動きなのか？時々、稀にそうなることもあるけど、実際には市場調査が逆の結果を示すと思う。これは、物事が本当にどれくらいの時間がかかるか、リーダーシップが本当に啓蒙されているのかどうかなど、いつもの戦争の霧を加える前の話だよ。高品質のアクセシビリティ向上ソフトを作ることに特化した会社の代替モデルを考えてみて。このソフトは、ユーザーが使う可能性のあるほとんどすべてのプログラムとの互換性レイヤーとして機能することを目指している。例えば、頻繁にメモリ内のスクリーンショットを使って、盲目のユーザーが何が起こっているのかを理解する手助けをするかもしれない。あるいは、FOSSの開発者が、彼らが実行できるすべてのターミナルプログラムがスクリーンリーダーとうまく動作するようにすることに集中するだけかもしれない。このモデルには多くの利点があって、特に小さな顧客基盤のために他のすべての人に重い税金を課さないという点がある。これは非常に専門的で、顧客向けの仕事でもある。ソフトウェアの中で、専用のフロントエンドやUI/UXの専門知識が必要な場所があるとしたら、それはスクリーンリーダーの互換性レイヤーを設計している人だろう。人気の拡張機能「Dark Reader」をこのパラダイムの例として挙げるけど、ほとんどのウェブサイトで素晴らしい仕事をしていて、うまくいかないウェブサイトでは簡単に無効にできるし、ウェブサイトの運営者には何のコストもかからない。美的理由でこれに異議を唱える人もいるかもしれないけど、同じソフトウェアを使うために、まるごと別のインターフェースレイヤーを走らせるのはちょっと不格好に感じるよね。この美的な違反は、今回は誤解されていると思う。状況を考えると、この作業は専門化から大きな恩恵を受けると思う。実際、2025年にウェブをアクセシブルにするのは、2000年よりずっと簡単になっている。なぜなら、第三者が状況を劇的に改善して、アクセシビリティレイヤーに接続するのが「単に」セマンティックに正しいHTMLを書くことを必要とするだけになったから。今、もし「Dark Reader」が存在して、ページのスクリーングラブから明らかだけど、ウェブデザイナーにはわからない細かい詳細をページに挿入できるとしたら、それはほとんどのビジネスにとってはるかに良いアプローチになるだろうね。

└

自己中心的な理由に頼らなくて済むといいんだけどね。賛成だけど、それって人間がもっと優しくて共感的であればいいって願ってるのと同じだと思う。もしそうだったら、世界は今とは全然違うくらい良くなってるだろうね。

ウェブ版のカーブカット効果って感じかな。デジタル（そして物理的な）アクセシビリティはみんなに利益をもたらすよね。

└

カーブカットはそれほど良くないし、今のトレンドは高架横断歩道だよ。スムーズな舗装も大きな違いを生む。妻が車椅子を使っているから、こういう小さなことが彼女の生活をどれだけ改善するかは言い尽くせない。 > デジタル（そして物理的な）アクセシビリティはみんなに利益をもたらす でも面白いことに、この分野では車椅子用の歩道が視覚障害者用の tactile paving としばしば衝突することがある。あの触覚の突起はカーブの内側にあることが多いから、車椅子がそれを避けることができないことが多いんだよね。

└

私たちはデジタル（および物理的）アクセシビリティの恩恵を受けている。そうだったらいいのに。問題は、ウェブ上のビジネスが、アクセスできないことから直接利益を得ていることなんだ。注意経済は摩擦からお金を生む。典型的なウェブサイトは、ユーザーが少し迷子になるような迷路になっていて、商品や第三者の広告、トラッキングにさらされる時間を最大化するためなんだ。段差をなくすことは、どこに行けばいいか教えて、少ない労力でそれを実行できるようにするだけだから、迷路を早く抜けられるようになって、ビジネスはお金を失うんだ。

もう一つの自己中心的な理由は、実際のHTML要素を使うとウェブページがすごくうまく動くってこと。特に、いろいろ組み合わせるときにね。Reactプロジェクトでは、いくつかのコンポーネントライブラリを混ぜて包括的なUIを作ることが多いけど、これらのライブラリは微妙に動作が異なる。組み合わせると、その違いが重なってくる。ダイアログを閉じたときにボタンにフォーカスが戻らなかったり、ページに4種類の青が使われていたり、日付入力が自国の形式を使っていなかったり。HTMLのプリミティブ、例えばラベル付きの入力や新しいポップオーバーAPI、ダイアログ、details + summary要素を使うと、ブラウザベンダーによって作られた動作がすべて統一されていて、相互に組み合わせるように設計されてる。これは本当に天と地の差があって、しかも無料なんだよね。私たちは与えられた素晴らしいツールを活用していない。

└

君に同意できたらいいんだけど、私の経験では、組み込みのコントロールには多くの欠陥があって、何年も何十年も停滞してるんだよね。

└

最後にネイティブの日付入力を見たのはいつだっけ？（もし見たことがあるなら？）

└

かなり多くのサードパーティ製コントロールがアクセシビリティに配慮されていて、正しいARIAやその他のアクセシビリティマークアップが揃ってるよ。

ウェブアプリをデバッグしようとすると、UIが「divスープ」だとDevToolsで自分を見失うのが難しい それはまだマシな方だよ。Tailwind CSSを追加してみて。Tailwind CSSの初期から見守ってきて、かなり深刻な哲学的な意見の相違があると思ってたけど、最近本気で試す機会があって、DevToolsでの扱いが信じられないほど厄介だと思った。みんなはこれにどう対処してるの！？ 何を言ってるのか分からない人は、https://tailwindcss.com/ の下の方にリンクされているサイトを見てみて。Inspector/Elementsパネルでは、DOMツリーが膨れ上がったゴミのようになっていて、クラス属性はインラインスタイルに等しいかそれ以上のもので、普通は数百文字にもなるから、意味のあるクラスを使うことを妨げて、まともなセレクタを使う代わりに、膨大に重複している。ほとんど良いものは、data-sentry-{element,component,source-file}属性を持っているものだよ。スタイルのサブパネルは全くナビゲートできなくなる。 （Tailwindのすべてが悪いわけじゃないけど、過去よりも限られたユーティリティスタイルのアプローチを使うことになると思うし、私の中で考えさせられることがいくつかある。マーケティングスタイルのウェブサイトよりもアプリに適していると思う。でも全体的には私には合わない。）

└

意味のあるクラスを使うのを妨げて、まともなセレクタを使う代わりに、膨大に重複したものを作ることになるよね。大きなサイトでは「意味のあるクラス」も同じように混乱してて、重複がすごく多くて、偶発的なカスケードに悩まされることになる。

└

何年も前からこう思ってたし、2年前にブログ記事も書いたんだよね。残念ながら、状況は良くなってないみたい。OPみたいな投稿があって、著者が自分たちのやり方に問題があるって気づくけど、Tailwindが大きな要因だってことを見落としてるんだよね。「裸の王様」ってやつだね。みんなも裸になっちゃう。

└

この記事の文脈では、まだ意味のあるセマンティック要素やaria-selectedのような属性が含まれてるよ。本当に必要なら、普通のクラスを追加することもできるしね。

└

意味がないけどカラフルでキラキラしたCSSが、トルエンで薄められて何年も積み重なってる感じ！ https://en.wikipedia.org/wiki/Fordite いつか人々は、archive.comにアーカイブされた今日のウェブページのスライスを切り出して、宝石のように磨いてジュエリーとして身に着けるようになるんだろうな。LLOOOOMMは、Minskyの「Society of Mind」アプローチを使って、焦点を合わせてスタイルや専門知識を様々なタスクに適用できるキャラクターをシミュレーションしてるよ。ウェブページをデザインするために、ユーザーインターフェースやデザインの専門家を集めて、明確でアクセスしやすいものを作る手助けをしてもらえるし、他のキャラクターを使って自分の美的感覚や声を表現させることもできる。実際にシミュレーションされたキャラクターを「スタイルシート」として使って、指示に従って組み合わせたり調整したりできるんだ。ここに、Klaus NomiがLLOOOOMMや「キャラクターを生きたスタイルシートとして」について、自分の声で書いた例があるよ。彼は友達やアクセシビリティを支持する専門家たちの助けを借りてる。 https://donhopkins.com/home/lloooomm/klaus-nomi-lloooomm-man... >このページは生成されました: Klaus Nomi + Jakob Nielsen + Ben Shneiderman + Bret Victor >「LLOOOOMMでは、すべてのウェブページがパフォーマンスであり、すべての機能が歌であり、すべての変数がコードの宇宙交響曲の音符です。」 — Klaus Nomi, デジタルオペラ歌手 そのコツ（秘密じゃないけど）は、LLMがすでにこれらのトピックや人々について膨大な知識を持っていることで、シミュレーションされたキャラクターがレンズを提供して、具現化したり、洗練させたり、会話したり、進化したり、問題を解決したり、経験から学んだり、その知識や知恵を覚えておくことができるんだ。さらに、彼らは自分たちのデザインガイドラインについて具体的な詳細を持って、キャラクターモデル（マークアップやyamlファイル）を強化することもできるし、自己反省してお互いに話したり編集したりもできる！魔法のようなのは、よく知られた実在のキャラクターやフィクションのキャラクターの人生の作品を、名前を挙げるだけで#includeできることなんだ（究極だけどフィクションのUIデザイナーをゼロから作るためにトークン予算を無駄にする代わりに）。それから彼らのWikipediaページや彼らが書いた投稿や記事、論文をコピー＆ペーストして、キュレーションして、焦点を合わせて、洗練することができる。ゼロから始めるよりもずっと少ない言葉で済むよ！代わりに、すでに「焼き込まれた」キャラクターの研究や出版物の人生の作品から始めるんだ。Alan Kayはオブジェクト指向プログラミングや言語設計の手助けが得意で、Marvin MinskyはAIや哲学について深く語るし、Seymour Papertは子供たちがプログラミングを学ぶ手助けをするのが大好きだし、Linus Torvaldsはgitやlinuxの手助けや、厳しいけど洞察に満ちたコードレビューが得意なんだ。Dangは、意見が多様で熱心なキャラクターたちの間で情熱的な議論を引き起こしたいときに呼ぶべき守護聖人だよ。もし炎上が起きたら、Dangはファンタジアの指揮者役のミッキーマウスを呼び出して、火を消すために水をかけるほうきの軍隊を呼び寄せることができる！ ;) LLOOOOMMに関するもっとたくさんのことは、近々GitHubに公開する予定だよ。 https://www.youtube.com/watch?v=Sn057QrCUm8&list=PLX66BqHq0q...

└

開発ツールだけじゃなくて、その混乱はソースコードにもあるからね…

アクティブクラスはここでは明らかに冗長だよね。もし .active セレクタに基づいてスタイルを設定したいなら、[aria-selected="true"] でスタイルを設定するのも全く同じくらい簡単だよ。10年以上前のことだけど、クラスセレクタの方がプロパティセレクタよりもパフォーマンスが良いって曖昧に覚えてる。

└

最近のサイトにはJSが山盛りだから、セレクタのパフォーマンスなんて心配することじゃないよ。

└

ここに著者がいます。実はCSSセレクタのパフォーマンスについてちょっと調べたんですよ。リンクはこちらです: https://nolanlawson.com/2023/01/17/my-talk-on-css-runtime-pe... で、要するに、クラスセレクタは属性セレクタよりも若干パフォーマンスが良いってことです。理由は、属性の「名前」だけがインデックスされていて、値はインデックスされてないからです。でも、99%のケースでは、そんなに大きな問題じゃないので、早まった最適化はしない方がいいですね。まずは自分のセレクタのパフォーマンスを測ることをおすすめします: https://developer.chrome.com/docs/devtools/performance/selec...

驚くほど多くのサイトにとって、EUの「欧州アクセシビリティ法」に基づいて、11日後からアクセシブルであることが法的に求められることを忘れないでね。[1] すべてのeコマースシステムは、WCAG 2.1のAAレベルを満たさなければならない。eコマースは、ビジネスと消費者の間で製品やサービスの契約を結ぶために設計されたオンラインシステムと定義されている。唯一の例外は、マイクロ企業の場合で、「従業員が10人未満で、年間売上高が200万ユーロを超えず、年間バランスシート総額が200万ユーロを超えない企業」とされている。[1] https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng (編集: Y-barからのURLを修正)

└

あなたのURLは期限切れのようです。いずれにせよ、「Document 32019L0882」は6月28日に発効します: > 2019年4月17日の欧州議会および理事会の指令 (EU) 2019/882、製品およびサービスのアクセシビリティ要件に関するもの（EEA関連のテキスト） https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng (このリンクは永久的だと思う)

└

今学期の大学の授業でWCAGを勉強したんだけど、専門家たちが「アクセシブルなウェブページについて知っておくべきことリスト」を作るために集まったのに、まだ多くのウェブサイトがそれを気にしてないのが本当に驚きだよね。ちょっとスクロールするだけで、すごく役立つヒントだってわかるのに。アクセシブルなものがあれば、普通の人にとってもより良い体験になるかもしれない。ちょっと関係ないけど、私が働いてる会場には、ステージのライトを管理するコンソールがあって、保存ボタンと削除ボタンが隣にあるんだ。それはインターフェースとして最悪の部類だと思う。

大規模な政府のフォームアプリケーション（ページ数が多く、サブセクション、モーダル、バリデーションなどがある）に取り組んでいるとき、もちろんアクセシビリティに関して厳しいルールがあったよ。でも、それのおかげで作業やデバッグ、テストがすごく楽になった。キーボードでアクセスできるから、すぐにテストしたり、必要な状態にするのが簡単だった。タブ、タブ、文字を入力、タブ、エンターっていう筋肉記憶があったし、よく使うことにはブックマークレットも作ってた。

アプリ（iOSネイティブ）やバックエンドの開発をしてるけど、障害者が多い層を対象にしてるから、アクセシビリティには力を入れてるんだ。ネイティブiOSのコーディングで重要なのは、早めに始めることだね。後からアクセシビリティを追加するのは面倒だから。

└

ちょっと気になるんだけど、そのデモグラフィックってどんな感じ？

ブラウジングのときにVimiumを使うのにハマっちゃったんだけど、実際の要素はJSの代替品よりずっと使いやすいよ。 https://chromewebstore.google.com/detail/vimium/dbepggeogbai...

これらはまあまあのポイントだね。ただ、例えばアクセシブルであるためにテーブルを使う必要はないと思う。正しいセマンティクスやARIAタグを含めて、スクリーンリーダーが何が起こっているかを理解できるようにすれば、好きなものを使うのは全然問題ないよ。著者があまり強調してないと思うのは、アクセシビリティの考慮事項の多くが視覚的で、リアルタイムで、または身体的な性質を持っていることだよ。アクセシブルなUIは、スクリーンリーダーにページの構造を伝えるだけじゃない。時にはユーザーが耳が聞こえないとか、色盲だったり、細かい動作が苦手だったり、コンピュータを使うときに身体的な疲労を感じたりすることもある。時には盲目じゃないけど、大きな文字やコントラストのある色が必要で、アプリケーションを迅速かつ正確に使うために必要なこともある。新しいものを表示しているときは、すべてのユーザーにそれを明確に知らせる必要がある。多分、強調されてないのは、多くのコンポーネントライブラリ（Prime、Material... すべて）にアクセシビリティのバグがあって、誰もそれを見つけないことだね。ほとんどの人が気にしないから。もしオープンソースのコミットに名前を残したいなら、これは本当に簡単に始められる方法だよ。ソース: 複数のWCAG監査を行ったことがあるから。 https://github.com/primefaces/primeng/pull/15161/commits/ea4...