Re: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)

[Steve Faulkner]

aye - (as TPG WG person)

--

Regards

SteveF
Current Standards Work @W3C


On 2 June 2016 at 13:48, Léonie Watson  wrote:

> Hello WP,
>
> This is a call for consensus to request that W3C publish the current HTML
> Working Draft (WD) as a Candidate Recommendation (CR). It has been posted
> to
> public-webapps@w3.org as the official email for this WG.
>
> Please reply to this thread on public-webapps@w3.org  no later than end of
> day on 10 June. Positive responses are preferred and encouraged, silence
> will be considered as assent.
>
> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
> make it more reliable, more readable and understandable, and a better match
> for reality. Substantial changes between HTML5 and HTML5.1 can be found in
> the spec [2].
>
> When a specification moves to CR it triggers a Call For Exclusions, per
> section 4 of the W3C Patent Policy [3]. No substantive additions can be
> made
> to a specification in CR without starting a new Call for Exclusions, so we
> will put HTML5.1 into "feature freeze". It is possible to make editorial
> updates as necessary, and features marked "At Risk" may be removed if found
> not to be interoperable.
>
> The following features are considered "at risk". If we cannot identify at
> least two shipping implementations, they will be marked "at risk" in the CR
> and may be removed from the Proposed Recommendation.
>
> keygen element. [issue 43]
> label as a reassociatable element [issue 109]
> Fixing requestAnimationFrame to 60Hz, not implementation-defined [issues
> 159/375/422]
> registerContentHandler [Issue 233]
> inputmode attribute of the input element [issue 269]
> autofill of form elements [issue 372]
> menu, menuitem and context menus. [issue 373]
> dialog element [issue 427]
> Text tracks exposing in-band metadata best practices [Issue 461]
> datetime and datatime-local states of the input element [Issue 462]
>
> Please share implementation details for any of these features on Github. To
> mark other features "at risk", please identify them by 10th June (ideally
> by
> filing an issue and providing a test case).
>
> At the same time we move HTML5.1 into CR, we plan to continue updating the
> Editor's Draft, and in the next few weeks we expect to post a Call for
> Consensus to publish it as the First Public Working Draft of HTML5.2, so
> improving HTML will continue without a pause. It also means that changes
> that didn't make it into
> HTML5.1 will not have long to wait before being incorporated into the
> specification.
>
> Léonie on behalf of the WP chairs and team, and HTML editors.
> [1] https://www.w3.org/TR/html51/
> [2] https://www.w3.org/TR/html51/changes.html#changes
> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
>
> [issue 43] https://github.com/w3c/html/issues/43
> [issue 109] https://github.com/w3c/html/issues/109
> [issues 159/375/422] https://github.com/w3c/html/issues/159 and links
> [issue
> 233] https://github.com/w3c/html/issues/233
> [issue 269] https://github.com/w3c/html/issues/269
> [issue 372] https://github.com/w3c/html/issues/372
> [issue 373] https://github.com/w3c/html/issues/373
> [issue 427] https://github.com/w3c/html/issues/427
> [Issue 461] https://github.com/w3c/html/issues/461
> [Issue 462] https://github.com/w3c/html/issues/462
>
>
> --
> @LeonieWatson tink.uk Carpe diem
>
>
>
>
>

Re: Notes from the future of HTML session at TPAC

[Steve Faulkner]

As I couldn't be there and have some interest in the outcome I wrote down
my thoughts:
Thoughts on “Notes from the future of HTML session at TPAC”
https://medium.com/@stevefaulkner/thoughts-on-notes-from-the-future-of-html-session-at-tpac-1c2f6f204cea#.vx45e5aeo

--

Regards

SteveF
Current Standards Work @W3C


On 28 October 2015 at 08:46, Léonie Watson 
wrote:

