Re: [SVG] Experiment and proposal

Hi Jim,

>>Anyway, how are you gonna "display" visual SVG information
>>being layout in tables to a blind person
>>or through a speech out program or similar ?
>>
>>It's kinda non-sense.
>
>No, it's not there's a lot of work done on image description, in any case,
>you're being way over simplistic that the issue is only relevant to the 
>blind.

So, to who else the description is relevant
to wget or lib-www scripts?

For any webcrawler, summarizer or similar table layout
can be computed to be irrelevant.

In fact, I've used some table layout paradigm to retrieve
content from websites using the same table template over and over.
Samething apply with CSS.

>>Accessibility could be solved by adding more information like
>>specifying that <table> is used for layout not for actual table'd data
>>for blind people or speech out.

>I think you need to do considerable research on accessibility, you've 
>already shown yourself unwilling to fully read the SVG spec before 
>pronouncing solutions to problems which are already solved.

I had a course and read few books on accessibility/usability,
but still I'm more concern about those than the majority
of people that I'm dealing with (programmers, managers, customers).

>>>An SVG viewer is not more capable, it's not a dynamic layout tool, it's
>>>whole design is based on achieving identical rendering, deviation from 
>>>this may be attractive, but it's certainly not an existing feature of the 
>>>spec in any way.
>>
>>It is possible already, it's just plain damn painful to achieve.
>>Just work out some madness JavaScript or ECMAscript and there you go.

>Actually it's not, because the user stylesheet is not exposed anywhere in
>SVG, and since you cannot access this you cannot do dynamic positioning 
>totally safely with javascript.

As I will repeat myself I don't care if people have their
own user stylesheet overriding, they will get an error message
and I cannot do anything about it.
But for the rest of us, who don't use such feature,
everything works perfectly.

>>BTW, all the 'text content' is created via JavaScript on the fly, without 
>>any external help.

>Oh dear, so it's reliant on javascript, which is a shame in accessibility,
>usability, and security terms too.

Well, for normal users, it is accessible.

My definition of 'normal user' accessibility:
- You can freely have control
  on any components and do whatever you want

- You can have keyboard shortcuts, tab control,
  without mouse usage for better efficiency

- You can type in, drag'n'drop, etc.

>> >>Do you see people doing that in HTML, no.
>>
>> >HTML has no layout semantics...  in CSS >(which I assume you're really
>> >discussing)
>>
>>HTML has layout semantics since decades way before CSS came out.
>>
>><center>

>Yes, and in modern HTML, such things have been _removed_ because it makes 
>content inaccessible, or less accessible to modern users, the older 
>technologies of semantic only HTML and CSS have come to fruition, CENTER 
>postdates CSS languages (although widespread take up of HTML 3.2 came 
>before widespread
>takeup of CSS)

I'm still generating pages for Transational HTML
<!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN">

The only way to be sure that it works on any browser,
with <font><center><div align='center'>
and CSS for the modern ones.

This is what I called accessible, it doesn't matter,
what kind of crappy browser you may use (2% to 5% website viewer),
you can still see the website properly, which is way more important
then your argumentation.

>> >I see a lot of people precomputing bounding boxes, and meeting
>> >many positional problems.
>>
>>Why computing bounding boxes, with HTML <Table>
>>the table WILL scale to the largest cell, so there's no need.

>I think because most people are now aware that many countries of the world 
>have requirements to make their content accessible, and TABLE for layout 
>will generally invalidate any "best practice" >defense as it's clearly 
>described as being inacessible.

I think most people are NOT aware that many countries...
If you have a formal IEEE papers, URL, newspaper articile or similar
describing this problem let me know, so I can look into it.

>>I read two books on SVG and some of the documentation,
>>but the big problem is that SVG tutorials looks like
>>a cartoonist/flash/animation approach,

>Please read the specification, you've missed huge areas (data:, viewbox 
>etc.) books can miss stuff, >and I've never seen a cartoonist tutorial,

I know viewbox, the book didn't cover data:, but data: is useless to me.
IMHO, converting a PNG into <rect> and compressing it via gzip,
is more efficient than downloading the PNG itself, not counting
the 4/3 ratio of BASE64 encoding.

viewbox is still useless to me now.


>>Doug has rightly corrected me in that letters are not simply images, only
>>the images used to symbolise those letters are (the glyphs)
>
>True, but sometimes text-selection should be prohibited temporarily or
>permanently.
>For instance, on buttons or while doing a drag and drop.

>What's that got to do with anything?  SVG provides such hints,

SVG provide hints????? HOW?
How can I disable text selection!

