W3C home > Mailing lists > Public > public-html-a11y@w3.org > July 2015

location of the region, full location, and specified path (Re: Canvas 2d update)

From: Philippe Le Hegaret <plh@w3.org>
Date: Thu, 09 Jul 2015 19:21:12 -0400
Message-ID: <559F01E8.5000606@w3.org>
To: chaals@yandex-team.ru, Richard Schwerdtfeger <schwer@us.ibm.com>
CC: HTML Accessibility Task Force <public-html-a11y@w3.org>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, mark.sadecki+w3c@gmail.com
We did manage to meet for one hour and looked into
 
http://cptvitamin.github.io/wpt-canvas/2dcontext/hit-regions/addHitRegion.IDNotNullPreviousInList-manual.html 


Chrome exposed two separate issues:

1. the first region focusable area is misplaced on the screen, as 
mentioned by Rich. However, the second region is placed correctly. We 
think this needs to be reported (and Mark will follow up);

2. if there is a reflow after the second region is added, then the 
location reported will be incorrect.

It seems to me that the Canvas spec is unclear on what gets reported to 
the user and the API. We'll need Rich to confirm that or not.

The spec says:
"inform the user of the location of the region representing the control 
given by the control member's value for this canvas element. The full 
location of the corresponding fallback element, pertaining to the 
control, as represented by the region is passed to the accessibility 
API, if supported."

I might be misreading the text but I have several questions:

For the first sentence:

1. If the region isn't focused (and it cannot be since we just created 
the region using addHitRegion!), why do we "inform the user" [1]? For 
example, why would we notify a magnifying tool if we're not focusing anyway?

2. if it doesn't matter, then what is the "location of the region"? Is 
it the hit region's bounding circumference subject to the clipping 
region? Is the implementation expected to deduce from that the region 
relative to the origin of the screen of the output device [2]? If yes, 
What is it if addHitRegion is invoked on a path that is not within the 
viewport but expected to scroll into view because it's not focused?

For the second sentence:

What is the "full location" of the element? Is it the location of the 
hit region's bounding circumference subject to the clipping region and 
relative to the initial containing block origin of the document [3]?

As a side, the term "specified path" and "source path" are used in the 
algorithm but never defined either.

Philippe

[1] http://www.w3.org/TR/2dcontext/#inform
[2] http://dev.w3.org/csswg/cssom-view/#screen
[3] http://dev.w3.org/csswg/css-display-3/#initial-containing-block
Received on Thursday, 9 July 2015 23:21:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 July 2015 23:21:20 UTC