

Re: Validity

Date: Fri, 4 Nov 2005 10:20:50 +0100
Message-Id: <200511040414234.SM03268@Inbox>

I think that the problem is specifically vendor-oriented.
Flash for accessibility features (that is available only with ms windows + jaws/hpr and IE) need to have <embed> element because they have implemented MSAA for work with embed.
Having valid code at level 1 don't means have problem with national law (all exisisting law that are wcag-based refer at least at level 2 of wcag 1.0) but means that Flash cannot be used.
This is the reality: and eventually there is the "Baywatch" (ops, the "baseline") that let the user to setup minimum requirements for browse the contents. So "best viewed with any Browser" will die in 2006. (R.I.P.).
Sorry for the tune of this post, but it's incredible that we need to force wcag 2.0 for conform with a plugin that is accessible only in one OS and with a specific configuration (i don't know what would happen if the company was Microsoft instead of Macromedia).	

----- Messaggio originale -----
    Da: "Johannes Koch"<koch@w3development.de>
    Inviato: 04/11/05 9.58.20
    Oggetto: Re: Validity
    Gez Lemon wrote:
    > The arguments put forwards against validity (from the
    > face-to-face meeting in Seattle) can be summarised as:
    > 1: Validity isn't essential for accessibility
    > 2: Some developers think they're being clever creating accessible
    > content, but they aren't
    > 3: The people who wrote the specification don't really want anyone to
    > be bothered by it
    > 4: Legislation could result in people being prosecuted for invalid markup
    Technically, conformance to specification is necessary for communication 
    between information provider and consumer, and so is essential for 
    consumers to be able to _access_ the information. Otherwise the consumer 
    has to implement error recovery, heuristics, guesses, etc. Validity is 
    one part of specification conformance. Another one (for markup) is this: 
    Markup specifications use concepts like heading, list, table, etc. and 
    define elements/attributes to transfer these concepts into markup code. 
    If the information provider wants to use one of the concepts, he has to 
    use the correct markup for this concept. OTOH, the information provider 
    has to use specific markup only to describe concepts which the markup is 
    intended for.
    One exception may be additional code that may be necessary to overcome 
    problems that the specification authors were not aware of and so is not 
    part of the spcification. In the case of markup, user agents should not 
    be confused by this, because they are required to ignore it and try to 
    process the child nodes. I think it's similar with "extensions" to CSS, 
    as long as the syntax conforms to the grammar.
    Johannes Koch
    In te domine speravi; non confundar in aeternum.
                                 (Te Deum, 4th cent.)

Received on Friday, 4 November 2005 09:17:54 GMT
