![http://blog.e-riverstyle.com/2014/12/svg.html](https://cdn-ak-scissors.b.st-hatena.com/image/square/40138e9d55e52353f0ce6e3e0a9f81c5b3e08ce0/height=288;version=1;width=512/http%3A%2F%2Fblog.e-riverstyle.com%2Fassets_c%2F2014%2F12%2Fblog_04-thumb-320x320-3027.png)
コンテンツは本当にアクセシブルか Webアクセシビリティは、大きく分けて 2 つの『デザイン』があります。ひとつは、情報を分かりやすく整理し、目的の情報へた辿り着くための Web アクセシビリティ。この要素は、色、形状、動き、スピードなど、UI デザインの課題と重なるところが多いです。もうひとつの要素は、情報の構成や文章のスタイルといった「編集」とも呼べる Web アクセシビリティです。 前者の情報構造や操作性は、明確なガイドライン化がしやすく、チェックもしやすいですが、後者の編集の部分は、パッと見では判断がしにくいだけでなく、ガイドラインとして共有するのも難しいです。 Webアクセシビリティにある 2 つの『デザイン』 もちろん JIS X 8341–3:2010 でも「利用者が理解できるコンテンツ」を制作・維持できるようにすることが重要であると書かれていますが、技術で解決できるところに
Introduction The BBC Mobile Accessibility Standards and Guidelines are a set of technology agnostic best practices for the BBC's mobile web content, hybrid and native applications. Each standard and guideline is listed with example code for implementing in HTML, Android, and iOS and steps for testing. The standards and guidelines are based on the requirements of BBC.co.uk content developed for UK
W3C が勧告しているウェブコンテンツ・アクセシビリティ・ガイドライン (WCAG) 2.0 の中に「アクセシビリティの 4 原則」というのがあります。JIS X 8341–3 をはじめ、国内外で定められている Web アクセシビリティの土台のような存在です。久しぶりに、この 4 原則を振り返ってみて気付いたのが、Web デザインの原則と同じではないかという点です。特にビジュアルデザインで気をつけることと重なるところがあります。 アクセシビリティの 4 原則は以下のとおりです(翻訳サイトより抜粋)。 知覚可能 情報およびユーザーインターフェースの構成要素は、ユーザーが知覚できる方法でユーザーに提示可能でなければならない。 操作可能 ユーザーインターフェースの構成要素およびナビゲーションは操作可能でなければならない。 理解可能 情報およびユーザーインターフェースの操作は理解可能でなければなら
SuperPopCamとか作ったときに、体系的な資料欲しいなぁーとか思ってたことのまとめ。 色々と自分の中の考えをまとめるためのメモ。世の中のアプリは機能を半分にして、減った予算分をUIの練り込みにつぎ込んだ方が絶対よいアプリになると思う。 書いてる作業が一番考えまとまるので、ちょぼちょぼあげていこうかと、まずはボタンから。 指の大きさの制約を受ける ・Webとスマホを比較した場合、最大の違い。 ・ピクセル単位でクリック位置を制御できるマウスポインタと違い、指は大雑把にしかタップ位置を指定できない。 ・このためAppleはボタンの最小サイズとして44pxというガイドラインを作っている。 ・視覚的に44px以下のボタンも実際のヒットエリアは大きめにする。 ・またこれに留まらず、ボタンとボタンの間のマージンは空けられるだけ空けた方が安全。 ・つまるところ「カッチリ」つめたボタンレイアウトのグラ
強調したい情報がある、だから繰り返したい!でも、それってユーザビリティ・アクセシビリティは高くないかもしれないのです。 某視覚障害者のMLにて 普段はソフトウェアの使い方や近況報告のようなMLなのですが、たまに僕たちのようなサイト制作者にとっては興味深い投稿がされます。例えば、視覚障害者からのこんな内容でした。 「JR東日本のメールでのお問い合わせが使いにくくて仕方がない」という内容。というわけで覗いてみました。 情報量が多すぎる! まず、指摘のあったその問題のページは、JR東日本:ご意見・ご要望の受付です。当ブログからでは分かりにくいのですが、実は手前のページからポップアップウィンドウで開きます。また、お問い合わせするだけなのになぜこんなにも個人情報を入力しなければならないのか、という疑問も沸いてきます。 では、このポップアップウィンドウを開く手前のページはどこなのか。それがJR東日本:
企業や官公庁がWebサイト上で様々な情報やサービスを提供するようになるにつれ,「様々な人がWebサイトにアクセス可能かどうか,Webサイトから情報を入手できるどうか」という「Webアクセシビリティ」が,非常に重要な課題になっている。利用者がこうした情報やサービスを入手できるかどうかが「生活の質(Quality of Life:QOL)」を左右すると言っても過言ではないからだ。 Webアクセシビリティ・ガイドラインの「JIS X8341-3」策定の中心的人物である東京女子大学の現代文化学部コミュニケーション学科教授である渡辺隆行氏と,インフォアクシア代表取締役の植木真氏の2人が,ガイドライン策定までの道のりと最新の事情,アクセシブルなサイト制作のキモを語る。(聞き手=矢野りん/ライター) ―― ビジネス的な理論では企業が提供するサービスなり商材なりのターゲットに障害者は含まれていない,だから
Home Archive del要素はあまり使わない方がいいかも del要素はあまり使わない方がいいかも 2007年11月19日 category:XHTML/CSS Comment(0) Trackback(0) del要素とかins要素って音声ブラウザとかで区別されず、普通のテキストとして読み上げられるんですよね。Web標準の日々のアクセシビリティトラックのメモをぱらぱらと見ていて、そういえば記事にしよう、と思ったのを忘れてました。 通常のdel要素を使った文章 下記のような文章は構造的に問題ないし、一般的なブラウザでは削除された部分と追加された部分がわかりやすく表示されるので問題ないですよね。 例文 15日16日は雨らしいです。 <p><del>15日</del><ins>16日</ins>は雨らしいです。</p> 問題点 上記の例だと音声ブラウザで「15
リンクテキストをスクリーンから隠したいときに、どんな方法が最もアクセシブルなのでしょうか。 Yahoo! User Interface Blogより もう3ヶ月ほど前のことですが、Yahoo! User Interface Blogで面白い取り組みをしていました。Empty Links and Screen Readersという記事です。その取り組みとは、リンクテキストをスクリーンから隠すための方法を1つ1つ検証し、どの方法がアクセシブルなのかを調査するというものです。 Yahooが調べたのは以下のリンクです。 通常のテキストとそれに対するリンク テキストもtitle属性もないリンク title属性はあるが、テキストがないリンク テキストの代わりに空白を入れたリンク これらのリンクに次のCSSを当てます。 特に指定しない offscreen visibility: hidden displ
自分用メモなのですが、せっかくなので公開します。CAPTCHA(Webサービスに登録する時やブログにコメントをつける際に認証を求めてくる、文字がぐにゃっとした画像)を知っている人も多いと思うし、それがスクリーンリーダー利用者などの、一部の人たちにとってはアクセシビリティ上大問題ということを知っている人も多いと思います。じゃあ、それではアクセシビリティは無視か?!というとそうでもなくて、どうやら色んな取り組みが行われているようです。 スクリーンリーダーのCAPTCHAの読み上げ方 まず、おさらいです。スクリーンリーダーはどういうふうにCAPTCHAを読み上げるのか。英語の動画ですが、次の動画が最も分かりやすい。 内容はちょっと違うのですが、海外の大手SNSで登録の際にCAPTCHAを使っているところが多くて、スクリーンリーダー利用者は登録できないじゃないか!というビデオ。でも、別にSNSだけ
Truwex manages website compliance with web accessibility, online privacy, and quality standards. Truwex is a web governance and testing solution, all in one product. Web compliance managers can use Truwex to: Define a uniform website standard. Monitor compliance status and automatically generate reports for upper management. Set action items for website owners and web developers. Web develope
集中的にアクセシビリティやユーザビリティを最近になってやっと学び始めました。JIS X 8341やWCAG1.0を読み進める中で、もっと自分自身勉強したいと思うようになってきました。そこで、JISやWCAGを学ぶ中で、自分がシニアや障害を持つ人との現場で、またそういった現場で働いている人たちの意見を踏まえた上で、疑問に思うことを列挙しておこうと思います。いずれは、こういうことをちゃんと実装レベルで解決できるようになりたいなと思いを込めて。 alt=""は空文字なのか、半角スペースなのか、それとも全角スペースなのか? 少し前に「ブロガーのためのアクセシビリティガイドライン」を書きました。この際に、はじめはalt=""と空文字を打つと書いていたのですが、よくよく調べてみると、空文字だと音声ブラウザによっては「画像」と読み上げてしまうことがあるようです。また、全角スペースの場合は、日本語環境以外
この文書は2つの質問に答えるために書いてみたんだ。 1コ目は、「なんでサイトをアクセシブルにした方がいいのか」。 だから、ここの情報はサイトを持ってない人には向かないかも。 2コ目は、「じゃどうしたらサイトをアクセシブルにできるのか」。 1コ目の答えが納得できるものじゃなかったら、2コ目はどうでもいいってことになるよね。 じゃ行ってみよう。 Dive Into Accessibility(英語版)をダウンロードする HTML(英語版)をダウンロード PDF(英語版)をダウンロード Dive Into Accessibilityを読む 目次 掲載された順序のままにならべてある、すべての情報はこちら。はじめてココ の文を読むときにおすすめの読み方。 人に基づいた情報分類 ここではどんな人に役立つかによって、情報が分けられています。 障碍に基づいた情報分類 ここではどういった障碍があるときに役立
ヤコブ・ニールセンの考えをまとめたユーザビリティガイドライン ユーザビリティのグル、ヤコブ・ニールセン氏の考えや調査を元にユーザビリティガイドラインを作りました。 デザインやコーディングをしている際に、このガイドラインを元に自分のデザインを一度チェックしてみるのもよいかと思います。 TRANS - ヤコブ・ニールセン氏の考えを元に、ユーザビリティガイドラインを作った。
ECサイトで扱う商品の魅力を効果的に訴求する一つの方法として、商品写真を「大きく」「複数」出すことが挙げられます。 特に写真が重要な商品(家具・アクセサリーなど)では、写真が小さく見づらい、見たい部分の写真がないことが購入意欲を減退させる大きな要因となります。 弊社のユーザビリティテストでは、商品写真は大きいほど、そして様々な角度・パターンが多いほどユーザへの魅力度が高まることが観察されています。 「写真はクリックして拡大できるようになっていれば良い」と判断し、商品紹介ページでは小さく表示するという選択も誤りではありません。 しかし、小さすぎる写真は訴求力が弱く、ユーザは「クリックして詳しく見たい」とまで思わずに購入を諦める可能性もあるため、注意が必要です。 楽天市場で人気の高いサイトを見ると、写真の使い方が参考になります。 中にはサイトの運営者が自ら撮影した商品写真もあり、写真のアン
唐突ですが、ブログやWebサイトを更新する際に、よりアクセシビリティが高いコンテンツをどうすれば書くことができるのか、そういったガイドラインを公開します。 といっても、元々は他団体向けにWebサイトを制作している際に、「結構、Webには詳しい」方にコンテンツを書いてもらっていたのですが、時折「概 要」とか、「2007年1月11日(水)」といった記述が見られ、「あー、このままでいくと、更新作業を今後やってもらうのってすごく不安だな」と思いました。そこで、どうすれば音声ブラウザなどがうまく対応できるようにコンテンツを書けばよいのかをガイドラインにまとめてみたのですが、せっかくですので、ウェブ上で公開することにしました。 前提として、 アクセシビリティに詳しい方にとっては、「何を今更」という内容。 デザインやマークアップよりも、コンテンツを書く=ウェブライティングに特化したガイドライン。 ブロ
ナビゲーションスキップは主に音声ブラウザ向けに、グローバルナビゲーションなどをスキップするために実装されるものだが、前々からずっとナビゲーションスキップをどのように書けば最適なのか、についてはずっと疑問に思ってきた。というわけで、調べてみた。 前提:まずは最適なHTML(XHTML)を書くこと。 これが大前提。音声ブラウザによっては、heading要素(h1とかh2)を順にスクロールすることができるから。というわけで、XHTML+CSSによるWeb標準での実装は大前提。というより、これをしっかりと書いておけば、ナビゲーションスキップを埋め込まなくても、音声ブラウザにとってはテーブルレイアウトに比べて、かなり便利になるようだ。 検討事項その1:そもそもナビゲーションスキップは見えるようにすべきか否か。 ナビゲーションスキップを見えるようにするべきか、しないべきかについて、まず考えておく必要が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く