正しいHTMLを書く目的はただ一つ 補足

あとで改めて、きちんとした補足記事にするかもです。 引用している他の方のツイートは、自分のツイートのきっかけになったものであり、それ以上の意味はありません。
SEO accessibility HTML
securecat 12292view 51コメント
20
ログインして広告を非表示にする

コメント

  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-22 00:07:26
    そのアクセシビリティ(と標準策定関係者が考えるもの)が顧客のニーズにマッチしないから開発者が泣かされているわけであって。開発者にとっては顧客が常に優先なのですよ
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-22 00:10:13
    標準に従って書いてもモバイル端末では意図どおりに解釈されないとか、そういうことがたくさんあるわけで。標準に従って書けばどんなブラウザでも無理なく適切にレンダリングされて読みやすく理解しやすく、作成者の意図した通りの構成で読み取れる、というのならみんな喜んで使うだろうけど、全然そんなことない現実が目の前にありますわな。
  • Yu Morita (yuu) @securecat 2013-03-22 00:27:26
    アクセシビリティは「アクセシビリティ」という自然言語について言っております。標準とか関係ないです。
  • Yu Morita (yuu) @securecat 2013-03-22 00:30:01
    また実際の実装にあたっては、まず標準に基づいた実装のうえで、どこまで個別の対応をするかというケースがほとんどではないのでしょうか。それとも、いきなり完全に独自の世界観で実装するのが現実だということですか?
  • Yu Morita (yuu) @securecat 2013-03-22 00:44:38
    あ、上記"標準とか関係ない"は語弊がありますね。おそらく、おっしゃる「アクセシビリティ(と標準策定関係者が考えるもの)」というのが、WCAGのたぐいを言ってるんじゃないかと思いましたので、そのたぐいの標準は関係なくて、自然言語としての「アクセシビリティ」について言っているという意味です。つまり情報への接近容易性といった意味です。
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-22 01:15:22
    顧客が求めるのは閲覧者にとってわかりやすく、読みやすく、ストレスがなく、操作がしやすく、操作ミスなどをしにくいもの、です。それを実現するのはHTMLの規格や標準ではなく、文法でもなく、UIデザインでしかなく、HTMLの規格や標準や文法はその手段に過ぎないので、役に立たないところは利用されないわけです。
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-22 01:17:28
    誤解を恐れずに大胆な言い方をするなら、顧客のニーズを満たすのに必要なのはHTMLのマークアップ(意味付け、定義付け)ではなく、CSSのレンダリングデザインのほうが比重が大きいんですよね、どうしても。
  • Yu Morita (yuu) @securecat 2013-03-22 01:24:00
    うーん。すみません。ちょっと理解できないです。僕は納品物に対して、手段(標準)を目的にせよとは言ってませんし。また、標準に則ったうえで(必要に応じて個別の対応をしたうえで)閲覧者にとってわかりやすく読みやすくストレスがなく操作がしやすく操作ミスなどをしにくいものは作れますよね。インターネットを汚さなかったというのはただの自己満足でも構いませんが、その自己満足をだれにも押し付けることなく顧客に売りつけることもなく実現することが可能です。そういうものをデザインして納品しているわけですので。
  • Yu Morita (yuu) @securecat 2013-03-22 01:28:45
    ああ、「正しいHTML」という言い方ですかね。grayengineerさんにとって引っかかってたのは? これは本件ブログが言及している元ブログのほうがそもそも「セマンティックで正しいコード」と表現しているものが、せいぜい「文法的に正しいHTML」程度の意味であろうという推測に基づいたうえでの表現です。ですから「正しいWebリソース」くらいに読み替えて頂ければと思います(物理的にはそう書いてなかったため、後出しっぽくて申し訳ないですが)。
  • Akihiro Oyamada @yomotsu 2013-03-22 02:38:27
    “レンダリングデザインのほうが比重が大きい”とあるけど装飾についてなら HTML 関係なくて...正しい HTML を書く“理由”自体はマシンリーダブルな印付けをするため、つまり a11y のためで論点がズレてる気が...
  • Akihiro Oyamada @yomotsu 2013-03-22 02:46:58
    例えば、正しい HTML を書けば、自動で適切な role が割り当てられて a11y に対する恩恵があるけど、SEO とかパフォーマンスとかには恩恵があるわけではないので。 http://www.w3.org/TR/2011/WD-html5-20110525/content-models.html#wai-aria
  • 拝島恭介@DQ11&スプラ2待機 @SE_O_T 2013-03-22 10:25:19
    なんか関係ないまとめツイートに載せられていたので削除しました。あしからず
  • Yu Morita (yuu) @securecat 2013-03-22 10:58:48
    無関係でしたか。すみませぬ。
  • たるたる @heporap 2013-03-22 12:36:45
    とりあえず、CSSとJavaScriptを全部外して、そのページをブラウザで見てみたら良いんじゃないでしょうか。PとFIGUREの違い、SECTIONとARTICLEの違いはどちらにしてもわかりませんが、少なくともDIV病ではどこが見出しでどこが本文かわからなくなることは判断できます。
  • たるたる @heporap 2013-03-22 12:38:46
    もちろん本来のHTMLの文法には、タグごとの違いを表示する方法はありません。そのへんはテキストブラウザで見てみれば、<h1>と<p>に表示上の違いが無い事がわかります。それでみれば、デザインとHTMLに関係がない事はわかると思います。
  • たるたる @heporap 2013-03-22 12:41:44
    ま、私は「正しい日本語を使いましょう」と同じレベルの、ともすれば自己満足だと思いますけどね。ただ、それが業務なら別。「正しい日本語を使えない営業マンは失格だ」なんて言われたりするんでしょうけど。
  • たるたる @heporap 2013-03-22 12:46:09
    自分で要約ツールなんかを作ってれば、<div data-abstruct="1">文章</div>などと書いてdata-abstructがある項目を探せば良いけど、要約ツール(リーダー、ブラウザ)ってのは自分で作ってるわけじゃないです。
  • たるたる @heporap 2013-03-22 12:46:38
    リーダーの機能をフルに使いたいのであれば、そのリーダーを作った人のルールに合わせる。そのリーダーがW3C-HTMLに合わせているのであれば、文書もW3C-HTMLに合わせるのが、妥当。ではないでしょうか。
  • たるたる @heporap 2013-03-22 12:59:27
    顧客がリーダーの機能(http://webcre8.jp/think/semantic-html-reason.html の5の項目)の事を知らなければ、安いDIV病/テーブルレイアウトと、高くてきっちり設計されたページの『見た目が同じ』なら、どちらを選ぶかというと、安い方だと思います。経験上。via:最初のコメント
  • たるたる @heporap 2013-03-22 13:04:05
    リーダーの機能を使ってる人がどれほどいるかわからない。また、使わなくてもほとんど問題にはならない。(抜粋なんかは、ざっとスクロールさせればそれでOKなことが多い)となると、利用者のメリットと制作費のコストパフォーマンスを比べれば、よほどの事が無い限りは『HTMLタグの意味』を考えるメリットがあるのかというと、制作者の立場としても疑問に思えます。
  • od @odododod 2013-03-22 13:16:49
    CSSの話をすると、デザインを乗せやすいマークアップ・乗せにくいマークアップという話が出てくるんですかね。個人的には、システム側では一旦なるべくシンプルで「正しい」HTMLを出すようにしておいて、デザイン側でそこにうまく乗っけてくれるとお互い幸せなのかな……と思ってます。
  • od @odododod 2013-03-22 13:22:31
    「これ画面が寂しいからデザイン乗せてよ。デザインはこっちでするから」と言われてそれ発注外だけどなと思いながら「わかりました」という話になったとき、先方のデザイナーさんがclass属性乗せるだけでOKなCSS準備してくれて大層助かったことが。しかし、これは単にデザイナーさんが気の利いた方だったという話かも……。
  • たるたる @heporap 2013-03-22 16:43:24
    HTMLコーディングとCSSコーディングは別ものではあるんですけどね。さらに言うと、(狭義の)デザインとHTMLコーディングも別ですし。「ウェブデザイン」という言葉の定義を広く広くして行けば、ライティング/コピーライティングからアニメーションプロモートやビデオ撮影、JS/PHPプログラミング、データベース設計まで含める事も、キリが無いと思います。
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-23 11:12:04
    >標準に則ったうえで(必要に応じて個別の対応をしたうえで)閲覧者にとってわかりやすく読みやすくストレスがなく操作がしやすく操作ミスなどをしにくいものは作れますよね。< それが理想だというのはわかるんですが、現実問題そうではないから泣かされてるわけです(昔よりはだいぶマシになりましたが)。だってそこはブラウザ次第なわけですから。実際Webシステム開発やってる人はわかると思いますが、まず最初にターゲットブラウザの範囲を確定するところから入るんですよ。
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-23 11:14:58
    社内向けシステムなどの場合はIE7/8限定にするとか、普通にやってます。オープンなものはそうもいかないけど、それでもIE6以下は切り捨てるとか、推奨ブラウザを列挙するとか、たいていやってるし、それができない場合はスクリプトを使ってブラウザ判別をして出力を分けるとかしています。そんなことをやらなければならない時点で「HTMLの文法的に正しく書くことが一番重要」とは思えないわけです(そうあってほしい気持ちはわかりますが)。
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-23 11:18:59
    マークアップが同じ場合でもレンダリングはブラウザによって微妙に異なります。で、顧客が重要視しているのはレンダリングの結果出力されてくる画面なわけであって、マークアップの正しさではない、ということです。もし同じマークアップのHTML文書がすべてのブラウザで同じレンダリングをされるのであれば、顧客もマークアップの正しさの重要性を理解できるようになるかも知れませんが
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-23 11:22:31
    だから制作者が正しいマークアップをすることが重要というよりも、各種ブラウザがレンダリングの仕様を標準化することのほうが重要じゃないのかなと思うわけです。もちろん、視覚障害者向けの読み上げブラウザなどは別だし、全部のブラウザを同じにするべきでない、というのもわかりますが、何らかの枠は欲しい、というのが開発者側の希望ですね。
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-23 11:25:05
    あるいはむしろ、ブラウザはHTMLのマークアップによるレンダリングを一切行わない、レンダリングに関するすべての指定はCSSでする、という形でもいいんですけど、その場合は今度はまたCSSの仕様の解釈の違いが問題になるだけですよね。
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-23 11:27:05
    「理想と現実」ってことです、要するに
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-23 11:28:08
    >装飾についてなら HTML 関係なくて...< HTMLのマークアップによってレンダリングが一切変わらないのであればそうなんだけど、そうじゃないから困るわけで…
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-23 11:30:25
    たとえばですけど、CSSのbackground-color属性のレンダリング仕様が、どのHTML要素に対しても同じであれば、HTMLは関係ない、と言えるわけですが、これがdiv要素の場合についてのみブラウザ間でレンダリングの結果が異なる、となるからHTML関係ないと言い切れなくて困っちゃうわけです。言い切れたほうが楽なんですけど、もちろん。
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-23 11:36:21
    文書中のある部分にどのHTML要素を適用するか、それを文書内での位置づけ、意味付けに従って決められるのが理想というのはわかるんですが、それはもともと学術文書のような狭いフォーマットルールの文書が主に想定されていた初期のインターネットの延長上にあるもので、現在実際に流れているのは動画やゲームコンテンツであったりするわけです。そうすると適用要素の選択の基準はどうしても必ずしも位置づけや意味付けだけにできない場面に遭遇してしまう。これは開発者なら少なからずみんな経験しているはずです。
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-23 12:00:23
    それと「装飾」と文書構造が必ずしも無縁ではないから難しい、というのもあって。それがつまりHTMLのマークアップによるレンダリングを撤廃できない理由でもあると思うんですが、見出しには見出しらしい装飾というのがあるし、リストにはリストらしい装飾というのがあって、それも割と幅が広い(縦のリストも横のリストもある)。人は主に見た目から構造を推測するからなんでしょうが、だからHTMLから装飾的要素をいっさい排除することは難しいのでしょう。
  • きゃっつ(Kats)⊿7/16乃木坂京都 @grayengineer 2013-03-23 12:03:02
    よくわからない、という方、一度IE7でTogetterを見てみてください。ヒドイことになってますから。それを見て顧客の立場でどう考えるか、そこを考えてみてほしいですね。
  • Jeffrey Francesco @JForg 2013-03-28 01:39:05
    実務でお困りになる事が多いというのはよく分かったんですが、結局grayengineerさんがおっしゃってる事はすべてCSSの問題であって、仕様に則った正しいHTMLを書くこととは無関係の話じゃないでしょうか。
  • Jeffrey Francesco @JForg 2013-03-28 02:08:19
    …もしかすると「(仕様上、以下省略)正しいHTML」=「ある部分にどのHTML要素を適用するか」という話だと思われてたりするのですかね?ここで言われている正しいHTMLってのはそういう話だけではなくて、もっと色々なことを含んでいるはずなので。
  • Jeffrey Francesco @JForg 2013-03-28 02:51:26
    例えば画像のalt属性を考えてみるといいかもしれません。ADSLや光回線が普及した現在、わざわざ画像を読み込まないようなブラウザ設定にしてあるPCはごく一部だろうし、代替テキストを省略しようが適当に付けてようが大抵の環境では画像が表示されるでしょうから、適切でない代替テキストが原因で「見た目にこだわる」クライアントから苦情が来るような事はほとんどないかもしれません(続
  • Jeffrey Francesco @JForg 2013-03-28 03:15:16
    でもアクセシビリティの観点からいえばalt属性はちゃんと考えて適切に設定すべきであって、それはクライアントが何と言おうが自己満足と言われようが「正しいHTMLを書く」ことを意識したら譲れない部分なんですよ。で、そこを譲らなかったからといって(altの内容がどうであろうが)画像は表示されるのなら「見た目にこだわる」クライアントには関係ないし迷惑を掛ける訳でもない。つまり、こだわる側が勝手に実装すればいい話です。
  • Jeffrey Francesco @JForg 2013-03-28 03:28:54
    「自己満足をだれにも押し付けることなく顧客に売りつけることもなく実現する」っていうのは、つまりそういう話です(と私は思ってるけど違うのかしら)。自分がWebサイトの構築を承る時でも別に「正しいHTML」なんてウリにしてませんし。クライアントが求めようが求めまいが、勝手に(なるべく)仕様に則ったHTMLになるように考えながら書いてるっていうだけです。
  • Jeffrey Francesco @JForg 2013-03-28 04:17:39
    で、別に対応ブラウザがIE7/8限定だろうが、そういうのは不変の話だと思うのです。例えば社内向けシステム限定だとしても「とても優秀な社員がある日突然不幸な事故で体が不自由になったら」とかは考えないですか?例えば最初から重要な要素にaccesskeyやtabindexを適切に設定しておけば、もしかするとその社員は(少しの努力は必要かもしれませんが)今までと変わらずに仕事ができるかもしれないのですが。それとも、そういう事態が起きるたびにシステム改修するんですかね…
  • Jeffrey Francesco @JForg 2013-03-28 04:22:36
    grayengineer 「ブラウザはHTMLのマークアップによるレンダリングを一切行わない、レンダリングに関するすべての指定はCSSでする」→これはすでにそうなっていますよね。ブラウザはそのデフォルトスタイルシートにしたがってレンダリングしているに過ぎませんし、制作者スタイルシートやユーザスタイルシートで簡単に上書きできますんで。
  • Jeffrey Francesco @JForg 2013-03-28 04:50:33
    grayengineer 「適用要素の選択の基準はどうしても必ずしも位置づけや意味付けだけにできない場面に遭遇」した場合は、そこは別にdivやspanを使えばいいと思うんですが…W3Cは別に「divやspanは一切使ってはいけない」なんてひとことも言ってないですよ(「他に適切な要素があるのならそちらを使うべきだ」とは言ってますが)。
  • Jeffrey Francesco @JForg 2013-03-28 05:04:44
    grayengineer 「「装飾」と文書構造が必ずしも無縁ではない」→それは当然ではないでしょうか。「ここはh1でマークアップしてあるんだから別に地の文と見分けが付かなくても一番重要な見出しだって分かるよね?」では逆に「視覚に全く問題がない人」のアクセシビリティを阻害する事になるんではないですか。
  • Jeffrey Francesco @JForg 2013-03-28 05:19:00
    grayengineer で、手元にIE7がないのでよく分かりませんけど「そもそもレイアウトが崩れて文すら読めない」みたいな話であればそれは単に「CSSの書き方が悪い」というだけの話であって、結局正しいHTML関係ないですね…それよりTogetterのHTML自体が仕様に則ってなくて文法エラーだらけなんで、自分はむしろそっちの方が気になる訳ですが。
  • Jeffrey Francesco @JForg 2013-03-28 05:21:36
    という訳で、何が言いたかったのかというと「Togetter文法エラー出まくるし説得力ない」ということでひとつよろしくお願いします。涙
  • Yu Morita (yuu) @securecat 2013-04-06 00:34:30
    "ブラウザはHTMLのマークアップによるレンダリングを一切行わない、レンダリングに関するすべての指定はCSSでする" そんなことはありえなくてCSS仕様の冒頭にあるレベルで否定されてませんかね? どんな妄想なんでしょうか。CSSはHTMLのスタイル言語です。ブラウザはHTMLに対して直接レンダリングしてるわけじゃなくて、ブラウザのもつdefault CSSに基づいてレンダリングしてるわけです。
  • Yu Morita (yuu) @securecat 2013-04-06 00:34:51
    まあ、そのうえでの発言なことはわかるんだけども、なんつーかなー、reset CSSすりゃいいんじゃないの?ってなっちゃいませんか。さらに、そのうえでの発言だということもわかりますが、それはブラウザのレンダリングバグですとしか言いようがない。で、さらにさらにそのうえで、僕は「それでも標準に則って作ることはおおむね可能である」と言っているのです。僕も15年以上この世界やってます。わかってます。そのうえで、言っているのです。
  • Yu Morita (yuu) @securecat 2013-04-06 00:37:59
    実際、そんなに滔々と愚痴るほどのことになったことがない・・・(空気読んでるグラフィックデザイナばかりだったのか? いやそうではないと思う・・・としか言いようがない)
  • Yu Morita (yuu) @securecat 2013-04-06 00:39:53
    JForg "「Togetter文法エラー出まくるし説得力ない」" でもまー、おおむねの人、表示できてるしね。問題ないんじゃないかな。と思ううえで、その判断基準何よって観点では説得力は無い。でもまあ、そういうものだとも。
  • アフロジャスティス @djsackman 2013-04-09 18:14:16
    あくまで「昔に比べたら」ってつもりで言ったんですが・・・まあいいや、消すのめんどい
  • アフロジャスティス @djsackman 2013-04-09 18:27:15
    SEOへの効果がコンテンツ>>>>>マークアップなんて事は分かってますが、昔はコンテンツ>>マークアップくらいだったし、見えない場所にキーワードを羅列するようなバッドノウハウも蔓延してたし、でも今はそういうのは全部スパムと見なされるようになって良い時代になったなと思いました、ハイ

カテゴリーからまとめを探す

「雑談」に関連するカテゴリー