Web アクセシビリティ向け Node.js 製の自動チェックツールや DevTools 用の拡張機能など
アクセシビリティを担保するプロセス作り この記事は Web Accessibility Advent Calendar 2016 - Adventar の 12 日目の記事です。 UI 実装の再考と a11y - Frontrend Vol.8 LT でも述べましたが、Accessibility is a Process, Not a Project ということでアクセシビリティ対応するプロジェクトではなく、アクセシビリティを担保するプロセスを作りましょうということで、チェックツールをいくつか並べて俯瞰してみます。対象読者は自分と同じようなクライアントサイドの Web アプリケーション屋さんということにしておきます。 ちなみにアクセシビリティ評価ツールについては 3 日目のアクセシビリティ方針、報告書、試験支援ツールa11ycのご紹介 (Web Accessibility Advent C
CSS Containment の制約と効能について覚え書き
ある要素内の状態による外界への影響を封じ込めて最適化を促す CSS Containment Module で定義される contain プロパティは will-change と同じようにブラウザが処理を最適化するために開発者から提供できるユーザーエージェント向けヒントとして機能します。 ヒントの目的はcontain の対象要素が親兄弟に影響を及ばさない独立した部分木であることを宣言し、各種の影響を contain の対象要素の中に封じ込めることです。 使うときは contain プロパティに既定の値として用意された size | layout | style | paint | content | strict のいずれかを指定します。content と strict は複合指定のエイリアスなので、本文では size layout style paint の4つについて個々の説明をします。
requestAnimationFrame とタイマーの今更な比較とデモ
フレーム描画のタイミング制御モデル 今更 requestAnimationFrame() だなんて Can I use を見ても IE 10 ですら実装していて、世界の 9 割以上で動作しうるカバレッジなわけですが改めて setTimeout() との違いを表現しうるサンプルをこさえてました。 それぞれの仕様の詳細や挙動についてはそれこそ今更なのでググっていただくとして、この記事ではサンプルについて曖昧な説明を添えていきます。 CodePen - setTimeout vs requestAnimationFrame (with CSS Transitions) See the Pen setTimeout vs requestAnimationFrame (with CSS Transitions) by Ayumu Sato (@ahomu) on CodePen. 比較のポイントとシ
既存 Web アプリケーションのアクセシビリティを向上させるときによくあるヤツと対応方針
アクセシビリティ向上メモ 最初から考慮されているのが一番ですが、そうでもなかったプロダクトに手を入れるときのあるあるを記録します。既存プロダクトはモノが出来上がってしまっているため根治的なリファクタリングよりも基本的には省力で済ませたいので、今回書いた対応方法も完璧よりは省力路線です。 HTML やらセマンティクスに関する知識はそれなりにあるつもりでしたが、AT やマシンリーダビリティを念頭に勉強し直すと自分で作ったものも至らなかったなと振り返らざるを得ない今日この頃。初期設計のときの考慮範囲が拡がったように思うので善きかなです。 各項目について、もっと良い解法や誤り等あれば twitter とかでご指摘ください。 1. 画像に alt 属性がない場合 付けましょう。付けます。はい。 昔から基本とも言うべき、HTML/CSS 書きとしては耳にたこができるほど言われてきたことなので今更感もあ
React v0.14.x から v15.2.x へのアップデート録
react v15.2.x アップデートに関連した記録 FRESH! by AbemaTV と AbemaTV の React を v0.14.x から v15.2.x にアップデートしたので、遭遇した WARN などについてメモ。 基本的には React v15.0 | React を読めばマイグレーションガイドがありますが、今回の作業で実際に遭遇したものだけ対応を記録します。 不明な prop を渡すなエラー … Unknown props foo, bar... on <***> tag. Remove these props from the element. <div {...props} /> のように、下位コンポーネントに対する props の雑な継承で WARN が発生します。DOMAttribute として正しくない prop が要素に渡ると警告の対象です。詳細は Unk
Web サイトっぽい SPA に必要なブラウザナビゲーションのエミュレートなど
Web サイトっぽい SPA に立ち向かう 大分前の話ですが、Node学園 20時限目 今回もdots!!!!! - connpass で Client Side of なんちゃらfresh.tv としてお話した内容のうち、Web サイトっぽい SPA に関してだけこだわりを再抽出して書き留めます。 本件は、ページ全体のスクロールや頻繁なナビゲーションを伴わず、1画面におさまるレスポンシブな Web アプリを作っている場合はあんまり関係がありません。画面内の局所的な状態更新は、コンポーネントの責務分割やら何やらの設計なので実は別の話です。 総じて、Web サイトっぽいくせに大人の事情で Web ブラウザのネイティブなナビゲーションを積極的に破壊しにいくときの心構えです。 URL が変わっても最低限レンダリングできるまで画面更新を遅延させる 画面遷移に必要なのは、 URL が更新されても次の
Isomorphic Architecture を実装してるときの細かいアレコレ
Isomorphic あらため Universal ？ 一時期火がついていた Isomorphic について。各自がプロダクションの事例を作り上げる潜伏期に入ったのか、はたまた本当に一過性で火が消えたのか、コモディティ化を遂げたのか分かりませんが、あまり耳にすることがなくなった印象です。 そんな中ですが先日、Universal JavaScript — Medium が公開され、なるほど Universal ってキモチになったので、タイトルに反して以下は Universal と呼称します。 今回の話題にするのは module レベルではなく Universal な JavaScript architecture のほうです。アーキテクチャのレベルで Universal なコードが役立つ代表的ケースは SPA (Single Page Application) と SSR (Server S
yahoo/fluxible による SPA + Server Rendering の概観
Single Page Application + Server Rendering yahoo/fluxible を使って、Single Page Application と Server Rendering の良いとこ取りのアーキテクチャを目指す。ある程度の複雑性と引き換えに、双方の利点で双方の欠点を打ち消し合うことができるため、全体的には良好なユーザーインタラクションを期待できる構成。 なぜ Single Page Application なのか 画面遷移時するたびにJavaScript/CSS のパースと評価をしなくて良くなる 画面遷移時のトランジションを柔軟に適用できる 画面遷移をまたがった実装が可能になる（あくまで可能になるだけ） なぜ Server Rendering するのか 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰
WAI-ARIA 対応のアクセシブルなタブ UI を React で実装する
タブ UI のアクセシビリティ対応 この記事は、下記の点に留意してご覧いただきたい。 タブ UI におけるアクセシビリティ対応（主に WAI-ARIA）の参考実装であること React コンポーネントとしての機能性は二の次のサンプルであること アクセシビリティ実装についてのツッコミは歓迎であること ひさびさにPCキーボード的なアクセシビリティ対応が必要そうな性質のサービスを開発することになったので、コンポーネント単位でのアクセシビリティ関連実装を進めている。 React 実装 今回はタブ UI を題材に、React コンポーネントを実装した。 行うべき操作を見通しよくするために、タブ UI を <Tabs> コンポーネント1つで実装した。厳密には <TabList> や <TabPanel> などの要素を分解してコンポーネント化したほうが良いだろうが、今回は簡易実装としている。 キーボード
RAIL という Web パフォーマンスモデルの概要
RAIL を簡単に紹介する 主に Googler が、という趣ですが今年に入ってから RAIL というパフォーマンスモデルが紹介される機会が増えてきました。 RAIL は Response / Animation / Idle / Load の頭文字をとった命名で「アプリケーションのライフサイクルの観点から、それぞれのフェーズの基準時間（限界時間）を示したもの」です。 手前味噌ながら Webパフォーマンスにおけるイニシャライズとランタイム で紹介したうちの「ランタイム」部分が細分化されて、それぞれに基準時間を割り当てたようなイメージです。 Idle や Animation あたりの時間は紹介する人・タイミングによって多少ブレている印象ですが、大まかに以下のような感じです。 Response : 100ms 「UI が操作されたときユーザーにレスポンスするまでの応答時間は 100ms 以内」
Google I/O で v1.0 が発表された Polymer の Elements Catalog が面白い
Polymer Elements のカタログページ Site: Polymer Element Catalog Repo: Polymer/polymer-element-catalog Polymer は、これからの Web 標準の一角を占めるであろう Web Components のラッパーライブラリです。その Polymer で作られたコンポーネントのカタログサイトが公開されていました。 これまでも Core Elements や Paper Elements が Polymer のコンポーネントとして提供されていましたが、分類も新たにレパートリーが拡充されています。 Cart に入れて Download カタログには各コンポーネントのドキュメントやデモが載っていて、使いたいものをチェックして Cart に入れていきます。必要なコンポーネントを Cart に入れてダウンロードさせると
JSX と TypeScript の混合 Flux または悪魔合体
JSX + TypeScript の悪魔合体 ギョーム的に気持ちになったので JSX + TypeScript をはじめました。 導入にあたってチーム内への説明を兼ねたブログ。AltJSに対して ES でいいじゃん派ですが、自分の型需要に対して 現状の Flowtype が辛みしかないのでやむをえず。 動機 紆余曲折あって結局 React を使うことにした React Component には JSX with Babel を使いたい（手書きは無理だ） UI 以外のロジックを持ったモジュールは型の恩恵に預かりたい Flowtype つらい TypeScript かー UI 周りは JSX で、その他の堅いロジックは TypeScript で書けばいいのでは？ 共存だ！！ メリットがあるのかも不明瞭ですが、分からないからこそ試してみようという感じです。JSX と TypeScript の境界
Web Components(+Virtual DOM)ラッパー書いてみた
Concept 『Web Components with Virtual DOM』 ahomu/Claylump Motivation Web Components ラッパーを書いてみたいなーと思った React の JSX がイマイチ気にくわない（JSとHTMLを一緒にするなオジサン） <template> に書いた内容を Virtual DOM 生成器に変換すればいいんじゃね というような所から人様のライブラリを借りてツギハギして習作してみた次第。借りてきたライブラリ（HTML String パーサと Virtual DOM）は独自実装しても楽しそうなので、やる気があればやる。 もちろん実験品なので、実用には耐えない Files claylump.polyfill.js（webcomponents.js + window.fetch + es6promise） claylump.run
Pixateでアプリのインタラクションモックアップが捗りそう
インタラクションのモックアップ ネイティブアプリを作っていて、いわゆるインタラクション・アニメーションの部分をモックアップできるツールの必要性を感じたので @hiloki さんに聞いたツールをいくつか試してみました。 The Next Generation of Mobile Interaction Design | Pixate Justinmind: Interactive wireframes for web and mobile Briefs 昔ながらに Flash を使うという選択肢もあった気はしますがせっかくなので、そういう用途に特化したツールを探したかった次第。（メンバーに Flash 使えるひとがいなかったという事情もある） Pixateがよかった The Next Generation of Mobile Interaction Design | Pixate 結果、一番
Polymer v0.8.0 Preview 所感
Improvement Polymer の Twitter アカウントが気になる発言をしていたので、Polymer のアップデート内容を確認した。 Next major version of Polymer: 5 x faster in Chrome, 8 x faster in Safari. Up to 87% smaller (15KB, 6KB gzipped) pic.twitter.com/SBJhuxIxXd — Polymer (@polymer) November 19, 2014 Chrome と Safari における実行速度の高速化はもちろんわかるが、ファイルサイズが 87% 減というのはかなり大きい。v0.5.1 の polymer.min.js が 123KB なのに対して、新しい v0.8.0 では 15KB になっているということだ。 それなりに大きい取捨選
npm とフロントエンドのパッケージ管理の未来
JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも
picture要素の関連仕様って今どうなってるんだっけ？を調べたメモ
<picture> どうなった 勤め先がモバイルに注力していたこともあり、レスポンシブもへったくれもない世界を生きてきた。そのせいで、その類の情報にかなり疎くなっていたので、現状を軽く調査してみた次第。 HTMLでの画像リソース読み込み分岐の必要性 CSS には Media Queries があるので、Viewport の width であったりデバイスのピクセル密度であったりを条件にして background プロパティの指定をすれば対応できる。 反面、<img> 要素と src 属性にはそのような仕組みがないため、Media Queries で可能な条件で同じようにやろうと思うと、JavaScript で DOMContentLoaded のあとに"頑張って"操作するか、バックエンドで UserAgent に応じて"賢く"返す仕組みを用意しなければならない。 WebP のような画像形式
Concatだけでビルドを済ませてた例（Backbone.jsとAngularJS）
Concatでどこまで戦えるのか @jxck_ browserify使ってるんだけどあんま意味ない感じになっててつらいんだよねーっていうのを昨日 @ahomu に話したら、concatで全然いけますよって言われたからさっき乗り換えた。 — Kazuhito Hokamura (@hokaccha) August 6, 2014 (＾ω＾) 全然いけますよ 依存管理をサボってconcat 以下、「依存管理に労力を割きたくない」という理由で依存管理を省略した場合に、concatだけで破綻無くビルドするためにやっていたパターンの紹介。いけますと言った手前はあるが、最終的には現場によってケースバイケースということで、どうかひとつご容赦願いたい。 Case 1: Backbone.js Backbone.jsの場合、extends に代表されるクラスベースのオブジェクト指向モデルに多少の制約が必要に
Polymer と Web Components の違い9選（もとい Polymer の便利機能）
違い、または付加機能 色々な周辺事情で、勢力を広げつつある Polymer さん。（つい最近、それに加担したような気もする） 「どこまでが Web Components で、どこからが Polymer なのか」を理解するためにもPolymerの機能をメモる。Polymer は色々なことを便利にしてくれるライブラリであり、差分を言い出すとキリがないので主要なポイントだけ。 <template> が自動で Shadow DOM に放り込まれる Shadow DOM内の <link> をインラインの <style> に展開 repeat のサポート {{interpolate}} のサポート <element> のかわりを <polymer-element> としてサポート on-click とかイベントハンドラの宣言 this.$ による idが付加された要素のコレクション observe に
Web Components を支えるPolyfillライブラリ
Hello 生成されるJSそのものはピュアな感じなので、たしかにbosonicを捨ててもWeb Componentsとして成り立ちそうではある。 瑣末だが、この記事を書いてる時点で試したらWeb Platform featuresのフラグをEnableにしたCanaryで、bosonic-pollyfillsがエラー吐いてる... 余談、実はえらいかも Polymerコンポーネントって、結局Polymer入れないと使えないなら、BackboneJSで使えないAngularディレクティブみたいなもんな気がしてきた。Bosonicのコンセプト、実は偉いかも。（出来る範囲は制限されるかもしれないけど） — あほむバーガー (@ahomu) June 30, 2014 結論 個人的にはふつうのPolyfillとして動いてくれるものを精査したかったのだけど、結果的に Polymer/platform
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
