making some aria roles act as 'labelable' elements

[Steve Faulkner]

I posted this to the public-webapps mailing list earlier today

https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0622.html

but would appreciate comments from browser acc devs on whether it is viable/desirable?

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="customcheck">i
> 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

[Dominic Mazzoni]

Hi Steve, one question - what would the 'control' property of HTMLLabelElement return when the label is an ARIA element? I believe that currently it rejects anything that's not a labelable control, but now it would have to check the ARIA role. Not a huge deal but it's currently uncommon for HTML code to care about ARIA - typically we implement browser accessibility support as a layer on top, with the lower layers mostly unaware of things like ARIA.

- Dominic

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/518283e9-274b-4e78-9e6f-277100e53a79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Surkov]

Hi. What do you mean by "same behavior as the native element and a <label>"? Is it same behavior on accessibility API level only, i.e. the accessible object has accessible name calculated from that HTML label and that's it. Or do you suggest something that affects on user experience in general? If latter then it's rather out of scope of ARIA.

Thanks.

Alex.

--

[Dominic Mazzoni]

Yeah, that's related to my question too - should clicking on the label focus the ARIA element? I think that would surprise many web developers who have until now assumed that ARIA doesn't affect the semantics of the HTML aside from accessibility APIs.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CA%2BepNseBvtX8UzxWr3MnYPnN3AgESaNUYMZVKgVjNmOxhDS9Hg%40mail.gmail.com.

[Steve Faulkner]

I suggest the reason for contemplating this is to extend the utility of the <label> element to custom controls.

On Tuesday, 12 May 2015 18:13:12 UTC+1, Dominic Mazzoni wrote:

Yeah, that's related to my question too - should clicking on the label focus the ARIA element?

yes

 

I think that would surprise many web developers who have until now assumed that ARIA doesn't affect the semantics of the HTML aside from accessibility APIs.

I suggest it would delight many developers to be able to use the label element to label custom controls :-)

 it doesn't change the behaviour of the label element except to extend the list of elements considered as labelable.

If the only benefit to use of the label in conjunction with ARIA roles is name calculation, then I don't think it is worth doing.

 

To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibility-dev+unsub...@googlegroups.com.

To post to this group, send email to browser-acce...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/518283e9-274b-4e78-9e6f-277100e53a79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibility-dev+unsub...@googlegroups.com.

To post to this group, send email to browser-acce...@googlegroups.com.

[Victor Tsaran]

Hi Steve.

Other than to enable the user to activate such a custom control by clicking on an associated label, what other advantages do we get from this approach? We do have aria-labelledby already.

*** *** ***

Find me on Twitter http://www.twitter.com/vick08

To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.

To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/29d3f2cb-1d83-4a21-aa6a-1a412ca81378%40googlegroups.com.

[Steve Faulkner]

On Wednesday, 13 May 2015 05:57:20 UTC+1, Victor Tsaran wrote:

Hi Steve.

Other than to enable the user to activate such a custom control by clicking on an associated label, what other advantages do we get from this approach? We do have aria-labelledby already.

what we would get is a combination of increased interaction area and accessible name calculation by default - built in rather than bolt on.via a well understood pattern. having said that I am going to park this idea for now :-)
 

[Alexander Surkov]

It makes me think then we should probably put effort into developing behavioral-semantical blocks for UI design. I'm not sure whether IndieUI has anything for that, but that's a direction I would move towards to. I wouldn't introduce behaviors in ARIA.

To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.

To post to this group, send email to browser-acce...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/518283e9-274b-4e78-9e6f-277100e53a79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.

To post to this group, send email to browser-acce...@googlegroups.com.