Re: Starter comments on WCAG 2.0 draft

It's nice to see discussion picking up on the AU list...

For clarity I just want to try and frame this discussion from the 
perspective of AUWG. I think perhaps any Web content accessibility issue 
may be looked at in (at least) three ways:

(1) in terms of the importance of the issue within completed Web content 
(i.e. after authoring is finished):
- this is best left to WCAG because otherwise we may find our work in 
conflict with theirs.

(2) in terms of supports for authors with disabilities:
- for example, structure-based search capabilities, ability to have 
authoring view display differently than the content would in a typical 
browser, etc.

(3) in terms of supports for all authors to create content that meets (1):
- for example checking and repair, summaries, help, etc.

So, taking the issue of markup validity…

For (1), this is where most of the discussion of whether content must be 
valid to be accessible has centered. While this is best left to WCAG, 
the AUWG could potentially take a position, but if there is no agreement 
(as seems to be the case), it would be best for people to send their 
comments to the WCAG-GL directly.

For (2), this might be an interesting place for taking into account 
validity. Basically, the group might decide that ensuring validity is a 
relatively complex and distributed task that might be further 
complicated when someone has a serial view of a page. The success 
criteria might be something like provide a validator.

For (3), there is the possibility of adding additional checkpoints along 
the lines of ensure automatically generated markup is valid or check and 
repair invalid markup, but if validity is in WCAG then it will 
automatically be picked up by all of ATAG’s Relative Priority 
checkpoints, so let’s move carefully.

Cheers,
Jan


Roberto Scano (IWA/HWG) wrote:
> 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.]
> 
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Wednesday, 27 July 2005 15:29:59 UTC