Re: [html4all] HTML5 Alternative Text, and Authoring Tools

On May 17, 2008, at 12:43, Gez Lemon wrote:

> I complete agree with you, Henri, and I am guilty of using the term
> "valid" here, when I meant "compliant":

The question is compliant to what? HTML5 syntax? Or WCAG 2.0? Or  
something else?

> I find it equally bizarre that an incomplete structure should be
> considered compliant output from an authoring tool, despite the fact
> that the incompleteness means the resulting output cannot be perceived
> by some people.

Passing a machine-administered syntax check and being accessible are  
fundamentally different things qualitatively. A (skilled) software  
developer can always make his/her program to produce output streams  
that pass a machine-administered syntax check regardless of the input  
of the program. Making the output meet its primary function *and*  
making it accessible at the same time depends on the cooperation of  
the data source the program has to work with.

So (a non-trivial subset of) software developers when they consider  
the question "Can I make the output of my program pass a machine- 
administered syntax check?" (in realistic vocabulary "Can I make the  
output of my program validate?") the answer is "Yes". If it happens  
that due to external constraints the answers the question "Can I make  
the output of my program accessible while still letting the software  
fulfill its primary function?" is "No", the software developer may end  
up hurting accessibility even more in order to make the output pass  
the machine-administered syntax check nonetheless.

I think it doesn't make sense to elicit software developer behavior  
that hurts accessibility even more, when the situation is that the  
developer can't make the output accessible (because doing so would  
require some day to that the data source to provide).

(I know that I'm going to get offended email because I used the word  
"primary" above. But let's be honest. There are use cases where people  
feel that they seek to deal with images in particular instead of  
feeling that they are seeking to communicate in general. For example,  
my camera doesn't even have a text input method, so the design of that  
human artifact reveals that someone thought people might want to  
capture pixels without capturing text at the same time and the fact  
that I bought the artifact validated this assumption.)

I think we've already established that there are use cases that are  
legitimate but cannot be accessible to everyone, so I think taking the  
stance that software should refuse to fulfill its primary function  
when the output cannot be accessible is not a reasonable position to  
take.

> Authoring tool developers have their own guidelines they should be
> following that disallow this practice.

The fundamental qualitative difference of making output passing a  
machine-administered syntax check and making the output accessible  
doesn't go away by twisting the definitions in a W3C publication.

> Sure, there are some amazingly
> poor developers out there, but lowering conformance constraints in the
> markup to exonerate these poor developers is not the solution.

You need software developers to make the Web more accessible. Giving  
them guidelines that seem completely unnatural to them because they  
intuitively see the fundamental qualitative difference I mentioned  
above and then chastising them as "amazingly poor" isn't helpful. The  
guidelines don't make the fundamental difference go away, so it would  
be more productive to work forward by not trying to twist words to try  
to hide the difference.

> Regardless of whether poor authoring tool developers proudly output
> bogus alt text in an attempt to make the content valid, or good
> authoring tool developers assist authors in providing good alt text,
> and do nothing if nothing useful is provided, the end result is that
> the content will not be accessible to some users, and neither should
> be considered compliant.

What I'm trying to get at is that it doesn't make sense to establish a  
policy that causes failures to be harder than they have to be. And  
there will be failures.

> At best, exonerating poor authoring tools by removing the requirement
> for alt text, which is essential for the resulting structure to be
> perceivable to some users, *may* result in some software developers
> refraining from doing the wrong thing, although that is unlikely, as
> these are poor software developers with little regard to guidelines
> they should be following (if it works, why change it?).

You know, part of the reason why developers aren't following the  
guidelines could be that the guidelines are really unnatural from the  
point of view of the developers.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Saturday, 17 May 2008 11:01:27 UTC