Re: Minimum viable custom elements

I am not championing is= as the answer to all the worlds ills, but it does
provide *examples* of built in features that I believe are critical to
robust accessibility support in web components:

which are:
roles/state and property mapping from existing attributes (disabled,
required etc)
platform/browser standard interaction behaviours (keyboard etc)
ability to provide an accessible name, and <label> elements (that are
labelable) using standard HTML

In this radio and checkbox example (view in chrome)
https://rawgit.com/alice/web-components-demos/master/index.html
(which has been referenced several times in this thread, but no one has
critiqued to my knowledge) all of the above are evident, while at the same
time appearing to overcome the issue of standard control fugliness

If there are better ways to achieve the built in features which support
robust accessibility I am all for it. ,

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>

On 29 January 2015 at 19:48, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> On Jan 29, 2015, at 7:52 AM, Steve Faulkner <faulkner.steve@gmail.com>
> wrote:
> On 29 January 2015 at 15:37, Anne van Kesteren <annevk@annevk.nl> wrote:
>
>  I don't have enough technical understanding to know what is viable or not,
>>>  you and others are saying that the current accessibility feature support
>>> baked in to custom elements spec via is= is not acceptable
>>>
>>> That seems rather disingenuous.
>>
>
> where am I being disingenuous?
>
> I don't understand how the various pieces are pulled together to make an
> element work in browsers to an extent to be able to offer possible
> technical solutions. If I did I would.
>
>
> I think there is a bit of miscommunication here.
>
> Correct me if I'm wrong but I think you're trying to fix the problem of
> Web developers writing their own UI widgets and components and they're
> often inaccessible because they didn't set ARIA roles right, etc…
>
> If that's the problem you're trying to solve here, then what you need is
> shadow DOM, not custom elements.  As someone who cares about accessibility
> deeply, I want to solve this problem too.  However, like Anne pointed out
> in earlier threads, authors aren't going to start using custom elements to
> implement those fancy UI widgets currently implemented via div's and span's
> using is=~ attribute since custom elements doesn't provide any mechanism to
> change the appearance of a builtin element.  Shadow DOM, on the other hand,
> is one proposed mechanism to replace the appearance of a builtin element by
> way of replacing the contents of the element via a shadow tree.  Now, if
> we're using shadow DOM to change the appearance of a builtin element, then
> choosing which appearance to use in the HTML markup via a content attribute
> is a layering violation.  We should be doing that in CSS instead.  And we
> have a proposal to do both of these things: decorators [1]
>
> One more thing.  I would really like if we could stop making claims such
> as web components as currently spec'ed magically improves accessibility
> because it's doing a huge disservice to the future of the Web
> accessibility.  They don't.  Far from it.  I've pointed out numerous issues
> with them over the last couple of years but none of them have been
> adequately addressed.
>
> [1]
> https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html#decorator-section
>
> - R. Niwa
>
>