Re: ISSUE-201: Aligning the two change proposals

I object to adding lightweight nodes at this time. Like the Path object proposal, they're completely unnecessary in solving the outstanding issues needed for Canvas to progress to a full recommendation.

The Path object proposal requires further input and interfacing with the SVG2 WG in relation to scope. The lightweight nodes proposal requires further interfacing with the Web Components contributors, especially in relationship to DOM events, focus and accessibility.

Both sections are useful, but unnecessary at this point. Neither have been discussed openly with the technology platforms whose semantics they adopt.

I'm happy to see that work happen, I'm happy to start work on it immediately. But I don't want it blocking or otherwise harming our work from the Canvas working group to push the Canvas spec along with HTML5.



-Charles



On Jul 12, 2012, at 3:53 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> I over estimated the time it would take me to produce a CP based on Ted's current CP
> 
> here it is:
> http://www.w3.org/html/wg/wiki/ChangeProposals/hitregions
> 
> Note Ted's proposal remains unchanged excpet for the addition of the following:
> 
> 
> 1. in the section:
> Additional rationale for addHitRegion and the Path object (http://www.w3.org/html/wg/wiki/ChangeProposals/hitregions)
> 
> ADDED start
> 
> As the 'lightweight objects which simply provide a label and a WAI-ARIA role' are not focusable and cannot have author assigned states  and properties, the allowed ARIA roles should be limited to a subset of the non interactive ARIA roles that do not require or benefit from the addition of states and properties.
> 
> For example, A region with role=button could not be considered  accessible unless it is able to receive focus. Or a role=checkbox has a required state of aria-checked, and must be able to recieve focus for device indepedent operation, so it makes not sense to allow such roles on lightweight objects.
> 
> ADDED end
> 
> 
> 2 in the section
> Details (http://www.w3.org/html/wg/wiki/ChangeProposals/hitregions#Details)
> 
> 
> Naturally changes to the proposed text, of an editorial nature, are at the discretion of the editor.
> ADDED start
> 
> In addition define the ARIA roles that many be assigned to unbacked hit regions:
> 
> ARIA role restrictions for unbacked hit regions
> 
> Unbacked hit regions cannot be focusable and cannot have the necessary states and properties assigned to adequately convey the semantics of interactive controls. Author may assign the following roles using the addHitRegion() > role() method.For all interactive controls associate a hit region with an HTML element using the addHitRegion() > control() method.
> 
> subset of document structure roles
> 
> article
> group
> note
> region
> separator
> landmark roles
> 
> application
> banner
> complementary
> contentinfo
> form
> main
> navigation
> search
> ADDED end
> 
> 
> 
> On 11 July 2012 22:09, Maciej Stachowiak <mjs@apple.com> wrote:
> 
> Can you offer a date by which you could have a new CP ready?
> 
>  - Maciej
> 
> On Jul 11, 2012, at 5:35 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote:
> 
>> Hi chairs, 
>> 
>> As we don't appear to be able to reach consensus on the 'unbacked regions' aspect of ted's proposal. 
>> Wondering if it makes sense for me to start work on a CP?
>> 
>> 
>> 
>> regards
>> SteveF
>> 
>> On 6 July 2012 08:16, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>> Hi Ted, 
>> 
>> thank you for persevering.
>> 
>> 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()."
>> 
>> reading http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-regions
>> 
>> to clarify, regions only have a control when they have an associated element. so unbacked regions don't have a control right?
>> 
>> As unbacked regions cannt be focusable and cannot have additional author defined properties it does not make any sense for ARIA roles that are for interactive objects.
>> 
>> 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.
>> 
>> So I suggest either the list of roles that can be used or the list of roles that cannot be used be defined so no one is under any illusion that unbacked regions can make representations of controls, for example a button, accessible.
>> 
>> Below is a suggested list of allowed ARIA roles:
>> 
>> subset of document structure roles
>> article
>> group
>> note
>> region
>> separator
>> landmark roles
>> application
>> banner
>> complementary
>> contentinfo
>> form
>> main
>> navigation
>> search
>> 
>> Is this something you are amenable to adding to your CP?
>> 
>> 
>> reegards
>> Stevef
>> 
>> 
>> 
>> On 6 July 2012 00:02, Edward O'Connor <eoconnor@apple.com> wrote:
>> Hi Steve,
>> 
>> You wrote:
>> 
>> > what is the source of the note? Is it in your CP?
>> 
>> It's from r7029, which is one of the revisions my CP aims to restore to
>> the W3C version of the spec.
>> 
>> > How is the region associated with the control since the region can
>> > have no properties added which define a relationship between them?
>> 
>> 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(). Is this unclear in the spec text?
>> 
>> > Soon as an author wants to go beyond simple grouping objects, they can
>> > no longer use the lightweight objects anyway as no relationship
>> > properties can be added to the lightweight objects.
>> 
>> We should make the easy things easy and the hard things possible.
>> Allowing hit regions to be associated with either unbacked region
>> descriptions or elements allows for this: if you have a complex thing
>> which requires WAI-ARIA states and properties to describe, use an
>> element. If not, use an unbacked region description.
>> 
>> 
>> HTH,
>> 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 
>> 
>> 
>> 
>> 
>> -- 
>> 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 
>> 
> 
> 
> 
> 
> -- 
> 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 
>