FLASH and W3C

[Jim Ley]

Re: FLASH and W3C

On Sat, 06 Sep 2003 17:05:40 +0200, Zak McGregor <zak@mighty.co. za>
wrote:
[color=blue]
>On Fri, 05 Sep 2003 16:51:03 +0200, Jim Ley <"Jim Ley"
><jim@jibbering .com>> wrote:
>[color=green]
>> Certainly with Flash that is relatively hard to achieve, especially in
>> reality, rather than theory, but it's no harder than with SVG[/color]
>
>Nonsense. As SVG is a W3 supported effort and its development is open for
>participatio n there is a huge difference in its accessibility.[/color]

Would you care to actually help show that and actually help me author
accessible documents, rather than just asserting it?
[color=blue]
>Software
>licenses can be as large an impediment to viewing content as a physical
>issue.[/color]

Well as there are open source SWF->SVG converters knocking about, I
don't actually think those issues can be much of an impediment.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Zak McGregor]

Re: FLASH and W3C

On Sat, 06 Sep 2003 18:34:46 +0200, Jim Ley <"Jim Ley"
<jim@jibbering. com>> wrote:
[color=blue]
> On Sat, 06 Sep 2003 17:05:40 +0200, Zak McGregor <zak@mighty.co. za>
> wrote:
>[color=green]
>>On Fri, 05 Sep 2003 16:51:03 +0200, Jim Ley <"Jim Ley"
>><jim@jibberin g.com>> wrote:
>>[color=darkred]
>>> Certainly with Flash that is relatively hard to achieve, especially in
>>> reality, rather than theory, but it's no harder than with SVG[/color]
>>
>>Nonsense. As SVG is a W3 supported effort and its development is open
>>for participation there is a huge difference in its accessibility.[/color]
>
> Would you care to actually help show that and actually help me author
> accessible documents, rather than just asserting it?[/color]

You mean you can't work out how a proprietary, binary-only format
technology is inherently less accessible than an open format?
[color=blue][color=green]
>>Software
>>licenses can be as large an impediment to viewing content as a physical
>>issue.[/color]
>
> Well as there are open source SWF->SVG converters knocking about, I
> don't actually think those issues can be much of an impediment.[/color]

Methinks the point could have been as big as the proverbial Greyhound Bus
and you'd *still* have missed it, simply because you want to.

Ciao

Zak

--
=============== =============== =============== =============== ============
http://www.carfolio.com/ Searchable database of 10 000+ car specs
Auctioning motoring-related items at eBay? http://www.carfolio.com/ebay/
=============== =============== =============== =============== ============

[Jim Ley]

Re: FLASH and W3C

On Sun, 07 Sep 2003 21:36:28 +0200, Zak McGregor <zak@mighty.co. za>
wrote:
[color=blue]
>On Sat, 06 Sep 2003 18:34:46 +0200, Jim Ley <"Jim Ley"
><jim@jibbering .com>> wrote:[color=green]
>> Would you care to actually help show that and actually help me author
>> accessible documents, rather than just asserting it?[/color]
>
>You mean you can't work out how a proprietary, binary-only format
>technology is inherently less accessible than an open format?[/color]

Binary does not mean inaccessible that's a complete myth, that would
be like saying a gzipped SVG is less accessible than one that wasn't.
Openness doesn't make a format accessible, having features which
enable accessible authoring does. There are a number of problems with
SVG, things like User Stylesheets being unusable as they make content
inaccessible (e.g. http://jibbering.com/2002/8/text-mixup.svg ) the
inability to define a reading order that's independant of the
rendering order, the inability to provide a navigation index order
independant of the reading order, they're just a few, there's a number
of others, some others at

http://jibbering.com/2002/8/svg-problems.html

It's all being worked on, and the WG take accessibility very
seriously, they do care, but it's a very difficult job. Flash takes
alternative approaches to these issues (text isn't text which means
you can entirely define your text equivalent reading order seperately
from the other content, this prevents the confusion you get in SVG
with reading order.)

Solve a few problems in SVG, and SVG will be a long way ahead of flash
but right now, it's not there, by 1.2 it will be.

On tool support SVG has an advantage to english speaking geek
accessible needs as a geek can view the source and guess if they speak
English what's going on. That's hardly much of a demographic though.

I'm certainly trying to help SVG become more accessible, but deluding
oruselves that it just is because it's not binary, and it's got a W3
stamp doesn't help anyone, it just provides the sort of hype-myth you
get with XHTML 1.0 being better than HTML 4.01.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Isofarro]

