Web Componentsのアクセシビリティ
•Download as PPTX, PDF•
22 likes•11,449 views
2015年1月25日に開催された「HTML5 Conference」での講演「Web Componentsのアクセシビリティ」で使用した資料です。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Web Componentsのアクセシビリティ
Similar to Web Componentsのアクセシビリティ (20)
More from Mitsue-Links Co.,Ltd. Accessibility Department
More from Mitsue-Links Co.,Ltd. Accessibility Department (17)
Web Componentsのアクセシビリティ
- 16. Web Componentsとアクセシビリ ティ コンポーネント…機能や意味を切り出し • 制作者はユーザーに提供したい情報を知っている • ユーザーにきちんと伝えることが重要 16
- 19. Web Componentsでは… コンポーネントのアクセシビリティが重要 • アクセシビリティの高いコンポーネントを選ぶ • アクセシビリティの高いコンポーネントを作る 19
- 29. Custom Elementsとは 既存要素の拡張 • <button is="xxx-yyy"></button> • document.createElement("button", "xxx-yyy"); 独自要素の定義 • <xxx-yyy></xxx-yyy> • document.createElement("xxx-yyy"); 29
- 30. Custom Elementsでセマンティクス を指定 既存要素の拡張 • 既存要素のセマンティクスを継承 独自要素の定義 • Shadow DOM 30
- 32. 例：Google ChromeのDeveloper Tools <button is="text-button"> • セマンティクスはbutton要素のまま 32
- 35. Shadow DOMとは ページのDOMツリーとは切り離された 要素独自のDOMツリー（Shadow Tree） • element.createShadowRoot(); 35
- 36. Shadow DOMの例 36 https://simon.html5.org/presentations/foms-2012/ 動画部分: © Copyright 2006, Blender Foundation / Netherlands Media Art Institute / www.elephantsdream.org
- 39. 39 https://simon.html5.org/presentations/foms-2012/ 動画部分: © Copyright 2006, Blender Foundation / Netherlands Media Art Institute / www.elephantsdream.org Shadow DOMの例
- 44. WAI-ARIAとは WAI: Web Accessibility Initiative • W3C WAIが標準化 ARIA: Accessible Rich Internet Applications • Webアプリケーションをよりアクセシブルに 44
- 45. WAI-ARIAのセマンティクス ロール：role属性 • 要素の種類 • ≒HTMLの要素型 ステート・プロパティ：aria-*属性 • 要素の状態や性質 • ≒HTMLの属性 45
- 46. 例：プログレスバー ロール： • progressbar プロパティ： • aria-valuemin：最小値 • aria-valuemax：最大値 • aria-valuenow：進捗を表す数値 • aria-valuetext：進捗を表すテキスト 46
- 51. 良い例 51
- 52. 良くない例 52
- 53. 良くない例を修正した例 53
- 55. まとめ 55
- 57. Web Componentsのアクセシビリ ティ 本質的にはWeb Componentsを使わない場合 と同じ Custom ElementsやShadow DOMを使用する 際は、セマンティクスをお忘れなく 57
Editor's Notes
- Web Componentsでは、1度書いたコンポーネントが再利用されます。なので、コンポーネントのアクセシビリティが、そのアプリなりサイトなりのアクセシビリティに大きく影響してきます。そう、コンポーネントのアクセシビリティが重要です。この時重要になるのは、アクセシビリティが高い、良いコンポーネントを選ぶこと、もしくは、良いコンポーネントを作ることです。
- Web Componentsでは、1度書いたコンポーネントが再利用されます。なので、コンポーネントのアクセシビリティが、そのアプリなりサイトなりのアクセシビリティに大きく影響してきます。そう、コンポーネントのアクセシビリティが重要です。この時重要になるのは、アクセシビリティが高い、良いコンポーネントを選ぶこと、もしくは、良いコンポーネントを作ることです。
- もう少し噛み砕いてしゃべると もしコンポーネントのアクセシビリティが高ければ コンポーネントを使うだけで一定のアクセシビリティを確保します 一度良いものを作ってしまえば、コンポーネント利用時に頑張る必要がありません。
- ですが、コンポーネントのアクセシビリティが低ければ、使うだけで全体の質が低下します。既にコンポーネントとして出来上がっているので、コンポーネント利用時になんとかしかアクセシビリティを高める、ことも難しいでしょう。
- Web Componentsのアクセシビリティと言っていますが、基本的なアクセシビリティの考え方は変わりません。
- 例えば、GoogleのOsmaniiさんとBoxHallさんが書いているアクセシブルなWeb Componentsという記事を見てみましょう。
- この内容を見ると、キーボードだけでも使えるか、画像などに代替コンテンツが設定されているか、要素のセマンティクスは大丈夫か、であったり、色だけに依存していないか、動いたり点滅したりするものは、止められるか、といった内容が書かれています。 これはWeb Componentsに特化した内容というよりは、一般的なアクセシビリティの内容です。
- このようにアクセシビリティに関して取り組むべき内容がWeb Componentsになったからといって変わるわけではありませんが、取り組む方法、どういう技術をつかってどう実装するか、という点には、Web Componentsなりの特徴がでてきます。 Web Componentsで特に重要なのは、セマンティクスの指定方法です。Web Componentsを使う場合には、自分で作ったコンポーネントのセマンティクス、意味をユーザーにどうやって届ける方法を押さえておく必要があります。
- ここで実際の例を見てみましょう。 これから3つプログレスバーを見ていきます。1つはHTML5のprogress要素をそのまま使った場合、2つ目はPolymerのpaper-progressというコンポーネントを使った場合、3つ目はGaia Componentsのgaia-progressというコンポーネントを使った場合です。
- このように視覚的には、同じ情報を伝えていても、セマンティクス、意味が伝わっているものと伝わっていないものが存在します。 この違いは、どこにあるのでしょう？ そして、どうすれば、良い例のように、Webb Componentsでもセマンティクスを伝えることができるでしょうか。
- Web Componentsでセマンティクスを指定する場合には、次の2つの技術が鍵になります。 Custom ElementsとShadow DOMです
- Custom Elements、これですね。W3Cで標準化が進んでおり、Editor’s DraftはGitHubで公開されています。
- このCustom Elementsでは、既存要素を拡張したり、独自要素を定義したりすることができます。どちらもregisterElementを使って、カスタムな要素を登録すると、その登録した要素がHTMLやDOMで使えます。拡張した名前、スライドではxxx-yyyになっていますが、-を1回以上含む必要があります（今のところ）。
- そして、この新しく作ったカスタムな要素にセマンティクスをどのように与えるか、ということですが、これは既存要素を拡張した場合いと、自分で新しく要素を定義し場合で異なります。 既存要素を拡張した場合には、拡張した要素は、拡張元である既存の要素からセマンティクスを継承します。 要素を自分で独自に定義する場合には、基本的にはShadow DOMを使うことになるでしょう。 ではそれぞれを見ていきましょう。 メモ：Custom Elementsの仕様にはCustom Elementsに直接WAI-ARIAを指定する方法が載っている
- 既存要素を拡張する場合は、拡張前の要素からセマンティクスが継承されるため、基本的に開発者が何か特別なことを行う必要はありません。 基本的に、と言っているのは、自分で拡張した要素のセマンティクスが拡張元のセマンティクスからかけ離れている場合には、セマンティクスを変更する必要があると思いますが、そういう場合は、ふつう拡張という方法をとらないでしょう。 ともあれ、button要素を拡張すると、button要素のセマンティクスが引き継がれます。なので、ボタンとして使っていれば、セマンティクスの問題は起きません。
- この拡張が使われている例には、Google ChromeのDeveloper Toolsがあります。 Developer Toolsのフロントエンド部分はHTMLとCSSとJavaScriptで書かれていますが、ここでは既存の要素を拡張したコンポーネントも使われています。 たとえば、テキストを含むボタンは<button is=“text-button”>、とbutton要素を拡張したものが使われています。 この要素のボタンとしてのセマンティクスは、支援技術に伝わっています。
- このように要素を拡張する場合は比較的簡単でしたが、自分で要素を定義する場合は、もう少し複雑です。 独自要素を定義する場合、ほとんどの場合はShadow DOMを使うと思います。
- Shadow DOMもW3Cによって標準化が進んでいますね。スライドにはWorking Draftのスクリーンショットを出していますが、こちらもGitHubでEditor’s Draftがでています。
- Shadow DOMとは、ページのDOMツリーから切り離された、要素独自のDOMツリーを定義するための技術です。
- このShadow DOMはブラウザーの中でも使われています。例えばGoogle ChromeやSafariのvideo要素のコントロールがShadow DOMを使って実装されているのは、良くしられています。 HTMLにはvideo要素しか記述されていなくても、ブラウザーは再生ボタンや時間のスライダーなどのUI部品や、キャプションを表示するための領域などを用意しなくてはなりません。ChromeやSafariではこれらはShadow DOMとして実装されています。
- Shadow DOMは
- このShadow DOMはブラウザーの中でも使われています。例えばGoogle ChromeやSafariのvideo要素のコントロールがShadow DOMを使って実装されているのは、良くしられています。 HTMLにはvideo要素しか記述されていなくても、ブラウザーは再生ボタンや時間のスライダーなどのUI部品や、キャプションを表示するための領域などを用意しなくてはなりません。ChromeやSafariではこれらはShadow DOMとして実装されています。
- 適切な要素を使える場合、例えばプログレスバーならばprogress要素を使えれば、そうしてください。そうすればブラウザーは適切なセマンティクスをユーザーに届けるでしょう。 プログレスバーの例で、実際にprogress要素を使うことはないと思いますが、例えば、見出しであったりリストであるならば、全部divとspanだけではなく、見出しやリストの要素を使う、という意味です。
- 実際には、さまざまな制約で適切な要素が使えない、ということもあると思います。 その場合は、WAI-ARIAを使ってセマンティクスを補うことを考えてみましょう
- WAI-ARIAもW3Cの仕様で、Editor’s DraftはGitHubで…