FLASH and W3C

Manu wrote:

How can i do with a flash object for obtain the w3c label ?

Which W3C label?
If you want to get the WAI (Web Accessibility Initiative) approvement,
Flash won't do it. You need an HTML page for that.

If you want to get a "Valid HTML" badge, then I wonder why? Basic
accessibility is much more important than syntax validation.

For more information, go to Google Groups and enter
valid html w3c flash object embed
http://groups.google.com/groups?q=va...h+object+embed

--
Google Blogoscoped
http://blog.outer-court.com

Jul 20 '05 #2

Jim Ley

On 5 Sep 2003 14:47:39 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

Manu wrote:
How can i do with a flash object for obtain the w3c label ?

If you want to get the WAI (Web Accessibility Initiative) approvement,
Flash won't do it. You need an HTML page for that.

No you don't, you need to be accessible, it's about access to content,
not technologies.

Certainly with Flash that is relatively hard to achieve, especially in
reality, rather than theory, but it's no harder than with SVG, and a
lot easier than video and animated gifs.

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

Jul 20 '05 #3

Jim Ley wrote:

On 5 Sep 2003 14:47:39 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:
Manu wrote:
How can i do with a flash object for obtain the w3c label ?
If you want to get the WAI (Web Accessibility Initiative)

approvement, >Flash won't do it. You need an HTML page for that.

No you don't, you need to be accessible, it's about access to content,
not technologies.

So how do you make "Hello World" accessible in Flash if you cannot use
HTML? How do you get it to work on braille, search engines,
text-to-speech, lynx, etc.? You might know more about Flash than I do.
Certainly with Flash that is relatively hard to achieve, especially in
reality, rather than theory, but it's no harder than with SVG, and a
lot easier than video and animated gifs.

Sure, Flash may be more accessible that a brick wall. If you compare it
with other inaccessible formats, it might rank good. Does that make it
any more accessible? In reality, I find e.g. SVG text easy to copy.
That was never easy in Flash. And in theory, SVG contains a lot more
accessibility features than Flash.

--
Google Blogoscoped
http://blog.outer-court.com

Jul 20 '05 #4

Manu

hum ok ok cool
but how conturn the "embed" tag for obtain w3c label

Jul 20 '05 #5

Jim Ley

On 5 Sep 2003 15:01:26 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

Jim Ley wrote:
No you don't, you need to be accessible, it's about access to content,
not technologies.

So how do you make "Hello World" accessible in Flash if you cannot use
HTML? How do you get it to work on braille, search engines,
text-to-speech, lynx, etc.?

Flash has the ability to have text equivalents for all its content, if
your user agent is inable to access them, then that is a problem with
your (or the search engines etc.) user agent. If you can only use
HTML and no image content, how do you make your content accessible to
those with cognitive problems who can't understand the words.
Accessibility is not about a working with Lynx, lynx is an HTML user
agent. Certainly content on your site should be usefully accessible,
and this may currently mean HTML, but WCAG certainly does not
_require_ HTML.
Does that make it
any more accessible? In reality, I find e.g. SVG text easy to copy.
That was never easy in Flash. And in theory, SVG contains a lot more
accessibility features than Flash.

Interesting, SVG has some huge holes in accessibility, which flash
don't suffer from (text being text in SVG is actually a problem, since
you can't control the order it appears if you also need to control the
z-index of the text.) Still SVG discussion is off-topic. Flash's
accessibility problems are around user agents, and author awareness of
how to author it accessibily.

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

Jul 20 '05 #6

Jim Ley wrote:

Flash has the ability to have text equivalents for all its content, if
your user agent is inable to access them, then that is a problem with
your (or the search engines etc.) user agent. If you can only use
HTML and no image content, how do you make your content accessible to
those with cognitive problems who can't understand the words.
Accessibility is not about a working with Lynx, lynx is an HTML user
agent. Certainly content on your site should be usefully accessible,
and this may currently mean HTML, but WCAG certainly does not
_require_ HTML.