Re: FLASH and W3C

Zak McGregor wrote:
[color=blue]
> On Sat, 06 Sep 2003 18:34:46 +0200, Jim Ley <"Jim Ley"
> <jim@jibbering. com>> wrote:
>[color=green]
>> On Sat, 06 Sep 2003 17:05:40 +0200, Zak McGregor <zak@mighty.co. za>
>> wrote:
>>[color=darkred]
>>>On Fri, 05 Sep 2003 16:51:03 +0200, Jim Ley <"Jim Ley"
>>><jim@jibberi ng.com>> wrote:
>>>
>>>> Certainly with Flash that is relatively hard to achieve, especially in
>>>> reality, rather than theory, but it's no harder than with SVG
>>>
>>>Nonsense. As SVG is a W3 supported effort and its development is open
>>>for participation there is a huge difference in its accessibility.[/color]
>>
>> Would you care to actually help show that and actually help me author
>> accessible documents, rather than just asserting it?[/color]
>
> You mean you can't work out how a proprietary, binary-only format
> technology is inherently less accessible than an open format?[/color]

Well, I can't. Please explain.


--
Iso.
FAQs: http://html-faq.com http://alt-html.org http://allmyfaqs.com/
Recommended Hosting: http://www.affordablehost.com/
Web Standards: http://www.webstandards.org/

[Zak McGregor]

Re: FLASH and W3C

On Sun, 07 Sep 2003 21:49:11 +0200, Jim Ley <"Jim Ley"
<jim@jibbering. com>> wrote:
[color=blue]
> On Sun, 07 Sep 2003 21:36:28 +0200, Zak McGregor <zak@mighty.co. za>
> wrote:
>[color=green]
>>On Sat, 06 Sep 2003 18:34:46 +0200, Jim Ley <"Jim Ley"
>><jim@jibberin g.com>> wrote:[color=darkred]
>>> Would you care to actually help show that and actually help me author
>>> accessible documents, rather than just asserting it?[/color]
>>
>>You mean you can't work out how a proprietary, binary-only format
>>technology is inherently less accessible than an open format?[/color]
>
> Binary does not mean inaccessible that's a complete myth, that would be
> like saying a gzipped SVG is less accessible than one that wasn't.[/color]

You are wrong. To put it simply, if you don't have a gunzip program on
the other end, you can't process the gzipped SVG content. So you rely on
the receiving end having SVG client _plus_ gzip handler. Suppose that the
gzip handler program did not in fact have a non-restrictive license, and
suddenly you have a license impediment to content. Did I really have to
explain this to you? Flash _has_ a restrictive license. In order for me
to use a Flash plugin, I have to resort to one generations behind (I
forget what it was called, but it was GPLd and did Flash V4 or so), or
give up my rights and agree to the Macromedia license for their plugin.

Flash being binary format means that without a Flash plugin on my
machine, I cannot even access the bare text of whatever is being
presented. Had it been a text format, I could read the content in a
number of ways.