> Thanks to everyone for a useful and informative discussion. Minutes
> available from the following palces:
>
> Web:
> http://www.w3.org/2015/10/28-html-minutes.html
>
> Text:
> http://www.w3.org/2015/10/28-html-minutes.html,text
> Léonie
>
> --
> Senior accessibility engineer @PacielloGroup @LeonieWatson
>
>
>
>

Re: Reminder regarding normative references

[Steve Faulkner]

On 7 October 2015 at 08:15, Mike West  wrote:

> As a concrete example, I'm going to send a transition request for Secure
> Contexts shortly. It uses the "creation URL" concept which was recently
> added to WHATWG's HTML (
> https://html.spec.whatwg.org/multipage/webappapis.html#creation-url).
> That concept is not present in the W3C's HTML (nor is it clear to me how to
> get it added :) ). How do you suggest that we proceed?
>

hi mike, i think you will find your example is in the W3C HTML 5.1:

http://www.w3.org/TR/html51/webappapis.html#creation-url

not saying there aren't other examples that would be concrete.

--

Regards

SteveF
Current Standards Work @W3C

Re: Making ARIA and native HTML play better together

[Steve Faulkner]

On 9 May 2015 at 22:22, Alice Boxhall  wrote:

> However, I'm on the fence about whether this proposal is the way forward
> for that problem. On the one hand, many developers (including me) have an
> expectation when they first encounter ARIA that it will magically affect
> behaviour, so it seems like a good "path of desire" to go ahead and fulfill
> that expectation.


Hi Alice, I would not go so far as to call it a proposal ;-) it is just a
few ideas , mostly not thought out at this stage and definitley not to be
taken as a package.

I think idea 1 has the potential to be implemented without being overly
burdensome, so forgetting about the ideas for the moment:

1. When a role is used that matches the default implicit semantics of
> labelable HTML elements [1] use of the label element will result in the
> same behaviour as the native element and a .
> Example:
>
>  i
> like this idea
>
>
What this would entail (i think ) is the addition of a defined set of roles
to the labelable elements list [1]. So when an element with one of the
defined roles is associated with a lable using the for attribute or as a
child of label, the behaviour matches that currently defined in HTML

The label element's exact default presentation and behaviour, in particular
> what its activation behaviour might be, if anything, should match the
> platform's label behaviour. The activation behaviour of a label element
> for events targeted at interactive content descendants of a label
> element, and any descendants of those interactive content descendants, must
> be to do nothing. [2]
>

labelable elements that have default implict ARIA semantics [3]

input type=checkbox - role=checkbox
input type=radio -  role=radio
input type=text - role=textbox
input type=number - role=spinbox
textarea - role=textbox
progress - role=progressbar
select - role=listbox or combobox

So the suggested implementation would be that where a role is used that
matches one in the list above, the association of a label element would
result in the same behaviour as it does for the corresponding HTML element
both interaction behaviour and accessble name association [4].


[1] http://www.w3.org/TR/html51/semantics.html#category-label
[2] http://www.w3.org/TR/html51/semantics.html#labeled-control
[3]
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#html-element-role-mappings
[4]
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#accessible-name-and-description-calculation
--

Regards

SteveF

Re: Making ARIA and native HTML play better together

[Steve Faulkner]

On 7 May 2015 at 07:53, Bruce Lawson  wrote:

> this makes sense, but (unless I'm inventing nonsense because I'm mad,
> which is definitely possible), doesn't this describe the current
> behaviour in many UAs anyway?
>

Currently ARIA does not do this stuff AFAIK. There is some limited keyboard
behaviour mapping for role=button in a few AT's.

--

Regards

SteveF
HTML 5.1 

Fwd: Making ARIA and native HTML play better together

[Steve Faulkner]

Forwarding on as this relates to custom elements which use ARIA to provide
semantics
--

Regards

SteveF


-- Forwarded message --
From: Steve Faulkner 
Date: 7 May 2015 at 06:42
Subject: Making ARIA and native HTML play better together
To: HTMLWG WG 
Cc: Chaals from Yandex , Léonie Watson <
lwat...@paciellogroup.com>, Richard Schwerdtfeger ,
Alice Boxhall 


