- From: Joseph Scheuhammer <clown@alum.mit.edu>
- Date: Thu, 03 Jan 2013 17:05:08 -0500
- To: wai-xtech@w3.org
- CC: Aaron Leventhal <aaronlevbugs@gmail.com>
> More notes -- pressed, selected and expanded are similar in that the > lack of them indicate an item is not pressable/selectable/expandable. I think that's a key point. Paraphrasing from the UAIG: - If aria-pressed="true", then IA2 and AT-SPI expose a toggle button role and set STATE_PRESSED. - If aria-pressed="false", then expose a toggle button role and *clear* STATE_PRESSED. Note that in the latter case, the state is cleared. There is no "pressed = false" in IA2 nor AT-SPI. STATE_PRESSED is like a bit in a bit vector. Thus, an AT that looks only at the states can not tell that the accessible could be pressed if the state is cleared. Hence, the additional information provided by the object property checkable:true indicates that the accessible can change its state. At least, that's my best guess at a rationale for storing that object property in the accessible. (Next question -- why not pressable:true? or is that not available in IA2 or AT-SPI?) Still, it means that an AT has to infer that "checkable" means "can be pressed" in this specific instance, and not "can be checked". And, the way to determine that is by looking at the role -- it's a toggle button. (But, if it's a toggle button, doesn't that entail that it's pressable?) In any case, that's my stab at what the rationale was for adding the checkable object property. But, it's pure speculation and inference on my part. -- ;;;;joseph. 'A: After all, it isn't rocket science.' 'K: Right. It's merely computer science.' - J. D. Klaun -
Received on Thursday, 3 January 2013 22:05:34 UTC