Re: ISSUE-201: Aligning the two change proposals

hi Ted,

you wrote"
"No; if you reread the quoted bit above, you'll see that a control is
either an element or an unbacked region description."

The whatwg spec says [1]:

"Optionally, either a
control<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-region's-control>,
or an unbacked region
description<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-region's-unbacked-region-description>
.

A control is just a reference to an
Element<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#element>
node,
to which, in certain conditions, the user agent will route events, and from
which the user agent will determine the state of the hit region for the
purposes of accessibility tools."
So your proposal differs from the revision
http://html5.org/tools/web-apps-tracker?from=7028&to=7029 (which is the
same as above)
and whats currently in the whatwg spec right?

you wrote:

"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."

HTML5 explicitly defines what roles,state and properties can be used with
what HTML elements, not ARIA
I don't see why it would be any different in this case. What reasoning do
you have for not wanting to add such a list? When it is clear that due to
the characteristics of the lightweight regions defined in HTML, being
neither focusable or able to have assigned states and properties, it only
makes sense for a limited set of roles to be allowed.


[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-regions

regards
SteveF


On 9 July 2012 21:30, 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.
>
>
> Ted
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html