On another thread recent thread, leonie and chaals [3] talked about adding
behaviours to ARIA. Here are a few ideas:

1. When a role is used that matches the default implicit semantics of
labelable HTML elements [1] use of the label element will result in the
same behaviour as the native element and a .
Example:

 i
like this idea

User able to click on label to check/uncheck

2. roles that match the default implicit semantics of interactive elements
are focusable (without need to explicitly set tabindex)

Example:
press me

will be included in the focus order.

3. roles that match the default implicit semantics of interactive elements
[2] inherit the interaction behaviour of the native elements
example:

press me
can be activated the same way a html  element can be:.
via space, enter ,click , touch or whatever.

Why? reduce manual labour of web devs. provide more consistent cross
browser behaviours for custom UI. Make custom UI more robust out of the box.

Review at your leisure, respond at will.

[1] http://www.w3.org/TR/html51/semantics.html#category-label
[2] http://www.w3.org/TR/html51/dom.html#interactive-content-2
[3]
https://lists.w3.org/Archives/Public/public-html/2015May/thread.html#msg0
--

Regards

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

Re: Custom Elements: is=""

[Steve Faulkner]

On 6 May 2015 at 14:25, Anne van Kesteren  wrote:

> I think we reached rough consensus at the Extensible Web Summit that
> is="" does not do much, even for accessibility.
>

I agree on one level, it does not do a lot for accessibility because the
issue of styling native elements still remains. I don't quite understand
how sub-classing does not help accessibility, when in the cases of simple
controls that have added custom features, re-using a button or a checkbox
etc rather than buidling it from scratch appears to be useful for
accessibility and other reasons.

note: this is not an argument for is= :-)
--

Regards

SteveF
HTML 5.1 

Re: Minimum viable custom elements

[Steve Faulkner]

On 12 February 2015 at 10:58, Anne van Kesteren  wrote:

> which is a very different problem from what you want to solve, no?


The problem I think needs solving for minimum viable custom elements is
reducing reliance on bolt-on accessibility. From the example provided
http://janmiksovsky.github.io/base-template/ it appears that in this
instance it does achieve that end.

I don't know whether this will extend to other UI controls or whether it is
a practical solution, which is why I brought it to the list for discussion.

--

Regards

SteveF
HTML 5.1 

Re: Minimum viable custom elements

[Steve Faulkner]

this turned up today:
A possible solution for web component subclasses
https://github.com/JanMiksovsky/base-template#a-possible-solution-for-web-component-subclasses

needs people who actually understand this stuff to critique ;-)

--

Regards

SteveF
HTML 5.1 

On 14 January 2015 at 14:45, Anne van Kesteren  wrote:

> I've been trying to think of the smallest setup that adds value, can
> get broad agreement, and is therefore hopefully interoperable fast.
>
> * ES6-style class syntax to declare the imperative constructor.
> * No subclassing of normal elements for now.
> * registerElement() to enable declarative syntax and createElement().
> * Parsing of declarative syntax invokes the registered constructor
> synchronously.
> * Existing lifecycle callbacks plus those agreed (copying, adopting).
>
> Notably this does not address upgrading. I think we can defer
> upgrading as it can be implemented in script fairly easily. You await
> for the imperative constructors to load and DOMContentLoaded at which
> point you traverse the tree and invoke replace() on those elements you
> want to upgrade. Ideally at some point we find a declarative solution
> for this, perhaps something like "HTML modules", but shipping a v1 of
> custom elements in multiple browsers should not have to wait for that.
>
> It also does not address subclassing normal elements. Again, while
> that seems desirable the current ideas are not attractive long term
> solutions. Punting on it in order to ship a v1 available everywhere
> seems preferable.
>
>
> --
> https://annevankesteren.nl/
>
>

Re: Minimum viable custom elements

[Steve Faulkner]

On 4 February 2015 at 19:05, Alice Boxhall  wrote:

