RE: ISSUE-201: Aligning the two change proposals

Ted, Frank:

Can we get an estimate of when you will be able to answer these questions?

HTML WG co-chair

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

From: Steve Faulkner []
Sent: Saturday, June 30, 2012 2:47 AM
To: Edward O'Connor; Frank Olivier
Cc:; Richard Schwerdtfeger; HTML Accessibility Task Force
Subject: Re: ISSUE-201: Aligning the two change proposals

Hi ted,

I consider the rationale and details for the lightweight hit regions to be insufficient
your CP states:

"The proposed addHitRegion()method allows for tying hit regions to either elements or to lightweight objects which simply provide a label and a WAI-ARIA role. This helps authors to make their canvas content accessible without incurring an unacceptable performance penalty."

Your CP defines 'lightweight' hit regions without:
a) the ability to make them focusable
b) the ability to add accessibility states and properties that are associated with interactive objects. Only providing the ability to add a role to lightweight regions means the the usable ARIA roles is limited to a subset of non widget roles, and even then those roles usefulness ir constrained as they cannot have ANY states and properties assigned.

It would be helpful for reaching consensus on this if you could:
a) detail in your CP why the above are not required, or
b) add the ability to make the lightweight regions focusable and provide he ability to  associate the required states and properties, or
c) drop the lightweight hit regions from your CP


On 29 June 2012 23:03, Edward O'Connor <<>> wrote:
Hi all,

I wrote:

> Frank and I got together today and went through the remaining
> ISSUE-201 items.
I've made a pass at updating my Change Proposal to reflect what came out
of that meeting. The updated proposal is available here:

Please review this updated proposal and let me know if I missed
anything. Here's the diff from the previous version of the proposal:

>> [Frank's CP only] A method ( clearElementPath() ) to remove hit
>> regions. I think we should have this in the joint proposal, as relying
>> on ClearRect or other drawing mechanisms to clear an association seems
>> overly involved and a burden on the author.
> We both agreed that having a clearElementPath() method makes sense.
To keep the method names aligned, I've added removeHitRegion() to my

>> r7025 - Add ellipse support to canvas. not needed, not accessibility
> Agreed; can wait.
>> r7026 - Add SVG paths to Path objects in canvas.
> Agreed, can wait.
I removed these revisions from the list of revisions to restore.

>> r7028 - add dashed lines and change how Path objects work to instead
>> use external line and font styles and transformation objects
> I need to look at this in more detail to see if the refactoring is
> necessary to make Path sufficiently useful.
I think leaving this in is probably necessary to keep the Path
definition sane.

>> r7033 - More font metrics.
> Definitely helps wit hit testing runs of text, so I'd prefer to keep
> this in. That said, I can live with putting it off until
>> r7034 - Path copy constructor
> I don't see the harm in keeping it, but like the font metrics, I can
> live with putting it off as well.
I removed these revisions from the list of revisions to restore.

Rich wrote, in <<>>:

> Does this mean that the ligtweight JSON objects will be an
> discussion item?

Sorry, I failed to mention unbacked region descriptions in my summary
email of the conversation I had with Frank. I argued for keeping them in
this version of the feature. I think Frank could live with that, but I
don't want to put words in his mouth. Frank, what do you think? I
haven't changed this aspect of my proposal.


with regards

Steve Faulkner
Technical Director - TPG<> |<> |<>
HTML5: Techniques for providing useful text alternatives -<>
Web Accessibility Toolbar -

Received on Thursday, 5 July 2012 15:24:25 UTC