- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 29 Jul 2011 10:48:57 -0700
- To: Doug Schepers <schepers@w3.org>
- CC: "www-svg@w3.org" <www-svg@w3.org>
- Message-ID: <4E32F289.4010904@jumis.com>
On 7/29/2011 1:36 AM, Doug Schepers wrote: > Hi, Charles- > > Charles Pritchard wrote (on 7/28/11 7:02 PM): > >> Not much I can do there, but I do want to tell you that SVG is >> absolutely critical to my business: >> we need a standard file format, and that's SVG+InkML. I've made certain >> that our file output renders on iOS SVG. > > I don't understand quite why you feel InkML is so important, but I'm > interested in hearing more on it sometime. I work with an online drawing and writing: InkML is a standard for serializing pen input. "As more electronic devices with pen interfaces have and continue to become available for entering and manipulating information, applications need to be more effective at using this method of input." Pen pressure data, if available, is very important for legibility. Stylized effects such as "spray paint", can then be applied on the GPU for quick rendering of archived documents. I do not believe that ink was part of the SVG design goals. InkML traces can be uploaded to the GPU as WebGL vertex attributes: http://www.khronos.org/registry/webgl/specs/latest/#5.12 InkML tries for some programmable mapping, allowing mathml to be used: http://www.w3.org/TR/InkML/#mappings Those can be converted for WebGL in the vertex shader. Consider any program where user input alters the scene; with InkML, you may send the original SVG scene, with InkML user input, and redraw the result. This allows one user to say, grab a swimming fish, and move it around, and that action can be recorded and replayed with fidelity, without fancy work on the part of the SVG author. Rendering a scene based on InkML-style input is one of the primary reasons we have to be using Canvas as a live layer, instead of using SVG. If SVG had a closer relationship with InkML, it seems plausible that we could get much better rendering times with a much smaller generated DOM tree. >> by the still-immature field of web development. I very much will ensure >> that any new specification has WCAG in mind at every level. > > You're preaching to the choir, and I hope you noticed that we brought > people with different perspectives into the same room, and used > valuable SVG WG time to discuss Canvas accessibility for over an hour, > before I put forth the conclusion that SVG didn't need to do anything > there; I think at the end of it, everyone was much more comfortable > with your proposal than before, reservations notwithstanding. We did cover the ~three methods of Canvas accessibility: caret position, visual outlines on focused elements, and element location and dimensions, as they relate to a pie chart with a a table and buttons in the fallback content. I'm curious as to how the pie chart example we discussed would work in SVG. Unfortunately, we ran out of time to test that markup. I know that you have a table demo, using ARIA and tspan. I'd like to extend that demonstration to include a pie chart; where the table is non-visible, but can still be used by an AT. With canvas we do something like this: <canvas><table /></canvas> In SVG, where do you put that markup? Does it go in the metadata and/or desc element? <svg><g><metadata role="grid"><tspan /></metadata></g></svg> I know that we ran out of time. I was hoping to clear up that question about SVG a11y. > I happen to think that Canvas is the wrong tech for what you're doing, > but I'm not standing in the way of you trying to make it more > accessible. I have concerns that few will bother using the > accessibility hooks you are adding, while it's more natural to do with > SVG. Perhaps I'm wrong, but it doesn't matter either way. We can > make both SVG and Canvas more accessible; it's not a zero-sum game. Well, I'd like to see SVG better handle some of the tasks I encounter. I've brought up InkML. As for usage of accessibility hooks -- This is mostly a matter of authoring tools; low level coders will do what they will, but others using authoring tools should be encouraged within the tool to add accessibility annotations. Based on a sampling of content from OpenClipArt, it seems that Inkscape does not adequately encourage a11y. Lets get these SVG authoring tools to do an ATAG 1.0 review. http://www.w3.org/WAI/intro/atag.php -Charles
Received on Friday, 29 July 2011 17:49:47 UTC