「絶対にdisabled属性を避けて、aria-disabled属性を使わなければならない」わけではありません - Qiita
「絶対にdisabled属性を避けて、aria-disabled属性を使わなければならない」わけではありませんHTMLアクセシビリティWAI-ARIA 最近、「アクセシビリティを向上させたいなら、HTMLの disabled 属性ではなく、aria-disabled 属性を使うべき」という主張を見かけますが、本当にそうなのでしょうか？ disabled属性を使っていても、スクリーンリーダーで要素を知覚できる そのような主張をしている人、それを受け止めた人の中には「 disabled 属性を使った要素はスクリーンリーダで読めなくなる」と誤解している人が少なからず存在するように思われます。しかしこれは正しい理解ではありません。 たしかに、disabled属性を付加している button 要素や input 要素、 select 要素、 textarea 要素は、Tabキーによるフォーカスはでき
スクリーンリーダーの操作にはTab以外のキーも必要です - Qiita
Webのアクセシビリティの確認としてスクリーンリーダーを使った動作確認もしてもらうと 「リンクとかボタンしか読まれず、見出しや説明文がスキップされてしまいました」 という報告をされることが時々あります。 これは大抵、スクリーンリーダーを起動して、Tabキーだけを繰り返し押してしまっていることによって起こります。スクリーンリーダーの操作方法を伝えると、読み飛ばしたと思っていたところもちゃんと読みあげてくれたということがほとんです。 アクセシビリティをかなり意識したページであっても、Tabキーだけでスクリーンリーダーを操作しているかぎり、ページの隅々まで読めることはほとんどありません。スクリーンリーダーにはTabキーを押す以外にもいろいろな操作が存在して、それを憶える必要があるわけです。私はアクセシビリティチェックのやり方を説明するときには、必ずその操作方法のうち最低限のものを紹介しているつも
入力欄のプレースホルダーって結局どうなの - Qiita
入力欄のプレースホルダーの話をします。プレースホルダーというのは、フォームの入力欄で、ユーザーが入力するまでの間に表示されているテキストのことです。 書籍「Webアプリケーションアクセシビリティ1」では、「3.1 ラベルと説明」のところで、紙版にして約1.5ページの分量を割いて、フォーム入力欄のプレースホルダー（<input> 要素や<textarea> 要素の <placeholder> 属性）の問題点を指摘しています。 この本で指摘されているプレースホルダーの問題点は以下の3つです。 プレースホルダーの色が薄く視認しづらい プレースホルダーとフォームコントロールの値との区別がつかない フォームコントロールに値を入力したときにプレースホルダーの値が見えなくなってしまう Webアプリケーションアクセシビリティ さらに、Nielsen Norman Groupによる「Placeholders
お前らはまだ img タグの alt 属性の付け方を間違っている - Qiita
1行で alt属性は、「全ての 画像をそのalt属性のテキストに置き換えたときにページの意味が変わらない 」ようにつける。 （HTMLの標準規格書より） マジでこれに尽きる。 具体例 例１：ロゴ ❌ 間違ったマークアップ
はじめての VoiceOver 対応 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こちらの記事は 「はじめてのVoiceOver対応 - Speaker Deck」 の詳細版になります この記事から得られること VoiceOver とは何か分かる VoiceOver 対応でどういった知識が必要なのか分かる VoiceOver 対応ではどんな作業をするのか分かる VoiceOver 対応がなぜ必要なのか分かる はじめに Patrickが使えるように — Apple - YouTube DJでありプロデューサーでもある全盲のPatrick Lafayette氏が、VoiceOver を使いこなしながら音楽制作や美味しそう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
