Re: すべての商用サイトは8341に対応すべき？
2018年4月7日 著 良くも悪くも2chぽさのあるWeb制作者専用のQ&Aサイト、W3Qですべての商用サイトは8341に対応すべき？という質問を見かけました。ここで言う8341というのは、Web制作という文脈からJISの規格、『高齢者・障害者等配慮設計指針－情報通信における機器，ソフトウェア及びサービス－第3部：ウェブコンテンツ』（JIS X 8341-3）を指していると考えて良いでしょう。あとで時間ができたらマジレスしようと思っていたのですが、既に元同僚の方がマジレスしていて、良い意味で出る幕が無かったという。 とはいえ、質問者の方がなぜこのような問いを立てたのかというのは結構、興味深いです。なんとなく察するのは、質問者は商用サイトの運営に関わっており、上司なり経営層からJIS X 8341-3に対応することを比較的最近になって求められたのではないかと。また合理的な範囲というフレーズか
Webアクセシビリティに関する大喜利 回答案
2015年12月8日 著 去る11月30日、Web担当者向けセミナー：障害者差別解消法 施行目前！アクセシビリティ対応、なぜ始める？どう進める？で登壇したわけですけども、そのセッション3 ディスカッション「アクセシビリティについて、いまWeb担当者が考えるべきこと」で繰り広げられた大喜利（と企画側では呼んでいた）に向け、個人的に用意していた回答案を覚え書きしておくなど。YouTube Liveの録画を見ていただければ分かりますように、ほぼ用意していた通り受け答えしたところもありますし、そもそも本番で言及されなかった？ 問いもあります： アクセシビリティ確保の端的なメリット・デメリットとは？ メリット：管理・運用するWebコンテンツの価値・機会・信頼の最大化、Web環境の変化に対する耐久性の向上、そしてコンプライアンス デメリット：無い、と力強く言い切りたいところだけれど、新規に取り組む前提
壊れたデザインプロセス（「The Broken Design Process」日本語訳）
2012年8月12日 著 以下の文章は、Philip Zastrow氏の書かれた「The Broken Design Process」を翻訳したものです。レスポンシブWebデザイン関連の記事をこの数ヶ月、いろいろ斜め読みしてきましたが、これは是非とも翻訳しておきたいと思ってZastrow氏にコンタクト、翻訳と掲載につき了解を得ました。ただし、この翻訳には誤りが含まれている可能性があります。英語が読めるなら、原文のほうを是非お読みください。 Webデザインのプロセスは壊れており、レスポンシブWebデザイン（訳者注：以後「RWD」と表記）の推進によって、モダンなアプローチを余儀なくされつつある。 典型的なデザインプロセスでは、理想化されたWebサイトのコンセプトイメージが写真編集アプリを用いて制作される。そして、コンセプトイメージを顧客または承認する立場にある権威に渡し、フィードバックや批判を
MobifyのモバイルUXチェックリスト
2013年11月28日 著 25 Top Design Upgrades to Make Your Mobile Revenue Skyrocketという記事で紹介されていた、モバイルUXチェックリストがなかなか興味深かったので、ざっくり訳してみました。適当なので、訳には誤りが含まれている可能性があります。英語が読めるなら、個々の項目の詳細を確認していただく意味でも、元記事のほうを是非ご覧ください。 ボタンやタッチターゲットは44px四方より広い（Buttons and touch targets are at least 44px by 44px.） 本文の文字サイズは14px以上（The font size of body copy is at least 14px.） 本文の行の高さは1.5以上（The line height of paragraph text is at leas
覚え書き@kazuhi.to: アクセシビリティとユーザビリティ
アクセシビリティとユーザビリティ 先日、関西でWebアクセシビリティを考える会が開催されたのを機に、アクセシビリティとは？ユーザビリティとの違いとは？みたいな内容の書かれた記事をいくつか目にしました。 関西でWebアクセシビリティを考える会に参加してきました！｜ふにろぐ アクセシビリティとユーザビリティ :: デザインワークス・オンサイド 「関西でWebアクセシビリティを考える会」に参加してきました | REFLECTDESIGN 言葉の定義というのは、議論をするうえでお互いの理解なり前提を揃えたりするのに重宝する反面、それに囚われ過ぎるとかえって大切な中身（それを「本質」と呼ぶかはさておき）を見失いがちになることがあると思っています。また、文脈によって言葉の意味するところは変化し得るとも思っているので、すべての人が賛同する定義というのはそもそもあり得ない気がするし、あったところでそれにど
覚え書き@kazuhi.to: font-size: 0; には気をつけて
font-size: 0; には気をつけて 一発ネタ（ネタ？）というか、それまで知らなかったので覚え書き。先日出席した2011年度第10回ウェブアクセシビリティ基盤委員会WG2で、塩尻市公式ホームページが話題に。というのも、アクセシビリティに配慮したホームページということで、 リニューアルし公開したホームページでは、総務省「みんなの公共サイト運用モデル改定版（2010年度）」に基づき、「JIS X 8341-3:2010」達成等級AAに準拠しました。 ……だそうです。話題になったポイントはそこではなく、Google Chromeでは一部のリンクにタブキーでフォーカスを与えることができないという点。具体的には、リンクがul要素でもってリストとして複数並べられている箇所でその事象が確認されており、たとえばヘッダーにある「音声読み上げ・文字拡大」「English」といったリンクラベルが並んでいる
覚え書き@kazuhi.to: 第1回「アクセシビリティBAR（仮称）」初夏のパンくず祭
第1回「アクセシビリティBAR（仮称）」初夏のパンくず祭 5月31日の覚え書き。中根さんの呼びかけによって催された、第1回「アクセシビリティBAR（仮称）」初夏のパンくず祭に参加しました。初回ということで実験的な側面もあり、人数をかなり少なめに設定したうえで、個室カラオケ本格中華スプラッシュ銀座コリドーの一室を会場に開催。参加されたのは、自分を含め主にウェブアクセシビリティ基盤委員会WG2の委員の皆さんでした。もとはといえばヤマザキ「春のパンまつり」になぞらえ、パンくずリストと呼ばれる何かについて語り合う「春のパンくずまつり」をカワサキで開催しようとかいう話だったのですが、気がつけばすっかり初夏になってしまい以下略。にしても、大変楽しくも有意義なひとときを過ごすことができました。詳細は割愛しますが、 Togetter - 「第1回「アクセシビリティBAR（仮称）」初夏のパンくず祭」 第1回
覚え書き@kazuhi.to: Re: CSS Nite in Ginza, Vol.31でお話させていただきました
Re: CSS Nite in Ginza, Vol.31でお話させていただきました コバさんのCSS Nite in Ginza, Vol.31でお話させていただきましたという記事を読んで。僕はイベントに参加したわけではないから、文脈であったり発言の真意を十分に理解したうえで書くわけではないのですが……。 また、結構思い切ってXHTMLを採用する際に、XML宣言を書かないようにということを言ってしまいましたので、もしかしたら反響もあるかと思います。僕の場合は、まぁ書いた方が仕様にそったものであるのは分かっているのですが、作業工数があがってしまうのはクライアントさん的にどうかなーということもありまして、デメリットを説明した上で、書かないということがほとんどです。せっかくCSSレイアウトになって作業効率の向上が実現されたということもありまして、それならば楽出来る部分は一層楽しましょうよという
覚え書き@kazuhi.to: アクセシビリティという言葉をなくしたい
アクセシビリティという言葉をなくしたい ……そういう想いで日々の業務に取り組んでいるつもりだし、そのために今後いつ・何に・誰と・どう取り組んでいくのかを考え続けている、ということを覚え書きしておきたいと思いました。きっかけは、今日の午前中にオブザーバー参加させていただいた、ウェブアクセシビリティ基盤委員会WG1の会議。そこで話し合われた内容にはあえて触れませんが、たまたま自分に発言が振られたときに、どういうわけかそういう話の流れになったんですね。どういうわけかといっても、所詮自分の発した言葉であって、自分なりの文脈はあったわけだけれど。 無論、なくしたいといっても、そう簡単になくせるものではない、というのは百も承知。言葉をなくすというのは、言わば表層的な意味でのゴールというか、メタファーなのであって、本質的にはその位置づけを常識にする（＝何ら特別ではない「当たり前のこと」であるからして、わ
覚え書き@kazuhi.to: Re: 第1回 ひきついだサイトはdivでいっぱい！
Re: 第1回 ひきついだサイトはdivでいっぱい！ ITProのほうで鷹野さんが「作業効率を高めるDreamweaverの小技」という連載を始められたのですが、その第1回 ひきついだサイトはdivでいっぱい！で以下の段落がふと気になりました。 </div>の手前に<!-- / div#wrapper -->のようにコメントを入れておくとよいでしょう。</div>の後ろに入れる方もいますが、構造上も手前が望ましいですし、上記の方法で選択する際、</div>の後ろでは選択されないため、ごっそりコピー&ペーストしたり、移動する際に、せっかく入れたコメントが忘れられてしまいます。 上記のなかで構造上も手前が望ましいと書かれているのですが、その根拠は何だろう？と思ったのです（2月22日追記：当該箇所は既に語弊があるという理由から削除されています）。Dreamweaverを用いた要素単位での操作にお
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
