Re: Minimum viable custom elements

Anne wrote:

> but do you see a viable way to get there?
>

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

To recap

What is= provides:
A way for developers take advantage of the built in roles,states and
properties of existing HTML elements without having to add ARIA to reflect
the acc properties and scripting to emulate behaviours (see what ARIA does
not do <http://www.paciellogroup.com/blog/2014/08/what-aria-does-not-do/>)
For example. putting aria-disabled=true on a button does not make the
element disabled like the ‘disabled’ attribute does (removes from tab order
etc), it just sets the disabled state flag in accessibility APIs.

So being able to do:
<button is=”my-super-button”>
means that devs can take advantage of built-in focus and keyboard handling
and built in states and properties (all of which have acc built-in where
needed) -

for example button related attributes.

autofocus - Automatically focus the form control when the page is loaded
disabled - Whether the form control is disabled
form - Associates the control with a form element
formaction - URL to use for form submission
formenctype - Form data set encoding type to use for form submission
formmethod - HTTP method to use for form submission
formnovalidate - Bypass form control validation for form submission
formtarget - Browsing context for form submission
menu - Specifies the element's designated pop-up menu
name - Name of form control to use for form submission and in the
form.elements API
type - Type of button
value - Value to be used for form submission

I think being able to extend existing elements has potential value to
developers far beyond accessibility (it just so happens that  accessibility
is helped a lot by re-use of existing HTML features.)

I am not married to the is= method, but am very concerned that custom
elements without some useful method to leverage existing HTML features will
make the accessibility support story for this new technology bleak and as
much as I love ARIA it is accessibility that must be bolted on by the
developer which is unfortunately prone to error and often left off.


--

Regards

SteveF


On 16 January 2015 at 16:52, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, Jan 16, 2015 at 5:45 PM, Steve Faulkner
> <faulkner.steve@gmail.com> wrote:
> > I have not suggested is= as the method that must be implemented (I have
> not
> > demanded anything), what I have tried to suggest is that minimum viable
> > custom elements with all accessibility as bolt-on is a poor solution by
> > design.  From an acc view it means custom elements are nothing more than
> > <div>s with fancy names.
>
> Sure, I hope everyone understands that,



> Again, I think that unless we solve the styling problem for
> native elements, we're not going to see them adopted, not even if you
> can subclass them (and proper subclassing without the is="" hack is
> another hard problem, as explained).
>
>
> --
> https://annevankesteren.nl/
>