RE: Starter comments on WCAG 2.0 draft

Roberto,

I don't think you are being fair to vendors or IBM. 

The question before this group is to develop a set of guidelines based
on available technologies AND available best practice. 

The long and the short of it is that valid code is not part of best
practice today. That is to say, simply having valid code does not ensure
the accessibility of a site or necessarily improve the usability of a
site. While we can argue it will one day have a positive impact the
reality today is that it does not. I would go a step further to say that
there are cases where relying on valid code alone can actually detract
from the accessibility of a site. Think about Flash and the use of the
<embed> element. It is not valid markup but Flash satay breaks the
accessibility of the ActiveX control. More generally, think about the
limited support of CSS in most screen readers. 

The fallacy here is that invalid code results in inaccessible sites or
that it detracts from the usability of the site. While I would agree
whole heartedly that there are cases where this is true, I do not
believe it is uniquely true. As I mentioned, there are cases where
invalid code results in a more accessible page. 

Interoperability and support for standards is a priority in industry. In
fact, I would argue IBM and Macromedia (to name just two examples
singled out here) are leaders in that respect. However, until we see
broader support, the issue is feasibility, not reluctance on the part of
industry. 

Cheers,
Bob


------------------------------------------------------------------------
-
bob regan | macromedia | 415.832.5305






-----Original Message-----
From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On
Behalf Of Roberto Scano (IWA/HWG)
Sent: Wednesday, July 27, 2005 7:53 AM
To: giorgio@dimi.uniud.it; Phill Jenkins
Cc: gv@trace.wisc.edu; w3c-wai-au@w3.org
Subject: 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 15:20:35 UTC