R: R: NEW: Issue #1544

-----Messaggio originale-----
Da: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] Per conto
di Matt May
Inviato: venerdì 12 agosto 2005 20.08
A: 'WAI-GL'
Oggetto: Re: R: NEW: Issue #1544

I think the entire discussion of validity vis-à-vis <embed> is missing 
the point. The <embed> element is still around in HTML 4.01 and XHTML 
1.x, and will be forever. We simply can't wish it away. It's the last 
invalid element in common use today, and none of the debate so far has 
been focused on whether or not this is a bad thing for accessibility -- 
merely that it fails validity, which has yet to gain consensus as a 
basic accessibility requirement. (I'm pretty sure that we're still 
working toward accessibility to users with disabilities, right?)

Roberto Scano:
Yes, we are working for accessibility but this don't authorize us to violate
other W3C specifications.
If someone wanna use embed, should use a custom DTD: but if we will do a
guideline where we said: "hey guy, if you use Flash you can violate DTD and
put <embed> element!", we are going out of road....

Matt May:
Is there a strong accessibility case to be made for allowing <embed>? 
Yes: there is no known technique that remains valid (i.e., uses 
<object>) _and_ offers ATs access to the internal accessibility features 
of Flash. The ATs don't handle <object> correctly. Now, we can shake our 
fists at the ATs and force validity anyway, but we'd be ignoring the 
elephant in the room, _and_ actively damaging Flash accessibility. The 
all-or-nothing validity approach simply does not work here.

Roberto Scano:
The problem is not the AT that don't handle <object> correctly but in the
case of Flash is that Flash uses <embed> for dialog with MSAA with "set"
options, instead of using <object> with "get" options
(http://livedocs.macromedia.com/flash/mx2004/main_7_2/wwhelp/wwhimpl/common/
html/wwhelp.htm?context=Flash_MX_2004&file=00000556.html).
Screen readers have trouble handling nonstandard controls because the screen
reader cannot reliably find the control's label and description. MSAA
exposes this information so that controls can be seen and manipulated by
screen readers and other assistive technology. The problem is that - if an
object don't respect this and use its own procedure for set these info
instead using standard Windows procedures, should use <embed> instead
<object> that let to use the "set" options. But this is a choose of the
object producer: if the object producer choose to use embed instead object,
choose to use its own dialog system for dialog with MSAA, and is not
possible to have this accessibility in all the OS, why we are still
discussing to use <embed> element?


Matt May:
The <object> and <embed> elements have been used together for quite some 
time to deal with Microsoft/Netscape conflicts. It seems that's a 
reasonable approach today. If a custom DTD is necessary, that might be 
okay too, though I doubt many people would use it.

Roberto Scano:
We are in 2005: if someone wanna use elements not available inside a last
Century DTD, can use custom DTDs.

Received on Friday, 12 August 2005 19:16:36 UTC