RE: Regarding children presentational in prep: Agenda: June 23, 2016 WAI-ARIA Working Group

No problem :) 

The tricky bit is which element has focus and how this should be handled, which is where it's unclear.

I agree that the aria-valueX attributes should go on the role=spinbutton element, but the spinbutton is considered to be a focusable widget role, so it may include tabindex=0 for this purpose to accept arrow key spinning. This matches the mapping on the HTML5 range input.

So if this same element also has embedded buttons, how would an AT interact with it? E.G Currently Forms Mode is entered when interacting with this field like a regular form field, etc.

Then, say tabindex was omitted and an input was embedded instead, then an AT would need to treat it like a named region instead, which is a totally different type of interaction. 

It's confusing and causing ambiguities about how this is supposed to work in ATs.

Hopefully this makes sense? :) 





Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com


-----Original Message-----
From: Joanmarie Diggs [mailto:jdiggs@igalia.com] 
Sent: Wednesday, June 22, 2016 7:00 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: ARIA Working Group <public-aria@w3.org>
Subject: Re: Regarding children presentational in prep: Agenda: June 23, 2016 WAI-ARIA Working Group

Sorry for the noise. Below I wrote "aria-valuetext" that is a typo.
"aria-valuemax" is the third required property of spinbutton. Please pretend I typed it right the first time in my response. :)

On 06/22/2016 09:52 PM, Joanmarie Diggs wrote:
> Hey Bryan.
> 
> Regarding this:
> 
> On 06/22/2016 07:47 PM, Bryan Garaventa wrote:
> 
>> The spinbutton role was removed from this proposal because there is a 
>> desire to make it composite. Currently the spec is not written to 
>> support this and changes would be needed to do this, because it's not 
>> clear where and what attributes are needed and how focus should be 
>> handled, but this should be broken out into another action item.
> 
> Taking the value-related properties as an example, and the assumption 
> that the children of the spinbutton would be an input and two buttons:
> aria-valuemin, aria-valuenow, and aria-valuetext are supported on the 
> following roles:
> 
> * range
> * scrollbar
> * slider
> * spinbutton
> 
> And through inheritance:
> 
> * progressbar
> 
> These properties are not supported on:
> 
> * input
> * button
> 
> From this, my conclusion is that the answer to where the value-related 
> properties go is on the spinbutton itself. Conformance testers should 
> already be able to verify this now. I think this is clear. If you do 
> not think so, what is missing? A sentence that states this explicitly?
> Something else?
> 
> I'm happy to address (at least) making it more clear where and what 
> attributes are needed. I've not done this because I didn't realize it 
> was needed. So if you could tell me which properties are unclear, and 
> what approximately you think would help clarify them, I'm happy to do 
> so and can even try to have it done in my branch prior to tomorrow's meeting.
> 
> Thanks!
> --joanie
>

Received on Thursday, 23 June 2016 16:15:58 UTC