>without doing anything to break the accessibility, your suggestions however 
>do lots to break accessibility.

No, I'm suggesting to OBTAIN accessibility, not to break it.

You find it accessible you to have
a button which you can select the text?

You find it accessible to drag a table filled of text
and having the text highlighting going on and off
and giving you a text cursor instead of a move cursor?

That's not how Windows/Gnome/KDE/MacOS application works, far from it.

Would you find it USABLE you to be able to highlight the text
inside your "START" button or to highlight the text inside
the "OK", "CANCEL", "PREV", "NEXT" button?

Would you find it usable to have a MENU with
"FILE, EDIT, VIEW, FAVORITE, HELP"
that is highlightable and selectable.

No it's not, it's not the normal behavior.
I'm asking for a way to get CORRECT NORMAL behavior,
not ruin accessibility of people but perhaps increasing it.

Even when you look at:
http://www.xfront.org/svgdemo/

You have that problem with "EDIT, DELETE, SUBMIT".

>>It's like having javascript disabled on a javascript heavy site...
>>samething.

>I have some hugely javascript heavy sites, and they degrade gracefully, as 
>I say many people don't have the option of ignoring such users, and there 
>are many good techniques to include them, the specs are also doing a lot to 
>support us in this.

Well, that's too bad for them.
That's their right to disable it,
but I cannot have a web application without javascript.

Most web application 99% use javascript, VBscript or JScript,
else they are considered unaccessible and difficult to use
web application, because you cannot have shortcuts,
dynamic content, content verification, etc.

> >That is a near impossible task >(it could only realistically achieved by
> >rasterising the SVG image, and then using >OCR to read back the text - it
> >would require significant processing overhead, and be extremely
> >error-prone.)
>
>NOT OCR, I was talking about having a SVG picture with text not selectable
>by style-sheet let say
>and have an XML babelfish to spit out something like this:
>
><text>Long life to SVG file format</text>
>translator EN-FR
><text>Longue vie au format de fichier SVG</text>

>That doesn't work... positioning is absolute, therefore the position of a
>character of text or word in one block may have little or no relation to 
>the sentance - please think about it, or look at a few SVG >documents.

You don't understand. Okay in simple words:

I was proposing to have text selection disabled.
The person said that translation would not be possible
I proved that it could since text is still text inside SVG,
even though it is use as an 'image' and could still be translated.
It has nothing to do with positioning.

>>But what I was saying even tough you disable the text selection
>>the translator could still spit out translated text.

>Where did this "disable text selection" come from?  I've never suggested 
>it,
>such a hint is as you say wholly irrelevant to accessibility.

I suggest it. No it's to INCREASE accessibility,
remember buttons and text selection?

