Re: hit testing and retained graphics

Cameron McCormack:
> > I think I may have misunderstood the proposal, but I am a bit
> > confused now.  Clicking on the canvas at a particular point that has
> > been associated with the <select> wouldn’t cause the native <select>
> > element to have its menu drop down, then, or cause any change in
> > what selected value is?  Is it up to the script author to listen for
> > a mousedown/mouseup event on the <select> and modify its value in
> > response to that (emulating the native behaviour of the element)?

Charles Pritchard:
> It's up to the script author to detect focus and activation of the
> select element, and in doing so, change its appearance and its
> associated path data;

I think I understand this part.  The script listens for changes in the
state of the native <select> element and then repaints the canvas with
the new selected value or what have you.

> the same holds true for child objects of the select element in the
> world of ARIA; though in HTML5, child elements are opaque.

The child objects as in the <option> elements, right, their “selected”
value can change as you interact with the <select>.

I don’t know where the automatic routing of events from the <canvas> to
the <select> comes in, though.  Here is how I am imaginging things work,
tell me if I’m wrong:

If a sighted user does a mouse down on the <canvas> on a region that you
have identified as corresponding to the <select> in the subtree, does
that event get dispatched instead to the <select>?  In this situation,
the <select> isn’t being rendered, so I guess it doesn’t result directly
in values being changed, a drop down popping up, or anything.  The
script author looks at the mouse event’s coordinates to determine how
the in-canvas representation of the form control is being manipulated.

If it’s a sighted user with a magnifier running, things would be the
same.  The only difference is that the “focussed area” of the <canvas>
(through knowledge of which canvas subtree element is focussed and the
association of the element and the path) is used to magnify the screen
over that area.

If it’s a blind user, the <canvas> isn’t visually presented; instead
it’s the canvas subtree that is presented.  Mouse events aren’t
dispatched.  Normal tabbing between form elements and interacting with
them as the user would with a static HTML form is done.

> > I wonder if (and maybe this is similar to what we discussed earlier
> > on www-svg) having an aria-region (or whatever named) attribute on
> > the shadow tree element is a simpler, more direct way of associating
> > the region of the <canvas> that has the focus.
>
> Yes, I brought it to SVG looking for feedback and possible re-use. If
> it's in the DOM, ATs can see it. If it's not in the DOM, but it's sent
> via method call, ATs can see it. It's imperative that ATs can see it.
>
> In talking with various developers, and in line with the motivations
> of many spec editors and vendors, it seems that adding functionality,
> such as the binding methods we've put forward, creates more incentive
> for all parties to include the methods.

To me, it seems like authors already need to do a whole bunch of
additional work to make their canvas-based application accessible, by
including the subtree and making interactions with the canvas modify the
state of the subtree elements and vice versa.  If they are going to that
effort, then to me it seems simpler just to set the aria-region
attribute on each subtree element to indicate the area the magnifier
should zoom to, rather than associating a specific path that was created
on the canvas context with a particular element.  But I’m no expert in
this area, so I’ll leave this judgement to others.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 24 June 2011 04:13:14 UTC