Re: Making ARIA and native HTML play better together

2015-05-11 Thread Steve Faulkner
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

2015-05-11 Thread Arthur Barstow

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

2015-05-11 Thread Andrew Twigger
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

2015-05-11 Thread bugzilla
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

2015-05-11 Thread bugzilla
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

2015-05-11 Thread Maciej Stachowiak

 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.