Re: camvas accessibility test results

I created a Chrome bug regarding the test failure: crbug.com/517521
Thanks for reporting it.

   -Justin

On Thu, Aug 6, 2015 at 12:00 PM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:

> From an implementation perspective we need to make sure clearHitRegion
> works in Chrome. We also need to check that the ids are passed back in hit
> testing (Chrome and Firefox) or an author won't be able to rely on them.
> The test cases timed out for some reason on this. None of this impacts the
> spec. other than having to have 2 implementations.
>
> The Firefox pixel bug is simply a bug that needs to be fixed. I don't know
> when it was introduced. It may just be a regression.
>
> Rich
>
>
> Rich Schwerdtfeger
>
> [image: Inactive hide details for Paul Cotton ---08/06/2015 10:20:26
> AM---Thanks for the report and update. Do you think any of the rep]Paul
> Cotton ---08/06/2015 10:20:26 AM---Thanks for the report and update. Do you
> think any of the reported failures should block our progres
>
> From: Paul Cotton <Paul.Cotton@microsoft.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: Dominic Mazzoni <dmazzoni@google.com>, Rik Cabanier <
> cabanier@gmail.com>, Canvas <public-canvas-api@w3.org>, HTML
> Accessibility Task Force <public-html-a11y@w3.org>
> Date: 08/06/2015 10:20 AM
> Subject: RE: camvas accessibility test results
> ------------------------------
>
>
>
> Thanks for the report and update.
>
> Do you think any of the reported failures should block our progress to
> Proposed Recommendation?
>
> Can you update the test results at
> *https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test*
> <https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test>?
>
> /paulc
>
> 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
> <schwer@us.ibm.com>]
> * Sent:* Wednesday, August 05, 2015 6:36 PM
> * To:* Canvas; HTML Accessibility Task Force
> * Cc:* Dominic Mazzoni; Rik Cabanier
> * Subject:* camvas accessibility test results
>
>
> I ran all the remaining canvas tests that indicated the test information
> needed to be filled in. There were a total of 5.
>
> Dominique you should take a look at test case 5. Let me know if you want
> me to open a bug with Chrome.
>
> Net, net: Chrome passes all cases except the ability to remove the hit
> region in test 5 below (I can still mouse over it and get an accessible
> from the point). This did not result in the first hit region being removed
> and the second hit region (bounds) were off in the accessibility API
> mapping.
>
> Rik, A general bug I found with Firefox is that the paths drawn for the
> rectangles are consistently 4 pixels short on both width and height and is
> then reflected in the hit region and accessibility API mappings. This bug
> is a general canvas problem as it impacts drawing and not just hit testing.
> There may be a transform error.
>
> The last two tests did not print out the results of the mouse overs to
> reflect the ids associated on a mouse "hit". The test cases are incomplete.
> I saw timeouts being generated.
>
> I tested with:
>
>    - Version 46.0.2473.0 canary (64-bit)
>    - Firefox 39
>
>
>
> * 1. TODO addHitRegion receives a dictionary object whose id is null, and
> a previous region has a null id*
>
>
> *https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test#TODO_addHitRegion_receives_a_dictionary_object_whose_id_is_not_null.2C_and_has_a_non-null_control.2C_and_a_previous_region_having_the_same_control_exists*
> <https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test#TODO_addHitRegion_receives_a_dictionary_object_whose_id_is_not_null.2C_and_has_a_non-null_control.2C_and_a_previous_region_having_the_same_control_exists>
>
>
> Passes Chrome
> Passes Firefox
>
> * 2. TODO addHitRegion receives a dictionary object whose id is null, and
> a previous region has a null id*
>
> *https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test#TODO_addHitRegion_receives_a_dictionary_object_whose_id_is_null.2C_and_a_previous_region_has_a_null_id*
> <https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test#TODO_addHitRegion_receives_a_dictionary_object_whose_id_is_null.2C_and_a_previous_region_has_a_null_id>
>
>
> Passes Chrome and Firefox
>
> Also shows incomplete mapping in accessibility API as it should because
> the associated button is outside the canvas element region.
>
>
> * 3. TODO addHitRegion receives a dictionary object whose id is not null,
> with a non-null region, and a previous region for the id is not null*
>
> *https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test#TODO_addHitRegion_receives_a_dictionary_object_whose_id_is_not_null.2C_with_a_non-null_region.2C_and_a_previous_region_for_the_id_is_not_null*
> <https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test#TODO_addHitRegion_receives_a_dictionary_object_whose_id_is_not_null.2C_with_a_non-null_region.2C_and_a_previous_region_for_the_id_is_not_null>
>
> Passes in Chrome
>
> Firefox has a hit region on the first region that is not right but then
> again there are two regions having the same id and the second overrides the
> first. This is really an error condition as you have two hit regions having
> the same id so you would not be able to tell which object the hit test
> applied to if you had an event handler on canvas. I would consider this an
> author error although it is necessary that this be tested.
>
> Firefox has a width and height of the fallback button 4 pixels short of
> the 40 pixels.
> When the second, green rectangle (button 2), is drawn it also is 4 pixels
> short on the width and height and the first red rectangle (button 1).
>
>
> * 4. addHitRegion receives a dictionary object whose id is not null, with
> a non-null region, and a non-null control id where a previous non-null
> region, associated with this control, does exist in the hit region list but
> has a different id*
>
>
> *https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test#addHitRegion_receives_a_dictionary_object_whose_id_is_not_null.2C_with_a_non-null_region.2C_and_a_non-null_control_id_where_a_previous_non-null_region.2C_associated_with_this_control.2C_does_exist_in_the_hit_region_list_but_has_a_different_id*
> <https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test#addHitRegion_receives_a_dictionary_object_whose_id_is_not_null.2C_with_a_non-null_region.2C_and_a_non-null_control_id_where_a_previous_non-null_region.2C_associated_with_this_control.2C_does_exist_in_the_hit_region_list_but_has_a_different_id>
>
> This passed both Chrome and Firefox in terms of the accessibilitiy API
> mappings and locations on the screen. For some reason the test harness
> indicated a timeout although I am not sure why
>
> * 5. addHitRegion is called twice. The first call receives a dictionary
> object whose id is not null, with a non-null region, and a non-null
> control. The control is associated with a fallback <div> having a WAI-ARIA
> role="button" and descendant text. The second call receives a dictionary
> object whose id is not null, with a non-null region, and a non-null
> control. Both hit regions have distinctly different ids and controls. The
> control is associated with a fallback <a> having and descendant text. Each
> hit region is at distinctly different locations within the canvas. The path
> used to create each hit region is drawn on the canvas. Call
> removeHitRegion() for the ID of the first region.*
>
>
> *http://cptvitamin.github.io/wpt-canvas/2dcontext/hit-regions/removeHitRegion.TwoRegions-manual.html*
> <http://cptvitamin.github.io/wpt-canvas/2dcontext/hit-regions/removeHitRegion.TwoRegions-manual.html>
>
> Chrome:
>
> - FAIL: the hit region start location of the red rectangle (top left is
> off) in the accessibility API. The hit regions should have been removed. It
> was not.
> - the hit region start location of the green rectangle (top left is off)
> in the accessibility API
>
> - The test file did not implement the mouse handler to print the id's of
> the hit when you mouse over the squares.
>
> Firefox:
>
> PASS except for the consistent 4 pixel errors in widths and heights.
>
> The test harness indicated a time out. I am not sure why.
>
> Rich Schwerdtfeger
>
>

Received on Thursday, 6 August 2015 16:56:42 UTC