- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Fri, 29 Apr 2011 21:13:18 +0100
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: Judy Brewer <jbrewer@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Fri, Apr 29, 2011 at 8:18 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: >>> 3. EVIDENCE: LACK OF ALT CHECKING IS HARMING >>> Additionally, since the HTML5 validators does not currently perform >>> any validation of whether alt is present at all or of how it is used, >> >> This is incorrect. See the "Show image report" feature at >> http://validator.nu/. > > I maintain that this is correct. There are two validators: validator.nu > and validator.w3.org. Only the former has an image report. But the > image report is just that - a report. Fair response. I still think this compromises the purity of the test. > The selection consists of pages made by "HTML5 pioneers" and people who > teach others about HTML5 authoring. These are "to notch" authors and > not "average joe". I've rarely found tech-hype pages of this sort to be beacons of best practice; usually the reverse. Top-notch HTML authors shouldn't need a validator to remind them to include an @alt. >>> A generator exception for img elements remains a form of >>> versioning. >> >> I find this argument sophistic. >> >> Document versioning was dumped from HTML because having versions trigger >> multiple code paths in user agents did not solve any problems the WG >> agreed were worth solving. >> >> The generator exception does not require multiple code paths even in a >> conformance checker, it's just yet another rule in its ruleset, and it >> does *try* to solve a important problem (specifically, the generation of >> bogus "alt" text). > > * the generator string creates "multiple code paths" in tools which > generate web pages How? Such tools should apply the generator flag. That's one code path not two. > and in the heads of the authors. I don't find this metaphorical leap persuasive. > * by your reasoning here, the difference between 'transitional' and > 'strict' is not related to versioning. Transitional doctypes triggered almost standards mode in Gecko, so they invoked multiple code paths. My impression is that the WG rejected versioning to avoid code branching in web engines to deal with HTML5 differently than other text/html based on some magic string at the top of the file (as originally requested by Microsoft, for example). Such code branching is bad because it hurts the competiveness of the browser market by significantly increasing the burdens on browser makers. I'm not saying there have not been other arguments, but that stands out to me as the one that actually mattered over the years. I don't think the WG will see itself as having nailed itself to the cross of making no difference in conformance requirements for different situations, so I think trying to hook ourselves to the no-versioning cart does us no favors here. I think we're stronger making arguments directly from clearly articulated user, author, or implementor needs or problems. If we can cite specific rationale from past decisions, all the better. e.g. Authors expect validators to act in a transparent manner. If the validator silently passes over missing @alt in generated code that will trick authors who are used to errors raised over their hand coding into thinking they haven't missed an @alt. >>> Authoring tools vendors are not going to be willing to stamp their own >>> code as substandard, let alone use their own product names as a >>> sub-quality marks. >> >> The generator flag doesn't establish two tiers of document quality >> beyond the >> obvious - generating good text alternatives requires human input. > > I don't see that you contradict what the text says. I don't think the text is a realistic portrayal of how vendors will see the flag. Maybe find some tool vendors who would actually refuse to use the flag, so that we have specific evidence of this? >>> C: GENERATOR IS ALREADY IN USE FOR OTHER PURPOSES >>> Authoring tools use the generator string as a kind of signal to >>> those who view source - to identify pages made by their product. >> >> How many any authoring tools that do not have any features for automatically >> generating markup insert the generator flag? If they generate markup, >> then the generator flag is appropriate. > > What is not appropriate is for the spec/validator to draw any > conclusions about the @alt usage based on the fact that it is a > generator made page. I think it is entirely possible to make a good inference about markup that does not reflect the intention of an author, so I disagree that this is intrinsically wrong. And in this case, we're talking about an inference made from a statement by the author (or their tool), rather than just some random quirk of the markup. -- Benjamin Hawkes-Lewis
Received on Friday, 29 April 2011 20:13:48 UTC