はてなブックマーク

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

改善戦略 実行のタイミングやGitHubの状況や依存サーバーのネットワークの状況によって変動はあるものの、早くて7分、だいたい10分〜15分くらいかかっている。早いか遅いかは、他の開発と比べても内容や状況が違うのでなんとも言い難いが、個人的な感想としては「遅い」。というより、一切の工夫をしていなかったので、もっと早くできるはずだと考えた。 ビルドされたファイルを複数の環境で共有する 処理全体の中で時間がかかっている処理は3つ。 依存パッケージのインストール ビルド テスト さらに、課題の一つとして「テスト実行時に開発用依存パッケージ（devDependencies）がインストールされているせいでテストが失敗しない問題がある」というものがあり、これを処理に追加しないといけない。 開発用依存パッケージのインストール ビルド 依存パッケージを一旦すべて削除 本番用依存パッケージのインストール テ

<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となります。 現段階で実装されているブラウザは少ないですが、簡易サンプルを作ったので体験しながら読んでいただくといいかもしれません。

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

前回の「WAI-ARIAを学ぶときに整理しておきたいこと」（以下、「前回の記事」と略）やYouTubeで生配信した「WAI-ARIA勉強会」で 要素には暗黙のロールをもつ role属性を使うことでロールを上書きできる 要素によって上書きできないロールがある と説明した。 しかし、上書きできないロールをrole属性で指定してしまったときに最終的にロールが何になるかの説明をしていなかったし、要素の条件次第によっては上書き可能なはずのロールが無効化されたり、ロールが変化したりすることに触れていなかった。今回はそこが仕様でどうなっているのか深堀りしてみたいと思う。 ロールの決定に影響するもの まず、簡単にロールがどういったものから決定されるのかをざっくりと最初にまとめる。 要素の種類（HTMLとしてのセマンティック） 属性 構造（先祖・子孫関係） これをまず念頭に置いて、仕様を読みすすめると理解が

現在の数字 最新バージョン: v2.10.1 コミット数: 2,122 IssueとPull Request: 530件（クローズ含む） npmダウンロード: 11,179（週間） テストコード数: 916 テストカバレッジ: 74% GitHubスター: 315ユーザー スポンサー: 1ユーザー ふりかえり ライトニングトークでのお披露目 最初のコミットから約4ヶ月後、VS Code拡張も用意できて業務でもドッグフーディングしてある程度機能するようなったので、開発の動機と楽しんで開発できている旨をライトニングトークした。SNSを中心にそこそこ広まってくれたのもあって、GitHubのスターが増えたり、「使ってみよう」という声をぼちぼちと聞くようになった。最初のアピールとしては良い滑り出しだったとは思う。 当然ながらスライドは日本語だしSNSの広がりも国内にとどまったので、GitHubのスタ

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

HTML Standardの更新を月ごとに掲載します。2022年3月から記載しています。HTML解体新書をひととおり読んで、その後にどんなアップデートがされているか確認したい方向けの本です。 HTML解体新書をまだ読んでない人は是非読みましょう。 https://www.borndigital.co.jp/book/25999.html

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

2.4.7 では基本的に「フォーカスインジケータが見えること」で適合となります。失敗例もインジケータを視覚的に完全に消していることのみとなっており、「十分な達成方法」や「さらに対応が望まれる達成方法」として『目立つ』という言葉をつかっているものの、その具体的な閾値は示されていませんでした。それが今回の 2.7.11 と 2.7.12 では、具体的な数値や計算方法が『面積』や『カラーコントラスト』で規定されることになります。 面積とコントラスト まずは原文を読み解いてみます。 Success Criterion 2.4.11 Focus Appearance (Minimum) (Level AA): When user interface components receive keyboard focus, an area of the focus indicator meets the

デザイナーやエンジニアがアクセシビリティのそれらに共感して「やっていき」になっていくとき、いくつかのパターンがあると思っています。新人教育や講義などでアクセシビリティについて語るにあたって 「どうやったら知識としてインストールされるだけなく、モチベーションを上げていわゆる『やっていき』に開眼させることができるか」 を常々考えています。十人十色なので、少ないパターンだと響かないで不発に終わることもあります。もちろん、そもそもそういうタイプではない（そこに良し悪しはありません）のかもしれませんが、潜在的に素養があるのにアプローチを間違えただけだとしたら非常に勿体ないですよね。今回はいくつかパターンを考えてみようと思います。 人権 「アクセシビリティは人権だ」という考え方です。アクセシビリティを向上させることは社会モデルにおける障害を取り除くことです。「すべての人類に与えられるべき権利」だと思え

(() => { "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ハードコア HTMLのプロ。 markuplint.dev 開発者。株式会社ディーゼロ 執行役員。

検討したり、例外を適切に設けるために使うものです。 要件定義 バックエンドシステム・CMSが以下に対応している 入力フォームに時間制限はない 入力フォームの入力チェック機能は適切なエラーメッセージがでる 出力されるHTMLが仕様に準拠したHTML 画像に代替テキスト(alt属性)が入れられる 動画にクローズドキャプションを追加できる 自動的に生成されるウィジェットがアクセシブルになっている 画像のポップアップ（モーダル）機能など 3rdパーティのウィジェットやASPがアクセシブルである 動画埋め込み 地図埋め込み サイト内検索 自動翻訳機能 チャットボット 情報設計 情報設計に問題がない・情報を管理できている ナビゲーション設計が適切でどのページにもたどり着ける リンクテキストとリンク先ページタイトル・見出しに乖離がない ページタイトルとh1見出しに乖離がない サイト内でページタイトルに重

結論 ロールについて知る 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"> のように標準

2020年Webアクセシビリティアドベントカレンダー14日目の記事です。 先日HTMLリンターであるmarkuplintのバージョン1.3.0をリリースしました。今回追加された機能は主にwai-ariaというリントルールの追加で、WAI-ARIAとARIA in HTMLにおける role属性やaria属性に関するチェックをするルールです。 wai-ariaルールは次の場合に警告します。 仕様に存在しないロールを指定した場合