HTML 4 時代に `<img>` 要素の `width` / `height` 属性の記述を避けていた理由
昨今、累積レイアウトシフト防止の観点から <img> 要素には width / height 属性を付けた方が望ましいとされています。しかし複数の記事（日本／海外問わず）において「レスポンシブ Web デザインの普及により一時期は両属性を書かない時代があった」という解説が行われていることには違和感があります。 私が HTML を書き始めたのは2001年ですが、昔の個人サイトのアーカイブを見返すと2003年にはすでに width / height 属性を意識的に避けていた形跡があります。レスポンシブ Web デザイン以前の時代にどういった理由で両属性を避けていたのかを思い返してみます。 <img> 要素自体は初期の HTML から存在していたのですが、width / height 属性が仕様に追加されたのは HTML 3.2 でのことです。当時は両方の属性を指定することで this allo
text-scale によるユーザ指定倍率での文字拡大 | blog.jxck.io
Intro 小さい文字が見づらい場合、ユーザは OS の文字サイズを大きくすることで、視認性を調整することができる。 こうした機能は大抵の OS が備えており、システムフォントのサイズなどに反映される。 しかし、その指定がそのまま Web コンテンツにも反映されるかというと、必ずしもそうではない。 この問題を解決するために、いくつかの標準が提案され、策定と実装が進んでいる。 サイズの相対値指定 「ユーザは文字を拡大することがある」というのは、おそらく多くの開発者が認識しているだろう。 WCAG を引き合いに出すなら、以下のセクションで「200% までの拡大に対応すべき」といった基準(AA)がある。 text can be resized without assistive technology up to 200 percent without loss of content or fun
3xx リダイレクト画面のマークアップ
HTTP レスポンスのステータスコードのうち、300番台の一部では Location ヘッダーフィールドを併用することでリダイレクトを設定することができます。この場合ブラウザでは通常リダイレクト画面は表示されないのですが、だからといってレスポンスコンテンツ（ボディ）が不要なわけではなく、通常の画面（200 OK）と同様に正しいマークアップを心掛ける必要があります。 ところが世の中の Web サーバーや Web フレームワークは不正な HTML を返すものも多く、リダイレクトが行われなかった場合（リダイレクト画面が表示された場合）にユーザーが不利益を被っているのが実情です。本記事ではなぜリダイレクト画面のマークアップにもこだわる必要があるのか、仕様とブラウザ挙動の両面から考えてみます。 RFC の記述§ リダイレクトの挙動§ RFC 9110 の 15.4. Redirection 3xx(
電子書籍（EPUB）ではHTMLは使えないことになりました — W3Cが苦渋の決断、Webと電子書籍の統合を阻んだ「XMLの壁」
1月15日、W3C Blogで「EPUB and HTML」と題した記事が公開された。この記事では、EPUB次期仕様におけるHTML採用の是非を問うアンケート結果と、それに基づくEPUB 3.4の仕様策定方針について詳しく紹介されている。 以下に、その内容を技術的背景を含めて簡潔にまとめて紹介する。 EPUBとは何か：パッケージ化されたWebサイト EPUBは、国際標準化団体W3Cが策定する電子書籍のオープンな規格である。技術的な実体は「HTMLやCSS、画像などを特定のルールで構成し、ZIP形式で圧縮したもの」であり、いわば「オフラインで閲覧可能なWebサイトのパッケージ」と言える。 現在の主力規格であるEPUB 3系は、リフロー（画面サイズに合わせた文字流動）やアクセシビリティに優れ、世界中の電子書籍ストアで採用されている。 記事の核心：なぜ「HTML採用」が議論になったのか 現代のW
本ブログにおいて `<blockquote>` 要素の `cite` 属性の提供を止めた
Markdown にはブロック引用の構文が用意されています。これは John Gruber によるドキュメント(daringfireball.net)にもあるように電子メールで慣例的に使われていたスタイルを踏襲したものですが、個人的には帰属情報を設定できないことに不満があります。 例えば拡張構文であるコードブロックなら先頭を ```html とすることでそのコードが HTML であることを明示できます。しかし引用文に対する引用元 URL やタイトル、言語情報などの設定は考慮されていません。 昔はプレーンな HTML で引用の帰属情報は <blockquote> の中に入れて良いのか、それとも外に出すべきかで議論が盛り上がったこともありましたが、今は HTML Standard 仕様で Attribution for the quotation, if any, must be placed
`headingoffset` と `headingreset` 属性による見出しレベルの調整
HTML にグローバル属性として headingoffset と headingreset 属性を追加する議論が進んでいます。これが実現すれば見出し要素だけでなく、その祖先要素でも見出しレベルを調整できることになります。 Consider adding a headinglevelstart attribute · Issue #5033 · whatwg/html implement headingoffset & headingreset attributes by keithamus · Pull Request #11086 · whatwg/html 一方、そうなると現状のように <hn> = 見出しレベル N とは限らなくなり、「見出しレベル N の要素を選択する」ことが困難になるため、CSS 側でも :heading および :heading() 疑似クラスの導入が画策されて
`hidden="until-found"`をReactでも使いたい！ | Tech Blog | uga.dev
引用：HTML Standard 日本語訳 https://momdo.github.io/html/interaction.html#the-hidden-attribute Safari以外の主要ブラウザでは利用可能な仕様[1]ですが、まだReact@19現在ではサポートが追いついておらず型エラーが発生し、Reactでは値のない論理属性として扱われてしまいます。 jsx<div hidden="until-found" /> 暫定的にhooksで解決するuse-hidden-until-found.tsimport { useEffect } from 'react'; export const useHiddenUntilFound = () => { useEffect(() => { document.querySelectorAll('[data-hidden-until-fo
Nu html CheckerとAxe DevToolsとの関係性 - 水底の血
とあるところで、HTMLチェッカーをかけて報告された問題を解決したのだけれども、axe DevToolsで問題が報告されるというような話を目にしたので、少し整理しておこうかなと。 HTMLチェッカー（ここではNu html Checkerとしましょう）でHTMLチェックすると、次の3つの種類の問題が報告されます。 Error Warning Info HTMLの構文に則ったHTMLを記述するには、少なくともErrorを0にする必要があります1。しかし、アクセシビリティチェックで指摘する問題となるかどうか、具体的にはWCAG 2の達成基準を満たせているかどうかとは無関係です。たとえば、次のHTML断片はErrorとして報告される構文違反ですが、どの達成基準の問題にも当てはまらないものです。そして、実害があるかといえば、ないといって構わないでしょう。品質のよろしくないHTMLでは、類似のHTM
<svg>ではaltが使えないからaria-labelはロジックをすっ飛ばしている - 水底の血
@_yuheiyによる当エンジニアブログで実施したアクセシビリティ改善の方法についての解説は全体的に丁寧に説明しているだけに、下記の記述がちょっと気になったという話です。 これがimg要素であればalt属性を使って代替テキストを設定すべきですが、svg要素ではそれができません。そこで、WAI-ARIAの出番です。次のようにすることで、alt属性と同様に代替テキストが設定できます。 SVGネイティブに代替テキストを設定する方法は（SVGの）title要素だ、ということはおさえておくべきかなと。SVG2仕様書訳（原仕様書）に次のように書かれています。 title 要素は、 その親要素用の短いテキスト代替を表現する。 つまり、aria-labelを使うことなく、次のように書けます。（HTML解体新書のp.339にもあります。） <a href="..."> <svg role="img"><ti
HTML/CSSで装飾可能に！ select・optionタグの新しいカスタマイズ方法 - ICS MEDIA
2025年3月にリリースされたChrome 134、Microsoft Edge 134では、<select>要素をカスタマイズできるようになりました。今までは<select>要素で表現できる見た目は限られており、やむをえず別のタグを組み合わせて独自の実装をしていた方も多いのではないでしょうか？ 独自の実装をした場合、アクセシビリティーやキーボード操作に対しても独自の対応が必要だったり、対応が不十分になる場合もあります。<select>要素をカスタマイズできるようになれば、こうした課題を解決しつつ自由なデザインやレイアウトを実現できるようになります。 この記事では、カスタマイズできるようになった<select>要素でどんなことができるのかを紹介します！（※本記事の作例はChrome 134、Microsoft Edge 134以上で閲覧ください）。 カスタマイズに必須のCSS まずはカスタ
スクリーンリーダーが <footer> 要素を「フッター」と読みません！ - 弁護士ドットコム株式会社 Creators’ blog
はじめに クラウドサインでは、組織内でアクセシビリティ向上に向けた改善を進めています。 今回は、スクリーンリーダーと <footer> 要素にまつわるお話です。 きっかけ 2024 年 9 月に「弁護士ドットコム×SmartHR「出張！俺の電子契約」〜クラウドサインのアクセシビリティチェック〜」というイベントを開催しました。 視覚障害当事者である SmartHR 社の辻さんに、スクリーンリーダーを使ってクラウドサインを操作していただくイベントでした。 詳細は記事 イベント開催レポート：「出張！俺の電子契約」〜クラウドサインをアクセシビリティチェック〜 - 弁護士ドットコム株式会社 Creators’ blog をご覧ください。 このイベントを見ていて気づいたことがあります。 フッターが「フッター」と読まれていないぞ……？ （その場面） クラウドサインのフッター部は、アプリ画面下部にある「ヘ
summary要素の内部にインタラクティブなコンテンツを配置できてしまう現象について
Anne: we can't disallow this, it's too common and it's useful Domenic: it's bad that AT isn't able to give their users the same capabilities as mouse/keyboard users Keith: can we change things from the browser side, e.g. expose as a group? Simon/Anne: not that simple, sadly Domenic: most recent summaries from ARIA space [Role Parity] What do we do about summary element? w3c/aria#939 (comment) summ
Webアクセシビリティにおける、ロール（role）の解説 - Qiita
アクセシビリティを考慮したWeb開発の話題で、しばしば 「ロール（role）」 というものが登場します。 role="button" のような role属性 として紹介されていることもあります。 ロールは、Webアクセシビリティでとても重要な概念なのですが、わかりやすい解説記事があまり多くない印象です。一方で「role属性を使えばアクセシビリティが向上する」という誤解を招きそうな内容のものもちらほらと存在しており、それを信じて誤った使い方をすることで、かえってアクセシビリティを下げかねない状態になっています。 そこでこの記事では、role属性ではなくロールそのもの についての解説をしたうえで、ロールを適切にする方法のひとつとして、role 属性の立ち位置についても解説します。 より広く詳しい内容については、Qiitaに書いた記事「role 属性とは、aria-* 属性とは、WAI-ARIA
`<a href>` の中を構造化すると iOS の VoiceOver ではリンクが分割されてしまう
年明け早々こんな記事が。 super short note on links in iOS with VoiceOver – HTML Accessibility(html5accessibility.com) 曰く、<a href="#">text <code>code</code> text</a> のようにリンクの中を構造化すると、iOS の VoiceOver ではリンクが分割されて読み上げられてしまうとのこと。手元の iPad (iPadOS 18.2.1) で試してみたところ、確かにそのようになってしまいました。 当該のユーザーにとっては事実上以下のマークアップと同義になってしまうわけで、ちょっとマズい状況です。 <a href="#">text</a> <a href="#"><code>code</code></a> <a href="#">text</a>
<label>で<button>を囲んでいるときにclickイベントが2回発火する問題の原因と対策
皆さんこんにちは。今回は、最近筆者が遭遇した、<label>で<button>を囲んでいるときにclickイベントが2回発火することがある問題について解説します。 さっそくですが、こちらのCodePenをご覧ください。 ここでは、0と書かれたボタンが表示されています。このボタンは1回クリックすると数字が1増えるように実装されています。 しかし、ボタンに表示されている数字をクリックすると、数字が2増えてしまいます。これは、clickイベントが2回発火しているためです。それ以外の部分（ボタンの端や、ラベル）をクリックした場合は数字が1増えます。 実装のHTMLとJavaScriptは以下のとおりです。 <p>数字をクリックするとonClickが2回発火する！！！</p> <div> <label> ラベルのテスト <button type="button"></button> </label>
type=”email”は使わない方が良いんじゃないか（ちょっと良いUIおれおれAdvent Calendar 2024 – 22日目） | Ginpen.com
ちょっと良いUIおれおれAdvent Calendar 2024 – 22日目 <input> は適切に type 属性を使いましょうとは言いますが、メールアドレスの type="email" は入力内容の検証が古いのでやめた方がよくないですか……。 デモ： https://codepen.io/ginpei/pen/dPbWQKB @ だけ見るのが良いのでは 先に結論なんですけど、もう基本は試しにメールを送って届いたら OK くらいのつもりが良いんじゃないのと思います。とはいえ入力内容は @ の有無くらいは見ておくと、爆速コピペでつい他の項目を入力してしまった際に気付けるかもしれません。 というわけでこれでどうですか。 メールアドレスの検証 メールアドレスの書式って実はだいぶ心が広くて、意外な文字や記号が利用可能だったりします。@ の右側もドットなしの localhost とか IP ア
スタイルをカスタマイズ可能な新しい `<select>` 要素
2024/09/21 現在、カスタマイズ可能な <select> 要素は Chrome Canary の v130 以降で Experimental Web Platform Features フラグを有効にすることで利用可能です。 従来の <select> 要素は CSS を利用したスタイルを適用できないため、多くの開発者にとって課題となっていました。この課題を解決するために JavaScript を用いて独自のセレクトボックスを実装することが一般的ですが、この方法はアクセシビリティやパフォーマンスの問題を引き起こすことがありました。 この問題を解決するために新しい既存の <select> 要素をカスタマイズする手段が提案されました。<select> 要素と ::picker(select) 疑似要素に対して appearance:base-select を指定することで、開発者は <s
空世界 〜HTMLの永遠仕様探訪記、或いは、文字なきsrcにまつわる寥々たる考察について〜
問題 <img src=""> をブラウザで表示した時、どうなるか知っていますか？わざわざimg要素のsrc属性を空文字列にする機会がないので意外と知らないかもしれません。 もちろん画像は表示されず、(指定していれば)altが表示されます。 img要素のsrc属性を空文字列にすると、リンク切れになることがわかりました！いかがでしたか？(？) そのときHTMLImageElementは JavaScriptでsrcが空文字列のimg要素のDOMインスタンスを確認してみましょう。例として https://zenn.dev/stin を開き、Chrome開発者ツールを使ってsrc属性に空文字列を指定したimg要素を埋め込んでおきます。 そして次のJavaScriptを実行します。 const element = document.querySelector('img[src=""]'); con
主題と副題のマークアップにはhgroupを使用する – TAKLOG
主題と副題のマークアップの方法に関しては度々Xでも話題になっていて、例えば次のポストの返信やリポストを見ると、人によって以下のような様々なアプローチがあることがわかります。 参考：過去に話題になったポスト ポストを別枠で表示する見出し要素（h1〜h6）の中に主題と副題の両方を含めるこの場合の副題はspanではなくstrongやsmallを使うと言った意見も見られる主題をh1要素でマークアップし、副題は隣接するh2要素を使う疑似要素とcontent:attr()を使って副題を表示するこのブログのトップページでも主題+副題が用いられていて、いくつかのマークアップ方法を検討した結果「hgroupの中に主題のh1要素と副題のp要素を含める」方法を選択しました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.a11y-collective.com/blog/aria-current/