サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
www.mitsue.co.jp
containプロパティにlayoutやpaintを指定した場合やcontent-visibilityプロパティを設定した場合のCSS Containmentの検証をご紹介します。 これまでの関連Blogについては「CSS Containmentの仕組みを理解してレンダリングパフォーマンスをアップする1 概要」「CSS Containmentの仕組みを理解してレンダリングパフォーマンスをアップする2 検証」でご確認いただけます。 layoutの検証 contain: layout;の設定の有無による要素の配置の違いからLayoutの封じ込めを検証します。 containプロパティがない場合 containプロパティの設定がないブロックを用意します。 ブロック内に3つの要素を設置します。 1つ目の要素は、position: fixed;を設定して相対的な配置にします。 2つ目の要素は、flo
春です。入社式のニュースが流れてくる季節ですが、当社もこの4月に多くの新入社員を迎えることができました。 そんな若者について、そもそもXHTMLという単語は何だろうという反応をするかもしれない一方で、長らくHTMLと付き合ってきた人は、XHTMLについて複雑な想いを抱く方も多いだろうと思います。そんな往年のXHTML1時代を過ごしてきた方に改めてお伝えしたいことは、XHTML(HTML Standardでは正確にはXML構文)でHTMLを書くことが推奨されないことが仕様に明示されるようになるというものです。 これは、HTML Standardを管理しているGitHubにWarn that the XML syntax is not recommendedというプルリクエストが作成されたことによります。 このプルリクエストは、XML構文が記載されている14章に次のWarningを追加するとい
containプロパティにstyleやsizeを指定した場合に、どうレンダリングされるかをご紹介します。 CSS Containmentの概要については「CSS Containmentの仕組みを理解してレンダリングパフォーマンスをアップする1 概要」をご確認ください。 タイトルを「レンダリングパフォーマンスをアップする」としていますが、今回ご紹介するstyleとsizeはパフォーマンスを向上するものというよりは、包含ブロックの内外でスタイルの計算やサイズの計算を分けることを目的としています。 styleの検証 contain: style;の設定の有無によるcounter()のカウントの違いからStyleの封じ込めを検証します。 containプロパティの設定がない場合 containプロパティの設定がないブロックを2つ用意します。 ブロックをまたいでそれぞれのブロック内の要素をカウントす
3カ月ほど前にさかのぼりますが、2023年11月2日に開催されたCSS Nite主催のイベント「#朝までマークアップ」において、私は「HTML軽視されすぎ問題」と題した講演を行いました(#朝までマークアップ 開催のお知らせ参照)。講演の録画や、使用したスライドは共有できませんが(セミナーアーカイブ:#朝までマークアップ(2023年11月2日開催)で販売中)、本記事では講演の概要をご紹介します。 まず、業界的にHTMLが軽視されていると考える根拠として、The WebAIM Millionの調査結果やJens Oliver Meiert氏による調査結果を紹介。アクセシブルではない、あるいは仕様に準拠していないHTMLがWebにあふれている現状を共有しました。また、CSS-Tricksの記事「The Great Divide」が論じたフロントエンド職の分断に言及しつつ、相対的にHTMLよりもJ
フロントエンドBlogにInterop 2024がスタートという記事が先日掲載されましたが、ここでは重点分野として加わったアクセシビリティに関して深掘りしてみたいと思います。 アクセシビリティに関しては、WebKitが詳細に、Bocoupが端的に、Mozillaが軽く触れています。もちろんInterop 2024のREADMEにも記載されていますが、これらをまとめ直してみるとおおよそ次のようになります。 アクセシビリティは、既にInterop 2023では調査分野として取り上げられていました。以前のアクセシビリティBlogの記事ARIAを取り巻く2つの自動テストでも触れていましたが、Appleのアクセシビリティチームが主導して、執筆現在では1300を超えるアクセシビリティテストが作成されており、Interop 2024では重点分野としても組み込まれるに至っています。 細かくは3つの領域が挙
Interop 2022、Interop 2023に続き、Interop 2024の取り組みがスタートした旨を知らせる記事が、参加組織それぞれから一斉に公開されました。 Interop 2024 | Blog | web.dev The web just gets better with Interop 2024 | WebKit Interop 2024 Launch - Bocoup Interop 2024 Launches | Igalia Microsoft Edge and Interop 2024 - Microsoft Edge Blog Announcing Interop 2024 - Mozilla Hacks - the Web developer blog 加えて、既にInterop 2024 Dashboardが公開されています。Interop 2023より引き
2023年11月28日 CSS Containmentの仕組みを理解してレンダリングパフォーマンスをアップする1 概要 UI開発者 佐竹 Interop 2023の重点分野の中からWebページの表示性能に関わるCSS Containmentをご紹介します。 CSS Containmentにはcontainプロパティとcontent-visibilityプロパティが定義されており、コンテンツの一部を独立したサブツリーとしてブラウザに認識させる「封じ込め」に関する指定ができます。「封じ込め」を行うと、ブラウザはレンダリング処理の一部を省略したり、必要なタイミングでレンダリングするようになります。結果、Webページのレンダリングパフォーマン向上につながります。 レンダリングの基本的なフロー CSS Containmentの理解を深めるためにレンダリングについて確認します。 以下のフローはBlin
W3Cからアナウンスされたように、WCAG 2.2が2023年10月5日付けで勧告(Recommendation)となりました。 WCAG 2.1の最初の勧告が2018年ですから、そこから5年が経って達成基準(Success Criterion)が追加されたことになります。 WCAG 2.1の勧告について「最初の」とわざわざ言っているのは、WCAG 2.1が先月に更新されたことによります(W3Cのアナウンス)。 WCAG 2.1の更新の内容はもっぱらエラッタの適用ですが(WCAG 2.1のChange Logも参照)、その中でも達成基準4.1.1について注記が追加されたのが目立った変更点と言えます。 この追記は、端的にはWCAG 2.2では達成基準 4.1.1が削除されているように、達成基準 4.1.1についての評価は別の達成基準で行うようにするという内容です。 さて、WCAG 2.2の話
2023年9月11日 Web Sustainability Guidelines(WSG)1.0が公開 エグゼクティブ・フェロー 木達 W3CのSustainable Web Design Community Groupが、8月30日付けでWeb Sustainability Guidelines(WSG)1.0を公開していました。このガイドラインは、Webサイトをよりサステナブルに、つまり持続可能にするための幅広い推奨事項、ベストプラクティスを列挙したものです。 Introducing Web Sustainability Guidelines | 2023 | Blog | W3C New Web Sustainability Guidelines Report | Sustainable Web Design Community Group ガイドラインは、持続可能な社会の実現に必要
2023年7月27日 セミナー「改正障害者差別解消法とWebアクセシビリティ」でお寄せいただいたご質問への回答 エグゼクティブ・フェロー 木達 昨日オンラインで開催したWeb担当者のためのピンポイント講座、改正障害者差別解消法とWebアクセシビリティには大変多くの方々にご参加いただきました。この場を借りて厚く御礼申し上げます。また、質疑応答の時間ではすべてのご質問に回答することができず、申し訳ございませんでした。 本記事では、開催後にアンケートへのご回答を通じてお寄せいただいたものを含め、いただいたご質問にお答えさせていただきます(セミナーの時間中に回答できたものについては割愛しております、あらかじめご了承ください)。字数の兼ね合いから、回答にご満足・ご納得いただけない場合もあるかと思いますが、その場合には是非お気軽にお問い合わせをいただければ幸いです。 アクセシビリティに対する意識の高さ
2024年1月18日に開催した本セミナーの録画(質疑応答を除く40分)を、どなたでもご覧いただけるよう公開します。改正障害者差別解消法を正しく理解し、また改正法の施行に正しく備えるため、ぜひお役立てください。
2023年7月20日 WCAG 2.2の勧告案が発行、8月にも勧告へ アクセシビリティ・エンジニア 中村(直) 筆者の個人的な予測としては、WCAG 2.2の策定にはまだまだ時間がかかるのではと思っていましたが、2023年7月20日付けでWCAG 2.2の勧告案(Proposed Recommendation)が発行されました(W3Cのアナウンス)。 前回の勧告候補(前回の記事WCAG 2.2の勧告候補が更新(2023年5月版)もあわせて参照してください)からの変更点については、編集上の変更にとどまっています。不安定な機能(at risk)とされていたSC (Success Criteria) 2.4.13 Focus Appearanceと2.5.8 Target Size (Minimum)については残留する格好となりました。 現時点でのWhat's New in WCAG 2.2でも
入力フォームがあるページの設計をする際はフロントエンドでもバリデーションを実装することが多くあります。代表的なバリデーションは例えば以下のようなものです。 必須の入力欄に値が入力されていなければエラーとする メールアドレス入力欄に入力された値がメールアドレス形式でなければエラーとする パスワードとして使用できない文字が入力されればエラーとする 入力内容が不適切な場合は、入力欄に装飾を施すために:validと:invalidの2つの擬似クラスを利用してきました。 :validと:invalidは、主にフォームコントロール要素に関連する擬似クラスで、以下のような基準にしたがって各要素の状態がマッチするかどうかを判定します。 required属性付きの入力欄が空でなければ:valid、空であれば:invalid type属性がemailである入力欄に入力された値がメールアドレス形式であれば:va
2023年5月31日 そのaria-labelは本当に必要ですか? チーフアクセシビリティエンジニア 黒澤 アクセシビリティ対応には複数の方法がありますが、方法によって運用負荷はさまざまです。 私はお客様に、aria-labelを設定するのではなく、画面に表示されているテキストで情報が伝わるようにすると運用負荷を抑えられますよ、という話をすることがあります。 aria-labelは指定をミスするとほぼ確実にアクセシビリティの問題につながりますが、画面に表示されないため、作業漏れが生じやすく、指定ミスに気がつきにくい性質があります。 実際、お客様サイト・サービスの現状把握や競合調査の業務ではaria-labelの作業漏れや指定ミスによるアクセシビリティの問題を多数見てきました。 この記事では実際の問題例をサイト・サービスが特定されないように調整したうえで紹介していきます。 紹介した例はいずれ
CSSだけでJavaScriptなどのスクリプトの有効・無効に合わせてスタイルを設定するには@mediaのscripting特性を使用します。 @mediaのscripting特性とは @mediaのscripting特性はW3C Working Draft の Media Queries Level 5となり、Firefox Nightly 113で追加になりました。 構文 scripting特性のキーワードにはnone initial-only enabledがあります。 none ... スクリプトが利用できない状態で有効です。 @media (scripting: none) { body { /* ... */ } } initial-only ... スクリプトが利用できる状態のページロード時に有効です。 例として、CSSだけでページロードの間だけローディング要素を表示し、ペー
内閣府が行った障害者に関する世論調査(令和4年11月調査)によると、一般の方への周知度は未だ24%にとどまっている障害を理由とする差別の解消の推進に関する法律、いわゆる「障害者差別解消法」。その改正については一昨年、「障害者差別解消法の改正とWebアクセシビリティ」でお伝えしていますが、本コラムはその続編です。 去る2月21日、Webアクセシビリティ入門セミナーの2023年版をオンラインで開催、私は講師を務めました。2023年版と言っても、ほぼ毎年のように実施している定番のセミナーですから、内容的には昨年のもののマイナーアップデート版です。 しかし質疑応答については、昨年までと顕著な違いがありました。といいますのも、改正障害者差別解消法(以下「改正法」)に関する質問が相次いだのです。時間中、「どこまで対応すべきか」「すべきことや必須の内容は」といったご質問をいただきました。 改正法の施行が
CSUN 2023のセッションを斜め読みしていたところ、PDF/UA-2: What's New?というものが目に付きました(セッションのスライドが公開されています)。このPDF/UA-2とは何なのでしょうか。 PDF/UA-2は、ISOの規格策定ルールのもとで策定中の規格であり、以前はISO/CD 14289-2.4として作業されていました(詳しい理由は不明ですが、削除されています)。現在はISO/DIS 14289-2として開発中です(参考:ISO/IEC規格の開発手順)。3月時点ではDIS投票期間中であり、早くて年内にはISとして発行されていると思われます。 ISO/DIS 14289-2は、「Document management applications -- Electronic document file format enhancement for accessibilit
スクリーンリーダーユーザーがWebページから情報を得る際には、画面を見ながらの情報取得とは違った工夫が必要な場合があります。その1つが、テーブルからの情報の取得です。画面を見ながらテーブルから情報を取得する場合、テーブルの行と列の内容を同時に確認できます。一方、スクリーンリーダーは項目を1つずつしか読み上げないため、特に2次元的にレイアウトを把握する必要のあるテーブルから情報を得ることが難しくなる場合があります。 こうした問題の解決策の1つに、テーブルの見出しセルにth要素を設定するというものがあります。th要素を設定すると、読み上げ方に若干の違いはあるものの、スクリーンリーダーでデータセル(td要素)の内容を読み上げさせたときに、対応する見出しセルの内容を合わせて読み上げるようになります。 th要素を設定することで閲覧しやすくなるテーブルの一例には、カレンダーがあります。見出し行に曜日が
Googleから2014年に「HTTPS everywhere(常時SSL化)」が提唱された後、HTTPS接続の重要性の認識が広がりました。2018年にHTTP接続のサイトに対して「この接続ではプライバシーが保護されていません」といった警告を表示する決定がなされた時には、多くのWebサイトでSSL化対応が行われてきました。 しかし、本番環境やステージング環境のSSL化は行っていても、ローカル環境をブラウザで確認する時に、常時 http://localhost のようなHTTP接続を行ってはいませんか? http://localhost は、基本的にHTTPS接続と同じように動作しますが、場合によって同じように動作しないこともあります。 今回は、ローカル環境でHTTPS接続が必要になるケースと、その対応方法について紹介します。 ローカル環境でHTTPS接続が必要になるケース ローカル環境でH
2022年10月4日 日本視覚障害者ICTネットワークが第2回支援技術利用状況調査報告書を公開 アクセシビリティ・エンジニア 大塚 今年の5月に当Blogで公開した記事、「日本視覚障害者ICTネットワークが第2回支援技術利用状況調査を実施」で触れた調査の結果が公開されました(第2回支援技術利用状況調査報告書)。2021年に行われた第1回の調査結果と比較しながら、個人的に印象に残った点を取り上げたいと思います。なお、1回目の調査結果については、当Blogでも日本視覚障害者ICTネットワークによる支援技術利用状況調査報告書という記事で取り上げています。 調査結果の中で注目したポイントの1つめが、パソコンで使うことがある支援技術をすべて選択する質問においてPC-Talkerを挙げる人がトップとなり、NVDAがそれに続いたことです。こちらについては、第1回目の調査結果と大きな変化はありませんでした
去る8月20日、オープンセミナー2022@岡山にて、「ミツエーリンクスから見たアクセシビリティ界隈、この2年半」というタイトルでセッションに登壇しました。当日参加いただいた皆さま、そして貴重な機会をいただいた実行委員会の皆さま、本当にありがとうございました。 オープンセミナー岡山には2015年から参加しており、オフラインで開催されていた頃は、名物となっている大規模な懇親会にLTという形でよく出演させていただいていました。そんななじみのあるセミナーから登壇依頼をいただき、本当にうれしく高揚した気持ちでお受けしました。 今回のセミナーは、 当方がミツエーリンクスに入社後、初の一般公開セミナーであることから、社員視点での内容にしたい。 入社前に開催していた勉強会「リーダブルな夜」がコロナ禍で延期されてから2年半が経ち、その間の情報発信を行っていない。 などの理由から、2年半分の「アクセシビリティ
昨日付の経済産業省のニュースリリース、日本産業規格(JIS)を制定・改正しました(2022年8月分)にありますように、EPUBコンテンツのアクセシビリティに関する仕様、EPUB AccessibilityがJIS X 23761として制定、JIS規格化されました。規格は冊子またはPDF形式で、日本規格協会 JSA Group Webdeskから購入することができます。 EPUB Accessibilityとは、もともと国際電子出版フォーラム(IDPF:International Digital Publishing Forum)で策定された仕様です。2017年のW3CとIDPFの統合に伴い、現在EPUB AccessibilityはW3Cで管理されています。そのバージョン1.0、EPUB Accessibility 1.0は2021年、ISO/IEC 23761:2021としてISO標準化
ミツエーリンクスでは全社的にInterop 2022の重点分野について調査をしています。 今回はその中から「新しいビューポートの単位」について紹介します。 ビューポートとは ビューポートはWebページを表示するための領域で、ブラウザウィンドウからアドレスバーなどのUIを除いた部分になります。 ビューポートの単位とは ビューポートの単位は相対的な長さの単位で、ビューポートの長さに従って指定します。 ブラウザで表示したビューポートの長さが対象となるため、@pageで宣言した印刷用のスタイルでは無効になります。 なぜ新しいビューポートの単位が必要になったのか 従来のビューポートの単位はUIがスクロールによって拡大縮小するような機能を持つ前に作成されました。 そのため後発の動的にサイズが変わるUIに対応しておらず、画面をスクロールする前の初期表示時に決定されたビューポートサイズを維持し続けます。
ユーザーの直帰率や離脱率とパフォーマンスの関係から、コンテンツを表示する速度や応答性(ページがユーザー入力に応答する速度)がいかに重要であるかは、既によく知られるようになってきています。 ではコンテンツを表示する速度や応答性を上げるにはどうしたらいいでしょう。 結論から述べるとパフォーマンスを客観的な指標に基づいて正確かつ定量的に測定し、そこから課題を見つけて解決することが必要になります。 GoogleはChrome User Experience Reportに新しく応答性指標INPを導入しました。 INPとは INP(Interaction to Next Paint)は、ページの読み込みを開始してからユーザーがページを離れるまでの間に発生するユーザー入力の応答性(インタラクション)を評価する測定基準で、遅延時間を計測します。 計測対象のインタラクションは、以下となります。 ユーザー入
2021年8月30日 Visual Studio Codeの設定ファイルを共有してチーム開発をより快適にする UI開発者 太刀川 .vscodeディレクトリとは何か Visual Studio Code(以下、VSCode)を既に使用されている方ならご存知かと思いますが、作業ディレクトリ固有の設定を行った際に.vscodeというディレクトリが作成されます。 一般的にはsettings.jsonなどが作成され作業ディレクトリの設定が記録されます。 .vscodeディレクトリに関しては.gitignoreなどでgitの管理対象外とする場合もありますが、設定を共有することによるメリットなども存在するため、今回は実例を交えながらメリットについて紹介いたします。 今回ご紹介する内容はVisual Studio Code version 1.59.1 時点の情報をもとに記載しています。 共有できる設定
inert属性はある要素とその要素のサブツリーに含まれる全ての要素を不活性にするための属性です。不活性とは簡単に言えば「クリックできない」「フォーカスできない」「選択できない」「編集できない」状態を指します。 また、HTML Standardでは「ページ内検索でも無視される場合がある」と記載されています。手軽に使える属性である一方、不用意に使うと思わぬところに影響がでる可能性があります。そこで今回はユースケースとinert属性を使う際の注意点をいくつかご紹介します。 ちなみに、似たような属性としてdisabled属性がありますが、disabled属性はinput要素やbutton要素などのフォームコントロール要素単体、およびフォームコントロール要素をグループ化するためのfieldset要素でのみ有効な属性です。 ユースケース inert属性はもともとdialog要素の仕様の一部として実装が
最近では、Twitterで画像に含まれる代替テキストを表示できるようになる(Twitter Accessibilityのツイート、ITmediaの記事)など、「代替テキスト」という言葉や機能が、Web制作者以外の方にも少しずつではありますが認知され始めているように感じます。代替テキストは、画像に追加することができるテキストによる説明で、適切な代替テキストが設定されていると、画像の確認が困難なスクリーンリーダーユーザーが画像に関する情報を得る際に役立ちます。 そんな代替テキストについて、設定する際に心がけるポイントとして「簡潔な内容のテキストを設定する」というものが挙げられることが多くあります(画像のアクセシビリティを向上させる方法、H37: img 要素の alt 属性を使用する | WCAG 2.0 達成方法集)。では、なぜ簡潔である必要があるのでしょうか。 代替テキストが長すぎてしまう
コラムのタイトルをお読みになり、いやいやインターネットにも国境はあるでしょう、中国のグレート・ファイアーウォールは有名ですし……といった感想をお持ちなら、それはある意味、正しい感想です。実際、私が監訳した2017年発売の書籍『グローバルWebサイト&アプリのススメ』の第1章「翻訳経済の新しいルール」には、「インターネットにはたくさんの国境がある」という見出しに続けて次のように記されています。 国境のないインターネットが、より国境なき世界を実現すると思われがちです。しかし、実際はその反対のことが起きています。インターネットには厳密な意味での国境はないかもしれませんが、仮想の法的な国境を作る国が増えているのです。 そうした状態は、破片を意味するSplinterとInternetを組み合わせた造語、「スプリンターネット」と呼ばれ、各国のインターネットに対する向き合い方、スタンスの違いが反映された
Web担当者のあなたは、担当しているサイトのアクセシビリティ向上に、今まさに取り組もうとしていたとします。あるいは、既に取り組んでいるけれど、より効率的に取り組みたいと考え、施策を見直している最中だったとしましょう。 そんなとき、どんなWebページでも特定のスクリプトを読み込ませるだけで、コンテンツ自体に手を加えることなくアクセシブルにできる……そんなうたい文句のソリューションが存在することを知ったら、あなたは飛びつきますか? もしサイトにGoogle タグ マネージャーを導入済みなら、特定のスクリプトを読み込ませる作業は、対象ページ数が数千だろうと数万だろうと短時間で完了できます。うたい文句が事実なら、金額次第とはいえ飛びつくWeb担当者は一定数、いらっしゃることでしょう。 事実かどうかはさておき、そのようなうたい文句のソリューションは実在します。私が認識する限り昨年来、英語圏で比較的よ
次のページ
このページを最初にブックマークしてみませんか?
『Web制作 | Mitsue-Links | ミツエーリンクス | WebIntegration』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く