This all seems fairly theoretic. In practice, Flash is inaccessible. If
you got some samples of popular clients and Flash-files supporting your
described features (in the sense that I can find text on the page using
a short-cut, that I can copy text, that I can resize fonts, override
colors), let us know. Otherwise, this discussion is just not pragmatic.
(You could also say it's a human deficiency we can't go through brick
walls. I'd say a good architect won't put up a brick wall when there
should be an entrance.)
However, all those might be good arguments against SVG, if you
want.('Cause SVG accessibility is also highly depending on The Real
World.) I never argued SVG should be used instead. If anything, I argue
HTML should be used. And that's only if one cares about accessibility,
validation, the W3C, users, and so on.

--
Google Blogoscoped
http://blog.outer-court.com

Jul 20 '05 #7

Jim Ley

On 5 Sep 2003 15:51:15 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

This all seems fairly theoretic. In practice, Flash is inaccessible.
No, In practice Flash is inaccessible to certain groups, and more
accessible than many to others, this is the nature of most content
types, certain groups find the content naturally accessible (depending
on their abilities etc.)
(in the sense that I can find text on the page using
a short-cut, that I can copy text, that I can resize fonts, override
colors), let us know.

Resizing is supported by all players that I know of, otherwise as you
note there's a user agent problem, however my point is not to defend
flash or say that it's brilliant, but to simply say that WCAG does not
require HTML, that's simply not true, it requires accessible to all
content.

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

Jul 20 '05 #8

Tina Holmboe

ji*@jibbering.com (Jim Ley) exclaimed in <3f****************@news.cis.dfn.de>:

If you want to get the WAI (Web Accessibility Initiative) approvement,
Flash won't do it. You need an HTML page for that.

No you don't, you need to be accessible, it's about access to content,
not technologies.

If you want to achieve WCAG, then Flash is out. 's as simple as that.
After all, if your UA doesn't have SVG support, then that's a problem
with the UA if I understood your point correctly.
--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905

Jul 20 '05 #9

Jim Ley wrote:

(in the sense that I can find text on the page using
a short-cut, that I can copy text, that I can resize fonts, override
colors), let us know.
Resizing is supported by all players that I know of, otherwise as you
note there's a user agent problem, however my point is not to defend
flash or say that it's brilliant, but to simply say that WCAG does not
require HTML, that's simply not true, it requires accessible to all
content.

One point of the Web Content Accessibility Guidelines reads:

"Guideline 11. Use W3C technologies and guidelines."
http://www.w3.org/TR/WCAG10/

There you go: SVG according to the W3C is more accessible, because as
opposed to Flash, it's their technology. OK, I'm only half-serious
about this.

As for who's responsible, the W3C says:
"Checkpoints that contain the phrase "until user agents ..." require
content developers to provide additional support for accessibility
until most user agents readily available to their audience include the
necessary accessibility features."

it requires accessible to all
content.

OK, good point. So again would you care to show me a Flash which is in
accordance with W3C accessibility guidelines, or rather, common-sense
accessibility guidelines? Because I don't buy any "the world's not
ready for this technology yet" arguments, putting all blame on user
agent accessibility (and of course, they might be blamed as well).

--
Google Blogoscoped
http://blog.outer-court.com

Jul 20 '05 #10

Jim Ley

On 5 Sep 2003 16:27:55 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

Jim Ley wrote:
it requires accessible to all

content.

OK, good point. So again would you care to show me a Flash which is in
accordance with W3C accessibility guidelines, or rather, common-sense
accessibility guidelines?

Flash can be part of your content, the same as you can still use jpegs
even though they obviously aren't accessible to all (modulo the
including of metadata within them with XMP etc., but you get the idea)

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

Jul 20 '05 #11

Jim Ley

On Fri, 05 Sep 2003 16:25:27 GMT, ti**@greytower.net (Tina Holmboe)
wrote:

ji*@jibbering.com (Jim Ley) exclaimed in <3f****************@news.cis.dfn.de>:
If you want to get the WAI (Web Accessibility Initiative) approvement,
Flash won't do it. You need an HTML page for that.
No you don't, you need to be accessible, it's about access to content,
not technologies.

If you want to achieve WCAG, then Flash is out.

Could you cite something which says that? And why if flash is out,
aren't jpegs too, surely they are even less accessible!
After all, if your UA doesn't have SVG support, then that's a problem
with the UA if I understood your point correctly.