> So then how do we treat it as "fallback content" i.e. un-rendered, while
> allowing it to be accessible to to the AT layer?


I suggest as in the working canvas example i provided, it not only be
exposed AT but also to keyboard interaction, and that the content inside
can be targeted for relationships such as





sign up


--

Regards

SteveF
HTML 5.1 

Re: Minimum viable custom elements

[Steve Faulkner]

On 4 February 2015 at 16:51, Ryosuke Niwa  wrote:

> 
>

I think if this worked. i.e. hid the styling and allowed styling over top,
while allowing access to the input functionality would be a good solution
for the many many instances of native controls being remade as custom
controls simply to be able to control style.

I made a simple example of using  to host a checkbox, as an
experiment:
http://codepen.io/stevef/pen/OPxvZX

note: am not saying  is a solution, like is= it provides the
ability to make use of built in features of native controls. which is the
outcome I would like to see baked into web components.
--

Regards

SteveF
HTML 5.1 

Re: Minimum viable custom elements

[Steve Faulkner]

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  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  wrote:

>
> On Jan 29, 2015, at 7:52 AM, Steve Faulkner 
> wrote:
> On 29 January 2015 at 15:37, Anne van Kesteren  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
>
>

Re: Minimum viable custom elements

[Steve Faulkner]

>
>  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.


--

Regards

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

On 29 January 2015 at 15:37, Anne van Kesteren  wrote:

> On Thu, Jan 29, 2015 at 3:54 PM, Steve Faulkner
>  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. I have said these things:
>
> 1) Compared to  the is="" construct is a hack that is
> unlikely to be attractive to those building libraries. Existing
> libraries seem to support this.
>
> 2) As long as the styling problem for form controls remains unsolved,
> making some form of automatic prototype mutation work for them is not
> going to get them adoption.
>
> Others have already explained how turning 1) around is hard as
> browsers, specifications, and stylesheets branch on local name rather
> than instance checks. 2) is even harder and has always been the real
> problem.
>
>
> --
> https://annevankesteren.nl/
>

Re: Minimum viable custom elements

[Steve Faulkner]

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:

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  wrote:

> On Fri, Jan 16, 2015 at 5:45 PM, Steve Faulkner
>  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
> > 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/
>

Re: Minimum viable custom elements

[Steve Faulkner]

On 16 January 2015 at 16:52, Anne van Kesteren  wrote:

>  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).
>

The demo i pointed to previously by Alice Boxhall from Google appears to
overcome the styling of checkboxes/radio buttons issue
https://rawgit.com/alice/web-components-demos/master/index.html  (view in
chrome)

but do you see a viable way to get there?


I don't have the technical understanding to see any way of getting there
;-)
--

Regards

SteveF
HTML 5.1 

Re: Minimum viable custom elements

[Steve Faulkner]

Hi Anne,

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
s with fancy names.



--

Regards

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

On 16 January 2015 at 13:16, Anne van Kesteren  wrote:

> On Fri, Jan 16, 2015 at 11:25 AM, Steve Faulkner
>  wrote:
> > With custom tags everything must be bolted on, with type extensions this
> is
> > not the case.
>
> I don't disagree with this, but is="" solves none of the problems of
> why developers moved away from native elements in the first place. As
> long as styling native form controls is a problem, is="" is not going
> to help us. In other words, is="" is not what is going to make Gmail
> stop its  abuse to mean . is="" solves none of the
> problems for which ARIA was invented as a workaround.
>
> Furthermore, is="" has considerably worse developer ergonomics
> compared to custom elements making it unlikely to be used much.
>
>
> > 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" ;-)
>
> is="" is not that hard. What is hard is making subclassing native
> elements work with good developer ergonomics. Making the markup of a
> subclass of HTMLButtonElement just as elegant as a subclass of
> HTMLElement is.
>
>
> --
> https://annevankesteren.nl/
>

Re: Minimum viable custom elements

[Steve Faulkner]

