Re: Starter comments on WCAG 2.0 draft

Hi,
The problem is that, with technologies that are xml based - like xhtml 1.0/1.1, invalid code stop the dom parsing and make pages inaccessible to all.
Atag 1.0 pointed valid code generation at level 1: shall atag 2.0 and wcag 2.0 renegade this?
I a k seriously: why all vendors against valid code (respect w3c rec.)?
It's about two years that in AC meetings I ask to Tbl that members should support w3c rec. And he always said: ask to them!
So I ask to IBM: why no valid code generation at level 1?

----- Messaggio originale -----
    Da: "Giorgio Brajnik"<giorgio.brajnik@gmail.com>
    Inviato: 27/07/05 15.58.15
    A: "Phill Jenkins"<pjenkins@us.ibm.com>
    Cc: "Roberto Scano (IWA/HWG)"<rscano@iwa-italy.org>, "gv@trace.wisc.edu"<gv@trace.wisc.edu>, "w3c-wai-au@w3.org"<w3c-wai-au@w3.org>
    Oggetto: Re: Starter comments on WCAG 2.0 draft
    
    [Phill, in case this message does not go to the list, could you
    forward it for me please?]
    
    I don't think invalid code is a major accessibility issue, and
    therefore that it should NOT be a level 1 requirement to have valid
    code.
    
    I think that the lack of an appropriate definition of accessibility
    that is linked to testing methods and criteria, prevents us from being
    able to clearly define in guidelines what an accessibility barrier is,
    and what are its negative consequences (like impact on end users).
    Defining accessibility as "possibility for everyone to access content
    / use authoring tools for generate contents" is, I think,  too general
    to be operable. "Usability for disabled people" is more practical
    because it inherits from the def. of usability appropriate contextual
    aspects that make it more operational. Eg. one def. of usability says
    (approximately) "... effectiveness, productivity and satisfaction for
    GIVEN users, in GIVEN operational situations, while aiming at GIVEN
    goals". On the one hand the focus on effectiveness, productivity and
    satisfaction allows one to think of users performance criteria (eg. we
    look how a sample of users behave when put in front of a web site; and
    from observations we derive metrics that are associated to those 3
    criteria, like number of errors that is associated to effectiveness).
    This is good because accessibility   encompasses human perception and
    cognitive processes.
    On the other hand the def. makes explicit 3 important contextual
    factors: Who we're dealing with,  What they should be doing and
    Where/When/How. This allows one to say (and test) for example that
    blind users using JAWS v.3.5 on IE 5.5 cannot (or can) subscribe to a
    newsletter.
    
    Both the contextualization and the focus on user performance criteria
    are missing or not clear enough with some currently used definitions
    of accessibility.
    
    If they were, it would be easier to understand if invalid html code is
    or not an accessibility issue, and to what extent (meaning "what kind
    of negative impact it has on which kind of user in which kind of
    situation wrt a certain goal"). For example, Slatin's and Rush'
    definition (with an accessible web site disabled users can achieve the
    same goals as non-disabled people) is quite operational. If we were to
    use that definition, the code validity issue could be investigated by
    finding cases where an invalid page  prevented disabled users to
    achieve something that other ones were able to.
    
    I think we could try to deepen this issue, at least by finding out
    concrete cases where some AT failed to function properly to such an
    extent that the violation would be associated to a level 1 violation.
    
    While I agree with all has been said about why a valid page is a good
    thing, in my experience I've seen only one case where invalid code
    prevented a user of a non-recent version of JAWS to perceive (and
    therefore understand and use) a home page of a site. The main problem
    was the inability to handle different frames, which made the user
    unable to skip onto other frames of the (framed) page. Other usages of
    screen readers, magnifiers, transcoders, PDAs, textual browsers on
    real web pages did not show this kind of problem (for the users I did
    accessibility testing
    with).
    
    My best,
    
    -- 
            Giorgio Brajnik
    
    

[Messaggio troncato. Toccare Modifica->Segna per il download per recuperare la restante parte.]

Received on Wednesday, 27 July 2005 14:53:50 UTC