HTML5 Conference 2018 聴講 ざっくりメモ


※ メモ書きのためヌケモレ、タイポ、勘違い含まれます
※ スライドURL等、情報入手次第追加予定

HTML5 Conference 2018

タイムテーブル

@sekiyaeiji が観たもののリスト & index

スピーカー全リスト

基調講演

東京電機大学挨拶

東京電機大学総合研究所特命教授・サイバーセキュリティ研究所長 佐々木良一
https://cysec.dendai.ac.jp
サイバーセキュリティのより一層の充実は、社会を安心・安全・豊かにするための喫緊の課題です。東京電機大学CySecプログラムは、社会ニーズに応えるべく、社会人向けにサイバーセキュリティ意識の高揚を先導する、高度サイバーセキュリティ専門家を大学院レベルの授業により養成します。ご興味がある方、ご賛同頂ける方のご連絡をお待ちしております。

HTML5 Conference 2018

  • 今回第7回目
  • 吉川徹
  • HTML5とか勉強会
  • 1日で定員オーバー
  • 「HTML5」名前問題 → 変えるのやめた w
  • WebXR
    • FirefoxReality
  • Windows Hello

えーじさん

  • えーじ
  • Google
  • 50億
    • = Webへの1ヶ月のデバイスアクセス数
    • スマホ、PC、電子書籍端末、ゲーム機
  • Web は インフラ
  • Video + Picture in Pidture
  • WebRTC
  • WebXR
  • WebAssembly + Web Audio
  • Web API
    • 2つ以上のブラウザが実装して標準化
  • Origin Trial
    • Vender Prefix の苦悩から発想
  • Extensible Web Manifest
    • Web Component
    • CSS Houdini
    • Service Worker
  • Layered API
    • virtual-scroller
    • async local storage
  • AMP (Accelarated Mobile Pages)
    • ウェブページ高速化を実現するフレームワーク
    • 多くの制約を設けることで高速化を実現
    • Web Component ベース
    • URLが二重になる
  • Web Packaging
    • Signed Exchange
    • Bundled Exchange
  • Feature Policy
  • "Web is the only platform no one owns."
    • Dave Winer
  • WebはDeveloperのフィードバックを求めている
  • WebからDeveloperへのお願い
    • ドキュメントの翻訳
    • 仕様やブラウザベンダーへのフィードバック
    • 勉強会への参加、登壇
    • ブログを書く

デザインを共有するための言語化あれこれ

Webやアプリを世に出すにはエンジニアの力が欠かせませんが、競争が激しくユーザーの要望も高まっている現在、デザインは大きな差別化に繋がります。
同じモノ作りをする職業ですが、課題解決の取り組み方から評価の仕方まで違いがあります。その違いが誤解に繋がることもあれば、「よく分からない」と遠ざけてしまうことになります。お互いの力を合わせることでより良いプロダクトが生まれるはずですが、機会を失うことになります。趣向・感覚が違うという単純な話で片付けることはできません。
本セッションでは、エンジニアとデザイナーが協働していくためのアプローチと「相手に何かを伝える」というコミュニケーションの仕方を紹介します。

デザイン

  • デザインの範囲
  • 誰にとって重要
  • デザインの解釈の違い

  • エコーチェンバー現象に気づいてない
  • 同業者感覚のコミュニケーション
  • 我々は正しいは「ある視点」に過ぎない

よいものを作りたいと願う仲間

  • 「ボタン」でイメージするもの
  • 「label」でイメージするもの
  • Bootstrap、Foundation間でも差異多数

どうしてる

  • 聴く(アンケートを採る)
    • ガイドラインにない言葉が行き交う
    • 開発、デザイン以外の視点も考慮
    • UI...

ニュアンスの共有

  • 「良い」って何?
  • 何が大事なの?

マズローの欲求段階説

  • 自己実現に向かう条件、の手法を取り入れる

価値に基づいた評価

  • 課題解決してるかどうか
  • ユーザーへ提供している価値は何か

危険信号

  • 「これはどうですか?」
  • センス、好み
  • 逆戻り、迷走

では

  • メリット
  • デメリット
  • リスク
  • 課題
  • 仮説
  • 指標
  • デザイン案