On 16 January 2015 at 10:25, Steve Faulkner 
wrote:

> https://rawgit.com/alice/web-components-demos/master/index.html


apologies, this demo needs chrome to illustrate it working well.

--

Regards

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

Re: Minimum viable custom elements

[Steve Faulkner]

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 

On 15 January 2015 at 23:33, Edward O'Connor  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:
>
> Cuora amboinensis, the southeast Asian box
> turtle
>
> Suppose instead that TedHaitchSeven is a subclass of HTMLElement and
> I've registered it as . In its constructor or createdCallback or
> whatever, I add appropriate role and aria-level attributes. Now I can
> write this:
>
> Cuora amboinensis, the southeast Asian box turtle
>
> This is just as accessible as the  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:
>
> Cuora amboinensis, the southeast Asian box turtle
>
> 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 .  is at
> least a heading, if not one of the right level. But in such a browser
> the  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 's implicit heading level:
>
> Cuora amboinensis, the southeast Asian box
> turtle
>
> I guess this is OK, but seeing aria-level=7 on and  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
>
>

Re: Minimum viable custom elements

[Steve Faulkner]

On 14 January 2015 at 14:45, Anne van Kesteren  wrote:

> 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.

[1] http://w3c.github.io/webcomponents/spec/custom/#semantics

--

Regards

SteveF
HTML 5.1 

pull request on custom elements spec

[Steve Faulkner]

Hi Dimitri,

made quite a few tweaks to the custom element semantics section after
feedback.

Appreciate a review of the PR https://github.com/w3c/webcomponents/pull/31

when you get a chance.
--

Regards

SteveF

Re: custom elements without the dash

[Steve Faulkner]

yeah, it was just explained to me by Mike Smith:
"standard custom-elements APIs is that the API doesn’t allow them register
custom elements without a dash"

which I did not know :-)

--

Regards

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

On 5 January 2015 at 14:10, Anne van Kesteren  wrote:

> On Mon, Jan 5, 2015 at 3:03 PM, Steve Faulkner 
> wrote:
> > I understand why, its the zillions of developers out there who don't or
> > don't care, either they are given good reasons not to do it in language
> they
> > understand and is meaningful to them or they ignore requirement and it
> > becomes useless.
>
> If they ignore the requirement they don't get custom elements...
>
>
> --
> https://annevankesteren.nl/
>

Re: custom elements without the dash

[Steve Faulkner]

On 5 January 2015 at 13:59, Jirka Kosek  wrote:

> Since there are no namespaces (in XML sense) in HTML language prefixes
> are used instead as a mechanism to prevent clash with future
> standardized element names.
>

I understand why, its the zillions of developers out there who don't or
don't care, either they are given good reasons not to do it in language
they understand and is meaningful to them or they ignore requirement and it
becomes useless.

--

Regards

SteveF

Re: custom elements without the dash

[Steve Faulkner]

>
> It's already mentioned in that Twitter thread. If somebody created
>  we could then never standardize an element using that name.


Sure, but that's not a possibility that has any immediate effect upon a
developer, as I said I suggest the consequences of doing so need to be
better articulated (in the spec?).

--

Regards

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

On 5 January 2015 at 13:51, Anne van Kesteren  wrote:

> On Mon, Jan 5, 2015 at 2:42 PM, Steve Faulkner 
> wrote:
> > Why force hyphen in custom elements?
>
> It's already mentioned in that Twitter thread. If somebody created
>  we could then never standardize an element using that name.
>
>
> --
> https://annevankesteren.nl/
>

custom elements without the dash

[Steve Faulkner]

brought up on a twitter thread
https://twitter.com/johnslegers/status/552064145399767040

Why force hyphen in custom elements? See alternative approach at http://
mdo.github.io/mdoml/   and https://
github.com/mdo/mdoml/issues/7 … .

NOTE I am not advocating this approach.

There is no apparent downside for a developer if they do


instead of


claimed issues with use of dash:

(1) causes bloat, (2) reduces readability & (3) reduces flexibility

