W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2010

Re: RESOLUTION to modify text alternative change proposal and reject WAI CG's consensus recommendation

From: Gez Lemon <g.lemon@webprofession.com>
Date: Mon, 12 Apr 2010 01:46:31 +0100
Message-ID: <v2je2a28a921004111746rdcae2c1hdd03b4d5b2e185ba@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:07 GMT