Well not exactly as there are a large number of SVG situations which
you can't author in an accessible manner - I'm not even happy with
something as simple as the valid html 4.01 badge (I have to have the
text say "W3C HTML 4.01 Valid" which I think is confusing, when the
appropriate text would be "Valid W3C HTML 4.01", a minor point, but
that's just 1 sentance!)
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #12

Alexander Clauss

Manu <ma**@cyklades.com> wrote:

How can i do with a flash object for obtain the w3c label ?
the "embed" is not accepted !
If you want to support Netscape 4.x as well, you have to use use
embed, because the support for the object element is very limited
in this browser.
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"

You should not (exclusively) use the classid attribute to select the
proprietary ActiveX-control because this is only working in Internet
Explorer under Windows (this is not working on other platforms
and maybe even under Windows it's not working in all browsers)

Instead let the browser find a suitable plugin or Active-X
control itself based on the "type" attribute:

<object data="Transfert/test0.swf"
type="application/x-shockwave-flash"
width="100" height="100">
<param name="quality" value="high">
</object>

This should work with standards-compliant browsers which support
the object tag.

In case MSIE for windows doesn't like this, you can even combine
this with the proprietary "classid":

<object data="Transfert/test0.swf"
type="application/x-shockwave-flash"
width="100" height="100">
<param name="quality" value="high">

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/..."
width="100" height="100">
<param name="movie" value="Transfert/test0.swf">
<param name="quality" value="high">
</object>

</object>
--
Alexander

Jul 20 '05 #13

Owen Jacobson

Manu wrote:

hum ok ok cool
but how conturn the "embed" tag for obtain w3c label

<http://www.alistapart.com/stories/flashsatay/>

Isn't this in the FAQ somewhere?

Jul 20 '05 #14

On Fri, 05 Sep 2003 16:51:03 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.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. Software
licenses can be as large an impediment to viewing content as a physical
issue.

Ciao

Zak

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

Jul 20 '05 #15

Jim Ley

On Sat, 06 Sep 2003 17:05:40 +0200, Zak McGregor <za*@mighty.co.za>
wrote:

On Fri, 05 Sep 2003 16:51:03 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.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.

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

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.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #16

On Sat, 06 Sep 2003 18:34:46 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.com>> wrote:

On Sat, 06 Sep 2003 17:05:40 +0200, Zak McGregor <za*@mighty.co.za>
wrote:
On Fri, 05 Sep 2003 16:51:03 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.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.

Would you care to actually help show that and actually help me author
accessible documents, rather than just asserting it?

You mean you can't work out how a proprietary, binary-only format
technology is inherently less accessible than an open format?

Software
licenses can be as large an impediment to viewing content as a physical
issue.

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

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/
================================================== ======================

Jul 20 '05 #17

Jim Ley

On Sun, 07 Sep 2003 21:36:28 +0200, Zak McGregor <za*@mighty.co.za>
wrote:

On Sat, 06 Sep 2003 18:34:46 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.com>> wrote:
Would you care to actually help show that and actually help me author
accessible documents, rather than just asserting it?

You mean you can't work out how a proprietary, binary-only format
technology is inherently less accessible than an open format?

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.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #18

Isofarro

Zak McGregor wrote:

On Sat, 06 Sep 2003 18:34:46 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.com>> wrote:
On Sat, 06 Sep 2003 17:05:40 +0200, Zak McGregor <za*@mighty.co.za>
wrote:
On Fri, 05 Sep 2003 16:51:03 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.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.

Would you care to actually help show that and actually help me author
accessible documents, rather than just asserting it?

You mean you can't work out how a proprietary, binary-only format
technology is inherently less accessible than an open format?

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/

Jul 20 '05 #19

On Sun, 07 Sep 2003 21:49:11 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.com>> wrote:

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

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.

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.
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
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]
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.
I assume these issues are at the spec level. Well, you have the option to
participate in the development, not so?

[snip]
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.

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/
================================================== ======================

Jul 20 '05 #20

Jim Ley

On Mon, 08 Sep 2003 00:21:34 +0200, Zak McGregor <za*@mighty.co.za>
wrote:

On Sun, 07 Sep 2003 21:49:11 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.com>> wrote:
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.
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.

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.
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.
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.
Further, their Flash implementation and development is entirely in their
hands, and is for the most part a closed process.
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.
I assume these issues are at the spec level. Well, you have the option to
participate in the development, not so?
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.
Rather, I am saying that proprietary formats immediately
disqualify themselves from being accessible by restrictive licenses.

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.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #21

On Mon, 08 Sep 2003 00:31:39 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.com>> wrote:

On Mon, 08 Sep 2003 00:21:34 +0200, Zak McGregor <za*@mighty.co.za>
wrote:
On Sun, 07 Sep 2003 21:49:11 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.com>> wrote:
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.

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.

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.

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?

Further, their Flash implementation and development is entirely in their
hands, and is for the most part a closed process.

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.

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.

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

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.

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.

Rather, I am saying that proprietary formats immediately
disqualify themselves from being accessible by restrictive licenses.

I don't see how that position is sustainable.

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/
================================================== ======================

Jul 20 '05 #22

Jim Ley

On Mon, 08 Sep 2003 18:03:43 +0200, Zak McGregor <za*@mighty.co.za>
wrote:

On Mon, 08 Sep 2003 00:31:39 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.com>> wrote:
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.
Ahem. The footnote you point to kind of invalidates your ire and bluster
over this point

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?
If
that specification is proprietary, then the end user is SOL in terms of
accessing the content.
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.
If that format happens to be textual, the end user
can at lthe very least read whatever text is present.
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.
whether its accessibility due to physical constraints or
moral ones.
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.
I don't exactly see why you can't grasp this most fundamentally simple
concept. In order to be considered accessible,

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.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #23

Nick Kew

In article <bj************@id-203055.news.uni-berlin.de>, one of infinite monkeys
at the keyboard of "Philipp Lenssen" <in**@outer-court.com> wrote:

[chop]

If you want to get a "Valid HTML" badge, then I wonder why? Basic
accessibility is much more important than syntax validation.

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 "accessibility" badges are blatent lies.
2. The WCAG requires markup to be valid. Not to mention avoiding deprecated
features (so "transitional" HTML is out).

--
Nick Kew

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

Jul 20 '05 #24

ni**@fenris.webthing.com (Nick Kew) wrote:

In article <bj************@id-203055.news.uni-berlin.de>, one of
infinite monkeys
at the keyboard of "Philipp Lenssen" <in**@outer-court.com>
wrote:
[chop]

If you want to get a "Valid HTML" badge, then I wonder why? Basic
accessibility is much more important than syntax validation.
Several good reasons for that.

There are two reasons for everything. The good reason, and the real
reason.
Leaving aside the question of importance,
Ummm... why?
here are a couple that spring to mind:

1. A "Valid HTML" badge doesn't lie (or can trivially be exposed if it
does).
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.
By contrast, many "accessibility" badges are blatent lies.
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.)
2. The WCAG requires markup to be valid.
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.
Not to mention avoiding deprecated
features (so "transitional" HTML is out).

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

