- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 16 May 2008 18:15:49 +0300
- To: Gez Lemon <gez.lemon@gmail.com>
- Cc: "HTML Working Group" <public-html@w3.org>, "W3C WAI-XTECH" <wai-xtech@w3.org>
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:49 UTC