Re: Alternative Canvas proposal from Charles

As long as we keep replying to all we should be fine. I have some questions
below for Charles.

Rich Schwerdtfeger
CTO Accessibility Software Group

James Craig <jcraig@apple.com> wrote on 06/21/2010 04:29:46 PM:

> From: James Craig <jcraig@apple.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS, David Bolter
> <david.bolter@gmail.com>, Michael Cooper <cooper@w3.org>, Janina
> Sajka <janina@rednote.net>, Charles McCathieNevile
> <chaals@opera.com>, Cynthia Shelly <cyns@exchange.microsoft.com>,
> Steven Faulkner <faulkner.steve@gmail.com>, Frank Olivier
> <franko@microsoft.com>, public-canvas-api@w3.org, HTML Accessibility
> Task Force <public-html-a11y@w3.org>
> Date: 06/21/2010 04:29 PM
> Subject: Re: Alternative Canvas proposal from Charles
>
> Discussion was off list for a little while. Bringing back to the
> list with Charles' permission.
>
> Note: I'm not subbed to the HTML ATF list, so this may or may not
> make it to that list. I'm only following public-canvas-api regarding
> this subject.
>
>
> On Jun 21, 2010, at 1:48 PM, Charles McCathieNevile wrote:
>
> > …feel free to re-post as much/little as you like to the group...
> >
> > On Mon, 21 Jun 2010 13:00:24 -0700, James Craig <jcraig@apple.com>
wrote:
> >
> >>
> >> On Jun 18, 2010, at 11:26 PM, Charles McCathieNevile wrote:
> >>
> >>> On Fri, 18 Jun 2010 22:59:10 +0200, James Craig <jcraig@apple.com>
wrote:
> >>>
> >>>> However, I do not believe image   maps are sufficient for complex
> >>>> examples of applications rendered in canvas, because there is no
concept
> >>>> of DOM hierarchy between image map areas.
> >>>
> >>> It sounds like you haven't read the proposal completely in its
> most recent version, because it includes extending image maps along
> the lines of HTML 4.01 precisely for this reason. (It is sort of
> possible to get a structure using HTML 4.01 - or the HTML5 model
> except that as far as I can see that doesn't work in any software.
> But making it easier would make more sense).
> >>

To Charles: One concerns I have with only using are map elements is
aria-activedescendant. Say I have a list box and I want to draw visible
focus on list box items managed by its parent. You really don't want to put
the list items in the tab order. So,
<map>
<div role="listbox" aria-activedescendant>
   <div role="option" id="op1">guacamole</role>
   <div role="option" id="op2">queso</role>
...

</div>
</map>
Were you thinking about placing a map around the option with a shape?
<map>
<div role="listbox" tabindex="0" aria-activedescendant="op1">
   <div role="option" id="op1" shape="rect" coords="">guacamole</role>
   <div role="option" id="op2" shape="rect" coords="">queso</role>
...

</div>
</map>

I am trying to see how this would work. Which focus shape gets drawn? I
don't want it to be the list box. Hence, do we really want to dump the
rectangle drawing function?

The second problem is switching the desktop to large fonts or switching to
high contrast mode. If we hard code the coordinates isn't this going to be
an issue. Ideally we would want to have the coordinates be a function of em
height.


> >> <!ELEMENT MAP - - ((%block;) | AREA)+ -- client-side image map -->
> >> http://www.w3.org/TR/REC-html40/sgml/dtd.html

> >>
> >> I must admit I had never noticed that HTML 4.01 allowed block
> content in MAP.
> >
> > In HTML 4.01 only area elements or a elements can have shapes/
> coords attributes, which is why the change proposal now adds them to
> every element. As noted, that is slightly overkill, but if they are
> not inside a map they simply have no effect so I don't *think* it is
> problematic, and it seems simpler than listing them for "almost
> every element...".
>
> This sounds to me like the idea is to keep the "shadow DOM" idea,
> but have the accessible tree as a descendant of the MAP element
> rather than inside the CANVAS element directly. Is that correct? If
> so, I like it. Simple cases could use plain old AREA siblings, but
> more complex examples could have as deep a DOM tree as needed.
>
> > So in HTML 4.01 you would have to use a elements for a lot of
> stuff, which still lets you do things like make
> >
> > <p contenteditable><a href=# onclick="foo()" shape="rect"
> coords="...">This is a fake form
>
>
> Why an anchor and not this?
>
> <map …>
> <p contenteditable tabindex="0" role="textbox" onfocus="foo()"
> shape="rect" coords="...">This is a fake textfield
> </map>
>
> James
>
> PS. I also appreciate that this will allow polygons, which were
> dropped from the previous proposal.
>