- From: Joanmarie Diggs <jdiggs@igalia.com>
- Date: Wed, 22 Jun 2016 21:52:10 -0400
- To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Cc: ARIA Working Group <public-aria@w3.org>
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 01:52:48 UTC