- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Fri, 16 Jan 2015 10:25:17 +0000
- To: "Edward O'Connor" <eoconnor@apple.com>
- Cc: WebApps WG <public-webapps@w3.org>
- Message-ID: <CA+ri+Vnycn0xE0dZU5cKEbW0bi=jKqg_wrS1u95ajX7j0dZkRg@mail.gmail.com>
hi ted, I think others have responded to your question, but wanted to chip in. I agree that for non interactive elements the usefulness of type extensions is limited, but not useless. For example: An experiment subclassing footer [5] and one implementing the HTML5 outline algorithm [6] There has been a popular mantra in regards to web accessibility support and the benefits of native HTML "built in is better than bolt on" See the First rule of ARIA [1] With custom tags everything must be bolted on, with type extensions this is not the case. In order to make custom interactive elements accessible and usable by people with disabilities, there are a lot of hoops developers must jump through. [3] I think reducing this burden on the developer is a worthwhile technical design consideration for Custom Element implementation in browsers. See the Custom Elements Semantics section of the Custom Elements spec [2] and the recent article by Bruce Lawson 'On the accessibility of web components. Again'. [4] which includes a link to an example of a input type radio type extension [7]. Another example is a disclosure button type extension [8]. It may be that it is too hard to implement type extensions (i freely admit much of the discussion on this thread is over my head), but I do not think that it should be dismissed out of hand or that the consideration should characterised as "longdesc mark II" ;-) [1] http://w3c.github.io/aria-in-html/#first-rule-of-aria-use [2] http://w3c.github.io/webcomponents/spec/custom/#semantics [3] http://w3c.github.io/aria-in-html/#custom-control-accessible-development-checklist [4] http://www.brucelawson.co.uk/2014/on-the-accessibility-of-web-components-again/ [5] https://github.com/ThePacielloGroup/w3c-footnote [6] http://thepaciellogroup.github.io/html5-h/demo-fallback.html [7] https://rawgit.com/alice/web-components-demos/master/index.html [8] https://github.com/ThePacielloGroup/disclosure-button -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 15 January 2015 at 23:33, Edward O'Connor <eoconnor@apple.com> wrote: > Hi all, > > Steve wrote: > > >> [I]t also does not address subclassing normal elements. Again, while > >> that seems desirable > > > > Given that subclassing normal elements is the easiest and most robust > > method (for developers) of implementing semantics[1] and interaction > > support necessary for accessibility I would suggest it is undesirable > > to punt on it. > > Apologies in advance, Steve, if I'm missing something obvious. I > probably am. > > I've been writing an article about turtles and I've gotten to the point > that six levels of headings aren't enough. I want to use a seventh-level > heading element in this article, but HTML only has h1–6. Currently, > without custom elements, I can do this: > > <div role=heading aria-level=7>Cuora amboinensis, the southeast Asian box > turtle</div> > > Suppose instead that TedHaitchSeven is a subclass of HTMLElement and > I've registered it as <ted-h7>. In its constructor or createdCallback or > whatever, I add appropriate role and aria-level attributes. Now I can > write this: > > <ted-h7>Cuora amboinensis, the southeast Asian box turtle</ted-h7> > > This is just as accessible as the <div> was, but is considerably more > straightforward to use. So yay custom elements! > > If I wanted to use is="" to do this, I guess I could write: > > <h1 is=ted-h7>Cuora amboinensis, the southeast Asian box turtle</h1> > > How is this easier? How is this more robust? > > I think maybe you could say this is more robust (if not easier) because, > in a browser with JavaScript disabled, AT would see an <h1>. <h1> is at > least a heading, if not one of the right level. But in such a browser > the <div> example above is even better, because AT would see both that > the element is a heading and it would also see the correct level. > > OK, so let's work around the wrong-heading-level-when-JS-is-disabled > problem by explicitly overriding <h1>'s implicit heading level: > > <h1 is=ted-h7 aria-level=7>Cuora amboinensis, the southeast Asian box > turtle</h1> > > I guess this is OK, but seeing aria-level=7 on and <h1> rubs me the > wrong way even if it's not technically wrong, and I don't see how this > is easier or more robust than the other options. > > > Thanks, > Ted > >
Received on Friday, 16 January 2015 10:26:25 UTC