- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sat, 30 Apr 2011 00:48:24 +0200
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Judy Brewer <jbrewer@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Benjamin Hawkes-Lewis, Fri, 29 Apr 2011 23:02:34 +0100: > On Fri, Apr 29, 2011 at 10:08 PM, Leif Halvard Silli wrote:> > >>>> 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. >> >> And (text) authors shouldn't need dictionaries? >> >> I think everyone needs a validator. > > My point is not that "top-notch authors" don't find value in > validators, but that if "top-notch authors" are failing to include > @alt all over the place in hand-authored pages then they're > unconcerned about the accessibility drawbacks of doing so, rather than > unaware of them. My point was actually that those HTML5 pioneers that I listed probably are aware of the debate about @alt in HTML5 and that this plays a role in why they have omitted @alt. Also, the theory of Ian is that it hurts accessibility to display an error message when @alt is omitted. >>>> * 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. >> >> HTML5 doesn't make it *obligatory* for generators to use the generator >> flag. If it were obligatory, the much less should there be a 'generator >> exception'. > > Either a generator chooses to use the flag or it doesn't. It doesn't need > two code paths to be conforming. (It might want to give authors an option, > but that's not required by spec.) 'Code path' needs a definition. Clearly, if a generator behaves differently with regard to what it does for image accessibility when it uses the flag compared to when it doesn't use the flag, then that represents two code paths, no? Since many generators will rely on online or embedded versions of the official validator, then - unless they modify the validator - it is highly likely that they *will* behave differently with and without the flag. Or, even if they formally don't behave differently, the author may perceive that it does. >>>> * 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. >> >> And apart from that, they were OK? > > I wouldn't go that far; I'm just talking about code paths. :) It seems that the transitional/strict/half-strict doctypes for the most part affected parsers, which was bad enough. >> The generator exception would burden developers and authoring tools >> creators. E.g an author who wants full validation must remove the >> generator string via post-editing with a text editor. Or the generator >> must offer a way to not publish the generator string. Or a new kind of >> generator flag would be invented by the tool vendors (e.g. a HTML >> comment ...). > > Hmm. I think I'd pitch the failure to removal the flag in terms of > errors costing users rather than being a massive burden to authors. > > Users will lose out when images miss @alt text because: > > * Authors take tool output (e.g. via Tidy) as the basis for > handcoding, but forget to remove generator flags. Exactly. Forget or find it impractical. > * Novice authors copy-paste code that includes the generator flag, > without understanding its effect they have on conformance checkers. Right. Good points. >>> 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? >> >> I'm not going to look for any authoring tool vendors ... Firstly: what >> should I ask them? > > Point them to the relevant bits of spec, then ask them if they will apply > the flag in the next version of their product, and if not, why not. If the generator exception is meant to please vendors, the most relevant question to ask perhap sis whether they need such an exception. >> Second: I am embarrassed to ask them - I'm ashamed >> about the entire, childish exception. Having to spend hours to get the >> chair to reopen this issue is ... well. > > Understood. > > The reason I suggest asking is that the Chairs have stressed that > they look for concrete examples to support claims like this when > evaluating the strength of objections. There is one example mentioned: what Aryeh said about MediaWiki. See the first paragraph. Aryeh was, as I understood it, focused on the need, due to 'those authors', for the exception. One reason why I won't ask is that I don't think we need the kind of answers that Maciej gave to John: a promise that Apple finds accessibility very important. What was that meant to mean? That we can just keep the generator exception because Apple will produce high quality code regardless, because they have a higher bar than that exception? But if evidence pops up before Monday, one could of course discuss to add it on the meeting then. [ snip ] -- leif halvard silli
Received on Friday, 29 April 2011 22:48:54 UTC