W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Minimum viable custom elements

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Fri, 16 Jan 2015 10:25:17 +0000
Message-ID: <CA+ri+Vnycn0xE0dZU5cKEbW0bi=jKqg_wrS1u95ajX7j0dZkRg@mail.gmail.com>
To: "Edward O'Connor" <eoconnor@apple.com>
Cc: WebApps WG <public-webapps@w3.org>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC