RE: ISSUE-201: Aligning the two change proposals

We appear to have two changes proposals for ISSUE-201:

a) ChangeProposals/hitregions
http://www.w3.org/html/wg/wiki/ChangeProposals/hitregions

b) Canvas hit testing
http://www.w3.org/wiki/Canvas_hit_testing

Are these still the two active change proposals under consideration?  Is there anyone in the WG that wants to propose any other change proposal for ISSUE-201?

/paulc
HTML WG co-chair

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Friday, July 13, 2012 8:41 AM
To: Charles Pritchard
Cc: Edward O'Connor; Steve Faulkner; Maciej Stachowiak; Paul Cotton; public-html@w3.org; Sam Ruby; Frank Olivier
Subject: Re: ISSUE-201: Aligning the two change proposals


Well, not to put a ruffle on things but I also think that the lightweight object concept is a bit immature.

Would people consider moving them to html.next along with the other full SVG path work that people agree that we move? This way the concept could be developed more.

Rich


Rich Schwerdtfeger

[Inactive hide details for Charles Pritchard ---07/12/2012 01:22:03 PM---I object to adding lightweight nodes at this time. Like]Charles Pritchard ---07/12/2012 01:22:03 PM---I object to adding lightweight nodes at this time. Like the Path object proposal, they're completely

From: Charles Pritchard <chuck@jumis.com<mailto:chuck@jumis.com>>
To: Steve Faulkner <faulkner.steve@gmail.com<mailto:faulkner.steve@gmail.com>>,
Cc: Maciej Stachowiak <mjs@apple.com<mailto:mjs@apple.com>>, Paul Cotton <Paul.Cotton@microsoft.com<mailto:Paul.Cotton@microsoft.com>>, Sam Ruby <rubys@intertwingly.net<mailto:rubys@intertwingly.net>>, "public-html@w3.org<mailto:public-html@w3.org>" <public-html@w3.org<mailto:public-html@w3.org>>, "Edward O'Connor" <eoconnor@apple.com<mailto:eoconnor@apple.com>>
Date: 07/12/2012 01:22 PM
Subject: 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<mailto: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<mailto: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<mailto: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<mailto: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<http://roles/#article>
              *   group<http://roles/#group>
              *   note<http://roles/#note>
              *   region<http://roles/#region>
              *   separator<http://roles/#separator>
landmark roles

              *   application<http://roles/#application>
              *   banner<http://roles/#banner>
              *   complementary<http://roles/#complementary>
              *   contentinfo<http://roles/#contentinfo>
              *   form<http://roles/#form>
              *   main<http://roles/#main>
              *   navigation<http://roles/#navigation>
              *   search<http://roles/#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<mailto: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<http://www.paciellogroup.com/> | www.HTML5accessibility.com<http://www.html5accessibility.com/> | www.twitter.com/stevefaulkner<http://www.twitter.com/stevefaulkner>
HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/<http://dev.w3.org/html5/alt-techniques/>
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html <http://www.paciellogroup.com/resources/wat-ie-about.html>



--
with regards

Steve Faulkner
Technical Director - TPG

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



--
with regards

Steve Faulkner
Technical Director - TPG

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