つまり

  • 課題解決へ議論をシフトさせる
  • デザインの経緯を記録する
  • 文書の定型化を心がける
    • カラースペクトルも記録
    • アイコンデザインのグリッド
    • ローディング
  • 複数人がデザインをサワれる仕組みづくり
  • 部品だけでなく考え方も書く
  • 着手しようと思ったらまずは色からシステム化
    • 色のルール
    • 色の名前

アクセシビリティ、はじめよう! 〜「できない」から脱出するための20(仮)のネタ🍣〜

最近流行の兆しを見せつつある「アクセシビリティ」、取り組んでいますか?
まだ何もしていない、何をしていいかわからない、というあなたに向けて、アクセシビリティの基本的な考え方、取り組む理由などについてゆるーくトークしていきます。
これから取り組んでいく、周りの人を巻き込んでいく際のヒントになるかも?
困っている方からの質問も大募集します!

アクセシビリティ

  • a11y
  • Accessibility = a(11文字)y
  • access + ability
  • Universal design との違い
    • 普遍的
    • Accessibilityの実現手段の1つ
    • 階段昇降機
      • AccessibilityだがUniversalではない
      • アクセシビリティには専用UIによる解決もある
    • 専用UI
      • 点字、音声
    • Webブラウザ側ですでに実装されているUniversal designも多い
  • 使う人によって使いやすい形に変えて利用できるもの
  • アクセシビリティ非サポート
    • アクセスできない
    • 使えない
    • 負の体験
  • アクセシビリティ手段
    • 見えない
      • スクリーンリーダー
      • 点字ディスプレイ
    • 見えづらい
      • 色調反転
      • 拡大
  • スクリーンリーダー

自身のサービス、製品も...

  • 実はターゲットかもしれない
  • ターゲットの知り合いかもしれない

障害者差別解消法

  • 2016年4月
  • 必要に応じて合理的配慮
  • 公共には義務、民間には努力義務として制定

何をするか

A(シングルエー)の例

  • 見出し構造
  • リンクテキスト
  • 色だけで表現しない

早見表

注意点

  • 離れたところが変化してもわからない
    • タブ切り替え
    • モーダル
    • など
  • 書籍 『インクルーシブHTML』
  • 書籍 『デザイニングWebアクセシビリティ』
  • VoiceOverなどを活用

最後に

誰でも始められるか?

  • アクセシビリティは0/1ではない
    • ゴールはない
    • 継続的な改善が大切
      • ボタン一つをキーボード操作できるようにする
  • Web制作のどのプロセスでもできることがある
    • MUを少し改善する
    • 企画、設計に取り入れる
    • アクセサビリティについて話す

「セマンティクスの作り方、これまで、今、そして未来」

HTMLによるネイティブセマンティクスからWAI-ARIAによるセマンティクスの補強、そしてAOM(Accessibility Object Model)によってJavaScriptからアクセシビリティツリーを更新できる未来。
ウェブのセマンティクスの作り方について、これまでと現在を振り返りながら未来についてもご紹介いたします。

セマンティクス

  • 広義のセマンティクス
  • 今回のセマンティクス : HTML
    • 想定される未来のうちの1つの話

セマンティクスの恩恵

  • アクセシブルになる
    • 近寄りやすい
    • 利用しやすい

HTMLのセマンティクス

  • セクショニング
  • フレージング
  • 要素名に依存する
  • 状態に依存する
    • DOMツリー
    • 新しい要素
    • 状態やプロパティの欠如
  • dialog要素
    • モダール
    • HTML5.2
    • FF、Edge、IEだめ
  • hgroup要素
    • 見出し要素複数設定
    • 二番目の要素はアウトラインを構築しない
    • W3Cから削除
    • WHATWGには現存
    • 全ブラウザ対応済み
  • 未だ観ぬ要素が発生する可能性はある

WAI-ARIA

  • HTML(ホスト言語)を補強する
  • 属性を利用
    • role
    • aria-xx
  • role tree treeitem
    • ツリーウィジェットである
    • selected
      • 選択されている/いない
    • label
      • 名前
    • describedby
  • タブ
  • ライブリージョン
    • チャット、株価、ニュース
  • ホスト言語と相互進化
    • input switch を 策定中
  • role button → button
    • html要素が誕生したものはhtmlを利用したい

