主にユーザー側の視点から語られることが多いアクセシビリティですが、制作という側からはどのように捉えることができるのでしょうか。2つの切り口から考えてみます。 # アクセシビリティという文脈において、何のためにHTMLを書くかという話になると マシンリーダビリティのため スクリーンリーダーのアクセシビリティのため というように、ユーザーが利用するため、というところにフォーカスした語られ方が多いように感じています もちろんユーザーのために作るというのは正しいのですが、今回はあえて視点を変えて、制作者自身の作るというところに視点を合わせて話してみたいと思っています 僕がどういうものなのかというと、 # 参照: 全部入りHTML太郎(@_yuheiy)さん | Twitter ツイッターでは「全部入りHTML太郎」という名前でやっています # 参照: シフトブレイン／スタンダードデザインユニット
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
ウェブの黎明期である2000年頃と比べてはるかにHTMLはコーディングしやすくなりました。10〜20年前のHTMLコーディングはどのようなものだったのでしょうか。 この記事では、NetscapeとIEのブラウザ戦争に決着がついた後の、IE6が全盛期となった2000年代のウェブサイト制作を振り返ります。懐かさに浸たり、現代のウェブの成り立ちに通じる温故知新な情報として参照ください。 テーブルレイアウト / spacer.gif XHTML・CSSが普及するまではテーブルレイアウトが一般的でした。テーブルレイアウトとはtableタグを使い、格子状にレイアウトしていく手法です。テーブルレイアウトは、デザインファイル（Image ReadyやFireworks）から画像を切り出す「スライス機能」と相性のいい方法でした。 <table border="0" cellspacing="0" cellp
私はWeb制作が初めての方向け講座だけでなく現役の制作者の方向けに様々なWeb講座をしていますが、現役のWeb制作者の方でもHTMLに関して意外と知られていないんだなと思うことがいくつかあります。 特に、HTML5以前の古いHTMLの使い方のまま覚えている方が多いように思われますので、この記事ではそれを中心に取り上げてみました。 なお、この記事はHTML 5.1およびWHATWG HTML Standardの仕様書を参考に書いています。 width=”100%” のように数値以外の文字列を “” に入れるのはNG たとえばimg要素などで、ブラウザの幅いっぱいに画像を表示したいという場合、昔はimg要素に width=”100%” のような属性をつけることがありましたが、HTML5からはwidthなどの属性値に数値以外を含めることができなくなっています。（つまり%などの単位を含めることがで
SVG has no native semantics for representing structures like tables, but ARIA1.1 introduces a number of roles that can be used to polyfill the necessary semantic information. If you're using HTML, use the relevant HTML elements to create tables. The table, thead, tfooter, tbody, th, and td elements are purpose built to do the job. Don't make things harder for yourself by reinventing the wheel. Tha
ウェブサイトの言語セレクトメニューを作る時、英語で一覧させることも多いが、それと同じくらいそれぞれの言語名でそれぞれの言語を表示することもある。母国語で表示されていれば絶対にわかるだろうし、見つけやすいだろうという理屈だ。そのこと自体にはいくつか欠点が考えられるわけだが、HTMLとしてはlang属性を使えばうまくマークアップできるだろう。同時にtitle属性を使って英語でフォローすると完璧……だが、そこそこ面倒くさいことになる。 それぞれの言語名でそれぞれの言語を表示した言語選択メニューは択一しづらい(またはスキャンしづらい)という問題がある。特にアルファベット＋αの言語名は混同しやすいし、ソート順が不明確になりやすく、順にたどって見つけなければならない。どこら辺にありそうかアタリをつけることができないわけだ。 ルート要素のlang属性でen-USが指定されているとする。 <span la
この夏、HTMLについて書く機会が別々に何回かあった。そのうちちゃんとした形で出ることだろう。そのままのテンションで一気にHTML Best Practicesの日本語版を作成した。内容は増えていないものの、さすがに日本語の方がさっと読め、色々直さなければという気になる……。 この量で 575は 無理でした カタカナ訳はちょっと嫌だったので「普通のHTMLの書き方」というタイトルにした。あまりうまい訳でもないので、そのうちカタカナ訳になりそうだ。 これに限らず「(Best )Practice」という言葉は訳出しづらい印象がある。直訳は「慣習」や「慣例」だが、日本語のそれらはネガティブなイメージがあるように思っており、このコンテキスト(ベスト)では不適当だと感じる。「実践手法」とするとかなり近いが、だいぶ硬い。あきらめて「プラクティス」というカタカナだと、今度は「練習」的な意味でとらえられる
こんにちは、Webアプリケーションエンジニアのid:nanto_viです。みなさんHTMLのフォーム検証機能は使っていますか? 近年は各Webブラウザの対応も進み、お手軽にフォームの利便性を高められるようになっています。 そんなフォーム検証機能のひとつがinput要素のpattern属性です。pattern属性の値にJavaScriptの正規表現パターンを指定することで、ユーザーの入力が意図しないものであった場合、フォーム送信ができなくなります。下図は5桁の数字の入力が求められるところに3桁しか入力せずフォーム送信しようとしたところです。ブラウザに組み込みのエラー表示が出現し、またそのメッセージにtitle属性の値が使われていることを確認できるでしょう。(pattern属性を指定する際には、title属性に書式の説明を記述することが推奨されています。) <input type="text"
What problems does it solve? 2021 update: Browsers now implicitly set rel=noopener for any target=_blank link, following a spec change. If the demo on this page no longer seems scary, congratulations — you’re using a modern browser! You’re currently viewing index.html. Imagine the following is user-generated content on your website: Click me!!1 (same-origin) Clicking the above link opens malicious
The target, rel, media, hreflang, and type attributes must be omitted if the href attribute is not present. Represents an abbreviation or acronym. The optional title attribute may be used to provide an expansion of the abbreviation. If specified, the title attribute must contain an expansion of the abbreviation and nothing else. Represents the contact information for its enclosing section. If it i
パート1：メディア・クエリのどこがまずいのか？ そう、もし君がウェブサイトを作っている時代が1993年2月23日から2010年5月25日の間だったら、画像の扱いなんてチョロかったね！ それはこんなふうに単純だった。 幅の固定されたレイアウトをにらみつける 画像がきっかり何ピクセルかを測る――その画像はあらゆるユーザーの画面で変わらないスペースを占めることになる Photoshopのエンジンをかける 画像をさっき測ったとおりのサイズで「ウェブ用に保存」する それを<img>タグでマークアップする グラスにビールを注ぎ（または新鮮なグリンピースの缶を開け）、仕事がうまくいったことを祝う ときおり聡明なる預言者が荒野から現れては、この手法に潜む問題について深遠な真実を説くこともあった。それでもこのやり方は、20年もの間、ウェブ・デザイナーを生業とするものたちに受け入れられてきた。 しかし、時代は
img要素は置換要素なので、現在の安定仕様では明記されてはいないものの歴史的な事情により::before/::after擬似要素による挿入は行えない。しかしChrome 41で遊んだところ、src属性がない場合は挿入することができるようだ。Internet Explorer 11やFirefox 36、Mobile Safari 8では行えない。 Demo: img element w/o src attribute and pseudo element Chrome 41ではalt属性の値である“img without src”という文字列の前に::before擬似要素で仕込んだ“pseudo element for img!”という文字列が挿入されていることがわかる。Chrome 43でも同様だった。 src属性がないとimg要素がパース・エラーで不明な要素にでもなるのかなと想像したが
理解しておきたい、CSSによるインラインレイアウトの仕組み（font-size／line-height編）Inline Layout─Frontrend Conference 高津戸壮（株式会社ピクセルグリッド） この記事は、Frontrend Conferenceのセッション「Inline layout」でお話させていただいた内容を基に、連載記事（全4回）として書き起こしたものです。今回は第１回目です。 はじめに Frontrend Conferenceでは、皆さんが新しい技術について話していた中、私からはCSS2.1のお話をさせていただきました。私が解説したのは、CSSを書く上で欠かせない、以下の4つについてです。 font-size line-height vertical-align inline-block トレンドとはほど遠い内容ではありますが、多くの人にとって、なんとなく感覚
Google が言う 「モバイルフレンドリー」 とは？ モバイルフレンドリーテストツールで色々試してみた Google がモバイル検索の順位決定時に 「モバイルフレンドリー」 かどうかを重要なシグナルとして利用すると発表したことに関連して、そもそも Google は何を根拠に 「モバイルフレンドリー」 かどうかを判断しているのか、という点について調べてみました。 先週ですが、Google が Official Google Webmaster Central Blog で、2015年 4月 21日 （米国時間） から、モバイル検索の順位決定時に、その Web サイトが 「モバイルフレンドリー」 かどうかを重要なシグナルとして利用すると発表しました。 Finding more mobile-friendly search results ： Official Google Webmaster
+1 ボタン 2 AMP 11 API 3 App Indexing 8 CAPTCHA 1 Chrome 2 First Click Free 1 Google アシスタント 1 Google ニュース 1 Google プレイス 2 Javascript 1 Lighthouse 4 Merchant Center 8 NoHacked 4 PageSpeed Insights 1 reCAPTCHA v3 1 Search Console 101 speed 1 イベント 25 ウェブマスターガイドライン 57 ウェブマスタークイズ 2 ウェブマスターツール 83 ウェブマスターフォーラム 10 オートコンプリート 1 お知らせ 69 クロールとインデックス 75 サイトクリニック 4 サイトマップ 15 しごと検索 1 スマートフォン 11 セーフブラウジング 5 セキュリティ 1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
