covid19-twitter-research_01.md 生活と意見: ソーシャルディスタンスなどと称してユーザー名や文章にスペースを挟む行為についての苦情 更新履歴 2020-05-13 追記 継続して観測していて、対応が行われたアカウントの記録などを残している https://twitter.com/bulkneets/status/1259419102851903490 FAQとして「機械が人間の都合に合わせろ」に対する反論を取り急ぎ置いておく 走り書きで書いた https://twitter.com/bulkneets/status/1260524434256879617 https://twitter.com/voqn/status/1259515760986095617 記事下部に、フィードバックなどを追記した。 はじめに この文章は mala (twitter: @bul
バニラ・エアの件、論点が増えすぎてうやむやになって終わりそうだったので、論点をいくつかに分類した上で私が思う問題点について書いてみます。 長いので結論だけ先にまとめておくと、車椅子利用者のみが自主的な事前連絡を求められていることはバリアフリーでなく、より確実なバリアフリーを目指すために航空会社がシステムの側で対応すべきということです。 ちなみに私は健常者ですが、中学の時にこのエントリと同じような趣旨で卒業レポートを書いたり大学で車椅子利用者向けのインターフェースについて勉強したりしていたので、どちらかと言うと車椅子利用者側の意見になっているかもしれません。 論点の整理今回の騒動で話題になった記事は http://b.hatena.ne.jp/topic/300611893821289425 が割とよくまとまっています（おそらく自動生成ではありますが）。これらのエントリを見ると、論点は大きく
いすみ鉄道のようなローカル線は、鉄道会社といっても零細企業です。 こういう小さな会社は、社長が何を考え、どういうポリシ―や方向性で進んでいるのかを皆さまに直接お伝えし、ご理解いただくことが大切だと考えています。 このブログでは、地元の情報やイベントなども併せて、「いすみ鉄道の今日」をお伝えいたします。 どうぞお付き合いくださいますようお願い申し上げます。 赤組でもなく青組でもなく、アイスクリームの飛行機が車いすのお客様を乗せる乗せないでもめたようですね。 私も長年航空の現場で働いてきましたが、車いすのお客様がスムーズにご利用できることは、ふつうに考えたらあたりまえのことで、今回のアイスクリームさんは、搭乗ブリッジのない沖止めスポットに飛行機を駐機しているにもかかわらず、階段を上れないお客様のための手段を用意しておかなかったというのが、会社側としての敗因でしょうね。 これは言い訳ができないと
あるアクションを引き起こす「モノ」を「リンク」とするか「ボタン」とするかは、何を基準に判断すればよいのでしょうか。ここでは最近の私の解釈を書きます。 最近の私の解釈 最近の私の解釈は「アクションが、ページの遷移かフォーカスの移動を発生させるものはリンク、そうでなければボタン」というものです。この解釈はWAI-ARIA 1.0のある注記がきっかけになっています。 WAI-ARIA 1.0 WAI-ARIA 1.0 （2011年1月18日勧告候補）にはlinkロールとbuttonロールがそれぞれ用意されています。中でもlinkロールには私の解釈の直接のきっかけとなった注記があります。 Note: If pressing the link triggers an action but does not change browser focus or page location, authors
安藤 優 @ando_suguru はてなブログに投稿しました 正しいHTMLを書く目的はアクセシビリティのためではないと思う。 - Ando.report(); // JavaScriptをもっと勉強したいブログ。 http://t.co/LCajXdIGWM 2014-02-06 12:08:01 Yu Morita (yuu) @securecat @ando_suguru アクセシビリティとはWCAGのことではなく、リソースが正しくリソースであることによってもたらされるアクセシビリティです(記事中でも補足しているはずですが)。 2014-02-06 14:43:36 Yu Morita (yuu) @securecat @ando_suguru TBL曰く"The power of the web is in its universality." 誰もが意図通りにアクセスでき、リソ
正しいHTMLを書く目的はただ一つ - ネコメシCEOブログを読んで、違和感を覚えたので、正しいHTMLについて考えてみた。考えて考えて考えた結果、本文はかなり短くなりました。ｗ はじめに はじめに断っておきますが、私は「正しいHTML」という表現自体、そもそも間違っていると思うので、私は以下、「適切なマークアップ」といいます。 マークアップの目的 適切にマークアップする事の目的は、「SEOの為」ではなく、「アクセシビリティの為」でもなく、文書を読む人（あるいはプログラム）に、文書の意味を適切に伝える事だと思う。 なぜかというと、本来HTMLは、「文書の情報構造を示すためのマークアップ言語」だから。 SEO・アクセシビリティのため？ よく「SEOの為」とか「アクセシビリティの為」と言われるけど、これらは「適切なマークアップが成されている結果得られるもの」じゃないだろうか。 だから、これら自
富士通は2013年8月20日、視覚障がい者や色覚障がい者のアクセシビリティを高めるための診断ソフトウェアツール群「富士通アクセシビリティ・アシスタンス」の無償提供を終了した（参照記事）。このニュースはSNSでの反響も大きく、ユーザーから「なぜこのような素晴らしいサービスが終了してしまうのか」との声が多く聞かれた。 同様のツールは他にもあったが、富士通アクセシビリティ・アシスタンスが愛用されるのにはわけがあった。富士通アクセシビリティ・アシスタンスは、3つのツール群「WebInspector（ウェブインスペクター）」「ColorSelector（カラーセレクター）」「ColorDoctor（カラードクター）」から構成されており、それぞれ以下の特徴が挙げられる。 WebInspector ローカルフォルダを指定した場合、サブフォルダのHTMLまで一括でチェックでき、結果をCSVで保存できる C
公開日 : 2013年4月12日 (2020年8月30日 更新) カテゴリー : アクセシビリティ / ユーザビリティ Web サイトのフォームの中には、入力必須の項目があります。大抵の場合、その項目が必須である旨を、ラベル (<label> 要素の中) に盛り込むことが多いでしょう。 <label for="name">お名前 (必須)</label> <input type="text" id="name" name="name" /> 上記のように、<label> 要素の中に「必須」と書かれていれば、たとえばスクリーンリーダーを使いながら [Tab] キ―でフォーカス位置を移動させている場合、フォーム入力要素 (<input> 要素、<textarea> 要素、<select> 要素) にフォーカスが当たるとその入力要素に紐づいたラベルが音声で読み上げられ、ラベルに包含された「必須」
2013年4月5日 著 釣りっぽい見出しで言いたいことは言い切ってしまっているけど、繰り返します。Webサイトをあらゆるデバイスに対応させるには、アクセシビリティを確保するしかない。別の言い方をするなら、ビジュアルデザインがレスポンシブに設計・実装されていようといまいと、アクセシビリティを確保していないWebサイトは、マルチデバイスに対応しているとは言えない。自分はそう考えています。1ヶ月ほど前に、スマートフォンの次に来るものという記事で中島聡氏は次のように書きました： 人類が誕生して以来、人々は何万年もの間、歩く時は常にまっすぐ前を見て生活して来た。ところが、スマートフォン（もしくはiモードケータイ）の登場以来、スマートフォンの画面を見て過ごす時間が長くなってしまった。その分、自分の身の回りに注意を払わなくなり、ある意味「外界とのインターフェイスを遮断」した状態で暮らす時間が長くなってし
2013年1月14日 著 この文章は、28回目となる国際「テクノロジーと障害者」カンファレンス（通称CSUNカンファレンス2013）に提出したペーパー「Do we really need skip links, seriously?」の日本語訳です。残念ながら審査を通過することができず（セッションに空きが出れば採用するかもねという返事）、発表をすることは叶いませんでした。ウェブアクセシビリティ基盤委員会が先だって開始したJIS X 8341-3:2010 達成基準7.2.4.1を満たす条件に関する意見募集に対する自分の意見（の一部）として、以下に掲載しておきます： Webページの主要なコンテンツに対し、直接的なアクセスを提供するスキップリンクを設けることは、WCAG 2.0の達成基準 2.4.1 バイパスブロックを満たすための方法として、広く知られています。スキップリンクは、Webページを
Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo
公開: 2012年4月11日1時25分頃 「首相官邸ホームページのリニューアル構築費用に対して製作者側からの考察 (7dw.jp)」というブログ記事を書かれている方がいらっしゃるようで。 申し訳ないのですが、最初から最後まで同意できない部分の方が多いですね。特に看過できないのがアクセシビリティの部分で、これは既に複数の方からツッコミが入れられています。 Re: 首相官邸ホームページのリニューアル構築費用に対して製作者側からの考察 (kidachi.kazuhi.to)Kotaro Kokubo - Google+ - 最近「デザイン」という言葉のひどい扱いを頻繁に目にしていたたまれない気持ちになって いたところにダメ押しのような某… (plus.google.com)「アクセシビリティに配慮すると、ビジュアルデザインが制約を受ける」「ビジュアルデザインとアクセシビリティは両立しない」という
公開: 2012年4月8日16時40分頃 首相官邸 (www.kantei.go.jp)のサイトがリニューアルしたそうで。 4500万円かかったと報じられていますが、何をやったのかが分からないので、高いか安いかは評価のしようがないですね。単純に規模から「やるべき事」を考えてみると、CMS抜きで4500万円かかっても不思議ではないと思います。戦略をみっちりやったり、それなりなCMSを入れたりすれば足りなくなるかもしれません。 そして実際にサイトを見てみると、まず、見た目だけで以下のような点が気になるわけです。 背景にうっすらと写真が敷かれていますが、肝心な部分がコンテンツの下敷きになってよく見えない上に、「首相官邸」というタイトルまわりが読みにくくなってしまっています。プロがこういう中途半端な写真の使い方をすることはまずありません。写真を見せたいならちゃんと見せるでしょうし、見せなくても良い
■ 首相官邸ホームページとアクセシビリティ 首相官邸ホームページのリニューアルに4,500万円かかったというニュースで高いの安いのと話題になっているけど、それはまぁどうでもよくて*1。これに対してあるWebデザイン会社が書いた「高くないよ!」というエントリを読んだアクセシビリティ業界人たちがそろって天を仰いだという話である。 件のエントリは「首相官邸ホームページのリニューアル構築費用に対して製作者側からの考察」で、特にアクセシビリティのところはツッコミどころ満載なんだけど、その点にかんしてはすでに木達さんが書いているので(ようするに先をこされた)、Web業界人はろくろなんて回してないで読んでおいた方がよいです。特にアクセシビリティとデザインの両立のところ。 さて、首相官邸ホームページのリニューアルでアクセシビリティを確保するとして、件の記事では300万円の見積を出しているのだが*2、じゃあ
2012年4月5日 著 4,500万円が妥当だの妥当でないだの盛り上がっているようですね。どうしても金額「だけ」を取り出して云々したくなるのが世の常・人の常だと思っていますから、その点については意見も感想ももっていません。いやもてない、と言ったほうが正確かな。あきみちさんがGeekなぺーじ:金額の報道は効果的に怒りを煽るで書かれているように、どこまでが4500万円の範囲内なのかを自分も知らないし。それはそれとして、首相官邸ホームページのリニューアル構築費用に対して製作者側からの考察という記事のアクセシビリティに関する考察は、多くの人にあらぬ誤解を招く可能性が高いように感じたので、反論させていただきます。 公共系の案件で用いられるアクセシビリティの基準の一つとして『Webアクセシビリティの新規格「JIS X 8341-3:2010」』というものがあります。 正確な標題は「高齢者・障害者等配慮
2012年1月28日 著 ばけらさんがスキップリンクにまつわるいくつかの議論を紹介されていましたが、そのとあるところに自分も居合わせていたので（議論した場を隠す必要性を僕は感じないのですが......ちなみにWAIC WG2でのお話です）、ちょこっと言及しておこうかと。 ビジュアルブラウザを使っている一般のユーザーが、「次の見出しにジャンプする」という機能を必要とするケースがあるのか スキップリンクによるブロックスキップは、特定の障害を持つユーザーの役には立つかも知れないが、その他のほとんどのユーザーには無用な者なのではないか 既にうろ覚えですが、上記は自分の発言からの書き起こしのように記憶しています。要点は、スタイルシートでマルチカラムレイアウトが実装されたWebページにつき、コンテンツをリニアライズして利用するのでなければ、ブロックスキップは有用ではないのでは？という疑問です。リニアラ
7.2.4.1 ブロックスキップに関する達成基準 複数のウェブページ上で繰り返されているコンテンツのブロックをスキップできるメカニズムが利用可能でなければならない。 注記 この達成基準は，等級A の達成基準である。 以上、JIS X 8341-3:2010 7.2.4.1 より ……これで全てです。これだけではさっぱり分からないと思いますので、対応するWCAG2.0の解説を参照することをお勧めします。JIS X 8341-3:2010の達成基準7.2.4.1は、WCAG2.0の2.4.1に対応します。 Understanding WCAG 2.0 - Understanding Success Criterion 2.4.1 (www.w3.org)WCAG 2.0解説書 - 達成基準 2.4.1 を理解する (waic.jp)ここで注意する必要があるのは、何らかの方法でブロックスキップが
font-size: 0; には気をつけて 一発ネタ（ネタ？）というか、それまで知らなかったので覚え書き。先日出席した2011年度第10回ウェブアクセシビリティ基盤委員会WG2で、塩尻市公式ホームページが話題に。というのも、アクセシビリティに配慮したホームページということで、 リニューアルし公開したホームページでは、総務省「みんなの公共サイト運用モデル改定版（2010年度）」に基づき、「JIS X 8341-3:2010」達成等級AAに準拠しました。 ……だそうです。話題になったポイントはそこではなく、Google Chromeでは一部のリンクにタブキーでフォーカスを与えることができないという点。具体的には、リンクがul要素でもってリストとして複数並べられている箇所でその事象が確認されており、たとえばヘッダーにある「音声読み上げ・文字拡大」「English」といったリンクラベルが並んでいる
アクセシビリティPodcast、完結 まぁ、タイトル通りなんですけども。勤務先での業務の一環として取り組んで来たアクセシビリティPodcastが、先月23日公開の第40回後編をもって完結しました。本当はその直後に個人的感想をこちらに記しつつ紹介しようと思っていたのですけど、なんとなくタイミングを失ってしまっていて。メインパーソナリティーの一人で同僚の辻さん（a.k.a. @debugon）のコラム『アクセシビリティPodcastが目指してきたもの』が本日付けで公開されたのを機に、ようやく？覚え書きしておきます。以下、コラムよりいち段落を引用させていただきます： 繰り返しになりますが、アクセシビリティPodcastは、Webアクセシビリティをもっと身近に感じていただくことを目的として開始したコンテンツでした。お寄せいただいた感想の中に、分かりやすい解説や読み上げ音声を交えたデモンストレーショ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
