W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

Re: Re : Influence of valid code on screen readers

From: Roberto Scano (IWA/HWG) <rscano@iwa-italy.org>
Date: Sun, 19 Jun 2005 16:51:54 +0200
To: <tina@greytower.net>, <w3c-wai-gl@w3.org>
Message-Id: <200506191049578.SM01024@Inbox>

An interesting article:
http://www.456bereastreet.com/archive/200506/web_standards_vs_accessibility/
And a piece of interview to Judy Brewer (all text is interesting!):
http://easi.cc/media/trans/tnbrewer.htm

"If you are generating a sort of junk HTML, or if you are generating invalid markup, you are invariably introducing some accessibility problems with that because it is harder for the assistive technologies to work with the invalid markup. 
So we address how to try to get conversion tools to produce Web standards, standard Web specifications, whether it being HTML or XHTML, XML, or what ever.  We also address database conversion tools.  A lot of Web pages are generated on the fly from a database. 
And so we wanted to make sure that those with more often generate accessible pages then inaccessible pages. "

----- Messaggio originale -----
    Da: "Tina Holmboe"<tina@greytower.net>
    Inviato: 18/06/05 23.10.05
    A: "w3c-wai-gl@w3.org"<w3c-wai-gl@w3.org>
    Oggetto: Re: Re : Influence of valid code on screen readers
    
    
    On 18 Jun, Maurizio Boscarol wrote:
    
    > Still, that will not guarantee accessible pages. It depends on quality 
    > of code, of textual equivalents, of structural and semantic markup,
    > and many other design solutions.
    
      Here's the catch. A valid document may, just as an invalid one, be
      accessible. However, an *invalid* one runs a much greater risk of
      having *poor* structure and mangled semantics.
    
      We all agree, I would presume, that structure and semantics are
      important pieces of accessibility. Valid code is essential: if the
      structure and semantics are coded *wrong*, then who knows what might
      come out in the other end of a random user-agent?
    
      Invalidity equals poor quality code, possibly incorrect structure, and
      the chance of confusing semantics. Whyever would we NOT want to make
      this a priority one checkpoint?
    
    
    
    > the problem about validation isn't always tag soup, but some little 
    > implementation mistakes, that don't significatively affect the quality 
    > of code. The pages can nonetheless be accessible.
    
      The problem we would need to accept is rather this: there is no way to
      tell whether the "little implementation mistake" is, or is not, a
      problem for accessibility.
    
      As you write:
    
    
    > a good indicator of quality, but even minor problems in validity
    > don't affect accessibility.
    
      Perhaps not. And perhaps they do. However, *major* problems with
      validity *do* affect accessibility.
    
      In reality, there is no way to tell which of these little mistakes
      might have an effect or not, without actual testing.
    
      The only sensible way of handling this situation is to state, clearly:
      validity issues that can be automatically tested, SHOULD be
      automatically tested as a priority one checkpoint and, in effect,
      gotten out of the way.
    
      Otherwise we need to add something to p1 which says: "Make sure any
      invalid code doesn't mess up accessibility".
    
      As has been pointed out - we cannot *know* that invalidity
      messes with accessibility. The flip side is that we cannot *know* that
      it doesn't, not without testing.
    
    
      Testing to see whether doing things incorrectly might create
      accessibility problems is somewhat illogical.
    
    
    
    
    > complain about validation, but only about real accessibility.
    > Validation should be encouraged, but at the top quality level, not at
    > basic level.
    
    

[Messaggio troncato. Toccare Modifica->Segna per il download per recuperare la restante parte.]
Received on Sunday, 19 June 2005 14:52:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:37 UTC