スクリーンリーダーを使用して1日Webを使用しました

この記事は、ユーザーの特定の人口統計を表す、さまざまな制約の下でWebを使用しようとするシリーズの一部です。 実在の人々が直面している困難のプロファイルを高めたいと思います。それは、彼らのニーズに共感する方法で設計および開発すれば回避できます。 前回は、キーボードだけで1日Webをナビゲートしました。 今回は、画面を避けて、スクリーンリーダー付きのWebを使用しています。

スクリーンリーダーとは何ですか？

スクリーンリーダーは、画面上のもの（テキスト、画像、リンクなど）を解釈し、視覚障害者が消費して操作できる形式に変換するソフトウェアアプリケーションです。 スクリーンリーダーユーザーの3分の2は、スクリーンリーダー出力として音声を選択し、スクリーンリーダーユーザーの3分の1は点字を選択します。

スクリーンリーダーは、ワードプロセッサ、電子メールクライアント、Webブラウザなどのプログラムで使用できます。 これらは、アプリケーションのコンテンツとインターフェイスを、スクリーンリーダーで読み取ることができるアクセシビリティツリーにマッピングすることで機能します。 一部のスクリーンリーダーは、特定のプログラムを手動でツリーにマップする必要がありますが、他のスクリーンリーダーはより一般的で、ほとんどのプログラムで機能するはずです。

Windowsで最も人気のあるスクリーンリーダーはJAWSであり、スクリーンリーダー市場全体のほぼ半分を占めています。 これは商用ソフトウェアであり、ホームエディションの価格は約1,000ドルです。 Windowsのオープンソースの代替手段はNVDAです。これは、デスクトップ上のすべてのスクリーンリーダーユーザーの3分の1弱で使用されています。

Microsoft Narrator 、 System Access 、 Window-Eyes 、 ZoomText （フルスクリーンリーダーではなく、読み取り機能を備えたスクリーン拡大鏡）など、他の選択肢もあります。 これらの合計は、スクリーンリーダーの使用量の約6％に相当します。 Linuxでは、Orcaはデフォルトで多くのディストリビューションにバンドルされています。

macOS、iOS、tvOSにバンドルされているスクリーンリーダーはVoiceOverです。 VoiceOverは、デスクトップスクリーンリーダーユーザーの11.7％を占め、モバイルのスクリーンリーダーユーザーの69％にまで上昇します。 モバイルスペースの他の主要なスクリーンリーダーは、AndroidのTalkback （29.5％）とSamsungのVoice Assistant （5.2％）で、これ自体はTalkbackに基づいていますが、ジェスチャーが追加されています。

私はMacBookとiPhoneを持っているので、この記事ではVoiceOverとSafariを使用します。 SafariはVoiceOverで使用することをお勧めするブラウザです。どちらもAppleによって管理されており、一緒にうまく機能するはずだからです。 別のブラウザでVoiceOverを使用すると、予期しない動作が発生する可能性があります。

スクリーンリーダーを有効にして使用する方法

私の説明はVoiceOver向けですが、選択したスクリーンリーダーに同等のコマンドがあるはずです。

デスクトップ上のVoiceOver

これまでスクリーンリーダーを使用したことがない場合は、気が遠くなるような経験になる可能性があります。 それは聴覚のみの経験に向かう大きなカルチャーショックであり、騒音の猛攻撃を制御する方法を知らないことは不安です。 このため、最初に学習したいのは、それをオフにする方法です。

VoiceOverをオフにするためのショートカットは、オンにするためのショートカットと同じです： ⌘ + F5 （ ⌘はCmdキーとも呼ばれます）。 タッチバーを備えた新しいMacでは、ショートカットはコマンドキーを押したままTouchIDボタンを3回押すことです。 VoiceOverの話し方が速すぎませんか？ VoiceOverユーティリティを開き、[音声]タブを押して、それに応じてレートを調整します。

オンとオフの切り替えをマスターしたら、 Ctrlキーと⌥キー（後者のキーは「オプション」とも呼ばれます）の「VoiceOverキー」（実際には2つのキーを同時に押す）の使い方を学ぶ必要があります。 」またはAltキー）。 VOキーを他のキーと組み合わせて使用​​すると、Webをナビゲートできます。

