RE: Validity

Greetings Bob.

Do you not agree that WCAG2, because of its incorporation of the concept of baseline, offers an excellent opportunity to promote the use of Flash?

WCAG1 Single A requires full functionality without the use of Flash.  I should think that this limits its penetration to those parts of the world that take WCAG1 seriously.

Section 508 1194.22, by contrast, could be argued to have already incorporated the concept of baseline (although it doesn't use the term) since JavaScript and Plug-ins are already explicitly conditionally allowed.

As someone with a computer science background, I perceive a deep fundamental flaw with a set of standards that proposes to use the baseline concept but rejects fully embracing basic syntax checking available with the core technologies.  I am incredulous really, and having worked in government for as long as I have, I have seen my share of absurdity!

> The point here is that there are times where we all assume the 
> vendors on all sides are working in perfect harmony with the 
> specification, OS, Tool maker and AT. 

Many of us know and appreciate the huge disconnects, and how long things take to get working correctly.

> The specific reference here is related to use of <embed> with Flash.

Understood, and you know I am all in favor of Flash content (so long as it is accessible of course).  I hate to be disagreeing with you about this, especially in public!  :-)

> Recently, there has been activity around creating code that embeds 
> Flash content in a page that follows standards.  From a validity 
> standpoint, it works great.  However, there is a negative 
> consequence here, this valid markup renders the Flash content 
> inaccessible using that screen reader.

You and I, and I am sure many on the list here, have also discussed that sometimes there is a disconnect between compliance with accessibility standards, and actually something being accessible (that is, actually compatible with the AT, and fully useable).  That is *okay* because the value of good stable standards for content authors is worth more than transitory and fragile accessibility.

> After a few chats with the AT maker, it is clear that a simple 
> fix is not forthcoming.  

Also understood, but is not the actual problem with the browser (i.e., IE)?  I cannot understand how, except for the misbehavior of an underlying Brower, that EMBED versus OBJECT should make a bit of difference for the plug-in nor the AT.  But maybe I am mistaken about that?  Please correct me if I am wrong about that.

> This creates a situation where the author must choose, 
> accessibility versus validity. 

Easy pickings:  choose validity.  Validity is a stable target.  Accessibility will follow as the OS / browser / plug-in / AT all improve, which they will.  If the author is committed to accessibility, they have a robust textual alternative.  (If they are comfortable skipping the robust textual alternative, they are most certainly comfortable using deprecated code.)

The dichotomy between real world accessibility and conformance to 508 1194.22 standards (lots of 1:1 mapping between it and WCAG1 as probably everyone here knows) is actually something that comes up here at the Department of Education with a great deal of regularity.  My team's core work duties involves accessibity testing of web sites multiple times every week.

The conflict used to come up a lot more, especially with multi-level tables coded using COLSPAN and SCOPE (versus HEADERS and ID, which always worked) that JAWS ignored.  If the content author demonstrated that their site was coded correctly to the specification, we passed it anyway!  Guess what, the current version of JAWS honors COLSPAN and SCOPE just fine now, thank you very much.

We held content authors and software developers to a stable set of standards, and eventually they met.  Some end users were left hanging in the meantime, but we (my group, not the authors nor developers) met their needs too.  Those accommodations were made as 504 obligations, not 508.

If we had insisted on artificial work-arounds from the content authors, we would have lost credibility, and the software developers might never have made the necessary improvements.

> From Macromedia's standpoint, it would be terrific 
> if the issue did not exist.  However, it does. 

Agreed, but if WAI caves on this issue, there is no reason to believe that the issue will ever be fixed.

> It is interesting that Makoto raises the issue of practicality 
> on the same day that this old debate has resurfaced.
> This is precisely the issue here. 

Promoting robust and stable long term standards, even if the face of known issues -- which we have every reason to believe *will* be temporary -- *is* being practical.

> When we looked at this issue for the current release, I
> advocated on behalf of the use of embed because to change our
> default techniques would have a very negative consequence for 
> people with disabilities. 

Do you disagree that EMBED is an ugly hack?
Do you disagree that, in theory, WCAG1 Single A pages already work fully well *without* Flash?

I think you are, quite reasonably, worried about real world pages that use Flash in a meaningful way and are accessible.  These pages might conform to 508, but I would be willing to wager that they don't technically conform to WCAG1 Single A.  Please cite two or three examples (preferably, I think, to the IG list) if you believe I am mistaken about this.  These content providers are obviously comfortable with their technique, what difference does it make to Macromedia if these pages are not technically WCAG2 conformant?

WCAG2 will take a long time to become enforceable anywhere.  Plenty of time for the EMBED vs. OBJECT technique to be fixed.  The only reason this particular issue, and ones like it, is still a problem is that validity has not been taken seriously.  If validity is treated seriously by WCAG2 then this artificial conflict will be resolved.

And I haven't even talked about all the accessibly good validity will do!  All I have done here is argue that it won't be a problem.

Bruce Bailey, Acting Director
ED OCIO Assistive Technology Program
202-377-4932 (voip)
202-401-8510 (tty)
202-401-8469 (fax)

Received on Friday, 4 November 2005 21:16:37 UTC