タグ

ブックマーク / blog.w0s.jp (14)

  • `<iframe>` 要素による外部リソース埋め込みには `<a href>` のリンクを付与して欲しい

    これはアクセシビリティのカレンダー | Advent Calendar 2023 - Qiita(qiita.com) の12日目の記事です。 Web アクセシビリティにおいて「画像に適切な代替テキストを設定する」はもっとも基的なことのひとつとして認識されています。動画や音声では字幕がそれに相当するでしょう。また、スマートフォン出現以来使われる機会は少なくなっているものの、イメージマップ にも代替テキストは必要です。 ところでこれらの画像、動画、音声、イメージマップは HTML において埋め込みコンテンツ(Embedded content) に分類されており、その要素一覧は次のとおりとなります。 画像 picture, source, img 主に外部リソースの埋め込み iframe, embed, object 動画、音声 video, audio, track イメージマップ map

    `<iframe>` 要素による外部リソース埋め込みには `<a href>` のリンクを付与して欲しい
  • HTML で `<select>` 要素を `<hr>` でセパレートできるようになった

    HTML Living Standard の5月2日付けの更新で <select> 要素の子要素として <hr> を含めることができるようになりました。 Proposal: Allow adding separator rows to <select> boxes using <hr> · Issue #3410 · whatwg/html Allow <hr> to be used inside <select> as a separator by annevk · Pull Request #9124 · whatwg/html 4.4.2 The hr element 4.10.7 The select element <select> 要素の中をグループ化する方法としては、従来から <optgroup> 要素が存在しますが、これは label 属性による可視ラベルの設定が必須なため

    HTML で `<select>` 要素を `<hr>` でセパレートできるようになった
  • `<hgroup>` 要素は今どうなっているのか

    今年(2022年)7月のアウトラインアルゴリズム廃止に伴い、使用方法が大きく変わったものの一つに <hgroup> 要素 があります。 W3C HTML5 時代の <hgroup> 要素 HTML Living Standard の <hgroup> 要素 <hgroup> 要素のアクセシビリティ上の問題 W3C HTML5 時代の <hgroup> 要素 § <hgroup> 要素が最初に登場したのは2009年5月のこと(web.archive.org) で、同年8月には W3C HTML5 の仕様書に追加 されています。 当時の使い方は <h1> 〜 <h6> 要素のみを組み合わせて小見出しや代替タイトルを示すものでした。 上記のコードでは、サブタイトルは Heading content である <h2> 要素でマークアップされているものの見出しとは見なされず、 <h1> 要素のみが見

  • CSS ファイルの最小化を止めた

    ブログでは一時期、転送量を最小限に抑えるために HTML, CSS, JavaScript の不要なコメントやインデント、改行を除去する最小化を行っていました。 HTML に関してはブログを始めた2009年以来、 CSS は Sass を導入した2011〜2012年あたりからだったと思いますが、最小化は転送量削減効果がある一方でデメリットもあります。 言うまでもなく HTMLCSS などの Web で使われるリソースはブラウザの「ソースの表示」機能やパケットキャプチャツール等で中身を確認できます。ユーザースタイルシートを書く、フォーム送信前に送信先(action 属性値)をチェックするなど、ユーザーが直接ソースコードを見る場面は一般的な使い方とまでは言えないものの、それなりには存在するでしょう。 昨今のデスクトップブラウザには開発者ツールが標準搭載されており、 HTMLCSS

    CSS ファイルの最小化を止めた
    klim0824
    klim0824 2022/06/21
  • HTML のアウトラインアルゴリズムが見出しレベルをベースとしたものに刷新されそう

    HTML のアウトラインアルゴリズムが刷新されようとしています。 記事では、最初に現時点のアウトラインアルゴリズムの概要を説明した後、どのような変更が行われるかを紹介します。 現時点のアウトラインアルゴリズムの概要 アウトラインアルゴリズムの刷新 現時点のアウトラインアルゴリズムの概要 § HTML にはアウトラインアルゴリズムという概念があります。 一昔前の HTML、すなわち HTML4 以前はセクションの概念がなく、章立ては見出し要素(<h1> 〜 <h6>)のみで行うしかありませんでした。 HTML5 ではアウトラインの概念が導入され、見出し要素とセクショニングコンテンツ(<section> 要素など)を組み合わせてセクションを使用することが可能になり、仕様では専用の章「Headings and sections」にて詳しく解説されています。 最初の HTML 5 Working

    HTML のアウトラインアルゴリズムが見出しレベルをベースとしたものに刷新されそう
  • `<aside>` 要素のアクセシビリティマッピングが変更

    W3C が公開している HTML Accessibility API Mappings 1.0 において、2022年4月4日付で <aside> 要素のアクセシビリティマッピングが変更されました。 Suggest <aside> should map to complementary with restrictions · Issue #86 · w3c/html-aam aside mapping revisions by scottaohara · Pull Request #350 · w3c/html-aam 記事ではなぜこのような変更が行われたのか、 Web 制作者が注意すべき点を含めて確認してゆきます。 <aside> 要素と対応する role アクセシビリティマッピングの変更 ブラウザ対応状況 <aside> 要素と対応する role § <aside> 要素はセクショニン

    `<aside>` 要素のアクセシビリティマッピングが変更
  • HTML の `hidden` 属性が列挙型に変更され `hidden="until-found"` が追加

    すべての HTML 要素に指定できる hidden 属性 はこれまで真偽属性 でしたが、このたび列挙型に変更され、新たに until-found が定義されました。 hidden="": Hidden 状態 hidden="hidden": Hidden 状態 hidden="until-found": Until found 状態 ← New! 2022年3月24日現在、 Chrome 102 (canary) は hidden="until-found" に対応しており、記事で例示する挙動を確認できます。 これは以下の issue で提案されていたものです。 Proposal: beforematch event and hidden=until-found attribute · Issue #6040 · whatwg/html 例えばこんな HTML の場合。 <section

    HTML の `hidden` 属性が列挙型に変更され `hidden="until-found"` が追加
  • ブラウザの画像ラベル自動生成が普及した近未来における代替テキストの妄想

    Edge が代替テキストの設定されていない画像に対して、自動生成されたラベルを提供するようになったそうです。 Appears to say: Microsoft Edge now provides auto-generated image labels(blogs.windows.com) alt="" のように alt 属性値が空とされた画像や小さなアイコン画像が除外される面も含めて、2019年に Chrome に実装された機能(www.blog.google) と同様なものと思われます。 今後 Firefox や Safari 、あるいは各種モバイルブラウザにも導入が進む可能性もありそうですが、将来的に多くのブラウザが有する機能になった場合、どういうことが起こりうるか考えてみました。 画像ラベルが自動生成されるケース 画像ラベル自動生成は当たり前になるのか alt 属性がないときの画像

    ブラウザの画像ラベル自動生成が普及した近未来における代替テキストの妄想
  • JavaScript の MIME タイプが `text/javascript` に統一されようとしている

    現在、 JavaScript の MIME タイプは2006年4月に公開された RFC 4329(www.rfc-editor.org) にて text/javascript (OBSOLETE) application/javascript (COMMON) text/ecmascript (OBSOLETE) application/ecmascript (COMMON) の4つが定義されています。 この RFC 4329 では text/* の2つは OBSOLETE 扱いな一方で、 JavaScript を呼び出す HTML の仕様では HTML5 以降、 <script> 要素の type 属性を省略することが推奨 されたうえで、省略時の値は text/javascript である とされました。 このように RFC 側と HTML 側で矛盾が生じる事態が長い間続いています。 実

    JavaScript の MIME タイプが `text/javascript` に統一されようとしている
  • 「デジタル庁創設に向けた準備サイト」がスクリプト無効で閲覧できない

    デジタル庁創設に向けた準備サイト(www.digital.go.jp) なるものが立ち上がったようです。 が、スクリプト無効設定でアクセスすると残念なことに……。 スクリプト無効設定で www.digital.go.jp にアクセスした様子。真っ白で何も表示されていない。 サイトポリシー(www.digital.go.jp) の「閲覧環境について」を読むと、 当ウェブサイトでは、より快適にご利用いただくためJavaScriptを使用しています。ご使用のブラウザの設定においてJavaScriptが有効となっていない場合、正しく表示されない、又は操作できないことがありますので、ご了承ください。 サイトポリシー(www.digital.go.jp) とあるので、これは設定ミスやサーバーのエラーでそうなっているのではなく、意図的な作りと思われます。ソースコードを見るに「Nuxt.js」を使い、レン

    「デジタル庁創設に向けた準備サイト」がスクリプト無効で閲覧できない
    klim0824
    klim0824 2021/04/28
    ブラウザはスクリプト有効が前提になってるだろうけど、スクリーンリーダー等がJavaScriptにどれだけ対応しているのか不透明だよね。だからスクリプト無効にしても閲覧できるのを目指すべき。
  • `<meta charset="UTF-8">` を書く必要性があるケースとデメリット

    HTML 文書内に <meta charset="UTF-8"> を書いていますか? 書いているとしたら、その必要性を問われた時に理由を説明できますか? 実は私も勘違いしていた部分があり[1]、改めてまとめてみました。 <meta> による文字エンコーディング指定の歴史 Content-Type ヘッダーと <meta> の関係性と優先度 <meta> が必要なケース <meta> で文字エンコーディングを指定するデメリット <meta> による文字エンコーディング指定の歴史 § まず基的なおさらいをします。<meta charset="UTF-8"> は HTML5 で登場した新しい記法で、 HTML4 以前は <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> などという長くて覚えにくい書き方をしてい

    `<meta charset="UTF-8">` を書く必要性があるケースとデメリット
  • 2016年を振り返って、 HTML, CSS, JavaScript の書き方を変えたところ

    2016年のブラウザ事情の進展に伴い、実務で HTML, CSS, JavaScript の書き方が変化した部分を列挙してみます。あくまで代表的なもののみです。 ブラウザのサポートバージョン変化環境面の変化まとめ ブラウザのサポートバージョン変化§ IE 8 サポート終了§ 2016年1月に IE 8 のサポートが終了しました。 html5shiv.js の読み込みが不要になったSVGが(PNGによる代替画像を用意することなく)使えるようになったvideo要素、audio要素が使えるようになった::before, ::after 擬似要素をダブルコロンで書けるようになった:not 擬似クラスが使えるようになり、例えば一行テキストエリアのセレクターが input:not([type]), input[type="text"] で正確に表せるようになったaddEventListener(),

    2016年を振り返って、 HTML, CSS, JavaScript の書き方を変えたところ
  • パスワード用途以外に`input`要素の`type="password"`を使うのは間違っていない

    パスワード用途以外にinput要素のtype="password"を使うのはどうやら間違っている - F.Ko-Jiの「一秒後は未来」(blog.fkoji.com) に対する返信記事です。 当該記事では Chrome の挙動をもとに セキュリティコードの入力欄に type="password" を使うというのが意味的にも間違っていると Chrome は言いたいのだなと解釈しました。 と締めていますが、 Chrome 問題を抜きにして意味的に間違っているか否かを確認するために、HTMLの仕様書を読み返してみました。 HTML 2.0(RFC 1866) HTML 3.2 HTML 4.01 HTML5 まとめ HTML 2.0(RFC 1866) § An <INPUT> element with `TYPE=PASSWORD' is a text field as above, exce

    パスワード用途以外に`input`要素の`type="password"`を使うのは間違っていない
  • パスワードの定期的な変更を勧める企業にその根拠を聞いてみた

    先日、とある企業からメールにて会員向けに「なりすましログイン」に関する注意喚起メールが届きました。 その中にパスワードを定期的に変更することが推奨されていたので、その根拠について質問し、先方の担当者とやりとりした結果を記録として残しておきます。長文の割にとくにオチはありません。 メール内容の引用は全文ではありません。文頭の挨拶文など、筋に関係ない部分は省略しています。 当該企業を晒し上げることが目的ではないため、サービス名、担当者名は伏せています。 まず最初に、会員向けに届いたメール(の一部)がこれです。 メールをお送りしているメールアドレスのIDでは、なりすましログインは確認されておりませんが、今後、会員情報が不正に利用されることを防ぐため、定期的なパスワードの変更をお勧めいたします。 ※なりすましログインが確認された方については、別途、弊社より個別にご連絡を差し上げております。 今

    パスワードの定期的な変更を勧める企業にその根拠を聞いてみた
  • 1