Google Slash Design Accessibility — Instrument — Independent Digital Creative Agency in Portland, Oregon
We at Instrument recently helped Google design and develop a new iteration of the google.com/design website. One of the biggest challenges in this project was making sure both the design and development met the WCAG 2.0 AA level of accessibility for people with low vision or those using any assistive technology. Where do we start? While this was not our first project with strong accessibility cons
role 属性を正しく設定してアクセシビリティを高める
role 属性は、要素が示す役割を明確にするための属性です。 例えば、header 要素はコンテンツの header か、あるいはサイト全体の header を示すことなどができますが、 どちらの header であるかを明確に区別する手段はありません。 しかしながら、role 属性の値 banner によって、コンテンツ固有の header ではなく、サイトの持つ header であることを示すことができます。 HTML5 以降の HTML は、ある役割を示す要素が多く存在しますが、role 属性はより強く役割を示します。 role によって役割を明確にする意味 role 属性は HTML などで使いますが、role 属性に与える値や役割は HTML とは切り離された ARIA と表記される区分に定義されています。 Accessible Rich Internet Application
2015年のWebアクセシビリティ | gihyo.jp
あけましておめでとうございます。株式会社ミツエーリンクスの黒澤剛志です。本稿では、昨年に引き続いて、2015年のWebアクセシビリティの短期的な予測を寄稿させていただきます。 HTML5がW3C勧告に 2014年10月、HTML5仕様がW3C勧告として公開されました。 W3C勧告として公開されることは、その仕様はブラウザーなどに既に実装されていることを意味しています。Webアクセシビリティの観点からは、HTMLのセマンティクスがユーザーに伝わるかどうか、という点も重要です。この点に関しては、2014年を通して多くのブラウザーが改善に取り組みました。特に、これまで対応が弱かったGoogle Chromeでの取り組みが目立ちました。HTML5 Accessibilityのスコアを見ると、Goolge Chrome（Windows版）は、2014年3月には47でしたが、2014年11月には83.
WAI-ARIA 1.1のブラウザー対応状況（2014年11月） - Unreviewed
この記事は、Web Accessibility Advent Calendar 2014、2日目の記事です。 2014年3月にWAI-ARIA 1.0（日本語訳）が勧告に達しましたが、W3Cでは次期WAI-ARIA 1.1（Editor's Draft）の標準化が進んでいます。WAI-ARIAは、Webで必要とされているセマンティクスと実際に使えるセマンティクスのギャップを埋める仕様であるため、必要とされるものが変われば、それを取り込んでいく（セマンティクスをより自然に表現できるようにする）必要があるのだと思います。 また、WAI-ARIAはその性質上Polyfillを作るのが難しく、どうしてもブラウザーや支援技術の実装に左右されがちです。実際のブラウザーを見ると、すでに対応は始まっていますので、この記事では2014年11月時点でのブラウザーにおけるWAI-ARIA 1.1の対応状況を見て
Webアクセシビリティを当たり前にするために
当たり前にしては難しい Webアクセシビリティを考慮し実践することは「当たり前」だと思いますが、その当たり前を実践することが非常に敷居が高い印象があります。仕様や規格を理解して実装しなければならないところから、クライアントのコミュニケーションやワークフローといった仕組みの見直しまで、「当たり前」を実践するために超えなければならない山がたくさんあります。 私たちが「当たり前」という言葉を使うとき、「誰でも同じように考えること・自然にできること」というニュアンスを含めています。そのニュアンスのまま当たり前と思って Web アクセシビリティに取り組もうとしても、目の前にある多くの課題に頭を抱えてしまう人もいると思います。当たり前という言葉と、現実にしなければならないことのギャップが、Webアクセシビリティを難しくしているのかもしれません。 当たり前という言葉が難しさに拍車をかけていることがある
WAVE Web Accessibility Evaluation Tools
WAVE® is a suite of evaluation tools that helps authors make their web content more accessible to individuals with disabilities. WAVE can identify many accessibility and Web Content Accessibility Guideline (WCAG) errors, but also facilitates human evaluation of web content. Our philosophy is to focus on issues that we know impact end users, facilitate human evaluation, and to educate about web acc
障害者差別解消法の三本柱-障害を理由とする不当な差別的取扱いの禁止、環境整備、合理的配慮の提供- | すちゃらかコーダー
第七条第一項（国の行政機関等、地方自治体）、第八条第一項（民間事業者）で、「障害を理由として障害者でない者と不当な差別的取扱いをすることにより、障害者の権利利益を侵害してはならない」と民間事業者も含めて義務として規定されています。 つまり、正当な理由なく、障害を理由としてサービスや機会の提供を拒否したり、何かしらの制約をつけてはならないということです。ここで気をつけて欲しいのは、障害者の実質的な平等を確保するための特別な対応は、不当な差別には当たらないということです。つまり、後で述べる合理的配慮の提供は差別ではありませんし、無論、逆差別でもありません。また、合理的な配慮を提供するために、プライバシーに配慮しつつ、障害の状況を障害者に確認することも、不当な差別ではありません。 環境の整備（事前的改善措置） これは、後で述べる合理的な配慮がなるべく必要にならないように、不特定多数の障害者を対象
ウェブアクセシビリティは未来像から伝え始めましょうぜ
ウェブアクセシビリティは未来像から伝え始めましょうぜ ウェブアクセシビリティの教育の話。ウェブ制作を学び始める人がウェブアクセシビリティに興味やイメージが湧くように、それが実現した未来に何が待っているのかというところから伝え始めたほうがいいんじゃないでしょうか time2014/02/04 hatenabookmark- WCAG20とかニールセンも、言ってることはステキだけど、「象牙の塔感」みたいのがあって、それが色々と敷居を高くしてる気はする。ユーザビリティの教科書なのにユーザー離脱率が高いというか。もう少しローエンド向けに書いてくれないと考えが末端まで普及しないんじゃないかとか。 — 深津 貴之 (@fladdict) 2014年 2月 4日 深津先生のこのツイート、割と同感でリツイートしたんですけど、ローエンド向けにとはまた違ったところで感じるところがあったのでその辺りの話とか、じ
PayPal Account | Mobile Wallet and More | PayPal UK
Start something great. You can earn a £10 reward when a friend joins PayPal and spends £5. That’s up to £100 in rewards when you refer up to ten friends.
Punkchip | Accessible HTML video as a background
Today I got a comment on Autoplay is bad for all users which asked: So why does this high-traffic site designed by a former top-Google UX designer use it? The comment has linked to a page which has video as a background element playing underneath the introduction text and call to action button, the images are moving but there is no sound on page load. At times this apparently important information
CSS outline property - outline: none and outline: 0
a { outline: none; } Don't do it! What does the outline property do? It provides visual feedback for links that have "focus" when navigating a web document using the TAB key (or equivalent). This is especially useful for folks who can't use a mouse or have a visual impairment. If you remove the outline you are making your site inaccessible for these people. Defining focus to navigation elements is
アイコンフォントのアクセシビリティ向上 | Accessible & Usable
公開日 : 2014年8月28日 (2024年7月17日 更新) カテゴリー : アクセシビリティ ウェブデザインにおいて、アイコンを配置することは多いと思います。最近では、画像アイコンではなく、Font Awesome のようなアイコンフォントを用いるケースも増えてきました。 「アイコンフォント」の例 (Font Awesome) アイコンフォントには、画像アイコンよりも読み込みが速い、ベクターデータゆえに高解像度の画面でもきれいに表示できる (ピンチ＆ズームしてもジャギーにならない)、手軽に実装できる (わざわざアイコンを作る必要がなく、豊富なアイコンから選択して所定のコードを埋め込むだけ)、といったメリットがあります。このように、とても便利なアイコンフォントですが、アクセシビリティ (とりわけ、スクリーンリーダーを介した情報伝達) の観点で考えると、実装において若干の工夫が必要です。
ナビゲーションメニューが複数ある場合のスクリーンリーダーでの識別 | Accessible & Usable
公開日 : 2014年7月31日 カテゴリー : アクセシビリティ / 情報設計 (IA) Web ページの中にナビゲーションメニューが複数あるというケースは珍しくありません。多くのサイトが、グローバルナビゲーション、ローカルナビゲーション、といった具合に、複数のナビゲーションメニューを持っていることでしょう。 これら複数のナビゲーションメニューは、ページレイアウトを見渡すことで、それぞれの役割を類推することができます。ページ最上部の共通ヘッダー内に並んでいるメニューはサイト全体のグローバルナビゲーション、メインコンテンツの横にもう少し細かな粒度で並んでいるメニューは (そのメインコンテンツが属するカテゴリーの) ローカルナビゲーション...といった感じです。 スクリーンリーダーユーザーにとっての課題 (ナビゲーションメニューの種類を推測する手間) ところが、Web ページ内の情報をシリア
ウェブ制作者が知っておくべきアクセシビリティ15のポイント - Random Thoughts
「アクセシビリティがないコンテンツ」＝「アクセスできないコンテンツ」です。ビジネスチャンスを最大化するためには、コンテンツのアクセシビリティを確保しなければなりません。政府・自治体のウェブサイトならば、人々の「知る権利」のためにアクセシビリティの確保は必須です。 とはいえ、もちろん「どの程度やればよいか」は、ケースバイケースです。そこで Web Content Accessibility Guidelines などの公的なガイドラインを参考にすればよいのですが、アクセシビリティ初心者にはとっつきづらい文書でもあります。最初のうちは、植木真氏による下記の実践的なチェックリストを参考にするのがよいと思います。 植木真氏による15項目の「アクセシビリティ・ガイドライン・セルフチェック」開始タグと終了タグがある（終了タグを省略しない） ただし、仕様で認められている場合を除く要素を仕様に準じて入れ子
WAI-ARIA の基礎知識 | Accessible & Usable
公開日 : 2014年4月15日 (2018年1月20日 更新) カテゴリー : アクセシビリティ / 情報設計 (IA) WAI-ARIA 1.0 が、2014年3月20日付で W3C の勧告 (Recommendation) になりました。 WAI-ARIA とは、Web Accessibility Initiative (W3C の中で、Web アクセシビリティに関する仕様を検討する部会) が策定した、Accessible (アクセシブル) な Rich Internet Applications (リッチインターネットアプリケーション : RIA) に関する仕様です。この仕様で定められた記述をソースコードに加えることによって、JavaScript などでインタラクティブに動くユーザーインターフェース (UI) であっても、その状況の変化を、マシンリーダブルな形で支援技術 (スクリー
Text link Accessibility: aria-label and title attribute
Notes: For JAWS, the above behavior is the same in Firefox and Internet Explorer (Windows 7). NVDA was tested only with Firefox VoiceOver was used with Safari on OSX and iOS Default verbosity settings were used for all screen readers. The test links are not indicative of markup to be used for download links for PDF (or other) file types. Conclusion: JAWS 15 provides the best user experience follow
Internet Explorerはimg要素に対応してください - Unreviewed
名前 ブラウザーはスクリーン・リーダーなどの支援技術向けに、ページの構造を提供しています。支援技術はブラウザーが提供するページの構造を読んで、ユーザーに情報を伝えています。このやりとりで使われるのが、アクセシビリティAPIで、やりとりされる情報は木構造であらわされるためアクセシビリティ・ツリーと呼ばれています（アクセシビリティAPIで表現される情報はWebページに限りません。ブラウザーのUIやその他のアプリケーションも、アクセシビリティAPIを通して支援技術と情報をやりとりしています）。 やりとりする情報の中には、オブジェクトの名前があります。WAI-ARIAから「アクセシブルな名前」*1の定義から前半を拾ってくると次のようなものになります（日本語訳は筆者）。 アクセシブルな名前はユーザーインタフェース構成要素の名前である。各プラットフォームのアクセシビリティAPIは、アクセシブルな名前の
装飾的なテキストの読み上げをテスト
以前からCSSでcontent:"▶";のように装飾としてテキストを付ける際、スクリーンリーダーに何か影響することはないものか気になっていたのですが、2014年1月17日に「Bulletproof Accessible Icon Fonts | Filament Group, Inc., Boston, MA」を読み、やはり装飾のつもりで付けたテキストが読み上げられることを知りました。 このサイトでも装飾としてテキストを付けていることもあり、実際にどのように読み上げられるのかを少しテストしてみました。テストはOS X 10.9.1のVoiceOverと、Windows 7のNVDAで行いました。 ちなみに、偶然にも本日「装飾的なテキスト — Website Usability Info」が公開されていましたので、そちらも読まれると良いかと思います。 NVDAでは装飾的なテキストが読み上げら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.e-riverstyle.com/2012/12/roleariawaiariahtml5-advent-ca.html
Service discontinued