From 53622ac22da547cee0f7ea2e1948bd2cc08c2cb4 Mon Sep 17 00:00:00 2001 From: Alice Date: Sat, 13 Jun 2015 10:28:29 -0700 Subject: [PATCH 1/2] Flesh out Accessibility benefits section --- proposals/Type-Extensions.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/proposals/Type-Extensions.md b/proposals/Type-Extensions.md index 9d75e3e7..4cd426ce 100644 --- a/proposals/Type-Extensions.md +++ b/proposals/Type-Extensions.md @@ -8,7 +8,23 @@ This document explores the pros and cons of various options for instantiating a #### Accessibility -* Using a type extension means - in most cases - that you get the semantics of the extended element without doing any extra work. This is discussed in detail [in the spec](http://w3c.github.io/webcomponents/spec/custom/#semantics). +* **Implicit semantics** - Using a type extension means - in most cases - that you get the semantics of the extended element without doing any extra work. This is discussed in detail [in the spec](http://w3c.github.io/webcomponents/spec/custom/#semantics). +* **Non-ARIA semantics** - There are semantics which currently can't be expressed using ARIA, such as a _paragraph_ role. +* **Focusability** - For interactive widgets, type extended elements inherit the native element's focusability without needing to add a `tabindex` attribute. (Note: there is (ongoing work)[https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?pli=1] to add this behaviour as a primitive.) +* **Keyboard events** - If not adding a shadow root, you also get the native keyboard event handling +* **Platform-specific presentation** - If not adding a shadow root, you can access platform-specific presentation such as the varying appearance of ``. + +##### Accessibility nuances + +There are several nuances to the accessibility argument which should be kept in mind when discussing pros and cons from an accessibility point of view. + +* **Primitives vs UI patterns** - Type extensions may help to solve two related but distinct problems in accessibility, which should be considered separately: + * Access to semantics currently only available to native elements. Over time, we _should_ develop alternative mechanisms for expressing the full range of semantics available to the web platform and to the assistive technology APIs; however, these mechanisms may take an arbitrarily long time to be realised. + * Inheritance of the full complement of accessibility-related attributes and behaviours built in to a native element. The main issue we see with accessibility on the web today is that even when the necessary primitives _are_ available (ARIA attributes, JavaScript keyboard event handling, etc.), developers don't use them. From an accessibility standpoint, our best advice is to use native elements where possible, since this represents the minimal amount of work to get the most robust accessibility. In the case of Web Components, the analogous advice should be to extend a native element. +* **Replaced shadow root behaviour** - When the native shadow root is replaced, some of the built-in accessibility and behaviour is lost. This is particularly true for composite semantic roles (see below). +* **Stand-alone vs composite semantic roles** - (Note: the term 'roles' here applies equally to any semantic role which an element may fill, regardless of whether specified as an ARIA attribute or implicit) + * Some [widget roles](http://www.w3.org/TR/wai-aria/roles#widget_roles), such as `button`, are _stand-alone roles_, meaning that it suffices to add that role to a single element, and then its descendant content is used largely for text alternative computation. These atomic roles represent the 'best case' for inheriting semantics from a native element. + * Other roles, such as `listbox`, are _composite roles_, meaning that there may be several interactive elements within the element with that role. `` is a very special case of a composite role, since it doesn't have a pre-defined structure for its (browser-provided) descendant content, but always has several interactive elements within it; plus, it is rendered very differently on different platforms. #### Forms behaviour #### Script-supporting element behaviour From 91d0169a95e3e0b0035519f7bb08ff6e54a7952f Mon Sep 17 00:00:00 2001 From: Alice Date: Sat, 13 Jun 2015 10:30:43 -0700 Subject: [PATCH 2/2] Fix typos. --- proposals/Type-Extensions.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/Type-Extensions.md b/proposals/Type-Extensions.md index 4cd426ce..d041928e 100644 --- a/proposals/Type-Extensions.md +++ b/proposals/Type-Extensions.md @@ -10,8 +10,8 @@ This document explores the pros and cons of various options for instantiating a * **Implicit semantics** - Using a type extension means - in most cases - that you get the semantics of the extended element without doing any extra work. This is discussed in detail [in the spec](http://w3c.github.io/webcomponents/spec/custom/#semantics). * **Non-ARIA semantics** - There are semantics which currently can't be expressed using ARIA, such as a _paragraph_ role. -* **Focusability** - For interactive widgets, type extended elements inherit the native element's focusability without needing to add a `tabindex` attribute. (Note: there is (ongoing work)[https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?pli=1] to add this behaviour as a primitive.) -* **Keyboard events** - If not adding a shadow root, you also get the native keyboard event handling +* **Focusability** - For interactive widgets, type extended elements inherit the native element's focusability without needing to add a `tabindex` attribute. (Note: there is [ongoing work](https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?pli=1) to add this behaviour as a primitive.) +* **Keyboard events** - If not adding a shadow root, you also get the native keyboard event handling. * **Platform-specific presentation** - If not adding a shadow root, you can access platform-specific presentation such as the varying appearance of ``. ##### Accessibility nuances