RE: SVG 1.2 Comment: Detailed last call comments (all chapters)

Hi, Ian-

| > | XHTML2+XForms, for example, is capable of being fully 
| usable in such
| > | diverse environments, and in fact is so usable by default
| > 
| > No more so than SVG. Are you seriously claiming that XHTML 
| is somehow 
| > more able to be leveraged for speech UAs?
| 
| Are you seriously claiming that it isn't?!
| 
| SVG:
|    <rect x="10" y="10" width="100" height="100" onclick="doit()"/>
|    ...
|    <text x="10" y="10">Test</text>
| 
| XHTML1 (or HTML4, for that matter) [1]:
|    <button onclick="doit()">Test</button>

Don't be disingenuous. You said XHTML2+XForms. My argument from the
beginning has been that SVG would be the presentation layer, and that the
semantics should be derived from the underlying language represented.

This is equally accessible in either language:
 <xforms:submission id='submit' action='http://w3c.org/submit' method='post'
/>
And with sXBL, we'll be able to do that legitimately in SVG.

For now, we have to do something like this:
 <rect x="10" y="10" width="100" height="100" onclick="doit()">
  <title>Test Button</title>
  <desc>This button chops, slices, and dices.</desc>
 </rect>
 <text x="10" y="10" pointer-events="none">Test</text>

In an appropriate UA (which had to be made for HTML, too, but HTML has the
advantage of age), this would be almost as accessible.


| In a speech-driven UA, the XHTML version can _trivially_ be 
| implemented by saying something along the lines of "Button: 
| Test" and then saying "Test" 
| will cause the voice-recognition software to automatically invoke the
| doit() function (by invoking a 'click' event on the button element).

And what does "Test" do? That's equally obscure in either language. In some
cases, this can be resolved by using XForms, as in my example above, where
the meaning is derived from the tagname; in other cases, metadata would be
necessary to make the purpose explicit.

Incidentally, I don't think that 'button' is a valid element in XHTML2,
which is what we had framed as a counterpoint to SVG. Buttons in both are
merely imports from Xforms, which is how it should be; forms have no place
in HTML. SVG has no widgets (which is how it should be), so we need sXBL to
help us bind form elements and controls to visual representations and
appropriate behaviors.


| The SVG version, however, gives the speech-driven UA no clue 
| whatsoever that the button is a button, that the text is 
| associated with the button, etc. There are, in fact, strictly 
| no semantics involved.

Yes, that's exactly the point. SVG is a presentation layer, and needs the
features to adequately represent semantic XML.


| This isn't hypothetical. There are speech-based browsers for 
| HTML. I have even heard of dynamic braille-based HTML browsers.

Using the IE speech plugin, I made an accessable SVG calculator [1], and
I've seen dynamic braille-based mapping applications [2]. My calculator is
experimental, the map is production. With better a better specification and
better UAs, my experiment could be standard.

Regards-
-Doug

[1] http://schepers.cc/walkingtalkingsvg.html
[1] http://www.svgopen.org/2003/proceedings.html#paper27

Received on Thursday, 4 November 2004 05:13:23 UTC