As there is no perceived negative effect for the developer when using non
dash custom elements (other than opprobrium from the  standards overlords)

Suggest the reasons for not doing so need to be better articulated.
--

Regards

SteveF

Re: PSA: publishing new WD of Custom Elements on December 16

[Steve Faulkner]

Hi Art, I don't have any objection to publishing as is.

Would like to note that I have pretty much completed the first draft of the
custom element semantics stuff now
http://stevefaulkner.github.io/webcomponents/spec/custom/#semantics
and have filed a pull request https://github.com/w3c/webcomponents/pull/29
to merge the additions. There is a merge conflict tried to work it out but
my git fu is lacking :-(



--

Regards

SteveF
HTML 5.1 

On 11 December 2014 at 01:10, Arthur Barstow  wrote:
>
> Dimitri prepared a new Working Draft of Custom Elements for publication on
> December 16:
>
>  WD-custom-elements-20141218/>
>
> If anyone has any major concerns about this proposal, please speak up.
>
> -Thanks, AB
>
>

Re: Custom Element Semantics

[Steve Faulkner]

Thanks Alex!
I have made some updates to the spec text in response to your feedback, I
have also added other content.

http://stevefaulkner.github.io/webcomponents/spec/custom/#semantics
please review, thanks!

--

Regards

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

On 9 December 2014 at 17:29, Alexander Surkov 
wrote:
>
> Hi. Some feedback per Steve's request on WAI group.
>
> * "but for the semantics to be formally expressed, developers must convey
> the role, states and properties of the element to browser APIs." It's not
> clear what role, states and properties is. It'd be good to develop this
> sentence by mentioning ARIA techniques. Also it might be not clear what
> browser APIs are. Perhaps I wouldn't even mention a11y APIs since this info
> is rather for browser developers and may sound confusing for web authors.
>
> * I don't think that any focusable element should get its name from its
> subtree. For example, tree control name is not a concatenation of subtrees
> of its item. I think role should define whether the element should grab its
> name from the subtree or not.
>
> Eat Me
>
> * "The addition of a tabindex
> <http://www.w3.org/TR/html/editing.html#attr-tabindex> attribute to the
> *taco-button* element"
>
> I think taco-button should be left for examples, but all rules should be
> worded in generic terms. For example, the sentence above would be "The
> addition of tabindex attribute to the custom element" and then give a
> markup example for taco-button.
>
> * "The addition of keyboard event handlers to the *taco-button* element
> provides the means for keyboard users to operate the control, but does not
> convey the presence of the functionality."
>
> I think I miss the idea of this sentence because the topic is about
> semantics of custom elements and thus it's not clear with me where
> functionality is supposed to be here.
>
> * "The addition of an ARIA role="button"
> <http://rawgit.com/w3c/aria/master/aria/aria.html#button> conveys the
> *taco-button* element's role semantics"
>
> It'd be good to generalize it and give this sentence as an example. It'd
> be good to mention other ARIA button related attributes.
>
> Thanks.
> Alexander.
>
>
> On Tue, Dec 9, 2014 at 4:23 AM, Steve Faulkner 
> wrote:
>
>> Hi PF!
>>
>> FYI
>>
>> I have been getting some accessibility related content into the custom
>> elements spec
>>
>> http://w3c.github.io/webcomponents/spec/custom/#semantics
>>
>> please provide feedback on bug
>> https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=&blocked=14968&short_desc=[Custom]%3A%20&product=WebAppsWG&component=Component%20Model
>>
>> or to webapps list http://lists.w3.org/Archives/Public/public-webapps/
>> --
>>
>> Regards
>>
>> SteveF
>> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>>
>
>

Re: [custom-elements] Re: web developer conformance requirements and advice in custom elements spec

[Steve Faulkner]

On 8 December 2014 at 16:37, Dimitri Glazkov  wrote:

> Totally. Happy to review/accept patches.


Great!
PR
https://github.com/w3c/webcomponents/pull/26

forked
http://stevefaulkner.github.io/webcomponents/spec/custom/#semantics



--

Regards

SteveF
HTML 5.1 

web developer conformance requirements and advice in custom elements spec

[Steve Faulkner]

Hi all,

looking at the custom elements spec
http://w3c.github.io/webcomponents/spec/custom/ i realized it includes no
defined requirements or advice for web developers on creation of custom
elements that are meaningful and expose useful semantics and behavior.

I would like to take a stab at this, what's the best way to contribute?
pull requests?


--

Regards

SteveF
HTML 5.1 

Re: [Custom] Custom elements and ARIA

[Steve Faulkner]

Hi Domenic,

--

Regards

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


On 28 August 2014 15:57, Domenic Denicola 
wrote:

> Hi Steve, thanks greatly for your help. It's clear now that I should have
> reached out to you for your expertise directly before being very wrong on a
> public mailing list :)
>

