Re: 2nd Call: SVGt1.2: Text Box

Doug

 >>Except in environments or UAs where script does not work, the  
script methods (while admittedly harder to author),
aywk: many people whether using assistive technology or not choose to  
turn scripting off.

 >>you should rely on HTML
as described below** this is not suitable

 >>You could, for example have a set of shapes
please try out http://www.iconomy.org/ in opera, batik or amaya

regards

   
Jonathan Chetwynd

j.chetwynd@btinternet.com
http://www.peepo.com/

+44 (0) 20 7978 1764



**embedded is most likely to be unsuitable in most instances, as not  
only are there significant accessibility issues regarding embedding  
documents, but only part of the document will be redirected, this may  
be inconvenient for the user and author, and makes a mockery of  
bookmarking. you may for instance try navigating http:// 
peepo.getmyip.com/~JonathanChetwynd/db/search080318.php?search=z

There is limited support for documents with mixed namespaces, and  
there remain significant accessibility problems navigating documents  
using mixed namespaces. I am not aware of any accessibility  
guidelines for such documents.
It seems unlikely these issues will be resolved in the short term.
On 18 Mar 2008, at 21:25, Doug Schepers wrote:

Hi, Jonathan-

~:'' ありがとうございました。 wrote (on 3/18/08 3:33 PM):
> SVGt1.2: Text Box
> Would it be reasonable to expect SVG1.2t to provide a standard and  
> easy to implement means for the user to enter text - to send  
> content to the server** -?

No, sorry.  SVG 1.2 Tiny is feature-complete, and has been for a long  
while now.  The only changes that can be made now are minor  
adjustments based on implementor feedback.


> HTML has provided an accessible form with textbox for many years.
> Reliance on methods that use script produces results that are not  
> known to be accessible.

Nor are they known to be inaccessible.  Except in environments or UAs  
where script does not work, the script methods (while admittedly  
harder to author), are no less accessible than declarative methods  
(like forms).  They use the same HTTP commands (GET and POST), and  
interact with the server the same way, except that with XHR (or get/ 
postURL), the browser does not navigate you to a new page; if you  
wish to navigate to a new page, simply compose a URL string and  
create (or change) a link (that is, the value of the xlink:href).   
There are libraries out there that encapsulate all of this for you.

Can you explain a manner in which these methods are inaccessible?

I myself would like to have a declarative solution, and it's possible  
that some future specification (whether from the SVG WG or another  
one) could define such a thing that would work with SVG to provide a  
declarative method for this and other use cases.  It might derive  
from XForms, but be a narrower, simpler model to implement.  But it's  
unlikely that this will occur in the next year or two.

In the meantime, if you must have a declarative means for data  
submission (for whatever reason), you should rely on HTML, and  
perhaps on ARIA (since this looks like it will be implemented in all  
major browsers).  I don't know if they have considered SVG elements  
as values for inputs, but it's possible. [1]

Of course, there is also the simplest declarative form, as you  
mentioned before: the link.  You could, for example have a set of  
shapes, say a circle, triangle, and hexagon, and make each a link to  
a CGI handler with the proper argument encoded in the URL,  
effectively making a POST submission.  That does not satisfy your  
request for text submission to a server, however.


> **
> Amaya does not support script

Amaya is not a browser, per se.  By its own claims, it is an  
"authoring tool with browsing features." [2]

"II.14. Does Amaya support JavaScript and animated images?
Due to a lack of manpower, we have no plan to implement them. These  
features are more important for a browser than for an editor." [3]

It does meet the requirements for a static SVG viewer, but not a  
dynamic SVG viewer. [4]  Perhaps you could file a feature request to  
support script, or XForms, or some other declarative solution with  
Amaya.


[1] http://www.w3.org/TR/wai-aria/#input
[2] http://www.w3.org/Amaya/User/FAQ.html#L125
[3] http://www.w3.org/Amaya/User/FAQ.html#II12.
[4] http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGViewers

Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Received on Wednesday, 19 March 2008 09:28:37 UTC