Jul 20 '05 #25

Jim Ley

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

(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.)
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.
ni**@fenris.webthing.com (Nick Kew) wrote:
2. The WCAG requires markup to be valid.

Anyone can satisfy that requirement by writing markup that complies to a
DTD, provided that the DTD is published.

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.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #26

Bertilo Wennergren

Jim Ley wrote:

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.

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 <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #27

Jim Ley

On Tue, 09 Sep 2003 19:45:43 +0200, Bertilo Wennergren
<be******@gmx.net> wrote:

Jim Ley wrote:
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.
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.

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.
Not to mention names of cities, rivers, oceans etc...

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.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #28

Tina Holmboe

"Jukka K. Korpela" <jk******@cs.tut.fi> exclaimed in <Xn*****************************@193.229.0.31>:

By contrast, many "accessibility" badges are blatent lies.

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.

That is harsh. Do you have any proof of this claim at all ?
--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905

Jul 20 '05 #29

ti**@greytower.net (Tina Holmboe) wrote:

By contrast, many "accessibility" badges are blatent lies.

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.

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

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

Jul 20 '05 #30

ji*@jibbering.com (Jim Ley) wrote:

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.
"It's just a name."?
I would rather say: "Moreover, it's a name!" Surely if indicating natural
language is useful for pronunciation purposes, for example, it is
particularly useful for proper names. For common foreign words, a user
agent can be expected to know the pronunciation from general glossaries,
but for proper names, the language indicator can really be indispensable.

