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

Re: This thread is huge - suggested actions

From: Doug Schepers <schepers@w3.org>
Date: Sat, 09 Jul 2011 14:07:39 -0400
Message-ID: <4E1898EB.3040907@w3.org>
To: Maciej Stachowiak <mjs@apple.com>
CC: Charles Pritchard <chuck@jumis.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Charles McCathieNevile <chaals@opera.com>, Henri Sivonen <hsivonen@iki.fi>, Karl Dubost <karld@opera.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Hi, Maciej-

Maciej Stachowiak wrote (on 7/9/11 2:15 AM):
>
> This thread has now gotten very long. While much of it is useful
> discussion, I suspect at this point it is hard for many in the WG to
> follow, and I also see some points being repeated. At this point, I'd
> like to make a few suggestions:
>
> (1) When posting on this thread, consider carefully whether you are
> actually adding genuinely new to the discussion or just repeating
> points that were already made.
> (2) Consider condensing this discussion into specific bug reports.
> (3) Consider gathering data on the wiki, for example summarizing
> key points on the thread, or collecting use cases, or outlining a
> proposal.

Good point and good suggestions.

As to point (3), I have started on a few of these actions already:

(a) I have started a wiki page (Canvas Accessibility Use Cases [1]) to 
discuss the specific points on this thread; note that it does not deal 
directly with some of the other issues, like the subtree/shadowtree, 
focus ring, or text proxies, though I wouldn't mind if they were added.

The structure I used for this was to list a set of requirements, which 
is not quite a use case.  I also added some other points that Tab had 
drawn together, from the WHATWG wiki, using a slightly different 
structure.

(Note that I saw an exchange [2] between Ian Hickson, Tab Atkins, and 
Dmitri Glazkov that suggested a different structure for recording use 
cases; I don't think this is the only effective structure, especially 
since it only implicitly defines a few of a diverse multitude of 
possible uses that should be considered, but it does bring things down 
nicely to brass tacks, and if that's what satisfies those folks, it's a 
small thing to do to get on the same page, and stop the frustrating 
back-and-forth that so raises tensions.)

I invite everyone to edit this use-cases wiki page, to fill it out, to 
add different structures of use cases, to add clarifying or correcting 
points, and so on.  Having it all on one page may help define the issue.


(b) As stated, the SVG WG (including browser and authoring tool vendor 
reps) will begin work on a concrete proposal for tighter integration of 
SVG and Canvas; this is certainly not the only possible solution to the 
problems at hand, but it strikes me as one with a lot of broad 
potential, and it's the only one I'm personally interested in working 
on.  My initial proposal [3] was very hand-wavy, intended as a general 
approach and not a specific technical writeup; but there has been 
interest from several people on the tweetoblogosphere in it, and we can 
pretty easily write up a technical outline of what some of the 
possibilities and challenges are, and start down the road to a solid, 
implementable proposal.  I don't know how long this will take, because 
it will require implementation experience, but anyone interested in 
helping with this, or in SVG accessibility, is welcome to chime in on 
the SVG WG mailing list, www-svg@w3.org, where we do our technical work.

Until we have something concrete, I probably won't chime in on this list 
much, but I will try to monitor it.


[1] http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Accessibility_Use_Cases
[2]
[[
   when we're asking for problem descriptions we're asking for
   something like "Google+ wanted to make a widget that popped
   up an extensible list of checkboxes when you hovered over
   a rectangle whose colour represented whether any checkboxes
   were checked, but HTML had nothing like that so they made
   their own using <div>s and JS"
   ...
   or "Twitter wanted a drop down in a bar at the top of their
   screen that showed the user's profile pic and when clicked
   showed a menu, but there was no way to do that in HTML so
   they made their own using <div>s and JS"
   ...
   "I want to make a prettier checkbox in SVG that still acts
   like a checkbox for forms" is a very precise concrete
   problem exactly the kinds of things we need a list of so
   that we can make progress
]]
[3] http://schepers.cc/retain-a11y-immediately

Regards-
-Doug Schepers
W3C Staff Contact, SVG, WebApps, Web Events, and Audio WGs
Received on Saturday, 9 July 2011 18:07:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:26 UTC