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

On May 15, 2008, at 12:46, Gez Lemon wrote:

> On 15/05/2008, Henri Sivonen <hsivonen@iki.fi> wrote:
>> On May 15, 2008, at 01:35, Gez Lemon wrote:
>>> From what I understand, at this point, my opinion is completely
>>> aligned with members from the HTML5 community. The difference in our
>>> opinions is that although I would suggest the authoring tool has  
>>> done
>>> the right thing for this particular scenario, the HTML5 working  
>>> group
>>> want the resulting output to be considered to be in compliance with
>>> the specification. I disagree with this viewpoint, as the resulting
>>> structure is inconceivable to some users with visual impairments and
>>> cognitive disabilities, in a way that the resulting structure  
>>> would be
>>> inconceivable to sighted users if the src attribute wasn't  
>>> provided in
>>> a browser that renders images. That is the structure is  
>>> inaccessible,
>>> and couldn't possibly be considered valid.
>>>
>>
>> The notion that a syntax specification should require software  
>> conforming
>> to the specification  to produce syntactically non-conforming  
>> output under
>> some circumstances is patently bizarre.
>
> This is the real point of contention for which we're unable to reach
> consensus. I find it equally bizarre that an incomplete structure
> should be considered valid output from an authoring tool, despite the
> fact that the incompleteness means the resulting output cannot be
> perceived by some people.

It's only bizarre if you ascribe a different meaning to "valid" than  
what its meaning in the markup context is. It doesn't mean that the  
page is generally good. It only means that the page passed a machine- 
administered syntax check.

Being valid that doesn't mean that the page can be perceived by  
people. A valid page can be totally useless for everyone. I usually  
don't like comparing market languages to programming languages, but I  
think DanC's point that a C compiler doesn't and can't check that the  
program has no bugs was a very apt analogy. You can have a  
syntactically correct C program that is absolutely useless.

It is a bit problematic that the general English meaning of the word  
valid may suggest something more than merely passing a machine- 
administered syntax check. However, changing the word at this point  
after being used this way in the markup context since the 1980s would  
be tilting at the windmills. Moreover, it is something that we already  
tried (albeit we tried changing the connotation into the other  
direction). A couple of years ago the WHATWG was avoiding the use of  
the word "validator" and was using "conformance checker" instead. When  
I told people who were into computer science and who had already used  
an HTML validator that I was working on a conformance checker, I got  
blank looks until I mentioned the word "validator". (Except one time a  
Semantic Web guy said "oh you're writing an HTML5 *validator*" when I  
had said I was working on a "conformance checker".)

In general, people intuitively assume that validity doesn't cover all  
sorts of goodness. For example, that it doesn't cover grammatical  
correctness, family-friendliness, content making any sense or other  
such evaluation axes. Unfortunately, since *one* accessibility issue  
was masqueraded as a syntax issue in the HTML 4 spec cycle, people  
don't necessarily unconflate the syntax and accessibility evaluation  
axes intuitively. I think this may actually be a problem when telling  
people to take care of accessibility if they thought they already did  
when they took care of syntactic correctness.

>> We shouldn't require something that
>> is bizarre in a way that it doesn't fit the software developer  
>> mindset,
>> because then we don't get the reactions we want from software  
>> developers.
>
> I don't understand your point here. If an author chooses not to
> provide alt text, it's the author's fault that the resulting output
> doesn't conform to the specification - not the authoring tool's fault.

That's not how (a non-trivial subset of) software developers think.  
You can always write your software to pass a machine-administered  
syntax check, so if you are the kind of software developer who cares  
about the correctness of the code you put out there, you make sure  
that the data streams your software emits always pass a machine- 
administered syntax check.

This isn't something crazy only related to the developers' self- 
approval. Other people use a machine-administered syntax check as a  
litmus test of tool bogosity. For example, people use Validator.nu to  
validate the output of Validator.nu, presumably to check if the  
validator developer is incompetent. It will be very hard to dissuade  
me from making Validator.nu self-validating, because I fear that  
potential users will judge me as clueless and the validator as bogus  
if the validator isn't self-validating. (Aside for those who are now  
intrigued to try: There's a known bug in this department relating to  
Unicode normalization.)

What Daniel Glazman and Steve Axthelm said suggests that this isn't  
just in my head.

See
http://lists.w3.org/Archives/Public/public-html/2008May/0386.html
and
http://lists.w3.org/Archives/Public/public-html/2008May/0390.html

(Some non-trivial subset of) software developers know that meeting a  
machine-administered syntax check is it something that they can always  
program their software to do, so they do it. They do realize that the  
accessibility properties of the output of their programs depend on the  
input and, thus, not within their power to fix when the input source  
is uncooperative. From a software developer perspective, syntactic  
correctness and accessibility are obviously different evaluation axes.

Note that I am not asking you to agree that software developers are  
*right* to think like this. I am just saying that if you create a  
policy that doesn't take into account that software developers *do*  
think like this, you won't get the results you want. Also, "educating"  
software developers to think differently (as seems to have  
successfully happened in the case of Dreamweaver) is an uphill battle  
compared to making a policy that concedes that this is how software  
developers think and (perhaps even uses that in the policy's advantage  
if possible).

Compare with what I wrote about affordances of door handles:
http://lists.w3.org/Archives/Public/public-html/2007Jun/0808.html

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

Received on Friday, 16 May 2008 15:16:46 UTC