頭を殴られたことのないフロントエンド開発者として、私はアクセシビリティについて聞いたことがあるのは明らかです。 Web サイトを作成するときは、スクリーン リーダーで問題なく読めるように、いわゆるベスト プラクティスに常に従うようにしています。私と同じような仕事をしているほとんどの開発者は、スクリーン リーダーを実際に使用したことがないのではないかと思います。簡単な仕事ではないようですし、お金もかかると聞きました
。 1 か月前、私は 1 週間かけて盲人のふりをし、スクリーン リーダーを使用して Web サイトを閲覧し、視覚障害のあるユーザーがどのようにしてこれらのサイトを聞いているのかを理解しようとしました (写真と事実、以下を参照)。多くのことを学び、自分では気づいていませんでしたが、HTML の書き方が変わりました。アクセシビリティに関しては多くの神話や誤解があります。以下は確実で間違いのある誤解です:
試してみるまではわかりません、試してみると驚くでしょう実はそれは間違っています
。長い間、私はスクリーン リーダーが理解しやすいように、リンクを説明するタイトル テキストをリンクに追加するように常に努めてきました。これで、スクリーン リーダー は単純に title 属性のテキストを 読み上げないことが分かりました。つまり、スクリーン リーダーのユーザーに追加情報を追加することは... パンツを脱いでオナラする必要はありません。これは実際にページのアクセシビリティを低下させるため、重要な情報です。私は HTML 専門家の Jeffrey Zeldman に、リンクにタイトル テキストを追加すべきかどうか尋ねたところ、彼の返答は次のとおりでした:
@silktide 氏: 私たちはリンクのタイトル テキストとその保持方法を検討しています。画面外の読者はそれを気に入っています。それを使う理由があると思いますか?
@Zeldman は言いました: いいえ!使用しないでください。
これに関しては、「タイトル文字でアクセシビリティが高まると勘違いしていた」と具体的に書きました。
スクリーン リーダーとブラウザを混同しないでください。これらは同じものではありません。スクリーン リーダーは、Web ブラウザだけでなくデスクトップ全体を読み取ることができます。スクリーン リーダーは特別なタイプのブラウザではなく、使用しているソフトウェアからテキストを読み取るだけです。これは、視覚障害のあるユーザーが他のユーザーと同じブラウザを使用することを意味します ① 。私は一部の Web 開発者から、視覚障害のあるユーザーのエクスペリエンスをテストする最良の方法は、Lynx ② や w3m ③ などのわかりにくいプレーン テキスト ブラウザを使用することだと誤解されています。
翻訳者の追加コメント。 :
① デスクトップ上のブラウザのショートカット アイコンにマウスを移動すると、他のブラウザではインストール パスやソフトウェア名などのプロンプト テキストが表示されます。Chrome ブラウザのみが「このインターネットにアクセスします」と表示されます。この治療を望んでいるのは、おそらく視覚障害のあるユーザー向けです (完全に個人的な推測です)。
② Lynx は、テキスト強調機能を備えた端末で使用されるテキスト専用 Web ブラウザーです。
③ w3m (Encyclopedia) は、テーブル、フレーム、SSL 接続、カラーをサポートするオープンソースのテキストベースの Web ブラウザーです。
WebAIM の調査によると、Windows では、ほとんどのスクリーン リーダー ユーザーは Internet Explorer と Firefox を使用しており、他の一般的なブラウザでテストすると、視覚障害のあるユーザーの真のエクスペリエンスが得られない可能性があります。無料のスクリーン リーダー NVDA のユーザーは FireFox を使用する可能性が高いですが、ちょっとしたアドバイスです。泣ける真実をお話ししましょう。Web 開発者に愛されている Chrome ブラウザは、少数の視覚障害のあるユーザーだけが使用しています。
俳優のほかに、ボロボロの服を率先して着る人がいるでしょうか?それでは、どれだけのユーザーが JavaScript を無効にするか想像できるでしょうか? 10人に1人が持っていると聞いたことがありますが、それはもう昔の話です。昔は、あまりに素敵な服を着ていると反動的だとみなされたからです。現在、JavaScript は機能的に便利であるだけでなく、多くのサイトで洗練されたエクスペリエンスを実現するためにも必要です。視覚障害のあるユーザーは通常のブラウザを使用しているため、ブラウザでも JavaScript が有効になっていることが足の指でわかります。したがって、ARIA の役割によるキーボード ナビゲーションの強化など、JavaScript を使用してスクリーン リーダー ユーザーのアクセシビリティを強化することは完全に実現可能です。
翻訳者の追加コメント: ④ タオバオの Kissy ライブラリの UI モジュールの相互作用により、jQuery Mobile と同様に、aria のサポートが追加されました。
多くの Web サイト (Eye Weibo、Penguin Weibo など) は、たとえばページが一番下までスクロールしたときに、コンテンツを動的に読み込むことができます。その時が来ると、「もっと見る」をクリックしなくても、新しい Weibo が動的に読み込まれます。
当初、これはスクリーン リーダー ユーザーにとって悪夢になるだろうと思っていましたが、多くの視覚障害のあるユーザーが「これは史上最高のページネーションだ!」と言っているのを聞きました。ページを声に出して読むのは気まずいですが、2 ページ目をめくってタイトルやメニューをもう一度見るよりははるかに効果的です。
これは今でも熱い話題です。また、視覚障害者が動的読み込みを非常に熱心に行う状況にも遭遇しました。動的読み込みがすべての状況で使用されるわけではありません。コンテンツを動的に読み込む必要がある場合は、視覚障害者が動的読み込みにアクセスできないと想定しないでください。まずテストしてください。
視覚障害のあるユーザーは私たちと同じブラウザを使用していることが上記で確認されているため、CSS を無効にするという考えは明らかに誤りです。多くの場合、CSS はスクリーン リーダーが情報を読み取る方法に影響します。たとえば、display:none が設定されている要素は、スクリーン リーダーによって読み取られません。賢い人が、「メイン コンテンツに直接アクセスする」ためのリンクをページの上部に配置し、display:none を使用してユーザーが目で閲覧しないようにしました。隠しリンク全体⑤ 。
翻訳者の追加コメント:
⑤ テストによると、display:none がスクリーン リーダーによって無視されるだけでなく、visibility:hidden も無視されます。詳細については、以前の「」を参照してください。ユーザビリティの非表示」「関連コンテンツ。
まず最初に、アクセシビリティを高めるために画像 には alt 値が必要であることを認識してください。すべての画像に代替テキストを追加する必要があります (一部の装飾的な画像要素など)。この場合、alt 属性は必要ありません。強迫性障害があり、この HTML が alt なしでは不完全で不快に感じる場合は、空白スペース、つまり、
おいおい、これは問題だ、彼女に近づかないでくれ!タブ インデックスの目的は、スクリーン リーダーがコンテンツを読み取る順序の問題を解決することです。たとえば、誰かがパスワード ボックスの後ろに「パスワードを忘れた場合」リンクを挿入すると、パスワードが入力された後にタブ インデックスが作成されます。 [送信] ボタンではなく、[送信] ボタン上で、この時点で、tabindex を使用して、より適切な読み取り順序を決定する必要があります (これは、実際には WCAG 2.0 では「フォーカス順序」と呼ばれます)。ただし、ほとんどの場合、tabindex は状況をさらに混乱させ、ユーザーが誤ったロジックに従うようにするだけです。私は道に迷ってしまいます。 !
先週、ブログのコメント欄に足跡を残そうと思い、各テキストボックスにタブを設定したところ、確認コードを入力したボックスにどうやってもフォーカスが当てられませんでした。おばあちゃんが Chrome ツールを使用して調べたところ、すべてのボックスに tabindex が設定されていることがわかりましたが、この確認コードは軽蔑されています。このため、キーボードを使用してコメントを送信することが困難になります。フォーカスの順序を変更すると、解決するよりも多くの問題が発生することがよくあります。コンテンツを適切な順序に配置してから、タブインデックスに「サイヨウララ」と言います。日本語がわからないので、「さようなら」と言うべきです。たとえば、上記の「パスワードを忘れた場合」は、パスワード ボックスの直後ではなく、送信ボタンの下または後ろに配置するか、CSS を使用してテキスト ボックスの後ろに配置する必要があります。コードは次のとおりです。 input type="password" />パスワードを忘れた パスワードを忘れた
誤解 8: 視覚障害のあるユーザーはロール タグと HTML5 構造要素を使用して閲覧する
WebAIM による調査によると、視覚障害者の 35% 近くが文字マーカーをほとんど、またはまったく使用しません。この割合は問題ありませんが、スクリーン リーダーとブラウザが連携すると状況が変わります。すべての Web サイトでペルソナが使用されているわけではないため、ペルソナは信頼できる方法ではありません。ほとんどのスクリーン リーダー ユーザーは、(HTML 自体ではなく) ページ タイトルを使用して移動し、キーボード ショートカットを使用してあるページから別のページに移動します。
私自身も試してみましたが、特に Web サイト開発者がタイトルを正しく使用していない場合、重要なコンテンツをスキップするのは非常に簡単であることがわかりました。これは議論する価値のある誤解です。将来的には、ナビゲーションの信頼性が高まるため、視覚障害のあるユーザーが構造要素や ARIA 文字をさらに活用するようになると思います。ただし、スクリーン リーダー ユーザーが閲覧する方法はこれだけではないことに注意してください。
他の多くの人たちと同じように、私も実践することで学びます。アクセシブルな Web サイトの作成には負担が伴いますが、そのほとんどは退屈で理論的なものです。私自身スクリーン リーダーを使用するだけで、視覚障害のあるユーザーがどのように Web を操作するか、より良い Web サイトを作成する方法について多くのことを学びました。明らかに、あなたは目隠しをしていますが、それはあなたに真の視覚障害体験を与えるわけではありません。したがって、私はあなたのウェブサイトを使用する視覚障害のあるユーザーを見つけることをお勧めします(私の知る限り、ペンギンの QQ ソフトウェアはこれを行います)、または少なくとも方法を教えることをお勧めします。スクリーン リーダーを正しく使用してください。ユーザビリティに関する最初の記事を公開した後、何人かの視覚障害のあるユーザーと素晴らしい会話をしました。質問するだけで多くのことを学ぶことができます。私のように自分でやりたいタイプの人は、自分でやってみることで多くの貴重な経験を積むことができます。