Re: ISSUE-201: Aligning the two change proposals

On Jul 9, 2012, at 1:30 PM, Edward O'Connor <eoconnor@apple.com> wrote:

> Hi Steve,
> 
> You wrote:
> 
>>> "Each hit region has an associated control, which is either an
>>> element or an unbacked region description. You pass in the control
>>> when you call addHitRegion()."
>> 
>> to clarify, regions only have a control when they have an associated
>> element. so unbacked regions don't have a control right?
> 
> No; if you reread the quoted bit above, you'll see that a control is
> either an element or an unbacked region description.
> 
>> If the list of roles allowed on unbacked regions is constrained to
>> those that make sense, then I could live with the rest of the concept.
> 
> I'd rather not add an explicit whitelist of allowed roles; instead, I'd
> rather the WAI-ARIA spec have some prose describing the sorts of roles
> that can be used with such constructs.


ARIA requires structure not available in this API. It seems that the main case for unbacked regions is to handle data heavy scatter charts where the hit points are not in the DOM (in a table tag). Are there other use cases?

In relation to ARIA, it seems we ought to drop the role attribute and just label them as "group"; the alternative seems to be to pick up aria attributes in bulk and allow the full aria language. Both of those seem to work with existing specs.

I still think these unbacked regions are risky; we can't run .focus, not enumerate, nor much else. But, if we're making them a feature, let's do it right. Full ARIA spec or just leave aria out of it and identify them as generic "group" to the a11y platform.

Received on Monday, 9 July 2012 20:48:07 UTC