Re: HTMLのルート要素ではcolorとbackground-colorをセットで指定すべき - 水底の血
ちょっと間が空いて、亀リプっぽくなっちゃいましたけど、HTML のルート要素では color と background-color をセットで指定すべきというお話について。 昔からブラウザには配色設定があり、テキスト色と背景色をユーザーが任意に指定できます。 ……という話は Web アクセシビリティとフェイルセーフの記事に以前書いたのでその詳細は省略しますが、WCAG 2.2 達成方法集の F24(W3C) において達成基準 1.4.3（レベルAA）などの失敗事例として掲載されているにも関わらず、このことは世間ではなぜか認知が薄いようです。 認知も薄いというか、私も言われるまで気づかなかったあたり、まあそういうことなんじゃないかなと*1。……という話だけはあまりにもアレなので、ざっくりとですが、ほんのちょっと深掘りしてみましょう。 WCAG 2.1 達成方法集のF24のタイトルは、「達成基
（メモ）「ウェブアクセシビリティ導入ガイドブック」は自身がアクセシビリティ規格を満たしているわけではない - 水底の血
デジタル庁が提供しているウェブアクセシビリティ導入ガイドブックは、ウェブアクセシビリティの理解の一歩として有用な資料ですが、このガイドブック自身は残念ながらPDFのアクセシビリティ規格であるISO 14289-1 (PDF/UA-1)を満たしているわけではない…という話。 どうやってチェックしたかですが、veraPDFというツールでチェックを行いました。チェック対象ファイルは2024年3月29日発行のウェブアクセシビリティ導入ガイドブックです。 チェックに使用するveraPDFのバージョンですが、veraPDF/veraPDF-libraryのReleasesを見る限り、Developmentバージョン（v1.26.0 RC）でもいろいろPDF-UA/1周りの修正が入っているようですので、今回はv1.26系列を使ってみることにします。ビルド済みのjarファイル（インストーラー）はhttps
アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その3） - 水底の血
アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その1）、（その2）の続きです。 おさらい 対象ページ：「アトリエ金工やまぐち」 Basic認証があるので、アクセシビリティ向上日誌１【各種ツール評価編】からたどってください @HeldaForStudy氏に了承を得てアクセシビリティチェックを行っています チェック基準：WCAG 2.1レベルA 文中のSCはSuccess Criteriaの略で達成基準のこと 目的はどうやってアクセシビリティチェックしているのか、チェックしながら何を考えているのかを書き記すことです 制作ページやチェック内容にネガティブなことをいいたいわけではありません チェックに抜け漏れ、誤りがあるかもしれません 仕様等は基本的に日本語訳を当たります では続きに入っていきましょう。 「ABOUT」セクション アクセシビリティチェックの経験がある
アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その2） - 水底の血
アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その1）の続きです。 おさらい 対象ページ：「アトリエ金工やまぐち」 Basic認証があるので、アクセシビリティ向上日誌１【各種ツール評価編】からたどってください @HeldaForStudy氏に了承を得てアクセシビリティチェックを行っています チェック基準：WCAG 2.1レベルA 文中のSCはSuccess Criteriaの略で達成基準のこと 目的はどうやってアクセシビリティチェックしているのか、チェックしながら何を考えているのかを書き記すことです 制作ページやチェック内容にネガティブなことをいいたいわけではありません チェックに抜け漏れ、誤りがあるかもしれません 仕様等は基本的に日本語訳を当たります では続きを進めていきましょう。 モーダル出現ボタン スクリーンショットですと、 HTMLソースとしては、
アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その1） - 水底の血
ツイッターでアクセシビリティ向上日誌２【目視試験編】‐Akira Tsuda Portfolio and Blogというのを見かけて、そういえばアクセシビリティチェックって何をどうしているのかという話をウェブ上でほとんど見かけない（というか自分は知らない）ので、思い切ってチェックの過程や考え方を書いてみようかなと。 チェック対象のサイトを作った@HeldaForStudy氏に尋ねたところ、題材として使ってよいという返事をいただいたので、「アトリエ金工やまぐち」のサイト1ページをチェックしてみることにします。 対象ページはBasic認証がかかっているので、アクセシビリティ向上日誌１【各種ツール評価編】からたどってください。 @HeldaForStudy氏はレベルはA*1でチェックしたとのことなので、チェック基準はWCAG 2.1レベルAでチェックすることにしましょう。 わたしは普段はCOB-
（メモ）ウェブアクセシビリティについて、改正障害者差別解消法はいったん脇に置いた方がいいんじゃないかみたいな話。 - 水底の血
ウェブアクセシビリティにフォーカスを当てたいときに、障害を理由とする差別の解消の推進に関する法律（障害者差別解消法）でもって、「合理的配慮」（義務）の事前的改善措置としての「環境の整備」（努力義務）という論法がわかりにくすぎると思っており、だからこそ不正確な話が出てくると思うんですよね。 なので、障害者による情報の取得及び利用並びに意思疎通に係る施策の推進に関する法律（障害者アクセシビリティ・コミュニケーション施策推進法）でもって話を進めるのがいまのところはシンプルなんじゃないですかね。通称にアクセシビリティって入ってますし。 （事業者の責務） 第五条 事業者は、その事業活動を行うに当たっては、障害者がその必要とする情報を十分に取得し及び利用し並びに円滑に意思疎通を図ることができるようにするよう努めるとともに、国又は地方公共団体が実施する障害者による情報の取得及び利用並びに意思疎通に係る施
ウェブコンテンツアクセシビリティガイドライン（WCAG）は何が難しいのか、あるいは難しさに立ち向かう方法 - 水底の血
LINEヤフーにおけるこれからのアクセシビリティというスライドで「WCAGはハードルが高い」という文言を見かけました。どうしてハードルが高い、言いかえるならば難しいとされるのか、その難しさはどこから来るのかをちょっと深掘りしてみようと思います。 WCAGという言葉について、改めて見ておきましょう。WCAGはもっぱら、Web Content Accessibility Guidelines（ウェブコンテンツアクセシビリティガイドライン）というW3Cの発行する技術文書を指すわけですけども、現時点でよく参照されるのがウェブアクセシビリティ基盤委員会（WAIC）が公開している日本語訳のWCAG 2.1でしょう。ちなみに本家のW3Cは、WAICが現時点で公開しているWCAG 2.1の改訂版を今年9月に公開し、さらにバージョンの進んだWCAG 2.2を先月に発行したばかりだったりします。 WCAG 2
JIS X 8341-3:2016のいう「サイズの大きなテキスト」について - 水底の血
JIS X 8341-3:2016（WCAG 2.0）では、用語集で「サイズの大きな (テキスト)」が定義されている。WAICの公開しているWCAG 2.0日本語訳のサイズの大きな (テキスト)は次のように記載されている*1： サイズの大きな (テキスト) (large scale (text)) 少なくとも 18 ポイント、又は 14 ポイントの太字。あるいは、中国語、日本語、及び韓国語 (CJK) のフォントは、それと同等の文字サイズ。 （中略） 注記 5: 半角の英数字のテキストにおける 18 ポイント及び 14 ポイントのサイズは、拡大印刷の最小サイズ (14 ポイント) と標準的な大きい文字サイズ (18 ポイント) に基づいている。例えば、CJK 言語のようなその他の文字については、「同等な」サイズはその言語での拡大印刷の最小サイズと拡大印刷でその次に大きな標準のサイズとなる。
autocomplete属性のものすごく簡単なメモ - 水底の血
Autocomplete workshopというミーティングが今年1月に行われたようで、autocomplete方面が盛り上がりつつあるみたいです（whatwg/html#4986）。 このワークショップのノート（Google Doc）が公開されていますけれども、参加者にブラウザーベンダー*1がいるのは当然として、Eコマースのプラットフォーム方面（Shopify、WIX、Checkout.com、Shipper HQ）が参加しているのが興味深いところ。 箇条書きでまとめられているものを雑に引っ張ってみると actocomplete属性の拡張をこれから考えていくことになるが、目下で注目しているのは名前と住所 250サイトについて入力フォームを調べてみた 日本を含めたいくつかの国は、オートフィルがうまく機能しない どの情報を1つのフィールドに入力するかについて、サイトごとにまちまち 日本では氏
国交省ハザードマップ検討会のWebアクセシビリティの認識が詰んでいる - 水底の血
ツッコミが追いつかないというのは、こういうことを指すの…？ ハザードマップのユニバーサルデザインに関する検討会 - 国土交通省水管理・国土保全局 障害等に対応する一人ひとりのニーズに応じた水害リスク情報提供のあり方を検討する有識者会議を開催します！ ～ハザードマップのユニバーサルデザインに関する検討会（第１回）の開催～ - 国土交通省 ハザードマップは、主に地図上に水害リスクに関する情報を示すものですが、視覚等に障害を有する場合は紙面等の情報を取得することが困難であること、また、自身のリスクが把握しづらく、避難行動に役立ちにくいという意見もあることから、一人ひとりの環境やニーズに合ったリスク情報提供のあり方を整理するため、「ハザードマップのユニバーサルデザインに関する検討会」を設置し、令和３年１２月２３日（木）に第１回検討会を開催します。 という趣旨らしいです。これまで検討会は4回開催され
WCAG2の「十分な達成方法」について - 水底の血
あるいは必要十分条件について1。 Nu Html Checkerの場合 Nu Html Checkerは、HTMLをチェックするツールである。Nu Html Checkerで特定の（種類の）エラーを0にすることは、「構文解析」のWCAGの達成基準を満たすための必要十分条件となる。 達成基準 4.1.1 構文解析 (レベル A): マークアップ言語を用いて実装されているコンテンツにおいては、要素には完全な開始タグ及び終了タグがあり、要素は仕様に準じて入れ子になっていて、要素には重複した属性がなく、どの ID も一意的である。ただし、仕様で認められているものを除く。 筆者による上記引用のハイライト部分“どのIDも一意的であること”について見てみる。たとえば以下のHTML断片のように、1つのページに同じid属性値が2回出現することはHTMLのエラーであり、かつ、WCAGの達成基準の違反となる：
総務省の近畿管区行政評価局によるホームページに関する報告書が面白い - 水底の血
【PR】HTML解体新書出版記念イベントとかあるらしいです。YouTubeライブでのストリーミングですが、アーカイブも残るという話らしいです。 令和4年3月付けの報告書が興味深いと思うんですよ。 総務省｜近畿管区行政評価局｜ホームページによる行政情報の提供状況に関する調査 https://www.soumu.go.jp/kanku/kinki/r03_1_report.html 技術的に細かいところはいろいろとありますが、この報告書をつくるに至るまでの取り組み自体は評価したいというのもありますし、（積極的に取り組むべしとされている）行政がどういう体制でどの程度のレベル感なのかを探ることができる、貴重な文書なんじゃないかなと。 いろいろと見所はあると思うんですけど、目に付いた箇所をざざっとメモ書きで。 表3-(1)-① JIS X8341-3 の主な達成基準と達成基準の具体的メリットの脚注に
公共系のウェブアクセシビリティの要件定義を考えるみたいな話から行政への働きかけ云々 - 水底の血
散らかってる上に、読み返してないのでおかしな文章になってるかもですが。 さておき、少し前ですけどなんかのイベントで雑談する機会があって、地方自治体の仕様書が斜め上でアレって話を聞いた記憶があるんですけども。例えば公共系の巷によくある文字サイズを変更するボタンとか、あれぶっちゃけ仕様書に入っちゃってるんで、どうしようもない的な怨嗟の声とか聞いたことがあった気がするんですけども、結局もっと上のレイヤーでそういう文言が入っちゃってるからそうなると考えるわけで。 たとえば、平成29年（2017年）3月に発行されている国土交通省所管事業における障害を理由とする差別の解消の推進に関する対応指針というのがありまして、これはまあ障害者差別解消法で定めるところの基本方針に基づいて、事業者が適切に対応するために必要な指針というものが出されるわけです（法第11条） その中には【航空運送業関係】として （２）合理
「やさしい日本語」のお焚き上げ - 水底の血
誰だったか「やさしい日本語」についてツイートしていたので、いろいろと調べていたら、ひつじ書房ウェブマガジン「未草」というサイトで「やさしい日本語」は在留外国人にとって「やさしい」のか？というドンピシャな連載があったのでいろいろ書けるかな…と思ったんですけど、この連載が結構な長編なのと、論説というよりかはエッセイテイストなのでまとめきれませんでしたみたいな（）。 全体をとおして、アクセシビリティガイドラインとの対比で言うと、WCAG2 SC 3.1.5 読解レベルと対比してどうなのか？といったところでしょうか。「やさしい日本語」は、果たして通常の日本語の代替コンテンツになっているのか？というのはアクセシビリティの観点から興味深いと思っており、このあたりは第10回 在留外国人に対する言語政策1：多言語表示と通訳と機械翻訳みたいなところとも絡んできており、特にウェブコンテンツとして「やさしい日本
HTML文書は文字エンコーディングUTF-8でなければなりません - 水底の血
さよならレガシーエンコーディング。 文字エンコーディング宣言が存在するかどうかにかかわらず、文書のエンコードに使用される実際の文字エンコーディングはUTF-8でなければならない。 4.2.5.5 文書の文字エンコーディングを指定する - HTML Standard 日本語訳 Require utf-8 when specifying character encoding by sideshowbarker · Pull Request #3091 · whatwg/htmlにより、HTMLで使用できるエンコーディングはUTF-8のみとなりました。これにより、古いHTMLでは許容されていた、Shift_JIS、ISO-2022-JP、EUC-JP、UTF16LEといった文字エンコーディングは適合するHTMLではなくなりました。すでにNu Html CheckerでUTF-8以外の文字エンコー
W3Cで現在公開されているHTMLとDOM仕様は将来廃止されます - 水底の血
まえがき W3C（とWHATWG）からの公式なアナウンスはまだ確認していませんが、何度目かに結成されるW3C HTML WorkingのDraft Charterと、このCharterから辿れるDRAFT Memorandum of Understanding Between W3C and WHATWG（Memorandumは日本語で覚書などと訳されるので、ここでも覚書と呼びます）がブログエントリーのタイトルのソースになります。もっとも、今確認できる覚書もドラフトですから、変更があるかもしれません。しかしながらURLで観測できるわけですから、大筋でW3CとWHATWGとの間で合意が取れているのではないかと推測します。あとは、覚書だけでなくCharterもドラフトということになっていますが、以下の文章では面倒なので省略します。最後にお約束ですが、このブログエントリーは「だいたいあってる」感
メモ：両HTMLにおけるmain要素の説明、ついに一定の収束の気配か。 - 水底の血
あの2015年9月に端を発したとてつもなく長いmain要素の定義をどうにかしようというissueについに収束の気配が。 whatwg/htmlに<main>の記述を変更するPull RequestがAnneから出されている。このPRによるdiffはこんな感じ。 このPRでは2つ目のNoteはこのように変更される： While there is no restriction as to the number of main elements in a document, web developers are encouraged to stick to a single element. 4.4.14 The main element (#3326) 試訳するとこんな感じか。「文書のmain要素の数に制限はないが、ウェブ開発者は単一の要素にこだわることを勧める。」 そんなこんなで、main要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
