CSS Nite LP43 Shift9に行ってきた。(前編)

Shift9:Webデザイン行く年来る年(CSS Nite LP43)

ここ最近の恒例行事、年末のshiftに行ってきた。
満席となる350名が参加。

毎年本当に参加人数が多くて、人気イベントは申し込みにひと苦労です。
Blog内に出てくる出演者は敬称を省略しています。

また、今回は前後編構成にしています(そうしないと下書きのまま葬られるorz)。


基調講演:制作者はもっと盗むべき、たったひとつの理由/長谷川 恭久
講演では言及されていませんでしたが、オリンピックのエンブレム問題に引きずられるように、「デザインとはなんぞや?」「オリジナリティとは?」が話題になった年でした。
デザイナーにとって「盗用」と「リスペクト」の違いを説明するのは非常に難しいですが、「難しい」で済まなくなってきているのかもしれません。

定義としては、
自分のためだけにインプットすること=盗用
クリエイティブやアウトプットとして世間に還元するためのインプット=リスペクト

同じインプットでも、それが世間のためなのか、自分だけのためなのかで、その意味合いは変化する。
また、デザイン制作の過程はブラックボックスで、「気づいたらできている」モノとして非デザイナーに認識されている。それ故に「盗用」と「リスペクト」の区別が付きづらい。
過程がわからないということは、制作物は「多数の情報をインプットした上で、デザイナーの中で消化/再構成されて吐き出されたもの(リスペクト)」なのか、「インプットした情報をそのまま吐き出した(盗用)」なのかがわからないということ。

自分のためではなく、世間にアウトプットするために「盗む(正確には「盗用」とは意味が違う。どちらかというと「情報収集」の意味合いが強い)」、デザインのプロセスを明確にし、デザイナーの考えていることを理解してもらうことが、より重要になってくるだろうという話でした。

とはいえ、


結局のところ、環境を作るのはデザイナー自身の仕事。

これは、以前読んだ、しくじり佐野研二郎氏に足りない「リスペクト」と「許される力」の内容と重なります。
「許される力」と言われている部分、つまりデザイン制作のプロセスを明確にし、成果物が「盗用」なのか「リスペクト」なのかの判断材料を関係するすべての人に提示すること。
それが、今後のデザイン制作には必要なのだと。

ちなみにヤスヒサさんのスライドは一見の価値ありです。
これ見るために、毎回基調講演聞いてると言っても過言ではありません。
Yasuhisa Hasegawa

マークアップ/益子 貴寛・小山田 晃浩・久保 知己
セッションの内容は

  1. ブラウザーの移り変わり
  2. CSSの書き方
  3. 制作環境の変化
  4. ライブコーディング

毎度おなじみ、問題を起こすIEのレガシーブラウザ問題。
イントラネットだとIE8がターゲットブラウザになっていたりすることもあり、制作者としては「IE爆発しろ」が合言葉。

IE8のサポート切れにより、IE9またはIE11ベースの制作が可能になりそうな気配。
今後はIEの後継ブラウザEdgeに期待と言ったところ。

そのほか、「壊れにくいCSSのための設計思想」が浸透してきたこと、Ruby版Sassよりもlibsass版(C言語)Sassのほうが400倍高速という話もありました。

残念ながらSassやタスクランナーの導入はまだ。
今後導入するとすれば、libsass版(C言語)Sassとgulpが良さそう。


そう。
BootstrapもLessからSassになったのだった。
そして、創成期からIT業界にいるデザイナーにはおなじみの「とほほ」が「とほほのSass入門」を公開している驚き…。
プリプロセッサはSass優勢になってきた感じです。

そのほか、タスクランナーでは


など、制作をしていく上で便利なものが多く、来年は1つでも多く取り入れたい。

とはいえ、メンバーすべてが一度に導入できるか?と言えば、スキルの違いなどから難しい。
制作環境が大きく変化し、便利なものが増えているけど、無理に導入するものではない。
メリット・デメリット(特に学習コスト)を十分に検討する必要があると感じました。


その通り。
便利なツールはいっぱいあるけど、「ちゃんと書く」ことができないと便利さも不便に変わる。
実際、ある外注のコーダーさんがSassを使っていたけど、吐き出されたCSSのネストが深くて縛りが厳しく、後日デザインの追加をした時に死ぬ思いをした。
吐き出されるCSSを予測して使わなければ、プリプロセッサも不便なツールです。関わる人間全員を不幸にしますw

そのほか、このセッションで使われていた「Aigis」というスタイルガイドをちょっと試そうかと考えてます。
導入が簡単だったのでStyleDoccoを使っていたけど、もっと良いものがないかなと物色中なので。
https://twitter.com/yomotsu/status/680632489992417281
…今年は「とにかく明るい安村」ネタ多いですねw

アクセシビリティ/植木 真・中根 雅文・山本 和泉
本当に面白いセッション。

毎回スクリーンリーダーの実演があるので、現在のWebサイトの使いづらさなどがよくわかる。
大昔にSEOの改善手法の一つとして、スクリーンリーダーを使うという方法を教わったことがあるけれど、コードを素直に読み上げるので、視覚に障害を持っていると分かりづらいUIはたくさんあると気づかされる。

今後は視覚から入る情報で認知させるほかに、視覚に障害を持っていても分かりやすいUI(というかマークアップ)を作る必要があると思う。


クライアントの思惑等、色々な「大人の事情」により、使い勝手が悪くなるというのは良くある話です。
ただ、重要なのは、使用者に「いろいろな状況の人たち」が想定されている場合、それに沿ったUI設計をしなくてはならないということ。
そして、おそらくは、配慮があるサイトの方が、障害の有る無しに関わらず使いやすいサイトであると思います。

また、マークアップに取り入れることによって、アクセシビリティの向上を図ることができる「WAI-ARIA」については、私は初耳だったので非常に興味深いものでした。


参考:WAI-ARIA の基礎知識

最近、Bootstrapのコードがやたら長い思っていたら、WAI-ARIAの技術仕様を元にコーディングされていたためでした。
実務ではアクセシビリティに配慮しない制作が多く、こういう情報を知ることができるのはイベントならでは。


公官庁のサイトは必須になってくるでしょうね。

そして、やっぱりというべきか、WAI-ARIA未使用のモーダルは、スクリーンリーダーで読み上げると本当に「アカンやつ」でした。

モーダルは</body>の直前に書くことが多いのですが、スクリーンリーダーは上から素直に読み上げます…そうすると意味不明。本当に意味不明な内容になる。


クリックしたら表示されるものであるだけに、そこでクリックしないとわけがわからない。
これは視覚障害者にとって理解に苦しむコンテンツ。
そこで「WAI-ARIA」。


aria-hidden=”true”
がミソ。これがあると、変なタイミングで読み上げないので一気にわかりやすくなる。
ただ、JSがね…JSが…。デザイナーは苦手な人多いから。

ちなみに、今年もネタ動画付きでしたw

毎回年末のCSS Niteで聞きかじっている程度ですが、来年はアクセシビリティのイベントにも参加したいです。

(後編に続く)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です