I dare say that I know well the problems of language markup, including
things more complex than the relevant problems that Bertilo has mentioned
in this thread. I mean both practical and theoretical problems.

But the _point_ here is that WCAG 1.0 makes an unconditional requirement
of indicating language changes, yet itself fails to comply with it, and
thus makes a false claim of conformance.
WCAG 1.0 can't reasonably
limit authors to particular DTD's, that would not be appropriate, so
what alternative wording is there?

I wasn't saying the wording should be changed. I commented on the coupling
of the validity requirement with the suggestion to avoid deprecated
markup. I saw this coupling as a category error.

You're probably right in the observation that being valid in the general
sense (i.e., conforming to _a_ DTD) is probably better than not being
valid. But this is not very high in importance. Surely the great majority
of Web pages fail validation, and surely this is seldom among the worst
problems in accessibility. And if, for example, a page lacks alt
attributes for img elements, it would not help much to change the DTD to
make the alt attribute not required.

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

Jul 20 '05 #31

Jim Ley

On Wed, 10 Sep 2003 05:51:23 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:

ti**@greytower.net (Tina Holmboe) wrote:
By contrast, many "accessibility" badges are blatent lies.

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.

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

I already proved that the badge on the WCAG 1.0 page itself is false
information.

I don't agree that you've proved it, as I don't agree that the natural
language changes when it meets a name with its roots in another
language.

Neither do I think that the document is accessible to the AAA it
claims with its silly badge (14.2 is a more glaring failure on that)

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

Jul 20 '05 #32

On Mon, 08 Sep 2003 18:20:36 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.com>> wrote:

This is a www authoring group, and www has always required gzip,
required? Optional, right? It's of no import to the original issue anyway,
where I was simply using the binary format you chose to use as an example.
Bottom line is simply that a binary format requires a parser of such a
format, while a plain text format can be parsed by a human (admittedly
with some effort perhaps) without necessitating a specific software
interpreter.

Please show me what you mean by "www has always required gzipo". A look
through RFC 2616 doesn't seem to indicate that gzip is a requirement for
either server or client.

[snip]

If
that specification is proprietary, then the end user is SOL in terms of
accessing the content.

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.

Your definition of freely available and mine differ. Not anyone can write
a parser for say V7. A search of the Macromedia site reveals the sdk one
version back from current, and itself restricted by a proprietary license
agreement.

If that format happens to be textual, the end user
can at lthe very least read whatever text is present.

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.

I challenge your "just as likely" assertion as bogus and completely
misleading. If the content meant to say "no parking" it would do so, and
not rely on the "parking" to be provided through one method and the "no"
through another - except in the most extreme cases. In your example, both
the "P" and the red line through it would more than likely be images.
You'd see both or neither unless the author set out to deliberately trick
or fool some system.
Accessing the text is certainly useful, but it alone does nothing to
make an image accessible, position and other symbols are almost
certainly required.

It surely does more for the user's ability to access the content than a
format that requires pre-parsing would.

whether its accessibility due to physical constraints or moral ones.

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.

Well it is. Advocating SVG over Flash is deinitely aceptable as there is a
process involved in its development in which individuals can participate,
and a published spec is freely available meaning clients can be written
without fear of prosecution or future license changes. Furthermore, it is
likely that clients can be written to work around the inherent technical
issues with the current SVG specification. With Flash there simply aren't
these options.

I don't exactly see why you can't grasp this most fundamentally simple
concept. In order to be considered accessible,

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?

I dare say that those guidelines are defficient if they lack such
definitions of accessible.

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

Jul 20 '05 #33

kchayka

Jim Ley wrote:

On Wed, 10 Sep 2003 05:51:23 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:
ti**@greytower.net (Tina Holmboe) wrote:
> By contrast, many "accessibility" badges are blatent lies.

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.

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

I already proved that the badge on the WCAG 1.0 page itself is false
information.

I don't agree that you've proved it, as I don't agree that the natural
language changes when it meets a name with its roots in another
language.

Agreed. I am American of Polish descent. I know how my name is
correctly pronounced with American English, but have no idea how a Pole
would pronounce it. For all I know, they might even say it "wrong". :)