don't worry same thing happens to me all the time.

>
> From: Steve Faulkner 
>
> > It appears (please correct me) you have made the assumption that 'strong
> native semantics' for roles is a UA requirement? This is not the case (in
> the W3C HTML spec [1] at least, can't speak for where the WHATWG spec has
> gone in defining ARIA in HTML), they  are author conformance requirements.
>
> Yes, I was misled about that pretty badly. That changes things, as it
> means there are no non-overridable roles or stoperties (as you show with
> ).


For roles this is true, for states and properties native wins where
specified (as Simon pointed out)


> From my reading though, the default implicit ARIA semantics are still UA
> requirements, right?
>

yes, these are what i pulled out of the spec and tested for HTML CR:
http://stevefaulkner.github.io/html-mapping-tests/ This doc lists all the
(ARIA section) UA requirements from the HTML5 CR spec, testing results for
the 4 major browsers, and browser bugs filed where needed.




>
> To be clear, my concern is entirely about UA requirements, so anything
> authoring-related is irrelevant to me.
>
> > The HTML spec (any brand) does not define how HTML features map to
> platform accessibility APIs. This is being normatively defined in the HTML
> Accessibility API Mappings specification [2].
> >
> > Would it be worth considering exposing the  platform accessibility APIs
> used in the browser, to JS so that custom elements can be implemented to
> fully reflect native element accessibility implementations?
>
> zcorpan pointed out this strategy in IRC as well. I think it is worth
> exploring. Although, I was hoping to use ARIA as a platform-independent
> interface into native platform accessibility APIs; that is, I was assuming
> that everything a native or custom element would want to do could be
> expressed with ARIA. But, you state earlier in your message that:
>
> > I don't think it is currently possible to define the browser
> accessibility API mappings in terms of ARIA as it defines and incomplete
> set of roles,states and properties used in acc APIs.
>
> This seems unfortunate. Why is that? Could you give an example?
>

I guess because ARIA is not trying to be provide a general abstraction of
all roles,states and properties. The only cases (generally) where native
features express role/state/property values in terms of ARIA in the acc
APIs are where no platform acc API role/state/property exists.

IA2 has a caption role that FF maps to the figcaption element, ARIA does
not.



>
> Would it be more fruitful to augment ARIA in some way, instead of trying
> to bypass it and go directly to platform accessibility APIs? The latter
> seems like it would require a platform-agnostic intermediate layer to be
> defined, which feels redundant with ARIA...
>

Possibly, I would suggest pinging the PF mailing list with some ideas would
be a good place to start http://lists.w3.org/Archives/Public/public-pfwg/

HTH

Re: [Custom] Custom elements and ARIA

[Steve Faulkner]

hi domenic,

a few quick initial comments, (I have only skimmed the material you have
provided):


I don't think it is currently possible to define the browser accessibility
API mappings in terms of ARIA as it defines and incomplete set of
roles,states and properties used in acc APIs.