Further, their Flash implementation and development is entirely in their
hands, and is for the most part a closed process.
[color=blue]
> Openness doesn't make a format accessible, having features which enable
> accessible authoring does. There are a number of problems with SVG,
> things like User Stylesheets being unusable as they make content
> inaccessible (e.g. http://jibbering.com/2002/8/text-mixup.svg ) the
> inability to define a reading order that's independant of the rendering
> order, the inability to provide a navigation index order independant of
> the reading order, they're just a few, there's a number of others, some
> others at
> http://jibbering.com/2002/8/svg-problems.html[/color]

Sure, SVG may have its problems. But it starts off on the right footing.
Flash however immediately starts off on the wrong footing and cannot
right itself except by opening itself up - Macromedia will never do this
unless they suddenly get management With a Clue [TM].

[snip]
[color=blue]
> Solve a few problems in SVG, and SVG will be a long way ahead of flash
> but right now, it's not there, by 1.2 it will be.[/color]

I assume these issues are at the spec level. Well, you have the option to
participate in the development, not so?

[snip]
[color=blue]
> I'm certainly trying to help SVG become more accessible, but deluding
> oruselves that it just is because it's not binary, and it's got a W3
> stamp doesn't help anyone, it just provides the sort of hype-myth you
> get with XHTML 1.0 being better than HTML 4.01.[/color]

I'm not saying that the W3C is without issues, or that opening protocols
and formats up automatically makes their problems disappear. That would
be foolhardy. Rather, I am saying that proprietary formats immediately
disqualify themselves from being accessible by restrictive licenses.

Ciao

Zak

--
=============== =============== =============== =============== ============
http://www.carfolio.com/ Searchable database of 10 000+ car specs
Auctioning motoring-related items at eBay? http://www.carfolio.com/ebay/
=============== =============== =============== =============== ============

[Jim Ley]

Re: FLASH and W3C

On Mon, 08 Sep 2003 00:21:34 +0200, Zak McGregor <zak@mighty.co. za>
wrote:
[color=blue]
>On Sun, 07 Sep 2003 21:49:11 +0200, Jim Ley <"Jim Ley"
><jim@jibbering .com>> wrote:[color=green]
>> Binary does not mean inaccessible that's a complete myth, that would be
>> like saying a gzipped SVG is less accessible than one that wasn't.[/color]
>
>You are wrong. To put it simply, if you don't have a gunzip program on
>the other end, you can't process the gzipped SVG content. So you rely on
>the receiving end having SVG client _plus_ gzip handler.[/color]

A conforming SVG viewer must handle gzip compression, if it doesn't
it's not an SVG client. (*) If you're going to make comments on the
accessibility of SVG, I strongly advise reading the spec.
[color=blue]
>Flash being binary format means that without a Flash plugin on my
>machine, I cannot even access the bare text of whatever is being
>presented.[/color]

Bear text doesn't give you anything, and can with SVG give you the
exact opposite meaning, since you can't control the reading order and
the rendering order independantly. You also need to understand the
SVG elements to get anything.
[color=blue]
>Further, their Flash implementation and development is entirely in their
>hands, and is for the most part a closed process.[/color]

Yes, not good, but irrelevant to accessibility, which is all we're
concerned about in this thread- You'll note that I do a lot in the SVG
world, and very little in the flash world, I don't think flash is a
good platform, but that doesn't make it any differently accessible to
SVG.
[color=blue]
>I assume these issues are at the spec level. Well, you have the option to
>participate in the development, not so?[/color]

Again, I feel you aren't looking that much at what is going on in the
SVG world, I have numerous issues on the spec, I review every draft, I
make formal suggestions on the list, and others through IRC and
similar, I try and get members of the WG drunk so they give me what I
want, short of finding a company to sponsor me onto the WG itself, I'm
not sure what I could reasonably do.

This research etc. is why I feel I'm reasonably confident I can talk
about SVG and how accessible it is.
[color=blue]
> Rather, I am saying that proprietary formats immediately
>disqualify themselves from being accessible by restrictive licenses.[/color]

I don't see how that position is sustainable.

Jim.


(*) You'll actually have to look in the (yet to be published) errata
for this, since pre-Errata clients were only required to handle gzip
encoding over HTTP, other protocols are addressed in the errata. the
WG indicated this would change st SVG Open and the mailing list.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Zak McGregor]

Re: FLASH and W3C

On Mon, 08 Sep 2003 00:31:39 +0200, Jim Ley <"Jim Ley"
<jim@jibbering. com>> wrote:
[color=blue]
> On Mon, 08 Sep 2003 00:21:34 +0200, Zak McGregor <zak@mighty.co. za>
> wrote:
>[color=green]
>>On Sun, 07 Sep 2003 21:49:11 +0200, Jim Ley <"Jim Ley"
>><jim@jibberin g.com>> wrote:[color=darkred]
>>> Binary does not mean inaccessible that's a complete myth, that would
>>> be like saying a gzipped SVG is less accessible than one that wasn't.[/color]
>>
>>You are wrong. To put it simply, if you don't have a gunzip program on
>>the other end, you can't process the gzipped SVG content. So you rely on
>>the receiving end having SVG client _plus_ gzip handler.[/color]
>
> A conforming SVG viewer must handle gzip compression, if it doesn't it's
> not an SVG client. (*) If you're going to make comments on the
> accessibility of SVG, I strongly advise reading the spec.[/color]