WAI-ARIAの課題

  • DOMに依存する
    • canvasではDOMの実体がない
  • idに依存している
  • 出力が評価できない
  • AOM
    • IDLインターフェイス
    • JS実装も可能
    • 拾えないイベント
      • increment、decrement イベントハンドラ実装提案
    • Virtual Accessibility Node
    • アクセシビリティツリーの自動テスト
    • 古いAccessibility Nodeは終了の方向
    • AOMの現状
      • 各ブラウザ実装中

開発体制に合わせたCSS設計

CSS設計手法は、BEMやFLOCSSなど代表的なものから、ECSSやRSCSSなど種類も増えてきました。サイト規模や開発体制という視点から見たとき、どういったCSS設計が望ましいのかをお話します。

CSS設計

  • 開発体制という視点から
  • 設計思想
  • 命名規則
  • 予測、再利用、保守、拡張 PRMS

必要性

  • コスト
  • 実装者単価
  • 実装工数
    • コンポーネント
    • デグレ削減
    • 並行開発
  • OOCSS、BEM、SMACSS、SUIT CSS、FLOCSS、MCSS、ECSS、AMCSS、RSCSS、RSCSS、ITCSS、FLOU、APB CSS...
    • いろいろあるが 10数個
    • ECSS
      • デザイン再利用防止
    • APB CSS
      • ATOMICデザインベース
    • RSCSS
      • ルールが少ない

FLOCSS

  • Foundation、Layout、Object
  • 「就活会議」で利用されている

ECSS

  • デザインを再利用しない
  • CSSの重複を許す
  • 変更や削除に強い
  • 「Qiita」で利用されている

RSCSS

  • 子セレクタ「>」でスッキリ記述
  • 比較的ルールがゆるい
  • フレームワークというよりアイディア集
  • 「行程さん」で利用されている

CSS設計あるある

  • 誰もルールを覚えない
  • 誰も正解を知らない
  • スタイルガイドのどこかにあった...
  • どのカテゴリに含めていいかわからない
  • 消しちゃいけない要素やclassを消す
  • ビジュアルデザイナーがコンポーネント使ってくれない
  • サイトすべてがいつまで経っても置き換わらない

検討項目

  • 実装社の人数が多い
    • ルールが多いもの
  • MUにかける時間が少ない
    • ルールが少ないもの
  • 実装社のスキル
    • 詳しい人がいる場合
      • ルール多
    • 詳しい人がいない場合
      • ルール少
    • 詳しい人だけがいる場合
      • ケースバイケース
  • 改修の頻度
    • 少ない場合
      • ルール少
    • 多い場合
      • ルール多
  • 社内政治力がある、コミュニケーションが取れているか
    • 取れてない
      • ルール少
    • 取れている
      • 話し合いで決定
  • コンポーネント種類の多さ
    • 少ない
      • ルール少
    • 多い
      • ルール多
      • 種類を減らすべき
  • サイトの規模
    • 小さい
      • ルール少
    • 大きい
      • ルール多
  • エンジニアとの依存度
    • 低い
      • ルール多
    • 高い
      • ルール少
  • 自社サービス
    • 自社サービス
      • ルール多
    • 受託
      • ルール少
  • 実装者お権限レベルの差
    • フラット
      • ルール少
    • 上下関係あり
      • ルール多

以上の組み合わせで判断する

大事なこと

  • サイトの特性
  • 開発体制
  • 社内政治力
  • 設定後の設計の変更
    • プロジェクトの独自ルールも必要
    • FLOCSSを選びつつRSCSSやECSSに寄せてくとかもできる

webpackのいままでとこれから

今やフロントエンドの世界では、JavaScriptのmodule化が一般的となりました。
このセッションでは、多くの開発で使われているwebpackの歴史を辿りながら様々な仕組みを紹介していきます。

モジュールバンドラー Module Bundler

webpack、parcel、browserify...

OpenCllective

  • OSS支援 → 開発者に還元

Vote and Prioritize

  • influence

Sort / Long Term Goals

以下、立ち見のためメモできず...のため

スライドで代用

以上