It appears (please correct me) you have made the assumption that 'strong
native semantics' for roles is a UA requirement? This is not the case (in
the W3C HTML spec [1] at least, can't speak for where the WHATWG spec has
gone in defining ARIA in HTML), they are author conformance requirements.


Section 3.2.7 WAI-ARIA [1] states:

"User agents must implement ARIA semantics on all HTML elements, as defined
in the ARIA specifications."

Relevant to this is section 5.2. Conflicts between native markup semantics
and WAI-ARIA [3]  in the Core Accessibility API Mappings specification

This is reflected in implementations, for example



is exposed in Chrome (in IAccessible2) on windows as;

ROLE_SYSTEM_MENUITEM display:block tag:hr xml-roles:menuitem location=(8,
8) size=(1125, 2) index_in_parent=0 n_relations=0 n_characters=0
caret_offset=0 n_selections=0

The HTML spec (any brand) does not define how HTML features map to platform
accessibility APIs. This is being normatively defined in the
HTML Accessibility API Mappings specification [2].

Would it be worth considering exposing the platform accessibility APIs

used in the browser, to JS so that custom elements can be implemented to
fully reflect native element accessibility implementations?

[1] http://www.w3.org/html/wg/drafts/html/master/dom.html#wai-aria
[2] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html
[3]
http://rawgit.com/w3c/aria/master/implementation/aria-implementation.html#mapping_conflicts

--

Regards

SteveF
HTML 5.1 


On 28 August 2014 00:42, Domenic Denicola 
wrote:

> TL;DR: we (Google) are trying to explain the platform with custom elements
> [1], and noticed they can't do ARIA as well as native elements. We would
> like to prototype a solution, ideally as a standardized API that we can let
> authors use too. (If that doesn't work, then we can instead add a
> non-web-exposed API that we can use inside Chrome, but that would be a
> shame.) A succinct statement of the problem is that we need some way to
> explain [3]. The rest of this mail explains the problem in great depth in
> the hopes other people are interested in designing a solution with me.
>
> Also, in the course of figuring all this out, I put together an intro to
> the relevant aspects of ARIA, which you might find useful, at [2].
>
> ## The problem
>
> Right now, custom elements can manually add ARIA roles and stoperties (=
> states or properties) to themselves, by setting attributes on themselves.
> In practice, this kind of allows them to have default ARIA roles and
> stoperties, but they are fragile and exposed in a way that is incongruous
> with the capabilities of native elements in this regard.
>
> For example, if we were to implement `` as a custom element, we would
> attempt to give it the separator role by doing `this.setAttribute("role",
> "separator")` in the `createdCallback`. However, if the author then did
> `document.querySelector("custom-hr").setAttribute("role", "menuitem")`,
> assistive technology would reflect our `` as a menu item, and
> not as a separator. So **unlike native elements, custom elements cannot
> have non-overridable semantics**.
>
> Furthermore, even if the author wasn't overriding the role attribute,
> there would still be a difference between `` and ``. Namely,
> `document.querySelector("hr").getAttribute("role") === null`, whereas
> `document.querySelector("custom-hr").getAttribute("role") === "separator"`.
> So **unlike native elements, custom elements cannot have default ARIA roles
> or stoperties without them being reflected in the DOM**.
>
> As another example, imagine trying to implement `` as a custom
> element. To enforce the restriction to a role of either `button` or
> `menuitem`, the custom element implementation would need to use its
> `attributeChangedCallback` to revert changes that go outside those
> possibilities. And that of course only occurs at the end of the microtask,
> so in the meantime screen-readers are giving their users bad information.
> And even then, the experience of the attribute value being reverted for the
> custom element is not the same as that for a native element, where the
> attribute value stays the same but the true ARIA role as reflected to
> screenreaders remains `button`. So: **unlike native elements, custom
> elements cannot robustly restrict their ARIA roles to certain values**.
>
> Finally, consider how `` synchronizes `aria-expanded` with the
> `open` attribute. To implement this with custom elements, you would use the
> `attributeChangedCallback` to set an `aria-expanded` a