Ahem. The footnote you point to kind of invalidates your ire and bluster
over this point. In case you missed the gist of the argument - and you
did - a _binary-only_ format means that the conversion from binary into
human-parsable content must happen according to some specification. If
that specification is proprietary, then the end user is SOL in terms of
accessing the content. If that format happens to be textual, the end user
can at lthe very least read whatever text is present. Got it?
[color=blue][color=green]
>>Further, their Flash implementation and development is entirely in their
>>hands, and is for the most part a closed process.[/color]
>
> Yes, not good, but irrelevant to accessibility, which is all we're
> concerned about in this thread- You'll note that I do a lot in the SVG
> world, and very little in the flash world, I don't think flash is a good
> platform, but that doesn't make it any differently accessible to SVG.[/color]

Part of accessibility _is_ the licensing of readers or plugins for the
format. Proprietary licenses impose moral impediments to the viewing of
content presented via such formats.
[color=blue][color=green]
>>I assume these issues are at the spec level. Well, you have the option
>>to participate in the development, not so?[/color]
>
> Again, I feel you aren't looking that much at what is going on in the
> SVG world, I have numerous issues on the spec, I review every draft, I
> make formal suggestions on the list, and others through IRC and similar,
> I try and get members of the WG drunk so they give me what I want, short
> of finding a company to sponsor me onto the WG itself, I'm not sure what
> I could reasonably do.
>
> This research etc. is why I feel I'm reasonably confident I can talk
> about SVG and how accessible it is.[/color]

Except you completely and utterly miss my point every time I make it.
I'll try one last time:
Before the technical aspects of a format's accessibility can be
considered, the accessibility issues raised by said format's restrictive
licensing stand between the viewer and the content; in other words, the
license a format is published/released under is part and parcel of
accessibility, whether its accessibility due to physical constraints or
moral ones.
[color=blue][color=green]
>> Rather, I am saying that proprietary formats immediately
>>disqualify themselves from being accessible by restrictive licenses.[/color]
>
> I don't see how that position is sustainable.[/color]

I don't exactly see why you can't grasp this most fundamentally simple
concept. In order to be considered accessible, a format first needs to
remove all licensing issues from its use. Got it yet? Boy I hope so.

Ciao

Zak

--
=============== =============== =============== =============== ============
http://www.carfolio.com/ Searchable database of 10 000+ car specs
Auctioning motoring-related items at eBay? http://www.carfolio.com/ebay/
=============== =============== =============== =============== ============

[Jim Ley]

Re: FLASH and W3C

On Mon, 08 Sep 2003 18:03:43 +0200, Zak McGregor <zak@mighty.co. za>
wrote:
[color=blue]
>On Mon, 08 Sep 2003 00:31:39 +0200, Jim Ley <"Jim Ley"
><jim@jibbering .com>> wrote:[color=green]
>> A conforming SVG viewer must handle gzip compression, if it doesn't it's
>> not an SVG client. (*) If you're going to make comments on the
>> accessibility of SVG, I strongly advise reading the spec.[/color]
>
>Ahem. The footnote you point to kind of invalidates your ire and bluster
>over this point[/color]

This is a www authoring group, and www has always required gzip, the
SVG WG intended that it would be for all protocols, however the spec
itself didn't make this clear, hence the errata. Do you have a
problem with errata's in specs?
[color=blue]
> If
>that specification is proprietary, then the end user is SOL in terms of
>accessing the content.[/color]

No they're not, if the specification is unavailable then they are,
there are numerous open source SWF reader/writers, so it's clear that
the specification is freely available, yet it's proprietary, but
anyone can write a parser etc.
[color=blue]
> If that format happens to be textual, the end user
>can at lthe very least read whatever text is present.[/color]

Reading whatever text is present simply does not make a format
accessible. Consider a road sign with the word "Parking" and a big
red line through it - that means "no parking" however if you just read
the text in the format all you get is "Parking" - the exact opposite
meaning to what is intended. Access to just the text is as likely to
mislead as it is to inform.

Accessing the text is certainly useful, but it alone does nothing to
make an image accessible, position and other symbols are almost
certainly required.
[color=blue]
>whether its accessibility due to physical constraints or
>moral ones.[/color]

