"Webアクセシビリティが無視されすぎで気にくわない。"について
忘れないために、少し書き残しておこうと思います。
経緯：社内勉強会のこと。
2016年01月29日（金）都内飯田橋某所にて、OBS（私の所属する株式会社大塚ビジネスサービスの略）勉強会の直前、3時間くらいで作ったものです。
後日facebook上でミツエーリンクスの木達さんから、そもそも出典とか大文字小文字とかおかしいぞ、と言われ、ああ恥ずかしい//となったりするクオリティです。
煽りっぽいタイトルですが、固い社内勉強会って、面白いですか？続きます？上野はつまんないです。
突っ込み入れられながら、笑いながら話した方がいい。タイトル自体で何かのリアクションないと、つまらない。
しゃべる方もつまらない。退屈。だから、このくらいでちょうどいいのです。
現に公開後、このタイトルだけで、反応していただいた方もいたようですし、考えるきっかけになれば十分。
誰かの記憶に留められたら、と思って、公開しました。
資料について、この記事について
そんな資料が、公開してどうも10000程のビューがあったようで、"へー"と他人事なかんじです。みんな興味あるんですね。a11y。シェア・リンクいただいて感謝。
安易な計算ですが、5分×10000=50000分。約800時間として、営業日に換算すると、100日。
・・・なんというか、誰かの5か月分のリソースを使ってしまったのだろうと思うと、少しコメント残しておこうかなと思った次第です。
資料は、勉強会の資料であって、内容は書いてませんから。
上野なりに、ちらほら意見を見てみましたが、結局興味あるのに（何かしらの反応があった）、意見がそれぞれ違うし（割とみんなバラバラの意見）、視点もそれだけの量があるんだ（価値観も違いそう）ということだと。
中には「あなたが神か」と思し召しな内容もありましたが、、、、まぁ、それは、、いいや。
資料（勉強会）の上野発表文の内容。
なんでこんな題材にした？
"Webアクセシビリティ"と題に入れた時点で、結論は"合理的配慮"で終わります。
だって法律だもの。Webアクセシビリティあるあるです。飽きましたけど。
偉い人が変えてくれるのでしょうかね。よって、最終的には、世の中動きません。それが、今ですから。
ただね、法律がどうのこうのの前に、超高齢化社会、実感しませんか？ほかの国より、真剣に考えていいはずです。別に、これから老人のケアをしなければいけないから、という理由だけじゃないです。子供を産むことすら批判される国なんだったら（出生率ではなく、中絶率を考えるべきですが）、せめて今生きてる人が少しでも生きやすい世の中にした方がいい。人は国の宝なんて言いませんけど、労働人口も減ります。当たり前です。（生きやすいってなんでしょう？というのは、ここで話しません。それはそれでまた長くなりそうですから。）
このようなことを凡人の上野が考えたところで、悪いことじゃないでしょう。というより、考えない人の方がおかしい状況なのではないかな？どうかな？目を背けているというか。
産みたくても産めない、という次元の話じゃないですよ。もっと程度の低い話です。そして簡単な話の方です。簡単だから難しい。
上野的確証バイアス全開で行けば、みんなで生きていくには、それらの成り立ちを繋ぐ、ユニバーサルデザインやバリアフリー、アクセシビリティなんてのは必要でしょうよ、ということです。
つまり、社会的なリソースはいつも限られているのですから、ロスがないようにそれぞれの仕事（社会貢献といってしまっていいでしょう）を建設的にした方がいいと。ある一定基準があるなら、それを乗っ取りましょうよ、と言いたいわけです。そのためにも、Webアクセシビリティ、となったわけです。
ただし、これは、"マイナスからプラマイゼロに戻す"だけの話です。
日本の現状
Web業界（に限らずですが）は、終電や残業、いやいや、そもそも朝とか夜とか曜日とか、そういう概念もない人すらいますよね。それ、異常です。
寝ないとだめです。病気で死にます。うつ病になります。そうなると、社会的損失です。
個人経営の人は自分事として致命的でしょう。会社員でも会社は人生まで責任を負いませんよ？当たり前です。使える人を雇っているので、使えなくなったら基本的にはいらないのです。まぁ、そう簡単ではないのですが。
経営者になったことはないのでわかりませんが、経営者も、いまやブラック強要会社のレッテルは、"痛い"でしょう。
結局は、自分の身は自分で守るしかないのです。
（もしそうじゃなければ、安心してください。とても効率的かつ有意義な生き方をしていますよ。）
簡単に言えば、ある一定の、巻き戻りがないように、使える仕様はちゃんと守ればいいわけです。
強要するもんじゃないし、強要できるもんじゃないけど、全体的にこうしないかい？というルールは、W3Cだったり、WAICだったり、Googleだったり、ISOだったりが出してるじゃないか。なぜ無視しまくるのだ？ということです。
こういうの、もうやめない？
上野だって、言いたくて言ってるわけじゃありません。
"無視しまくる現状"が目の前に溢れ出てきてくれるので、愚痴になるわけです。
コンテンツのアウトラインがないなんて生ぬるい、
見出しを力強くコメントアウトしてくれちゃったり、ナビゲーションもコンテンツもなんでもJSにしたりですね。
HCDだ、UXDだ、ユーザビリティテストの結果だ！って言いながら、7pxの注釈がものすっごいコントラスト薄くて文字読みづらかったりですね。
マーケティング戦略だ！っていいながら、構造ぐちゃぐちゃのバナー量産、ユーザーフローとか関係ないから、とかですね。
注文を出してるんだから、言った通りに動くのは当たり前、追加要件・仕様変更でも、同じ値段で同じ工期でやるのが当たり前とかいうステークホルダーだったりですね。
別の話で、アプリケーションとしてのHTMLとか、好きですよ。canvas一つとったって、何がアクセシビリティだ、となるわけです。
でも、こういった話をするときも、常にサイロがもうサイロサイロ！
そんなものは、大企業病だけで十分なのです。パトラッシュ僕もう疲れたよ。
いづれにせよ、狭義なWebアクセシビリティ（読み上げや実装方法など）も、広義なアクセシビリティ（あるべきどうこう）も、それぞれのレベル感も、こうなっちゃうとバラバラになるわけです。
だから、俺らOBSはさ・・・
だからね、俺らは、最低ラインの標準技術（W3Cだったり、WAICだったり、Googleだったり）はしっかり守って、守るだけの勉強とスキルを身に着けて、さらに、マーケの効率化、人に合わせてよりよい生活体験が生まれるUX/HCD、他領域のコラボを見据えてのサービスデザインなどをしていかない？そういう仕事をしていこうよ。そういった内容を、インプットだけじゃなく、アウトプットもしていこう。自分たちだけがやったって、それはそれで意味がないんだから。俺ら自体がちゃんと人間らしい生活をして、胸張って次の世代に渡せる社会を作りたいじゃん？
"マイナスからプラマイゼロに戻す"だけではなく、"ゼロからただしくプラスへ"していこうじゃないか。ねぇ？
という、勉強会でした。一応報告ですが、内容自体はポジティブだったのです。資料の上では、中二的に吠えてますがｗ
上野のほかに発表者は、デザイナー、ディレクター、の計３人。・・・いえ、参加人数が３人だっただけです。とても楽しかったですよ。有意義なディスカッションができました。粒度や内容は種別がそれぞれ違いますが、残り二人も同じくらい面白い内容かと思います。
OBS（大塚ビジネスサービス）のWebチームについて少し。
WAICの１・２・３部に参加させていただいてたり、UX系はAIITで卒業生２名、現役生２名がいたり、UXグラフツールの運営してます。手が遅いですけどね。人間中心設計専門家はスミマセン。（あのエクセルは年始年末無理だわ）
大規模サイトの運営・構築・設計あたりメインにやってます。メンバーは50名程。・・・なんですけど、自社Webサイトには、たった１ページだけ（笑）。特にサービス内容は書いてませんし、サイト自体もレガシー感すごいのでなんとかしたいんですけどね。いい加減恥ずかしすぎる。
主に、（関連会社なので）中の仕事メインで、外の仕事は外注さんと連携していますが、クオリティやレギュレーションなど差が出てしまいますし、、こういう背景も、本勉強会の題材として選んだ一つだったということです。
ちなみに、社内勉強会、としていますが、ゆくゆく他の人と腹を割って話していってみたいね、としているので、どなたか議論したい方いらっしゃれば、お声がけいただけると、楽しいです。
注： △勉強会 ○飲み会
CSSだけでランダムなサイコロゲーム作りました with水どう
CSS3で、ちょっとしたゲームを作ってみました。
が、検証もしてません。特にスマートフォンで見ないでください。
たぶん、超縦長です。
大体の機能が網羅されているのかなと思いますので、これから学習するコーダーさんのドリル的な何かにも使えそう。
※（素材は、きっと水どうコミュニティなら許してくれるはず。）
使った技術
HTMLとCSSのみ。
何のために作ったのか？仕事のためです。
上司から、「そんなことしてて売り上げにつながるのか？暇なのか？」と言われた後に、「なんでできないんだ？できるんだろ？」と言われそうなことだなと思いながら。
思ったこと①
firefoxのパフォーマンスがいいですね。chromeは重い、遅い。
思ったこと②
animationループは、当然マシンパワーを使い続けるので、
どっかで止めるように仕向けないといけないね。知ってる。
トリガーを無理やり作ろうとおもったんだけど、やればたぶんできる。諦めてはいない。
思ったこと③
アクセシブルにするために、JSが必要なこともあるってこと。
ゲームの回答をDOM内に記述することになり、それってゲーミフィケーション無視してるよな、って思った。
人は、パンのみで生きるのではない、と。
読み上げ系のデフォって、z-indexのanimationレンダリングするのかな。。。
思ったこと④
画像周りは、あまり興味ないんですが、data形式のがきれいに見える不思議。
思ったこと⑤
CSSやる人は、IAであり、クリエイターであり、CADエンジニアであり、物理学者でなければいけない、ということ。
あえて言えば、CSSは、taranslateZとz-indexの恩恵により、N次元になりうる。
ネタばれ。
flashっぽいのですが。
懐かしいですね。20年くらい前ですかね。
新しい（？）単位で、vw/vhがあります。これを使うと、
画面にならって作ることができるため、っぽくなります。
例えば、モーダル系のUIとか。私は極力さけますが。
なんでランダムができるの？
z-indexとanimationの組み合わせです。
厳密には、ランダムと違いますが、ユーザーの動きと組み合わせればランダムといっていいでしょう、と思います。
PCは:hoverで動きとめてます。
結果が個別に動くのですが。
ボタンは、ラジオボタンのlabelを使ってます。
そのラジオボタンは、次のセクションの表示トリガーになってます。
:checkedで表示トリガー後、必要DOMをdisplayさせてます。
動きは、animationとか、transitionとかのdelayあたりです。
IEでペラペラなのですが。
社会不適合ブラウザに時間を割く必要はございません。あなたも、私も。
気が付いたこと
その①DOM指定
animationの復帰ポイントは、該当DOMの親要素の出入りがあると、うまくいかない。
直接指定する必要がある。
その②使えなかったメソッド
matrix3d()を使えなくて、残念。
その③計算。数学。物理。
サインコサインタンジェント微分積分重力落下とかは、ちゃんとお勉強しなければ無理。片手間でできるもんではないと痛感。
calc()があるとはいえ、CSSのみで計算いけるのか、ちょっと謎。ペジェ操作できるからいけるのかなー・・・。
その④視点
動かしすぎる、というか動かすと基本的に酔う。自分は。今回は視点はずらしてないです。
その⑤角丸と影
今回挑戦しませんでしたが、３Dの角丸と影。
ネイティブな感じでつけるとなると、光源とか必要ですね。
selectタグのスタイルをcssで整える方法と考察（IE7,IE8,IE9,IE10,～他モダンブラウザ）
<select>のスタイリング（CSS）の記述とその内容について、記事にできるだけまとめました。調べる限り、たぶんみんな苦しんで、そして諦めていったんじゃなかろうか、と感じたので、ある一定までブレイクスルーできたかと思います。
いまだに、IE7だのIE8だのの対応をしなければいけないことを、残念に思いながら。。。
結論のソースを先に。
■HTML
<div class="input-type-select">
<select>
<option>[*テキスト１*]をお選びください</option>
<option>[バリュー１]</option>
<option>[バリュー２]</option>
<option>[バリュー３]</option>
</select>
</div>
■CSS
div.input-type-select{
vertical-align:top;
display:inline-block;
max-width:490px;
box-sizing:border-box;
overflow:hidden;
border-top:1px solid #ccc;
border-right:2px solid #ccc;
border-bottom:2px solid #8E8E8E;
border-left:1px solid #ccc;
border-radius:5px;
background:#FAF6F5 url("bg.png") no-repeat right center;
position:relative;z-index:3;}
div.input-type-select select{
text-overflow:ellipsis;
box-sizing:border-box;
width:518px;
width:calc(100%);
-webkit-appearance: none;
-moz-appearance: none;
appearance: none;
padding:3px 35px 3px 5px;
background:transparent;
border:none;
border-radius:4px 3px 3px 4px;
font-size:14px;font-size:1.4rem;line-height:1.5em;color:#333;font-family: Meiryo,"メイリオ","Hiragino Kaku Gothic Pro","ヒラギノ角ゴ Pro W3",Helvetica,sans-serif;
white-space:normal;
position:relative;z-index:-2;}
div.input-type-select select::-ms-expand {display:none;}
div.input-type-select select option{background:#FAF6F5;}
div.input-type-select select:focus option{background:#fff;}
div.input-type-select:after{
content:"";display:block;width:10px;height:100%;
position:absolute;right:23px;top:0;z-index:10;
background:#FAF6F5 url("bg.png") no-repeat left center;}
div.input-type-select::after{
content:"";display:block;width:19px;height:100%;
position:absolute;right:35px;top:0;z-index:10;
background:#FAF6F5;
transform:rotate3d(1,1,0,180deg);
transform-origin: 0 150px;
-webkit-transform:rotate3d(1,1,0,180deg);
-webkit-transform-origin: 0 150px;}
*+html div.input-type-select{background:none;border:none;}
*+html div.input-type-select select{width:100%;background:#FAF6F5;padding:0;}
■firefoxにてキャプチャ（一番の理想に近いもの）
■IE8（エミュでキャプチャしたので、ちょいずれてるが。実機ではＯＫ。）
なぜこんな記事を書こうと思ったのか
Ｗｅｂで調査した（調べ方がよくないのかもしれない）が、みんな<select>のスタイリングの可能性を、どうも途中でとめているようだ。
可能性、、というよりは、社会不適合ブラウザの対応・・といった方が正しそうだが。
かくいう私も、現時点で完璧にやり切れたかといわれると、たしかに、細かいところを突かれると、ＨＴＭＬとＣＳＳだけでは、実現できなかった部分がある。これについては、すでにソースを分析し終えた方であれば、その理由がわかるはずであるし、本文の後の方で反省として残しておこうと思う。
当然だが、"こんな"記事は、すなわちビジネスの決済をしているようなお偉い方々や、そもそもあなたの同僚にさえ、まったく理解ができないかもしれないし、価値も見いだせないかもしれない。
だからこそ、このように文明の発達を阻害するブラウザのために、わざわざあなたの貴重な時間を使ってほしくないと願い、今にいたる。
未来の可能性がまだまだある20代の方々などには、特に、この負の遺産ブラウザへの対応をする時間は、とりわけ"労害のための会議"に付き合うようなものであり、モチベーションなどあるはずもない。
何かの助けや参考になれば幸いである。
色々な制限を先に
<option>だ。
こいつは、もう次元の違う強さを持っている。ブラウザをはみ出すのだ。
手の付けようがない。結局こいつをちゃんと操作することはできなかった。
ただし背景色を付けたりすることくらいはできる。
<select>のafter,before。
selectにafter,beforeが使えたら、どんなに楽だったか今でも残念。
まあ早い段階で心の切り替えしができた。
<select>の矢印ボタン。
基本的に、矢印ボタンは、いる。しかもIE8,9あたりは、消せない。
↑こういうやつ。
selectのスタイリングは、こいつとの向き合いが全ての勝負である。
ただし、単純にないがしろにもできない。この矢印部分の存在は、配下のoptionを開くという認知的機能（メンタルモデルというか、アフォーダンスというか、シグニファイアというか）が提供されるため、いってみれば、なくてはならない。
したがって色形を変更す際にも、UIデザインとしては、必須であり位置もそうそう替えられないものであるがゆえに、考えることは多い。
validでa11y的にも問題がないようにする。
HTML/CSSともにきれいなコードにし、設計もちゃんとする。
option選択時、option選択後、の表示にも気を遣う。
前述したとおり、option自体はブラウザを超える表示になるため、操作不能だとしても、多少なりのケアは必要。
例えば上記矢印部分を右側にoverflowさせるサンプル例を見るが、%で飛ばすと、コンテンツ幅（テキスト量）の割合なので、削る部分がどれくらいか操作できなくなる。
さらに、option選択時、selectの幅であろう部分より飛び出てしまう。
ちょっと不細工であること（まぁ、そもそも最大幅以上の文字があると同じようになるのだが）と、選択後、
作成されるであろう背景モノに被るため、よろしくない、という結論。
ソースの説明
DOMは説明するまでもないだろうと思う。
一応補足すると、特にdivじゃなくていい。今この場で文書構造の説明をする気もないのでdivにした。少し悔しかったのは、何か一枚ないとレイアウトすらさせてくれなかったことくらいか。
したがって、以後はＣＳＳの説明を。
■div.input-type-select{～
外側のスタイルを指定している。どっかに置く場所によってちょこちょこ変えてくれればそれでいいかと。かなり一般的な内容だと思うので、必要分だけ説明。しいて言えば、このくらいの大きさの背景画像ならdata形式にすることをお勧めする。コンポーネント数の削減はパフォーマンスを向上させる。
z-indexは、社会的損失であるIE8の対応。
max-widthは、optionの特性で横にはみ出させようと<select>に働きかけるらしくそれの予防。値はレイアウトによって入れ替える。
■div.input-type-select select{
こいつが一番の肝。
text-overflow:ellipsis; ←できれば、はみ出そうとする要素を3点リーダ
box-sizing:border-box; ←widthの計算式を楽にするため
width:518px; ←存在価値のないIE8のための記述（結局ＩＥ８はマックスまでいく必要がある。）
width:calc(100%); ←Webの発展を阻害するIE9以降の幅で上書き
-webkit-appearance: none; ←selectの矢印消し
-moz-appearance: none; ←selectの矢印消し
appearance: none; ←selectの矢印消し
padding:3px 35px 3px 5px; ←レイアウト保持（ただし労害IE8はきかない）右paddingは、今回のbg用。
background:transparent; ←デフォ背景消し
border:none; ←デフォボーダー消し
border-radius:4px 3px 3px 4px; ←まぁ。
white-space:normal; ←一応折り返して表示してくれるブラウザがある。
position:relative;z-index:-2; ←z-indexのためのrelative。（Web標準外のブラウザIE8用）
■div.input-type-select select(:focus) option{
これは、ただ背景変えてるだけ。
■div.input-type-select select::-ms-expand {
産業廃棄物であるIE10のためにある、selectタグの矢印を消す、ms独自の疑似クラスがあるみたい。
■div.input-type-select:after{
これは、世界の経済的損失の原因になっているIE8のための記述。シングルコロンなのは、イントラを見るためだけのブラウザIE8がダブルコロンをサポートしていないから。
この仕様を逆手に今回は使う。
一つお伝えしておきたいが、IE11などのエミュレーションと、実機のIE8は、挙動がまるで違った。IEtesterのIE8と実機のIE8は、ある程度似ていた。
content:"";display:block;width:10px;height:100%;
position:absolute;right:23px;top:0;z-index:10;
background:#FAF6F5 url("bg.png") no-repeat left center;}
IE8宛にしていることは、矢印部分とテキストの間を、もともとの背景で埋めている。
矢印ごと埋めちゃえばいいだろう、と思うかもしれないが、上位のDOM:afterで埋めると、selectが動作しなくなり、矢印部分がマウスクリックで反応しなくなる。
これは、UI上致命的な欠陥であるため、避けることにした。
ここでも背景画像は、当然dataにしておくといい。
height100%にしているのは、文字拡大対応のため。
↓この部分
くどいかもしれないが、疑似クラスのオブジェクトのz-indexには、IE8特有のバグがある。前述の親要素に対してのシツコイz-index記述は、このため。
■div.input-type-select::after{
これは、歴史の教科書などにのるはずもない、何かの実験台かかませ犬だったのであろうIE9のための記述。（しかし2016年以降もサポートはするようだが。）
ダブルコロンを使い、シングルコロンで使った記述の上書きをする。
区画を作って上書きすることはIE８と同様であるが、その位置は違う。
IE8とIE9での、矢印出現位置が異なることに由来する。
IE9には、inline-blockかつ、selectにpaddingが"効く"ので、この位置に矢印がくる。
transform:は、IE9では実装されていなく、IE10以降に実装されているプロパティ。やってることは、このafterで作った物体を、overflowの外に飛ばし無効化（？）させること。値は適当。これにより、IE9専用の記述ができる。
見た目、矢印部分とテキストにやや開きが生まれるが、
結果的に、それほど違和感がないため、許容した。
ただし、IE8と同様に、押せない部分ができることは免れない。
■*+html
言わずとしれた、ie7。これは、できるだけデフォに戻してるだけ。
まぁ、この流れなら、ie6も対応できますよ、ともいえそう。
結論
ざっとこのソースに対して説明した。
社会的嫌悪の的であるIEの８９で少々のバグがあるのがわかると思う。
afterで作った区画は、"押せない"のだ。
また、存在価値がないie8にいたっては、padding分も押せない。
これらのマウスを使った視覚で操作するユーザビリティの担保は、おそらくこの方法のHTML/CSSだけでは賄えない。ＪＳなどで別途機能を作る必要がありそうだ。
また、諸悪の根源であるIE8対策のために、paddingの値をcalcを使うことで操作できる。したがって、widthをフルに使うことなく、本来のinline-block的な挙動に抑えることができる可能性を残している。
さらに別の可能性として、<select>にcolumnを使った手法であれば、もしかしたらIE8に対しての別の解を求めることができるかもしれない可能性をここに残しておく。
Webの仕事は製造業か？
ウェブサイトは、HTMLでできている。物理的、、というかデータとして。
コンテンツをHTMLでコーディングし、HTMLファイルを作り、サーバにアップする、というだけのことを見れば、製造業に近いのかもしれない。
半分はあってる。けど、半分はあってない。
実際モノづくりな側面はあるので、第2次産業ではあると思う。ただ、それが人にとって、社会にとって、それ以上にエコシステムとしてどうあるか、というUXだのSDだのが入った時点で、第3次産業の側面が含まれるようになる。
あるいは、負荷価値として、安定した品質とか、高クオリティとか、そういったプロパティを持った時点で、人にとってすでにサービスといえる。安心を買うという行為になるため。
とても当たり前の話であって、違和感もない。
モノづくりとしてのWeb
そもそも論で、モノづくりとしてのWeb制作業は、それ自体に価値がある。
誰かが作らなければ、何もない。加えてこのとてもスピード感あふれる技術革新においついて、トップクオリティを維持しているなら、なおさらだ。
ただ、Webの価値をチラシと同等の機能であると勘違いしている客にとっては、高クオリティである必要もないし、インフラである必要もない。
したがって、アクセシビリティなどと意味のないことにつながるし、そもそもページ自体が自分で作ったパワポやワードのキャプチャ画像一枚でいいのかもしれない。
TimBLが、とてもがっかりしそうな内容だ。
検索を含むWebそのものが生活インフラを構築する
Web制作者は、www上で、生活インフラを構築していることの自覚をもたなければいけない。セマンティックやパフォーマンス、高品質なコンテンツと、ユーザビリティ。インフラである以上、アクセシブルである必要は、言うまでもない。
Webとチラシを混同する類のデジタルイミグラント世代は、総じてソーシャルフラキシケーション系は理解しづらいだろうし、いやいやその前に、文字は大きくなければ見えないだろう。
isoでのフォントをpxに換算すれば16px。これはほぼブラウザのデフォルトサイズ。相対指定でいえば、
html{font-size:62.5%}
p{font-size:16px;font-size:1.6rem}あたり。
自己中な客は、自分を見ない
自分のやりたいことを達成するためには、自分がユーザーであることを忘れることが多いようだ。これは、相手がいる仕事ではないので、プロフェッショナルな仕事をする人間とはいいがたい。
自分がやりたいことには、自分が知っている範囲で、自分だけの想像が全てであり、否定されることは許されないのである。しかしながら、いざ自分が生活のモードに入った場合、同じようなサイトを見て言うのだ。「こんなのだめだ」。
社会的価値につながるか？
こういった自己中な客へのサービスは、高品質なエンジニアやデザイナーや設計者をあてがうべきではない。そもそも高クオリティを求めていないし、費用も高い。高品質なメンバーは、高品質を求める客とつながることで、win-winの関係を築き、社会的価値、言うなれば社会生活インフラをよりよく構築することができる。
日本の中でさえ、困っている人は多いのだ。"客"という存在をボトルネックにしてインフラの拡大を阻害してはいけない。なぜ社会生活を阻害するのか？その権利は自己中にはないはずである。
利他的行動により社会が成り立っており、（そのための"心"というシステムを持っているのだが）、利己的であればあるほど、社会のモラルは崩れるということになる。そんな人間に肩入れする必要もないであろう。
もし、それが強制であり、他の手段が本当にないのならば、その場を離れるという選択が候補にあがる。社会をよりよくするためは、まっとうな社会活動をしている場に身を置くべきだろう。あるいは自力でその思想を体現するのがよいのではないだろうか。
大規模と小規模のCSS設計使い分け
Bootstrapなどのフレームワーク、BEMSなどの命名規則や、OOCSSなどの構造の考え方。プロトタイプなどでない場合の、サステナビリティを確保するために構築するWebサイトの場合、これらの考え方をそのまま使うのは注意が必要。
Webサイトの形骸化は、結局のところ管理者を含む運用者のレベルやリソース、モチベーションなどに依存する上、お金や時間のコストと目的や目標と釣り合わないと、継続できなくなるから。
そりゃそうだ。無駄だもの。
小規模サイトの場合
命名規則はそれほどシビアにならなくてよいです。ナビゲーションの一貫性やグリッドの合わせくらいは考慮したいですが。
正直、PCサイトとして作るだけなら、右画像左テキストなどのエレメントは、tableで画像側にwidth:1%とガーター分のpaddingを入れるので全部のサイズに対応できるので、手間かけたくなければそのくらいの妥協していいと思う。
運用者が自由にCSSなどを書いてレイアウトやビジュアルを操作できる場合
実運用者がフレームワークや命名規則、構造を既存のものを理解するか、ある程度カスタマイズできる状態なら、武器になる。
後々自由にできる部分とできない部分で詰まり、その場しのぎの対応を積み重ねることで、ミンチェスターミステリーハウスのように、後々メンテナンスなんてできねーぜ！ってならないように注意できればいい。
運用者がCSSなどがわからない場合
Webサイトを設計する際、テンプレートパターンを作っておくといい。事前に用意されたテンプレートに沿って、内容を変えるだけ。
そうでなければ、WYSIWYGなど使ってもいいと思う。その場合には、あらかじめエレメントパターン（コンポーネントとかテンプレートとか言われる類）を用意して使いわけるのが楽。サイトの整合性も保てるのでお勧めです。
大規模サイトの場合
コーポレートサイトやプロモーションサイトなどコンテンツの種類が多い場合
大規模は、500～1000P以上くらい。
現実的には、実装がわかるIAを入れましょう。話はそこからだ！と言いたいところですが、CSS側だけでできることもあります。
一番大きな区画で名前空間を区切ることでリスク回避+サイト管理
一番大きなナビゲーションを区画としますが、
CSSでの名前空間を考えるだけで、大きな保守性を生むことができます。
ヘッダーもフッターもメインエリアも含め、サイト全体に及ぶ場合、グローバル領域でセレクタ指定します。
.bold{font-weight:bold}など
メインエリアなどだけで使う場合
#main .box-3column{}など
ある区画のメイン領域で使う場合
.hogehoge #main .hugahuga{}
この.hogehogeをトリガークラスと呼びますが、このトリガークラスがあることで、領域定義の汚染なく、区画ごとにCSSやエレメント（コンポーネント）管理できます。
あとは個別の命名ルールについては、プレフィックスやサフィックスで、どんなエレメントがあるかを全体把握し、適切な深さにふさわしい名前を付けるとよい。
.hogehoge #main .nav-category{}
など。
ECサイトやニュースサイトの場合
大体テンプレートパターンでいける。バナーのせろだの、この余ってるとこに何かしろだのいってくるパターンが多いです。経験でいうと・・・。
なので、エンジニアに話がきた時には、時すでに遅し、の場合がほとんどなので、気にせず生きましょう。