たとえば、 VO + Aを使用して、現在の位置からWebページを読み取ることができます。 実際には、これはCtrl + ⌥ + Aを押し続けることを意味します。 VOが何に対応するかを覚えているのは最初は混乱しますが、 VOの表記は簡潔さと一貫性のためです。 VOキーを別のものに構成することは可能であるため、誰もが従うことができる標準的な表記法を使用することは理にかなっています。

VOキーと矢印キー（ VO + →およびVO + ← ）を使用して、DOMの各要素を順番に確認できます。 リンクに出くわしたら、 VO + Spaceを使用してクリックできます。これらのキーを使用して、フォーム要素を操作することもできます。

ハザ！ これで、VoiceOverについて十分に理解し、Webをナビゲートできます。

モバイルでのVoiceOver

VoiceOverをオンにするためのモバイル/タブレットのショートカットはデバイスによって異なりますが、通常はホームボタンの「トリプルクリック」です（設定でショートカットを有効にした後）。

Two-Finger Swipe Downするコマンドを使用して現在の位置からすべてを読み取ることができ、 Swipe Right or LeftしてDOM内の各要素を順番に選択できます。

これで、デスクトップと同じくらいiOSVoiceOverについて知ることができます。

コンテンツタイプによるナビゲート

目の見えるユーザーとしてWebをどのように使用するかを考えてください。 すべての単語を上から下に順番に注意深く読んでいますか？ いいえ。人間は設計上怠惰であり、興味深い情報をできるだけ早く検索するためにページを「スキャン」することを学びました。

スクリーンリーダーのユーザーには、これと同じ効率性のニーズがあるため、ほとんどの場合、見出し、リンク、フォームコントロールなどのコンテンツタイプごとにページをナビゲートします。 これを行う1つの方法は、 VO + Uでショートカットメニューを開き、 ←および→矢印キーで目的のコンテンツタイプに移動してから、 ↑↓キーでこれらの要素を移動することです。

これを行う別の方法は、「クイックナビゲーション」を有効にすることです（ ←を同時に→と押し続けることによって）。 クイックナビゲーションを有効にすると、 ←または→の横にある↑矢印を押したままにして、コンテンツタイプを選択できます。 iOSでは、 Two-Finger Rotateジェスチャを使用してこれを行います。

コンテンツタイプを選択したら、 ↑↓キー（またはiOSではSwipe Up or Down ）を使用して各ローターアイテムをスキップできます。 それを覚えておくのが大変だと感じた場合は、この非常に便利なVoiceOverチートシートを参照用にブックマークしておく価値があります。

コンテンツタイプを介してナビゲートする3番目の方法は、トラックパッドジェスチャを使用することです。 これにより、iPad / iPhoneのiOSでVoiceOverを使用する方法に近づきます。つまり、スクリーンリーダーコマンドのセットを1つだけ覚える必要があります。

OSXの組み込みトレーニングプログラムで、ジェスチャーベースのナビゲーションや他の多くのVoiceOverテクニックを練習できます。 [システム環境設定]→[ユーザー補助]→[VoiceOver]→[VoiceOverトレーニングを開く]からアクセスできます。

チュートリアルを完了した後、私は行くのがめったにありませんでした！

ケーススタディ1：YouTube

YouTubeで検索

SafariツールバーのYouTubeホームページに移動すると、VoiceOverからCtrl + ⌥ + Shift + ↓でWebコンテンツに「ステップイン」するように指示されました。 同じメカニズムが埋め込みコンテンツと一部のフォームコントロールに適用されるため、すぐにWebコンテンツにステップインすることに慣れます。

クイックナビゲーションを使用すると、フォームコントロールを介してナビゲートし、ページ上部の検索セクションに簡単にスキップできました。

質の高いコンテンツを検索しました。

そして、検索ボタンに移動しました。

しかし、 VO + Spaceでボタンをアクティブにすると、何もアナウンスされませんでした。

目を開けると検索が行われ、ページに結果が表示されましたが、音声だけで知る方法はありませんでした。

困惑して、私はdevtoolsを開いた状態で自分のアクションを再現し、ネットワークタブを監視していました。

疑われるように、YouTubeは「クライアント側レンダリング」と呼ばれるパフォーマンス手法を利用しています。これは、JavaScriptがフォームの送信をインターセプトし、検索結果をインプレースでレンダリングして、ページ全体を再描画する必要がないようにすることを意味します。 通常のリンクのように検索結果が新しいページに読み込まれていれば、VoiceOverは私がナビゲートするための新しいページをアナウンスしていたでしょう。

