Re: Re : Influence of valid code on screen readers

Tina Holmboe wrote:

>  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?
>  
>

I made an example for this in my last mail.
Valid code does not mean well structured code. We are always 
counfounding this two things.

Nothing in validity check can tell us if the structural markup is ok, 
and if the author used semantically rich markup.

It has nothing to do with well-formed and valid documents. A broken 
document may be better structured and in fact have better accessibility 
than a valid one. And we want to put validation in prioriy 1? I just 
can't understand why.


>>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.
>  
>


Yes, this is a critical point, I agree.
But we have to put in p1 things that we *know* are surely problems for 
accessibility, not *potential* problems, who knows, may be, in some 
cases, guess if, maybe not... :)


>  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.
>  
>

Yes, they often do. But does this authorize us to claim validity in p1? 
I claim that even some invalid pages may be accessibile, and more 
accessible than some other valid pages.
Disabled users I know never look if a page is valid. In fact, in the 
real world, pages they surf are *largely* invalid. But they can 
nonetheless browse and navigate, even with some effort. Putting 
validation in p1 means not recognizing this simple reality.

I agree that pages well structured and valid should be better. But it's 
a quality improvement, not a basic accessibility issue.


>  In reality, there is no way to tell which of these little mistakes
>  might have an effect or not, without actual testing.
>  
>

Yes, this is absolutely true. And so I claim for actual testing prior to 
writing the p1 guidelines! :))

How can we decide what is basic accessibility without testing? Or even 
without seeing real disabled users use the web, and understand what they 
really dislike, and what isn't really a big problem?

Again, I'm not against validation. I'm against putting validation in p1, 
because I know that most disabled users don't care about valid or 
invalid pages, and because I know that authoring tools and CMS are not 
mature right now to produce valid pages, but this doesn't prevent most 
pages from being basically accessible.

So do we want all this pages to be blamed as inaccessible, even if users 
can easily access them?

Ok, we can say (actually, we must say...) that with invalid code there 
may be some accessibility problems (or may not). But the "may" options 
used to be in old AAA level, as far as I can remember...

>  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.
>  
>

I don't agree, because validity issues that can be automatically tested 
are often issues that aren't related with accessibility. Anyway, this is 
not a p1, but a higher quality level of accessibility.
Here I see a dangerous bias toward automatic testing, despite of being 
related with accessibility. If a condition can be automatically tested, 
but it doesn't refer to a theoretical concept called "accessibility", 
than we shouldn't use it as a mean to measure or evaluate accessibility, 
of course.

>  Otherwise we need to add something to p1 which says: "Make sure any
>  invalid code doesn't mess up accessibility".  
>

Well, this may be. In wcag1 there's a lot of such generic statements, 
maybe we could think about something similar in wcag 2.

>  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.
>  
>

Yes: at top level, pages should also be valid.
But if we cannot know if validity massess with accessibility, we cannot 
put it in p1.

Maurizio

Received on Sunday, 19 June 2005 13:55:04 UTC