Right so your point seems to be "Flash is morally inaccessible!" my
point is SVG is technically inaccessible, as you've demonstrated a
lack of awareness in SVG, I'm sure you'll agree that neither are in
your opinion appropriate, certainly advocating SVG is not appropriate.
[color=blue]
>I don't exactly see why you can't grasp this most fundamentally simple
>concept. In order to be considered accessible,[/color]

Do you have a source for this unusual definition of accessibility,
it's not the W3's WAI's version, it's not the USA's Section 508
definition, where does it come from? Or did you just invent it?

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Nick Kew]

Re: FLASH and W3C

In article <bja7ma$gcjn2$1 @id-203055.news.uni-berlin.de>, one of infinite monkeys
at the keyboard of "Philipp Lenssen" <info@outer-court.com> wrote:[color=blue]
> [chop]
>
> If you want to get a "Valid HTML" badge, then I wonder why? Basic
> accessibility is much more important than syntax validation.[/color]

Several good reasons for that. Leaving aside the question of importance,
here are a couple that spring to mind:

1. A "Valid HTML" badge doesn't lie (or can trivially be exposed if it does).
By contrast, many "accessibil ity" badges are blatent lies.
2. The WCAG requires markup to be valid. Not to mention avoiding deprecated
features (so "transition al" HTML is out).

--
Nick Kew

In urgent need of paying work - see http://www.webthing.com/~nick/cv.html

[Jukka K. Korpela]

Re: FLASH and W3C

nick@fenris.web thing.com (Nick Kew) wrote:
[color=blue]
> In article <bja7ma$gcjn2$1 @id-203055.news.uni-berlin.de>, one of
> infinite monkeys
> at the keyboard of "Philipp Lenssen" <info@outer-court.com>
> wrote:[color=green]
>> [chop]
>>
>> If you want to get a "Valid HTML" badge, then I wonder why? Basic
>> accessibility is much more important than syntax validation.[/color]
>
> Several good reasons for that.[/color]

There are two reasons for everything. The good reason, and the real
reason.
[color=blue]
> Leaving aside the question of importance,[/color]

Ummm... why?
[color=blue]
> here are a couple that spring to mind:
>
> 1. A "Valid HTML" badge doesn't lie (or can trivially be exposed if it
> does).[/color]

Surprisingly many "Valid HTML" badges are false claims. I would normally
not say they are lies, since "Valid HTML" badges are generally used by
ignorant people, and the concept of lying implies awareness of truth.
[color=blue]
> By contrast, many "accessibil ity" badges are blatent lies.[/color]

To the best of my knowledge, all of the accesssibility badges that claim
conformance to WCAG 1.0 are provably wrong. But again, probably not lies.
(This includes WCAG 1.0 itself, http://www.w3.org/TR/WCAG10/
since it fails to comply with the Priority 1 requirement of indicating
changes in the language of the document. It contains a large number of
proper names in languages other than English, yet fails to use
corresponding lang attributes.)
[color=blue]
> 2. The WCAG requires markup to be valid.[/color]

Checkpoint 3.2 indeed says "Create documents that validate to published
formal grammars." It mentions HTML 4.0 (sic) strict as an example.

Anyone can satisfy that requirement by writing markup that complies to a
DTD, provided that the DTD is published. There is no requirement on the
mode of publication, so putting the DTD onto the Web should do just fine.
[color=blue]
> Not to mention avoiding deprecated
> features (so "transition al" HTML is out).[/color]

I seem to fail to understand the meaning of the phrase "not to mention".
I thought it roughly meant 'et a fortiori', but I must have erred.

Checkpoint 11.2 says "Avoid deprecated features of W3C technologies",
which I read as meaning less that "Do not used deprecated features - -"
would say. It pretty much looks like "should", not "shall not". But in any
case it does not follow from the principle of using valid markup.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Jim Ley]

Re: FLASH and W3C

On Tue, 9 Sep 2003 17:19:41 +0000 (UTC), "Jukka K. Korpela"
<jkorpela@cs.tu t.fi> wrote:

