HTML Standardの更新でdialog要素に関する変更があったので、自分の理解の整理のためにもまとめてみます。 Scott O'Hara氏によるdialog initial focus, a proposalという提案の一部が反映された変更で、#8199でマージされました。主な変更差分を見るとわりと大きめの追記がされていることがわかります。 提案されていることがすべて採用されていたり、提案で言及されている問題がすべて解決しているわけではなく、議論が続いているものも多いので、今後dialog要素がどういった方向に変更され、進化していくのかを見守る補助的な記事になればいいなと思います。 autofocus属性ほぼ必須 結論から言うと、autofocus属性がほぼ必須となります。そのautofocus属性はdialog要素自体とは限らず、内包している子孫要素に適切な場合もあります。 <d

リンクとボタンのビジュアルが似たものもしくは同じものになる理由のひとつに「押せる」[1]という共通点があるからだと思っている。 ビジュアルを似たもの・同じものにするかどうかは状況により判断されるので、そこに画一的な優劣は存在しない。しかしリンクとボタンは明確に異なる機能や振る舞いをもっている。その振る舞いやそれに対するユーザーのメンタルモデルから結果ビジュアルが同じになるのならいいのだが、ただ単純に「押せる」ことだけを基準にデザインされてしまうのは具合が悪い。このエントリーでは、リンクとボタンをデザインするにあたって「押せる」だけではなく、他にも判断材料となるものがあることを共有したいと思う。 前提と定義 今回の話はウェブブラウザで動作するUIを前提に考える。途中で言及するが、リンクがURLに関係していることと、URLをユーザーが意図的に変更できることが大きく関係するので、ネイティブアプリ

(() => { "use strict"; const elements = Array.from(document.querySelectorAll("*")); const clickEvents = elements .map((element) => { const listeners = getEventListeners(element); const clickListeners = listeners.click || []; clickListeners.forEach((event) => (event.owner = element)); return clickListeners; }) .flat(); for (const event of clickEvents) { if (event.owner.matches("button, a[href]")) {

結論 ロールについて知る HTMLの暗黙のロールを知る ロールを知った上でロールに対して使用できるプロパティ/ステートを使う (おまけ) markuplintを使おう aria属性を使う前に まず、いきなりaria-labelやaria-selectedとかに手を出さない。 aria-selectedとかを発見してしまうと「option要素以外にもselectedみたいな意味を付加できるんだ！すげえ！使ってみよう！」みたいな気持ちが沸き上がってしまう。わかる。とってもよくわかるよ。当時ぼくもそうだったから。 ただ、そこはぐっと我慢してほしい。 なぜかと言うと、aria属性は、使っていいときと悪いときがある。きちんとWAI-ARIAという仕様と、ARIA in HTMLやCore Accessibility API Mapping (Core-AAM)という仕様で決められていっている[1]の

これは備忘録であり、閉じた空間で話したことをオープンにしたいと思って公開している記事です。文字起こしでありません。 経緯としては、僕がモーダルの不満をツイートしたのがキッカケで、情報設計の分野の大先輩の稲本さんに、とりあえず不満を聞いてもらいつつ、いっしょに意見を整理させてもらった。 定義 ここでいうモーダルは、「モーダルダイアログ」のことで、他の操作を受け付けない状態、つまり文字通りモード状態になるもの。基本的に全面に被さるダイアログが現れてその他の操作はそれをを閉じるまで不可能になるインターフェイスと定義する。 Webアプリはわかる、しかしWebサイトのそれはわからん まず前提として、Webアプリケーションにおけるモーダルの有用性や必要性は理解できている。そもそもGUIが誕生した初期から存在していて、WindowsやmacなどのOSでも要所々々で今でも採用されているインターフェイスだ。

前提 自分が嫌だと思う項目を作らない。 曖昧を許容できるようにする。 なぜその項目が必要なのかを説明する、もしくは予想できるようにする。 倫理的に、そして法的に問題ないものか確認する。 HTMLの仕様とブラウザの挙動を活用する。 システムの都合が優先される場合があるが、なるべくそれに引っ張られないように工夫したい。 分割しない 姓名、郵便番号、電話番号、年月日、時分など、入力フィールドが分かれていることがあるが、なるべくこれを避ける。フォーカスの移動が、面倒だからだ。なるべくユーザーの手間を減らしたい。 フォーム送信後のデータベースの都合や、事務処理、または運用にて必要不可欠である場合を除いて、分割しないようにしよう。 年月日や時分などは <input type="date"> <input type="time"> <input type="datetime-local"> のように標準

<search>要素がHTML Standardに追加されました。私も初めて出会う要素になるわけですが、とても良い機会なので、私が要素を調べる際にどうやって調べて学んでいるのかを共有したいと思います。これは新しい要素に限らず、既存の要素の調査に応用できると思います。また、初学者はもちろん、マークアップを生業としている方にも参考になると思います。 新要素追加の経緯を調べる まずはHTML StandardのGitHubのPRからスタートするとよいでしょう。議論や更新はGitHubで行われています。たとえば、今回の<search>はAdd the <search> element #7320というPRによって更新されました。 そもそも更新自体のキャッチアップ方法はクローズされたPRを更新順にして確認してもいいですし、更新のみをツイートしている@htmlstandardのTLを確認してもいいと思

HTML Standardにpopover属性をはじめとしたPopover APIが正式にマージされました。Open UIによって提案されていた[1]APIで、名前がPopoverなのかPopupなのか紆余曲折の末、やっとHTML Standardとなります。 現段階で実装されているブラウザは少ないですが、簡易サンプルを作ったので体験しながら読んでいただくといいかもしれません。