--
To email a reply, remove (dash)ns(dash). Mail sent to the ns
address is automatically deleted and will not be read.

Jul 20 '05 #34

Jim Ley

On Wed, 10 Sep 2003 18:01:30 +0200, Zak McGregor <za*@mighty.co.za>
wrote:

On Mon, 08 Sep 2003 18:20:36 +0200, Jim Ley <"Jim Ley"
<ji*@jibbering.com>> wrote:
This is a www authoring group, and www has always required gzip,
required? Optional, right?

That sentance contained an error, I hoped you'd understand the
intention - gzip is requied by SVG user agents accessing documents
over HTTP, and always has been.
If the content meant to say "no parking" it would do so,
Rarely, the common English road-signs all use a red line through the
word to indicate not, I understood this was a reasonably global
convention. There's also the issue of word ordering which you've not
addressed, or the user-stylesheet position, I've demonstrated numerous
issues with SVG and text, and
In your example, both
the "P" and the red line through it would more than likely be images.
That would be incorrect in SVG - and very difficult to author
(creating a vector representation of parking that isn't a text is
quite some effort - there's no authoring tools which do it currently.
Well it is. Advocating SVG over Flash is deinitely aceptable as there is a
process involved in its development in which individuals can participate,
and a published spec is freely available meaning clients can be written
without fear of prosecution or future license changes.

Certainly, irrelevant to the accessibility aspect of the two
technologies I pulled you up on.

Or did you just invent it?

I dare say that those guidelines are defficient if they lack such
definitions of accessible.

I await to see your comments on the WAI IG's...

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

Jul 20 '05 #35

ji*@jibbering.com (Jim Ley) wrote:

I don't agree that you've proved it, as I don't agree that the natural
language changes when it meets a name with its roots in another
language.
The page contains several personal names of people whose names are clearly
in a language other than English.

Of course there are cases where a person's name does not unambiguously
belong to one language, especially in the United States where names have
been partly adapted to the English language, in pronunciation or
spelling or both. (That's one of the many complications that I referred
to, regarding lang markup.) But most names are uniquely identifiable as
being in one language.

Isn't it actually rather questionable to claim that _all_ the personal
names in that document are English? This what <html lang="en"> claims when
not overridden. (By the way, the WCAG 1.0 document presents itself as an
XML document, yet uses lang only, not xml:lang.)
Neither do I think that the document is accessible to the AAA it
claims with its silly badge (14.2 is a more glaring failure on that)

Well, 14.2 is rather fuzzy. It's hard to prove that a document does not
comply with it. You would need to construct some graphic or auditory
presentation that would facilitate comprehension of the page. I'm sure
that could be done for almost any nontrivial page, but it would take
skill, labor, and creativity. Naturally it is _impossible_ to prove that a
document complies with the requirement. It is surely impossible to prove
that no such additional auxiliary presentation can ever be created.

But there are many other requirements that are more or less impossible to
satisfy.

14.1 ("Use the clearest and simplest language appropriate for a site's
content") has always puzzled me. It's surely an important principle - far
more important to most users than most other WCAG 1.0 rules - but I cannot
really understand how anyone can claim conformance to it. Unless it is a
deliberate lie, it really indicates a failure to understand how complex
simplicity is.

To prove that a page fails 14.1, a priority 1 requirement, it is
sufficient to point out _one_ single verbal expression on the page that
could be formulated in clearer, or simpler, without reducing
appropriateness for the site's content.

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

Jul 20 '05 #36

Dean Tiegs

"Jukka K. Korpela" <jk******@cs.tut.fi> writes:

Of course there are cases where a person's name does not
unambiguously belong to one language, especially in the United
States where names have been partly adapted to the English language,
in pronunciation or spelling or both. (That's one of the many
complications that I referred to, regarding lang markup.) But most
names are uniquely identifiable as being in one language.

How would you suggest marking up a name like "Qu'Appelle, Long Lake
and Saskatchewan Railway"? It has parts that are French, parts that
are English, and parts that are Cree but not spelled in any normal
Cree orthography.

--
Dean Tiegs, NEÂ¼-20-52-25-W4
â€œConfortare et esto robustusâ€
http://telusplanet.net/public/dctiegs/

Jul 20 '05 #37