StackExchangeサイトのアクセシビリティツール
私は今学期に学校でHCIクラスを受講していますが、現在のオンラインプラットフォームのデザインがアクセシビリティなどの特定の領域でどのように求められているかが非常に明白です。
StackExchangeを含むほとんどのWebサイトに、色反転、音声入出力などの基本的なアクセシビリティツールがないのはなぜですか？
これを容易にするツール（ブラウザ拡張機能、スクリーンリーダー）があることは知っていますが、それらのいくつかをWebサイト自体に配置しても、アクセシビリティと使いやすさが向上するだけです。
プラットフォームの観点から、設計、統一性、実現可能性、努力と結果のトレードオフに関して実装の問題があるかどうか疑問に思っていました。そのため、（当然のことながら）これらのツールが存在するはずです。
例としてスクリーンリーダーを見てみましょう。
お金の価値はありません。
一般的に、支援技術を必要とするユーザーの数は、支援技術を必要としないユーザーと比較して、かなり少ないです。スクリーンリーダーのカスタム実装をWebサイトに装備することは、ユーザーにのみメリットをもたらす非常に大きなプロジェクトになるでしょうその1つのサイトの（小さいオーディエンス）。
ただし、ユーザーのために機能するスクリーンリーダーの開発任意のサイトのは、はるかに大きな数です。
それは実用的ではありません。
サイトであってもdidスクリーンリーダーをサイトに接続できます。視覚障害者はどのようにしてそれを利用する方法を知っていますか？
一貫性のない動作。
ユーザーdidがスクリーンリーダーを利用できたとしても、サイトAのスクリーンリーダーがサイトBのスクリーンリーダーと比較してどのように動作するかを予測する方法はありません。
さらに、スクリーンリーダーのカスタマイズは、設定を全体に適用するのではなく、その1つのサイトにのみ適用できるようになりました。
（確かにもっと理由があります...）
それは単一責任の原則に違反していると言えるでしょう。 Stack Exchangeが独自の画面読み上げ技術をサイトに実装したとしましょう。それはすばらしいことですが、今では維持およびテストする必要があり、追加のオーバーヘッドになります。また、ユーザーがStack Exchangeツールにその仕事を任せるためには、NVDAなど、インストールした可能性のある技術を使用する必要がないことも意味します。また、自分のスクリーンリーダーの設定と一致するようにStack Exchangeツールを再構成する必要があります。StackExchangeツールが機能と一致しない場合は、ツールを切り替えて、競合しないことを期待する必要があります。
より簡単なことは、ユーザーが実行している可能性のある独自のスクリーンリーダーを使用して、ブラウザープログラムとOSを実際に操作できるようにすることです。 JavaScriptの範囲外です。
さらに、サイトが行う必要がある主要なこと、およびStack Exchangeが大部分を行うことは、セマンティックマークアップの使用です。つまり、<h1>タグ、<label>タグ、aria属性、およびOSレベルのアクセシビリティツールがフックとして使用し、ユーザーに何が起こっているのかを説明できるようにするもの。
同様に、OSは、グラフィックスディスプレイレベル全体に適用できるハイコントラスト機能を提供できます。独自のハイコントラストスタイルシートを提供することは良いことですが、それを同時に有効にすると、オペレーティングシステムがハイコントラストを有効にする場合、それらはキャンセルされるか、無効になります。
つまり、Stack Exchange doesにはアクセシビリティ機能がありますが、特定の、潜在的に悪い実装を強制することはありません。