Re: Making ARIA and native HTML play better together
On 9 May 2015 at 22:22, Alice Boxhall aboxh...@google.com 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 label. Example: span role=checkbox id=customcheck/span label for=customchecki like this idea/label 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: Stability of Widget DigSig
On 5/11/15 4:23 AM, Andrew Twigger wrote: I expect that removing the statement from the namespace document will resolve the concerns of ATSC and CEA members. Andrew - the warning has been removed. -ArtB Thank-you for your quick response to this request. Andrew Twigger -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: 08 May 2015 13:55 To: Andrew Twigger Cc: Marcos Caceres; Frederick Hirsch; public-webapps@w3.org Subject: Re: Stability of Widget DigSig Andrew - seeing no objections from the group to removing the Implementers ... statement from [NS] document, if that statement is removed, does that address your concern? -Thanks, ArtB [NS] http://www.w3.org/ns/widgets-digsig/
RE: Stability of Widget DigSig
Art, I expect that removing the statement from the namespace document will resolve the concerns of ATSC and CEA members. Thank-you for your quick response to this request. Andrew Twigger -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: 08 May 2015 13:55 To: Andrew Twigger Cc: Marcos Caceres; Frederick Hirsch; public-webapps@w3.org Subject: Re: Stability of Widget DigSig Andrew - seeing no objections from the group to removing the Implementers ... statement from [NS] document, if that statement is removed, does that address your concern? -Thanks, ArtB [NS] http://www.w3.org/ns/widgets-digsig/ On 5/8/15 7:14 AM, Arthur Barstow wrote: [ + Marcos and Frederick ] Hi Andrew, The group stopped working on XML Digital Signature for Widgets several years ago and there is no plan to resume work (except to process errata as required). Marcos, Frederick - this spec's namespace document includes the following statement: [[ http://www.w3.org/ns/widgets-digsig/ Implementers should be aware that this document is not stable. ]] Any objections from you or anyone else to remove this statement? -Thanks, ArtB On 5/7/15 5:55 AM, Andrew Twigger wrote: ATSC and CEA are developing standards that include the ability to download digital signed applications. Their current specifications reference the W3C Recommendation for XML Digital Signature for Widgets (18 April 2013). However, the associated Widgets Digital Signature Namespace (http://www.w3.org/ns/widgets-digsig/) contains a statement that Implementers should be aware that this document is not stable. which has raised questions as to the stability and suitability of referencing Widget DigSig. The alternative would be to reference XAdES with the C and T forms to allow for the inclusion of timestamp and certificate revocation information which are not included in Widget DigSig. I would be pleased to receive any information regarding the stability of Widget DigSig and whether referencing XAdES would provide a better alternative. Thank-you, Andrew Twigger
[Bug 28552] [Shadow]: Shadow DOM v1
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28552 Bug 28552 depends on bug 20017, which changed state. Bug 20017 Summary: [Shadow]: Retargeting relatedTarget algorithm prevents events from be fired if a user creates a MouseEvent manually with a relatedTarget which is same to the target. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20017 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28564] [Shadow]: Event model
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28564 Bug 28564 depends on bug 20017, which changed state. Bug 20017 Summary: [Shadow]: Retargeting relatedTarget algorithm prevents events from be fired if a user creates a MouseEvent manually with a relatedTarget which is same to the target. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20017 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
Re: Making ARIA and native HTML play better together
On May 7, 2015, at 12:59 AM, Domenic Denicola d...@domenic.me wrote: From: Anne van Kesteren ann...@annevk.nl On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Currently ARIA does not do this stuff AFAIK. Correct. ARIA only exposes strings to AT. We could maybe make it do more, once we understand what more means, which is basically figuring out HTML as Custom Elements... These are my thoughts as well. The proposal seems nice as a convenient way to get a given bundle of behaviors. But we *really* need to stop considering these roles as atomic, and instead break them down into what they really mean. In other words, I want to explain the button behavior as something like: - Default-focusable This point isn’t correct for built-in buttons on all browsers and platforms. For example, input type=button is not keyboard-focusable on Safari for Mac but it is mouse-focusable. Likewise in Safari on iOS (both if you connect a physical keyboard, and if you use the onscreen focus-cycle arrows in navigation view). This raises an interesting and subtle point. Built-in controls can add value by being consistent with the platform behavior when it varies between platforms. Giving very low-level primitives results in developers hardcoding the behavior of their biggest target platform - generally Windows, but for some mobile-targeted sites it can be iOS. It’s hard to make low-level primitives that can sensibly capture these details. Sure, I guess we could have a feature that’s default-focusable but only on platforms where that is true for controls you don’t type into”. That is pretty specific to particular platform details though. Other platforms could make different choices. In fact, what controls fall in which focus bucket has changed over time in Safari. Let’s say you really want to capture all the essences of buttonness in a custom control, but give it special appearance or behavior. I think two good ways the web platform could provide for that are: (1) Provide standardized cross-browser support for styling of form controls. (2) Allow custom elements to subclass button or input type=button (the latter is hard to define cleanly due to the way many form controls are all overloaded onto a single element). - Activatable with certain key commands - Announced by AT as a button Buttons also have further aspects to their specialness, such as the way they participate in forms. I think adding clean primitives for these has value. Adding an easy way to get a package deal of standard button behaviors with greater customizability is also valuable, potentially more so in some circumstances. (I don’t think ARIA is the best way to invoke a package deal of behaviors though, since it’s already pretty established as a way to expose behavior through AT without having many of these effects. It would risk breaking author intent to change it now.) Regards, Maciej and then I want to be able to apply any of these abilities (or others like them) to any given custom element. Once we have these lower-level primitives we'll be in a much better place.
