macOSのSafariでは、ボタンやリンクにTabキーでフォーカスを移動できないのがデフォルトの設定になっている Safariでは、「設定」画面の「詳細」パネル内にある「Tabキーを押したときにWebページ上の各項目を強調表示」のチェックを入れていないと、Tabキーを押したときにボタンやリンクにフォーカスが移動しません（Optionキーを押しながらTabキーを押すと移動できます）。デフォルトではチェックが入っていない状態になっています。 また、macOS版Firefoxでは、「設定（about:preferences）」内の「タブキーでフォームコントロールおよびリンク間のフォーカスを移動する」にチェックが入ってないと、Safariと同じくボタンやリンクにはTabキーでフォーカスが移動しないようになっています。これはSafariの挙動にあわせて追加されたようで、やはりデフォルトではチェック
この記事は、2022年10月28日に開催されたDIST.37「マークアップな夜」での発表「マークアップのわかり方」をもとにしたものです。当日は話せなかった内容も大幅に追加しています。 現代における「マークアップ」とはどのような行為なのか。いかにそれと向き合っていけばいいのか。そういったことについて考えてみます。 マークアップの議論においては、「マークアップには正解がない」という意見が決まって出ます。正解がないと言うならば、たいていなんであってもそうです。たとえばCSSやJavaScriptの書き方には「正解」があるのかと考えてみると、必ずしもそうではありません。 しかし、ことさらマークアップにおいてこれがよく言われる理由としては、妥当性を判断する基準がわからない、ということでしょう。 というのも、CSSなら望む通りの見た目になればとりあえずOKだし、JavaScriptでも意図した通りの振
Creating Accessible SVGs Scalable Vector Graphics (SVGs) have been around since 1999, but they have seen a real resurgence in use as design interactions have become more complex and CSS/JavaScript have replaced antiquated animation programs such as Adobe Flash. There are plenty of reasons to use SVGs today including: Browser support – Increased native browser support of SVGs means better consisten
主にユーザー側の視点から語られることが多いアクセシビリティですが、制作という側からはどのように捉えることができるのでしょうか。2つの切り口から考えてみます。 # アクセシビリティという文脈において、何のためにHTMLを書くかという話になると マシンリーダビリティのため スクリーンリーダーのアクセシビリティのため というように、ユーザーが利用するため、というところにフォーカスした語られ方が多いように感じています もちろんユーザーのために作るというのは正しいのですが、今回はあえて視点を変えて、制作者自身の作るというところに視点を合わせて話してみたいと思っています 僕がどういうものなのかというと、 # 参照: 全部入りHTML太郎(@_yuheiy)さん | Twitter ツイッターでは「全部入りHTML太郎」という名前でやっています # 参照: シフトブレイン／スタンダードデザインユニット
Web Accessibility Advent Calendar 2017の12月8日を担当させていただきます、有限会社時代工房の柴田と小寺です。 「きけるおしながき umenu（以降「ユーメニュー」）」の紹介と、技術的なメモを書きます。 なお文中、「Docomoのらくらくホン」が度々登場しますが、これはらくらくホンが、スクリーンリーダを搭載したガラケーとして、視覚障害者の利用率が大変高い（高かった）ためです。 まず基本的な紹介から（柴田） ユーメニューは、視覚障害者向けのサービスです。視覚障害者が飲食店を利用する際、飲食店のメニューを知るためには、以下のいずれかの方法が確保されている必要があります。 飲食店が点字のメニューを用意している 飲食店のサイトでメニューを表示していてアクセシブルである お店のひと、あるいは同伴者に教えてもらう しかし、点字のメニューを備えている店舗は少なく、飲
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
この記事は、Web Accessibility Advent Calendar 2017 2日目の記事です。 私が疑問に思った事をA11YJ Slackでご教示いただいた内容になるのですが、こちらを見ていないかたにもぜひ読んでもらいたいと思い記事にしました。 タイトルにあるようにA Responsive Accessible Tableの記事を読んでの感想なのですが、「Going Responsive > Adjusting to Viewport Size > Column Headers と Some Sort of Cell Label」の内容はアクセシブルではないと思いました。 Column Headers まず、table要素をCSSでdisplay: blockにするとスクリーンリーダーがテーブルと認識しなくなる件についてですが、実際にWindows7/NVDA2017.3jp
アクセシビリティ向上メモ 最初から考慮されているのが一番ですが、そうでもなかったプロダクトに手を入れるときのあるあるを記録します。既存プロダクトはモノが出来上がってしまっているため根治的なリファクタリングよりも基本的には省力で済ませたいので、今回書いた対応方法も完璧よりは省力路線です。 HTML やらセマンティクスに関する知識はそれなりにあるつもりでしたが、AT やマシンリーダビリティを念頭に勉強し直すと自分で作ったものも至らなかったなと振り返らざるを得ない今日この頃。初期設計のときの考慮範囲が拡がったように思うので善きかなです。 各項目について、もっと良い解法や誤り等あれば twitter とかでご指摘ください。 1. 画像に alt 属性がない場合 付けましょう。付けます。はい。 昔から基本とも言うべき、HTML/CSS 書きとしては耳にたこができるほど言われてきたことなので今更感もあ
2015年4月23日 HTML Accessibility API Mappings 1.0草案からわかるテキストレベルの意味問題 アクセシビリティ・エンジニア 黒澤 去る4月7日、W3CはHTML Accessibility API Mappings 1.0草案を公開しました。なお、この仕様は以前、HTML to Platform Accessibility APIs Implementation Guideと呼ばれていました。 さて、HTML Accessibility API Mappingsは、ブラウザーなどが、HTMLの意味（セマンティクス）などをスクリーン・リーダーなどの支援技術に対してどのように提供すべきかを定めた仕様です。支援技術は、ブラウザーから提供される情報をもとに利用者に情報を提供しているため、ブラウザーが提供する情報が十分でなければ、ページの出来が良くても利用者に適
object 要素で配置した SVG ロゴをスクリーンリーダーに読ませる 公開日: 2014年12月10日 タグ: memo, tips, html, accessibility, svg という訳で、Web Accessibility Advent Calender 2014 9日目の記事です。私も初日から公開される記事をずっと読んで勉強しておりますが、ここまで割と仕様とかガイドラインとか、あとは制作者としての気の持ちよう(?)とか、そういった話がずっと続いている気がしましたので、ここらでひとつ箸休めというか、実装に関する軽い話題をお送りしたいと思います。 さて、今ご覧のこのサイトですが、この数日ちょこちょことリニューアルを進めております。まだ制作途中で未完成な部分もありますが、概ねこんな感じにしようという部分はだいたい完了しましたので、見切り発車で公開しつつ直していこうかなという。まあ
Jaws 15 and Internet Explorer 10 is the best combination at present, although nested SVG images are not well supported. NVDA and Internet Explorer present the role, title and desc, but support is erratic with multiple images announced and repetition of the title and desc. In all other browser/screen reader combinations the SVG is ignored. ARIA enhanced SVG accessibility It is possible to enhance t
Scalable Vector Graphics (SVG) exists in a quantum state of accessibility. Which is to say that SVG is both accessible and inaccessible at the same time. Happily, there is no SVG uncertainty principle. We know which aspects of SVG are accessible to whom, which are not, and what we can do to improve both. SVG 1.0 was released by the W3C in 2001. SVG 1.1 came along in 2003, and SVG 1.1 2nd edition i
Translation of: Bulletproof Accessible Icon Fonts by Filament Group アイコン・フォントを利用する場合、あらゆるユーザーに適切にアイコンを提供しようとすると、かなり気をつける必要があります。そのフォントが読み込まれなかった時にどうなりますか？@font-faceがまだサポートされていないブラウザーでは？ どうすれば安全に(bulletproofに)アイコン・フォントを利用できるかをこれから解説したいと思います。 効率的で機能的なウェブサイトを制作するという、この終わることのない探求において、ベクター形式のアイコンを提供する手段として、簡便であるフォントを利用することが何度も提案されてきました。対して私達は通常ベクター形式のアイコンとしてSVGをIan Featherがブログ書いたような理由から選んで(また、薦めて)おり、既に
SVG1.1 accessibility support is limited in browsers and screen readers. Things are set to improve with SVG2, but ARIA can be used now to improve the accessibility of simple SVG. SVG includes two elements for providing short and long text descriptions: The title and desc elements. <body> ... <svg xmlns=http://www.w3.org/2000/svg> <title>Circle</title> <desc>Large red circle with a black border</des
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
