タグ

htmlに関するklim0824のブックマーク (151)

  • 主題と副題のマークアップにはhgroupを使用する – TAKLOG

    主題と副題のマークアップの方法に関しては度々Xでも話題になっていて、例えば次のポストの返信やリポストを見ると、人によって以下のような様々なアプローチがあることがわかります。 参考:過去に話題になったポスト ポストを別枠で表示する 見出し要素(h1〜h6)の中に主題と副題の両方を含めるこの場合の副題はspanではなくstrongやsmallを使うと言った意見も見られる主題をh1要素でマークアップし、副題は隣接するh2要素を使う疑似要素とcontent:attr()を使って副題を表示するこのブログのトップページでも主題+副題が用いられていて、いくつかのマークアップ方法を検討した結果「hgroupの中に主題のh1要素と副題のp要素を含める」方法を選択しました。

    主題と副題のマークアップにはhgroupを使用する – TAKLOG
  • 2024年版 HTMLで作るフォームバリデーション - ICS MEDIA

    すべてのフォームが要件を満たしている場合のみ、送信できます。 フォームバリデーションのデザイン 上記の例では最低限のHTMLのみ実装されています。しかし、実際のサイトではバリデーションエラーをユーザーにフィードバックする必要があります。よりユーザビリティの高いフォームでは、以下の点を検討する必要があります。 エラー時のスタイル エラーメッセージの出し方 バリデーションエラーの表示タイミング 以下では、それぞれについて深堀りします。 エラー時のスタイル エラーを検知する方法として、CSSには:valid疑似クラスと:invalid疑似クラスがあります。これらの疑似クラスは『CSS疑似クラスを活用した、モダンでインタラクティブなフォームの作り方』でも紹介されている、バリデーションエラーが起きている要素にのみ適用されるクラスです。 しかし、この疑似クラスには欠点があります。required属性を

    2024年版 HTMLで作るフォームバリデーション - ICS MEDIA
  • dialog要素を使用したモーダルウィンドウの実装例 | TAKLOG

    dialog要素を使用したアクセシブルなモーダルウィンドウの実装メモです。このブログのハンバーガーメニューで使われている実装と同じものになります。 dialog要素は現在全てのモダンブラウザでサポートされているため、iOS Safariをどこまで対応するかに依りますが実務で使用しても差し支えないでしょう。

    dialog要素を使用したモーダルウィンドウの実装例 | TAKLOG
  • 実践 popover 属性 〜HTMLのみのモーダルで実案件に使えるのか確認〜

    こんにちは森田です。 前回、HTMLのみでモーダルが作れる popover 属性の概要についての記事を書きました。 2024年はHTMLのみでモーダルが作れそう。popover属性を試してみる。 前回の記事内では軽い動作しかしていなかったので、今回は実際に案件でどこまで使うことができるか確認したいと思います。 popover 属性を試してみる ではさっそく popover 属性を色々試してみましょう。 まずは動作確認として超シンプルなモーダルを作ってみます。 動作確認用超シンプルなモーダル まずは前回の記事のおさらいで、動作確認用の超シンプルなモーダルです。 モーダルになる要素に popover 属性と任意の id を。表示するボタンにpopovertarget属性を指定し、モーダル要素の id を指定します。 <button type="button" popovertarget="po

    実践 popover 属性 〜HTMLのみのモーダルで実案件に使えるのか確認〜
  • HTMLタグにデフォルトスタイルを付けるCSSライブラリ

    以下を満すようなツール (自分は)書き捨てHTMLを見やすく(pretty)する用途で使う ビルドツール不要 スタイル用にHTMLを修正しなくていい(class-less)

    HTMLタグにデフォルトスタイルを付けるCSSライブラリ
  • フロントエンドid属性管理戦略

    アクセシビリティのチェックなどを行っているとよく発見される問題にIDの重複がある。HTMLではid属性はグローバル属性でありすべての要素に指定できるが、その値は一意である必要があり、ドキュメント内において重複があってはならないことになっている。 ただ実際に実装してみたり開発経験のある人ならご存知のとおり、滅多なことでこの重複が問題になることは少ない。HTMLのパースは中断することなくブラウザは要素を描画するし、CSSのセレクタは期待通り要素を特定してスタイルを適用する。なのでこの重複に対してそこまで気を使ってこなかった人も多いだろうし、先のアクセシビリティチェックでよく発見されるのもそういった背景があるのだろうと思う。 しかし表面的に問題が起きていなくとも、実際には重大な構文エラーであり、潜在的に多くの問題を抱えている。IDの重複が引き起こす問題は単純で、そのIDを参照する処理はひとつめの

    フロントエンドid属性管理戦略
  • HTML: The Inaccessible Parts

    I’ve always abided in the idea that “HTML is accessible by default and then we come along and mess it up.” In a lot places this is very true and by just using a suitable HTML element instead of a generic div or span we can have a big Accessibility impact. But that’s not always the case. There are some cases where even using plain ol’ HTML causes accessibility problems. I get frustrated and want to

    HTML: The Inaccessible Parts
  • input[type=checkbox] 要素に switch 属性を指定することによる HTML 標準のスイッチ UI の提案

    input[type=checkbox] 要素に switch 属性を指定することによる HTML 標準のスイッチ UI の提案 2023.12.23 スイッチは多くのウェブサイトで使われているものの、HTML の標準要素としては存在していませんでした。そのため多くの開発者は、スイッチを実装するために独自の実装を行っていましたが、このような独自の実装はアクセシビリティの問題を引き起こす可能性がありました。この問題を解決するために、WHATWG により `input[type="checkbox"]` 要素に `switch` 属性を追加することが提案されました。この属性を指定することで、チェックボックスをスイッチとして利用できます。 input 要素の switch 属性は 2023 年 12 月現在実験的に実装されている機能です。将来的に仕様が変更される可能性があります。 スイッチ とは

    input[type=checkbox] 要素に switch 属性を指定することによる HTML 標準のスイッチ UI の提案
  • モーダルダイアログの未来はdialog要素で幸せになるか

    こんにちは、及川です。 今回のテーマはdialog要素です。みなさん、dialog要素はご存知でしょうか?もう現場で使っているでしょうか? dialog要素はいわゆるダイアログボックスを描画するための実装で、HTML要素の中では比較的新しめの要素です。このdialog要素の仕様を理解し、モーダルダイアログコンポーネントとしてどのように実装するかを学習することが記事のゴールです。 dialog要素 ってなに?dialog要素はダイアログボックスを表現するためのHTML要素です。 cf) <dialog>: ダイアログ要素 – HTML: ハイパーテキストマークアップ言語 | MDN dialog要素は新しめとは言うものの意外と長い歴史をもっていて、2012年あたりから今の形でHTMLの草案に追加されたり削除されたりを繰り返し、全てのモダンブラウザで動くようになったのが2022年のことです。

    モーダルダイアログの未来はdialog要素で幸せになるか
  • `<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 の form は PUT / DELETE をサポートしないのか? | blog.jxck.io

    Intro 10 年ほど前に同じことを調べたことがある。 なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。 この問題についてあらためて記す。 仕様策定の経緯 表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。 仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio

    なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io
    klim0824
    klim0824 2023/11/28
    “「誰の何の問題を解決するためなのか」が説明されていない正しさは幻想”
  • HTML: ログイン・ユーザー登録フォームの厳選ベストプラクティス11(翻訳)|TechRacho by BPS株式会社

    概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: 11 HTML best practices for login & sign-up forms—Martian Chronicles, Evil Martians’ team blog 原文公開日: 2023/05/24 原著者: Andrey Sitnik(PostCSSとAutoprefixerの作者、首席フロントエンドエンジニア) サイト: Evil Martians -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 日語ブログ: 合同会社イービルマーシャンズ - Qiita 日語タイトルは内容に即したものにしました。 はじめに ログインフォームやユーザー登録(サインアップ)フォームは、ほとんどのWebサイトで使

    HTML: ログイン・ユーザー登録フォームの厳選ベストプラクティス11(翻訳)|TechRacho by BPS株式会社
  • アイコンボタンのアクセシブルな名前はボタンが持つべきかアイコンが持つべきか

    記事は<svg>要素のみを持つ<button>要素(アイコンボタン)にアクセシブルな名前(accessible name)を持たせる方法について調査した結果と、WCAG 2.2のSuccess Criterion 1.1.1 Non-text Contentに関する私見をまとめたものです。 結論 アイコンボタンの非テキストコンテンツは装飾ではなく意味を持つ画像なので、ボタンではなくアイコン画像自体にアクセシブルな名前を持たせるべきだと考えます 一方で、非テキストコンテンツの範囲をアイコンのみではなくアイコンボタン全体と捉えると、ボタンにアクセシブルな名前を持たせることも妥当に思えますが、<img>要素や<svg>要素など様々な種類のアイコン画像の実装を想定した場合、やはりボタンにアクセシブルな名前を持たせない方針に倒す方がシンプルだと思います <svg>要素のみを持つ<button>要素

    アイコンボタンのアクセシブルな名前はボタンが持つべきかアイコンが持つべきか
  • dialog要素を使ってアクセシブルなモーダルを作ってみよう

    この記事について 2022 年 3 月、Safari15.4で HTML の dialog 要素が標準でサポートされました。 これにより、全ての主要ブラウザ(Chrome, Edge, Safari, Firefox)で dialog 要素が利用可能になり、今まで@react-ariaなどのライブラリに依存していたモーダル実装を見直したいと思っている方も多いのではないでしょうか。 記事では、HTML の dialog 要素の使い方からアクセシブルなモーダルの要件、それらを全て満たすアクセシブルなモーダルの実装例についてご紹介します 🫡 そもそもアクセシブルなモーダルの要件って何? そもそもアクセシブルなモーダルの要件とはどのようなものを指すのでしょうか。 Accessible Rich Internet Applications (WAI-ARIA) 1.1やARIA Authorin

    dialog要素を使ってアクセシブルなモーダルを作ってみよう
  • HTML First

    HTML First is a set of principles that aims to make building web software easier, faster, more inclusive, and more maintainable by... Leveraging the default capabilities of modern web browsers. Leveraging the extreme simplicity of HTML's attribute syntax. Leveraging the web's ViewSource affordance. Goals The main goal of HTML First is to substantially widen the pool of people who can work on web s

    HTML First
  • ウェブコンテンツアクセシビリティガイドライン(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

    ウェブコンテンツアクセシビリティガイドライン(WCAG)は何が難しいのか、あるいは難しさに立ち向かう方法 - 水底の血
  • dl/dt/ddのスクリーンリーダーの読み上げをなんとかする

    この記事で取り上げる手法は実験的です。何か問題があった際に、すぐに修正・改善できる立場にないのであれば採用するべきではありません。 期待と異なる読み上げ スクリーンリーダーを使ったことがある開発者ならご存知のとおり、dl要素、dt要素、dd要素の構造はスクリーンリーダーの読み上げにおいては期待と異なる挙動をします。おそらくは歴史的な経緯からそうなっているのだと思いますが、この挙動を理由にdl要素、dt要素、dd要素を使わないという選択をする開発者もいるようです。 現行のスクリーンリーダーの読み上げは概ね以下のような挙動をします。HTMLコメントの部分が読み上げられる内容とします。 <dl> <dt>りんご</dt> <!-- リスト 1/4 りんご --> <dd>バラ科の落葉高木</dd> <!-- リスト 2/4 バラ科の落葉高木 --> <dt>みかん</dt> <!-- リスト 3

    dl/dt/ddのスクリーンリーダーの読み上げをなんとかする
  • 1Password のオートコンプリート機能をサービス提供側で無効化する

    Leaner Technologies の @corocn です。 最近フォームを作っていて、意図しないタイミングで 1Password のオートコンプリートが表示されてしまい困っていたので解決法を残しておきます。 画像はshadcn/ui - dialogから拝借 結論 input に data-1p-ignore 属性を付与する autocomplete="off" しても空気読んで無効化してくれないので注意。

    1Password のオートコンプリート機能をサービス提供側で無効化する
  • アクションシートの実装から学ぶ <dialog> 要素を使う時の3つの落とし穴 - Katashin .info

    2023年8月28日HTML,CSS,JavaScript<dialog> 要素が主要なブラウザすべてに実装され、現実的に使えるようになってきましたが、これをそのまま実際の Web アプリで使うには様々なものが足りません。足りないものを自分で実装していくと、分かりづらい挙動があったり、癖のある実装が必要なことがあります。例えば、<dialog> 要素のデフォルトは中央揃えで、コンテンツに合わせたサイズになりますが、これの位置、サイズ調整やアニメーションをする際に落とし穴があります。 記事では、以下のアクションシートのようなモーダルを実装する例を通して、<dialog> 要素を使う時の3つの落とし穴を紹介します。 デフォルトのスタイルが分かりづらい #<dialog> 要素にはデフォルトでいくつかのスタイルが設定されていますが、これまでの HTML 要素のデフォルトスタイルと比べると値が特

    アクションシートの実装から学ぶ <dialog> 要素を使う時の3つの落とし穴 - Katashin .info
  • input[type="number"] のマウスホイール事故を防ぎたい

    Leaner Technologies エンジニアのぐりこ( @glico800 ) です。 今回は何かと話題に上がりがちな input[type="number"] について、個人的に新しい発見があったので簡単にまとめてみました! 背景 ユーザーから入力した値と保存されている値が違うとのお問い合わせがあり、「そんなはずは…。」と思って調べてみたところ、 input[type="number"] の入力後にマウスホイール操作でページ下部にある保存ボタンに移動する際に入力値が意図せず変更されてしまっていたことが発覚。 「これは気づけない!」ということでなんとかしたい。 やりたいこと input[type="number"] でマウスホイール操作による入力値の変更をできないようにする。 前提 今回はPCChrome バージョン: 114.0.5735.198 で表示したケースを想定 実装方針

    input[type="number"] のマウスホイール事故を防ぎたい