- From: Gez Lemon <g.lemon@webprofession.com>
- Date: Mon, 12 Apr 2010 01:46:31 +0100
- To: John Foliot <jfoliot@stanford.edu>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
On 11 April 2010 22:54, John Foliot <jfoliot@stanford.edu> wrote: > OK, so we call it an ERROR. Now what? What *practical* result does it get > us? > > The image still displays in the browser. > > Even calling it a "super-mega-show-stopping-error-to-end-all-errors" still > gets the same result in the browsers, so it's just a word IMHO; the net > result is that the image still displays. What have we 'won', what have we > gained? The word to describe something that is structurally incomplete is important. If there is no text alternative, the content will not be perceivable by some people. The fact that an image with a valid src attribute displays in a visual browser is of no use to people that are unable to perceive the image. If the border attribute is specified on a an image element, conformance checkers must issue a waning. Does an erroneous border attribute have the same impact that a missing text alternative would have? It's incomprehensible that these issues should be regarded equivalent. In software engineering, the difference between an error and a warning is of massive significance. A compiler will not compile code if there is an error in the source. A compiler will compile code if there are warnings, and warnings can be suppressed in all compilers I've ever used. The WDG HTML validator has an option to suppress warnings, as does the W3C's CSS validator. There's no reason why HTML5 validators would also have an option to suppress warnings (retaining features from HTML 4.01 that are not in HTML5 are not considered important, so result in warnings), which will result in something important for accessibility being degraded to the same level as including some redundant feature of a previous version of HTML. >> Both are on the >> same level. Lowering standards for one and not the other is >> discrimination. I can't live with that. WAI CG's consensus document >> doesn't live with that. > > Laura. This isn’t about _us_ lowering our standards - that has been done for > us already by the browsers and there is no going back; we won’t get > draconian fail and honestly that is the only real penalty that would make > @src and @alt truly equal. (The browsers could use the same argument too > BTW - that introducing draconian fail is a lowering of their well > established rendering standards to a point that they cannot accept) I assume you must mean browsers refusing to render content for anyone if errors are present, as browser do behave significantly better if alt is present (the difference between making the content perceivable to some users, whereas it can't be made perceivable if a text alternative has not been provided). This issues is absolutely about lowering standards, and there are significant consequences. It's not so much about what browsers refuse to do if there are errors, but what they're able to do with valid content. If alt text is provided, decent browsers relay the alt text to an accessibility architecture, and will use the text if images are not loaded for whatever reason. If no alt text is provided, they can't relay that information to an accessibility architecture nor display anything if images are not loaded. Suggesting that something as important as a text alternative for images is a "SHOULD", rather than a "MUST" is absolutely lowering standards. Gez -- _____________________________ Supplement your vitamins http://juicystudio.com http://twitter.com/gezlemon
Received on Monday, 12 April 2010 00:47:05 UTC