[color=blue]
>(This includes WCAG 1.0 itself, http://www.w3.org/TR/WCAG10/
>since it fails to comply with the Priority 1 requirement of indicating
>changes in the language of the document. It contains a large number of
>proper names in languages other than English, yet fails to use
>correspondin g lang attributes.)[/color]

Whilst indicating the language a name is in us useful for
pronunciation purposes - names are identical in all languages, my name
doesn't change just because I put it in a french document, neither is
it an English name, it's just a name.
[color=blue]
>nick@fenris.we bthing.com (Nick Kew) wrote:[color=green]
>> 2. The WCAG requires markup to be valid.[/color]
>
>Anyone can satisfy that requirement by writing markup that complies to a
>DTD, provided that the DTD is published.[/color]

Yep, I don't actually see this as a bad thing, - It'll have to
certainly approximate an HTML dtd to even render, and it's certaintly
better, than not being valid to anything. WCAG 1.0 can't reasonably
limit authors to particular DTD's, that would not be appropriate, so
what alternative wording is there?

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Bertilo Wennergren]

Re: FLASH and W3C

Jim Ley wrote:
[color=blue]
> Whilst indicating the language a name is in us useful for
> pronunciation purposes - names are identical in all languages, my name
> doesn't change just because I put it in a french document, neither is
> it an English name, it's just a name.[/color]

Names do sometimes change. E.g. in Latvian and Lithuanian all personal
names are adapted to the grammar of those languages. Names are also
adapted in Chinese.

Not to mention names of cities, rivers, oceans etc...

It can still be hard to mark-up names according to the language. Is e.g.
the name "Jouko Lindstedt" (the name of a Swedish-speaking Finn) in
Finnish? Or is the last name perhaps Swedish? It's certainly Swedish in
origin.

--
Bertilo Wennergren <bertilow@gmx.n et> <http://www.bertilow.co m>

[Jim Ley]

Re: FLASH and W3C

On Tue, 09 Sep 2003 19:45:43 +0200, Bertilo Wennergren
<bertilow@gmx.n et> wrote:
[color=blue]
>Jim Ley wrote:
>[color=green]
>> Whilst indicating the language a name is in us useful for
>> pronunciation purposes - names are identical in all languages, my name
>> doesn't change just because I put it in a french document, neither is
>> it an English name, it's just a name.[/color]
>
>Names do sometimes change. E.g. in Latvian and Lithuanian all personal
>names are adapted to the grammar of those languages. Names are also
>adapted in Chinese.[/color]

Ah, sorry yeah, being somewhat over the top with my never. My name
though doesn't even work with the pronunciation, as it's often
pronounced wrongly within the UK - so whilst it is an en-GB name, I
tend to find en-US speakers often pronounce it better. I'm not sure
I really see the value in changing the language for peoples names.
[color=blue]
>Not to mention names of cities, rivers, oceans etc...[/color]

Yes, these are changed more commonly, but these are normally written
in the same language as the surrounding document, if they're not, then
you should certainly change the language then.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Tina Holmboe]

Re: FLASH and W3C

"Jukka K. Korpela" <jkorpela@cs.tu t.fi> exclaimed in <Xns93F1CE5F210 C6jkorpelacstut fi@193.229.0.31 >:
[color=blue][color=green]
>> By contrast, many "accessibil ity" badges are blatent lies.[/color]
>
> To the best of my knowledge, all of the accesssibility badges that claim
> conformance to WCAG 1.0 are provably wrong. But again, probably not lies.[/color]

That is harsh. Do you have any proof of this claim at all ?


--
- Tina Holmboe Greytower Technologies
tina@greytower. net http://www.greytower.net/
[+46] 0708 557 905

[Jukka K. Korpela]

Re: FLASH and W3C

tina@greytower. net (Tina Holmboe) wrote:
[color=blue][color=green][color=darkred]
>>> By contrast, many "accessibil ity" badges are blatent lies.[/color]
>>
>> To the best of my knowledge, all of the accesssibility badges that
>> claim conformance to WCAG 1.0 are provably wrong. But again, probably
>> not lies.[/color]
>
> That is harsh. Do you have any proof of this claim at all ?[/color]

I already proved that the badge on the WCAG 1.0 page itself is false
information. For the general proposition, I made the reservation "to the
best of my knowledge". I haven't yet encountered such a claim that proved
out to be true, but I haven't checked all Web pages in that respect.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html