クライアントがレンダリングしたアプリケーションのアクセシビリティに特化した記事全体があります。 この場合、検索の送信が成功したときにアナウンスするaria-liveリージョンをYouTubeに実装することをお勧めします。

ヒント1： aria-liveリージョンを使用して、DOMに対するクライアント側の変更をアナウンスします。

 <div role="region" aria-live="polite" class="off-screen"></div> <form> <label> <span class="off-screen">Search for a video</span> <input type="text" /> </label> <input type="submit" value="Search" /> </form> <script> document.getElementById('search-form').addEventListener('submit', function (e) { e.preventDefault(); ajaxSearchResults(); // not defined here, for brevity document.getElementById('search-status').textContent = 'Search submitted. Navigate to results below.'; // announce to screen reader }); </script>

騙されて見るべき検索結果があることがわかったので、目を閉じて、Quick Navの「見出し」モードに切り替え、そこから結果をステップスルーして、結果の最初のビデオに移動しました。

YouTubeでビデオを再生する

YouTubeビデオページをロードするとすぐに、ビデオが自動再生されます。 これは私が日常の使用で大切にしていることですが、VoiceOverと混ぜて話し合うと、これは辛い経験でした。 後続の動画の自動再生を無効にする方法が見つかりませんでした。 私が本当にできることは、次のビデオをロードし、 CTRLを押してスクリーンリーダーのアナウンスを停止することだけでした。

ヒント2：自動再生を抑制する方法を常に提供し、ユーザーの選択を覚えておいてください。

ビデオ自体は、対話するためにステップインする必要がある「グループ」として扱われます。 ビデオプレーヤーの各オプションをナビゲートすることができましたが、これには嬉しい驚きがありました。Flashの時代にはそうではなかったと思います。

しかし、プレーヤーの一部のコントロールにはラベルがないことがわかったため、「シネマモード」は単に「ボタン」と読み上げられました。

ヒント3：常にフォームコントロールにラベルを付けます。

スクリーンリーダーのユーザーは主に視覚障害者ですが、約20％が「ロービジョン」に分類されているため、ページの一部を見ることができます。 したがって、スクリーンリーダーのユーザーは、「シネマモード」をアクティブにできることを引き続き評価できます。

これらのヒントは重要度の高い順にリストされていませんが、もしそうなら、これが私の一番です。

ヒント4：スクリーンリーダーのユーザーは、目の見えるユーザーと機能的に同等である必要があります。

「シネマモード」オプションのラベル付けを怠ることにより、スクリーンリーダーユーザーを他の方法で使用する可能性のある機能から除外しています。

とは言うものの、機能がスクリーンリーダーに適用できない場合があります。たとえば、コンテキストのない数字のジブリッシュとして読み取られる詳細なSVG折れ線グラフです。 このような場合、特別なaria-hidden="true"属性を要素に適用して、スクリーンリーダーで完全に無視されるようにすることができます。 フォールバックとして、画面外の代替テキストまたはデータテーブルを提供する必要があることに注意してください。

ヒント5： aria-hiddenを使用して、スクリーンリーダーユーザーに適用できないコンテンツを非表示にします。

一部のコンテンツを巻き戻すことができるように、再生位置を調整する方法を理解するのに長い時間がかかりました。 スライダーに「ステップイン」したら（ VO + Shift + ↓ ）、 ⌥ + ↑↓を押したまま調整します。 私には直感的ではないように思えますが、Appleが物議を醸すキーボードショートカットの決定を下したのはこれが初めてではありません。

YouTubeビデオの最後に自動再生

ビデオの終わりに、私は自動的に新しいビデオにリダイレクトされましたが、それは混乱を招きました—アナウンスは起こりませんでした。

私はすぐに自動再生コントロールに移動してそれらを無効にすることを学びました：

これにより、ビデオページをロードしたときにビデオが自動再生されるのを防ぐことはできませんが、そのビデオページが次のビデオに自動リダイレクトされるのを防ぐことができます。

ケーススタディ2：BBC

ニュースは特定のものを検索するのではなく受動的に消費されるものなので、見出しでBBCニュースをナビゲートすることにしました。 これにはクイックナビゲーションを使用する必要がないことに注意してください。VoiceOverは、パワーユーザーの時間を節約できる要素検索コマンドを提供します。 この場合、 VO + ⌘ + Hキーを使用して見出しをナビゲートできます。

最初の見出しはCookieの通知で、2番目の見出しは「アクセシビリティリンク」というタイトルの<h2>でした。 その2番目の見出しの下で、最初のリンクは「コンテンツにスキップ」リンクであり、他のすべてのナビゲーションをスキップすることができました。

「コンテンツにスキップ」リンクは、スクリーンリーダーのユーザーだけでなく、非常に便利です。 以前の記事「キーボードだけで1日Webを使用した」を参照してください。

ヒント6：キーボードとスクリーンリーダーのユーザーに「コンテンツにスキップ」リンクを提供します。

見出しでナビゲートすることは良いアプローチでした。各ニュース項目には独自の見出しがあるため、特定の記事についてもっと読むかどうかを決める前に、見出しを聞くことができました。 また、見出し自体がアンカータグで囲まれているため、クリックしたいときにナビゲーションモードを切り替える必要もありませんでした。 VO + Spaceだけで、現在の記事の選択肢を読み込むことができます。

ホームページのskip-to-contentショートカットは#skip-to-content-link-targetアンカー（次にトップニュース記事の見出しを読み上げる）にうまくリンクされていましたが、記事ページのスキップリンクは壊れていました。 別のID（ #page ）にリンクしているため、見出しを読むのではなく、記事のコンテンツを取り巻くgroupに移動しました。

この時点で、 VO + Aを押して、VoiceOverに記事全体を読み上げてもらいます。

Twitterの埋め込みにヒットするまではかなりうまく対処し、Twitterの埋め込みがかなり冗長になり始めました。 ある時点で、「リンク：1068987739478130688」を読み上げてしまいました。

これは、ツイートのビデオ埋め込み部分にある少し危険なマークアップに起因しているようです。

VoiceOverはネストされた画像のalt属性を読み取らず、アンカー内に他のテキストがないようです。そのため、VoiceOverは、URL自体の一部を読み取るという最も便利な方法を実行します。

他のスクリーンリーダーはこのマークアップで正常に動作する可能性があります—マイレージは異なる場合があります。 しかし、より安全な実装は、代替テキストを運ぶために、 aria-labelまたは画​​面外の視覚的に隠されたテキストを持つアンカータグです。 私たちがここにいる間、私はおそらく「埋め込みビデオ」をもう少し役立つものに変更します。たとえば、「埋め込みビデオ：クリックして再生」）。

リンクのトラブルはあそこにはありませんでした：

メインのツイートコンテンツの下には、「いいね」カウンターを兼ねる「いいね」ボタンがあります。 視覚的には理にかなっていますが、スクリーンリーダーの観点からは、ここにコンテキストはありません。 このスクリーンリーダーのエクスペリエンスは、次の2つの理由で不適切です。

1. 「1,887」の意味がわかりません。
2. リンクをクリックすることで、ツイートが気に入ってくれるかどうかはわかりません。

スクリーンリーダーのユーザーには、より多くのコンテキストを与える必要があります。たとえば、「1,887人のユーザーがこのツイートを気に入りました。 クリックしていいね。」 これは、いくつかの思いやりのあるオフスクリーンテキストで達成できます。

 <style> .off-screen { clip: rect(0 0 0 0); clip-path: inset(100%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; } </style> <a href="/tweets/123/like"> <span class="off-screen">1,887 users like this tweet. Click to like</span> <span aria-hidden="true">1,887</span> </a>

ヒント7：単独で読み取る場合は、すべてのリンクに意味があることを確認してください。

私はBBCに関するいくつかの記事を読みました。その中には、「長い形式」の機能も含まれています。

長い記事を読む

別のBBCの長い形式の記事からの次のスクリーンショットを見てください—いくつの異なる画像を見ることができ、それらのalt属性は何である必要がありますか？

まず、写真の中央にあるハヴァス湖の前景画像を見てみましょう。 その下には、「ハヴァス湖は、コロラド川を阻んだ1938年のパーカーダムの完成後に作成されました」というキャプションがあります。

キャプションが提供されている場合でも、 alt属性を提供することをお勧めします。 altテキストは画像を説明する必要がありますが、キャプションはコンテキストを提供する必要があります。 この場合、 alt属性は、「晴れた日のハヴァス湖の航空写真」のようになります。

代替テキストの前に「Image：」や「 alt 」などを付けないように注意してください。 スクリーンリーダーは、 altテキストの前に「画像」という単語をアナウンスすることで、すでにそのコンテキストを提供しています。 また、 altテキストは短くしてください（16語未満）。 より長いaltテキストが必要な場合、たとえば画像にコピーが必要なテキストがたくさんある場合は、 longdesc属性を調べてください。

ヒント8：説明的で効率的なaltテキストを作成します。

意味的には、スクリーンショットの例は< <figure> >要素と<figcaption>要素でマークアップする必要があります。

 <figure> <img src="/havasu.jpg" alt="Aerial view of Lake Havasu on a sunny day" /> <figcaption>Lake Havasu was created after the completion of the Parker Dam in 1938, which held back the Colorado River</figcaption> </figure>

次に、そのスクリーンショットの背景画像（さまざまなコップや機器を運ぶ画像）を見てみましょう。 原則として、これらのような背景画像またはプレゼンテーション画像には空のalt属性（ alt="" ）が必要です。これにより、VoiceOverには代替テキストがないことが明示的に通知され、読み込もうとしません。

空のalt=""は、 alt属性がないことと同じではないことに注意してください。これは、大きな違いです。 alt属性が欠落している場合、スクリーンリーダーは代わりに画像のファイル名を読み上げますが、これはあまり役に立たないことがよくあります。

ヒント9：プレゼンテーションコンテンツに空のalt属性を使用することを恐れないでください。

ケーススタディ3：Facebook

今すぐFacebookにアクセスすると、以前から離脱症状が出ていたので、もっと実用的でないジョーカーを探しに行きました。

Facebookは、私がこれまでに試した他のサイトよりも1、2歩進んでおり、「コンテンツにスキップ」リンクの代わりに、ページまたはページのセクションにそれぞれリンクする2つ以上のドロップダウンがあります。

Facebookはまた、ページのどこからでも使用できるショートカットキーとしていくつかのキーを定義しています。

私はこれらを試してみましたが、VoiceOverで非常にうまく機能します。 私が見る唯一の問題は、それらがプロプライエタリであるということです（これらの同じショートカットがFacebookの外で機能することは期待できません）が、Facebookがここで本当に一生懸命努力しているのは素晴らしいことです。

Facebookのアクセシビリティについての私の第一印象は良いものでしたが、すぐにサイトをナビゲートするのを難しくしているちょっとした奇妙なことに気づきました。

たとえば、見出しを介してこのページをナビゲートしようとすると、非常に混乱しました。

ページの最初の見出しは、サイドバーに隠れている見出しレベル3です。 この直後に、ページで共有されたステータスに対応するメインコンテンツ列の見出しレベルSIXが続きます。

これは、Chrome / Firefox用のWeb開発者プラグインで視覚化できます。

原則として、差が1以下の連続した見出しを付けることをお勧めします。そうでない場合は取引を妨げるものではありませんが、スクリーンリーダーの観点から見ると、間違いなく混乱を招きます。 h1からh6にジャンプしたため、誤っていくつかの重要な情報をスキップしました。

ヒント10：見出しの構造を検証します。

さて、ウェブサイトの要点である投稿に。 Facebookは、人々と連絡を取り合い、彼らが何をしているのかを知ることを目的としています。 しかし、私たちはほとんどのユーザーにとってaltテキストが未知の概念である世界に住んでいます。それでは、Facebookはこれらの独善的な自撮り写真や犬の写真をスクリーンリーダーの視聴者にどのように翻訳しますか？

Facebookには、オブジェクト認識テクノロジーを使用して写真の内容（または誰）を分析し、そのテキストによる説明を生成する自動代替テキストジェネレーターがあります。 それで、それはどれくらいうまく機能しますか？

この画像のaltテキストは、「画像には空、草、屋外が含まれる可能性があります」でした。 「夕暮れ時のケンブリッジ大聖堂」を認識するのは遠い道のりですが、それは間違いなく正しい方向への一歩です。

いくつかの説明の正確さに非常に感銘を受けました。 私が試した別の画像は、「画像に含まれる可能性があるもの：John Smith、Jane Doe、Chris Ashtonを含む3人、笑顔、クローズアップ、屋内の人々」として出てきました。

しかし、ソーシャルメディアでバイラルになるミームやジョークが本質的にアクセスできないことは私を悩ませます。 Facebookは、以下を「画像に含まれる可能性のあるもの：鳥とテキスト」として扱います。これは真実ですが、真実の描写からはほど遠いものです。

幸いなことに、ユーザーは必要に応じて独自のaltテキストを書くことができます。

ケーススタディ4：Amazon

Facebookで気付いたことが、Amazonでも起こっています。 検索ボタンは、DOMの検索入力フィールドの前に表示されます。 これは、ボタンが入力フィールドの後に視覚的に表示されるという事実にもかかわらずです。

あなたのウェブサイトは視覚的に論理的な順序になっている可能性があります。 誰かがあなたのウェブページの一部をランダムに動かした場合はどうなりますか？それは意味をなし続けますか？

おそらくそうではありません。 これは、DOM構造をビジュアルデザインと同期させることについて訓練を受けていない場合に、スクリーンリーダーのエクスペリエンスに起こり得ることです。 CSSを使用してコンテンツを移動する方が簡単な場合もありますが、通常はDOMで移動する方が適切です。

ヒント11：DOMの順序を視覚的な順序と一致させます。

これらの2つの注目を集めるサイトが、検索ナビゲーションでこのベストプラクティスガイドラインを採用しないことを選択する理由は、私を困惑させます。 ただし、ボタンと入力テキストはそれほど離れていないため、それらの順序によってアクセシビリティの大きな問題が発生します。

アマゾンの見出し

繰り返しになりますが、Facebookのように、Amazonには奇妙な見出しの順序があります。 見出しを介して検索したところ、ページの最初の見出しが「Amazonの他の出品者」セクションの見出しレベル5であることが最も混乱していました。

これはスクリーンリーダーのバグだと思ったので、Amazonのソースコードを調べて次のことを確認しました。

ページのh1は、ソー​​スコードで約10,000行下に表示されます。

これは意味的に貧弱でアクセシビリティに乏しいだけでなく、SEOにも貧弱です。 SEOが悪いということは、コンバージョン（販売）が少ないことを意味します。これは、Amazonが非常に優れていると私が期待していることです。

ヒント＃12：アクセシビリティとSEOは同じコインの両面です。

スクリーンリーダーのエクスペリエンスを改善するために私たちが行うことの多くは、SEOも改善します。 意味的に有効な見出しと詳細なaltテキストは、検索エンジンのクローラーに最適です。これは、サイトが検索でより高くランク付けされることを意味し、より多くのオーディエンスを呼び込むことを意味します。

アクセス可能なサイトを作成することが重要であることをビジネスマネージャーに納得させるのに苦労している場合は、別の角度から試して、代わりにSEOのメリットを指摘してください。

その他

1日分のブラウジングと体験を1つの記事にまとめることは困難です。 ここに、カットを行ったいくつかのハイライトとローライトがあります。

あなたは遅いサイトに気付くでしょう

スクリーンリーダーは、DOMが読み込まれるまで、ページを解析してアクセシビリティツリーを作成することはできません。 目の見えるユーザーは、ページの読み込み中にページをスキャンして、その価値があるかどうかをすばやく判断し、価値がない場合は戻るボタンを押すことができます。 スクリーンリーダーのユーザーは、ページが100％読み込まれるのを待つしかありません。

パフォーマンスの高いWebサイトを作成することはすべてのメリットをもたらしますが、スクリーンリーダーのユーザーにとっては特にメリットがあることに注意してください。

私は何に同意しますか？

NatWestのこのようなフォームコントロールは、関係を示すために空間的な近さに大きく依存する可能性があります。 スクリーンリーダーの世界では、空間的な近さはなく、兄弟と親だけが存在します。何に「はい」を付けているかを知るには、当て推量が必要です。

免責事項がラベルの一部であった場合、私は何に同意したかを知っていたでしょう。

 <label> Important: We can only hold details of one trip at a time. <input type="checkbox" /> Tick to confirm you have read this. * </label>

次のコードは悪夢です

スクリーンリーダーを使用してCSSTricksの技術記事を読んでみましたが、正直なところ、その経験を理解することはまったく不可能でした。 これはCSSTricks Webサイトのせいではありません—技術的なアイデアやコードサンプルを完全に聴覚的に説明するのは非常に複雑だと思います。 パートナーと一緒にデバッグを試みたことが何回ありますか。必要な構文を正確に説明するのではなく、コピーして貼り付けるものをパートナーに提供するか、自分で入力しますか。

記事からこのコードサンプルをどれだけ簡単に読むことができるか見てください：

ただし、スクリーンリーダーのバージョンは次のとおりです。

スラッシュスラッシュ最初にビューポートの高さを取得し、それを1 [一時停止]パーセントで乗算してvhユニットの値を取得します。vhをウィンドウの内側の高さに等しくします。スター[一時停止]ゼロゼロ1スラッシュスラッシュ次に、[一時停止]に値を設定します。 ]ドキュメントのルートへのvhカスタムプロパティドキュメントドキュメント要素スタイルセットプロパティ[一時停止] vhドル左中括弧vh右中括弧px

サウンドスケープではまったく読めません。 コメントに句読点がない傾向があります。この場合、スクリーンリーダーのランドで1つの行が次の行にシームレスに流れます。 キャメルケースのテキストは、まるで文章で書かれているかのように、別々の単語として読み取られます。 window.innerHeightなどのピリオドは無視され、「ウィンドウの内側の高さ」として扱われます。 読み取られる唯一の「コード」は、最後にある中括弧です。

コードは標準の<pre>および<code> HTML要素を使用してマークアップされているため、スクリーンリーダーユーザーにとってこれをどのように改善できるかわかりません。 コーディングに固執する人は誰でも、私の完全な称賛を持っています。

そうでなければ、私が見つけた唯一の欠点は、サイトのロゴにホームページへのリンクがあり、 altテキストがないことでした。そのため、私が聞いたのは「リンク：スラッシュ」だけでした。 属性href="/"のリンクがあるかどうかを知っているのは、Web開発者としての私の立場だけです。そのため、Webサイトのホームページに移動するので、リンクの目的を理解しました。ただし、「リンク：CSSTricks」ホームページ」の方が良かったです！

iOSのVoiceOverはOSXよりも扱いにくい

私の電話でVoiceOverを使用することは経験でした！

画面をオフにしてモバイルキーボードを使用して、Twitterアプリをナビゲートしてツイートを書くことに挑戦しました。 予想以上に大変で、つづりを間違えました。

私が通常のスクリーンリーダーユーザーである場合、外部キーボードを使用してBluetoothキーボードに投資しているモバイルスクリーンリーダーユーザーの41％に参加する必要があると思います。 Clara Van Gervenは、2015年にスクリーンリーダーを40日間使用したときに、同じ結論に達しました。

3本の指を使ってトリプルタップでスクリーンカーテンモードをアクティブにするのはかなりクールでした。 これにより画面はオフになりましたが、電話のロックは解除されたままだったので、誰も見ていなくても電話を閲覧し続けることができました。 この機能は、肩越しに見ている人に無意識のうちにパスワードを教えてしまう可能性のある目の不自由なユーザーにとって不可欠ですが、バッテリーを節約するのに最適であるという副次的な利点もあります。

概要

これは面白くてやりがいのある経験であり、シリーズの中でこれまでに書くのが最も難しい記事でした。

立ち止まって考えてみると明らかな小さなことにびっくりしました。 たとえば、スクリーンリーダーを使用する場合、Webの閲覧と同時に音楽を聴くことはほとんど不可能です。 特に電話などで邪魔された場合は、ページのコンテキストを維持することも難しい場合があります。 スクリーンリーダーに戻るまでに、場所を失ってしまいました。

私の最大のポイントは、オーディオのみの体験に行くことには大きなカルチャーショックがあるということです。 これはWebをナビゲートするまったく異なる方法であり、そのような対照があるため、「良い」または「悪い」スクリーンリーダーエクスペリエンスを構成するものを知ることさえ困難です。 それは非常に圧倒される可能性があり、多くの開発者がそれらのテストを回避するのも不思議ではありません。

しかし、それが難しいという理由だけでそれを避けるべきではありません。 チャーリー・オーウェンが彼女の講演で言ったように、親愛なる開発者、ウェブはあなたについてではありません：これ。 は。 君の。 仕事。 Whilst it's fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can't just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.

Let us do our jobs responsibly, and let's make life a little easier for ourselves, with my last tip of the article:

Tip #13: Test on a screen reader, little and often.

I've tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I'd have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.

Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.

Did you enjoy this article? This was the third one in a series; read how I Used The Web For A Day With JavaScript Turned Off and how I Used The Web For A Day With Just A Keyboard.