>>>You're confusing usage with defined for, it's never been defined for that
>>>(HTML is simply not about layout, it's purely about semantics.)
>>
>>It doesn't matter if it was defined for what or for who, the point is,
>>it works it's used therefore it's the new definition for it. Period.

>Your assertion that it works, is unfortunate as the majority of opinion 
>I've
>seen has shown convincing argument that it does not - if you would like to
>show some evidence to the contrary, I'm sure the WAI groups would be glad 
>to
>hear it - I suggest you actually do some background reading first.

WAI == W3C Web Accessibility Initiative.

Web Content Accessibility Guidelines 1.0
http://www.w3.org/TR/WAI-WEBCONTENT/

1. Provide equivalent alternatives to auditory and visual content.
use ALT, TABLE SUMMARY, etc.

2. Don't rely on color alone.
That's normal, more over don't have more than 7 distinctive color,
don't create fuzzy color effect, red on blue and similar,
have high contrast.

3. Use markup and style sheets and do so properly.
I use both so it works on any browser.

4. Clarify natural language usage
I normally try to use proper formal language, so that people
can use Babelfish to translate my site in a nearly readable way.

5. Create tables that transform gracefully.
That's is valid for table which are TABLE,
but people are using TABLE for layout, you could always
like I said provide a table summary saying 'table layout'.
If you don't like the <table><tr><td> tags in SVG
replace it with <grid><grid-row><grid-col> and provide them.

6. Ensure that pages featuring new technologies transform gracefully.

6.1 Organize documents so they may be read without style sheets
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why I'm not surprised???
It's stated right there, don't use CSS style-sheet only webpage!!!

6.3 Ensure that pages are usable when scripts, applets, or other 
programmatic objects are turned off or not supported. If this is not 
possible, provide equivalent information on an alternative accessible page.

i.e. error page or static document.

I normally put <!-- -->
withing <SCRIPT> and provide <NOFRAME> <NOSCRIPT> things

as suggested in 6.5

7. Ensure user control of time-sensitive content changes.

7.4 Until user agents provide the ability to stop the refresh, do not create 
periodically auto-refreshing pages. [Priority 2]
For example, in HTML, don't cause pages to auto-refresh with 
"HTTP-EQUIV=refresh" until user agents allow users to turn off the feature.

That is something that I have no control over it
and I cannot do much about it apart providing a refered link,
for those disabling it.

8. Ensure direct accessibility of embedded user interfaces.

Currently, I've got no way to check this.

9. Design for device-independence.

9.4 Create a logical tab order through links, form controls, and objects. 
[Priority 3]
For example, in HTML, specify tab order via the "tabindex" attribute or 
ensure a logical page design.
Techniques for checkpoint 9.4

This is something I have in my accessibility list.

9.5 Provide keyboard shortcuts to important links (including those in 
client-side image maps), form controls, and groups of form controls. 
[Priority 3]
For example, in HTML, specify shortcuts via the "accesskey" attribute.

This is something I have in my accessibility list.

10. Use interim solutions.
i.e. Use interim accessibility solutions so that assistive technologies and 
older browsers will operate correctly.

In order words, use HTML 4.0 transational if you can.

11. Use W3C technologies and guidelines.

Don't use FLASH, PDF or similar, but that's quite rough.
11.2.2 User overriding CSS --> I cannot do anything about it.

12. Provide context and orientation information.
13. Provide clear navigation mechanisms.
14. Ensure that documents are clear and simple.

Normal stuff.

>>Whatever, I say is practical,
>>I could use it yesterday to do some serious
>>application stuff
>>instead of using SVG for stupid cartoonist scalable animation crapt.

>I do application stuff in svg (image annotation, presentations, maps etc),

That's the usual SVG stuff, like:
http://www.xfront.org/svgdemo/

What about converting a native Windows application or Solaris application 
into a web page using SVG/JavaScript,
instead of DHTML/JavaScript with Perl5/PHP4/ASP/JSP ?

>SVG's can't do accessible applications yet, but it can't do a lot.

Yes it can, I can do it, it's just damn painful,
and there is glitch here and there,
and that's why I'm participating
to this message thread so heavilly.

>>So, it's a problem for database
>>generation without gzip compression

>Well doing the gzip would seem the easiest solution, after all, it's 
>trivial to implement in apache, and IIS 5 for example)

Easy solution when you have your own Apache/ISS server.

Most ISP won't provide such feature, in fact it's hard to get
PHP4,Perl5,ASP or JSP on some of them.

I had situation where I had to translate a project from Perl to PHP,
because the ISP didn't want to support Perl for security reasons.

I can tell you two things about Production Server:
Once it's working you are NOT allowed to modified it
for any damn good reason, even if your 250,000$ project
rely on loading a new module.

  (We had a senior admin who screwed up an Apache server,
   we never knew what went wrong
   and we were not able to get up and running before few days.
   Guess what the company lost 1M$ in lost of revenue,
   because 30 departments and 500 peoples where heavilly relying on it.
   The company bought a redundant server after that event.)

> >No, as we've discussed, this is already provided for in SVG!  data:
> >viewBox
> >etc. etc.
>
>I couldn't find any PERFECT bitmap image converter to SVG.

>That's because bitmaps are not vector data, SVG is.


>>Anyway the following stats might prove my point:
>>   MSIE 5         5894     53.46%

I assume these are trillions or something,
as anything else is much too small to be from a relevant source.

Well, I checked most sites and that's our user based,
it might be irrelevant to you, but it is relevant for us.
Get statistic about your user base and optimize your site for 99% of them.

>> >HTTP response codes in the region of 300-309
>>
>>I rarely got across those code, mostly 404 and 500 stuff.
>>What are those for?
>
>Please read specifications, they really are the place to start.

Thanks for the RTFM reply,
and you talk about accessibility/usability? Let me laught.

>>Okay, but I don't care about line modes neither,
>>some other might perhaps.

>So because you don't care the specs should ignore those?

Jim, I said I don't care, I never said the specs should ignore those,
I specified in this thread many times, other might care it should work for 
them.

Still, having a CSS stylesheet with style="text-selection: disabled;" would 
be a good thing,
for buttons, menus and SVG widgets.

Moreover, having <table><tr><td> equivalent lets called them
<grid><grid-row><grid-col> to make you happy, would also be a good thing.

Sincerely yours,
Fred.




_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

Received on Saturday, 26 April 2003 17:32:10 UTC