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

On 12 April 2010 04:11, John Foliot <jfoliot@stanford.edu> wrote:
>> 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.
>
> Exactly!! That is Draconian Failure! However, in this particular instance,
> the 'compiler' (the browser) *WILL* compile (render) the image/page despite
> its brokenness. So while it is an ERROR (and I will even argue a critical
> one) to us, and our constituents, as far as the browsers are concerned, it
> isn't.

The browser (which is not a compiler) is behaving correctly, as it's
following Postel's law, as browser always have in order to handle tag
soup: "be conservative in what you do, be liberal in what you accept
from others". The important issue here, which I accept you understand,
is that they're not able to provide a text alternative if one hasn't
been provided. I'm not suggesting that browsers do not render invalid
content. The HTML5 specification goes into detail about how browsers
should recover from certain types of errors, such as unescaped
ampersands. An unescaped ampersand "might" clash will named entity
references: missing alt text will not be perceivable by some. I fail
to understand why anyone would consider missing alt text a mere
warning considering the consequences (not perceivable by some), rather
an error: it is an error.

> I've been saying exactly the same thing for years Gez, back to the
> html4all days.  I wrote then:
>
>        "Having *any* of the above methods of expanding upon the visual-only
> content present would thus render the <img> element conformant. I would then
> suggest that any other HTML5 implementation of <img> which lacks *any* of
> the provided means of "equivalent alternatives" be non-conformant, and
> further suggest that this result with the most drastic of consequences:
> non-rendering."
> http://html4all.org/pipermail/list_html4all.org/2008-April/000797.html
>
> as well as:
>
>        "It's about consequences: until such time as there are real consequences
> for slack developers/tools that allows content to exist that is incomplete,
> then there will be content that is incomplete - it's a simple
> as that.  Why would <img src="path..." /> be any more complete than <img
> alt="Photo of a leprechaun" />?  I mean, clearly, anyone processing that
> info in their user-agent will 'get' the intent of the author, right?  Yet
> today, the first example will render in the browser, the second delivers a
> 'fail'.  Ergo (to me) there is a problem of inequity here that must be
> addressed - if it fails for some, it should fail for all."
> http://lists.w3.org/Archives/Public/public-html/2009Mar/0418.html
>
> Those 2 statements got me this:
>
>        “Seriously, you know what we should do to make the world more accessible?
> F*** over all the sighted people.”
> - the ever eloquent Mark Pilgrim:
> http://diveintomark.org/archives/2009/03/18/if-it-fails-for-some

That's not saying what I'm saying: your two statements are extremist
and unreasonable. Browsers should and do follow Posetl's law. I don't
agree with the way Mark responded to you, but I agree with his
sentiments.

>> 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
>
> Then let's look at language that forbids the suppression of warning messages
> that impact accessibility: "Validators and authoring tools MUST NOT suppress
> warning messages of this nature".

So instead of dealing with the issue (missing a programmatically
determinable text alternative is incomplete and should be an error),
we should raise other bugs that are even more unlikely to be accepted
by the HTML5 working group? I can't see them accepting that
conformance checkers are not allowed to suppress warnings, as some
people just want to fix their errors, and don't particularly care
about warnings. That's why the name given to incomplete content is
important, as warnings are for trivial issues. Missing alt text is not
a trivial issue.

>> 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.
>
> Please elaborate on this point. What are the consequences? (outside the
> obvious failure to deliver to some members of the audience) What consequence
> arises from us calling or not calling this brokenness an ERROR?
>
> I ask this seriously and with respect.

The consequences are that people who care fix errors. Warnings are for
trivial issues, and aren't so important to fix. A missing text
alternative is an issue that should be fixed: it is an error.

> The Change Proposal goes to lengths to describe how, why and what should
> happen upon this discovery, and I support that 100%. What we call that state
> is in many ways irrelevant, as it is clearly (to me) not exhibiting all of
> the behaviors of ERROR (as defined in your analogy to compilers), yet it is
> also clearly unacceptable and incomplete.

It does exhibit the behaviour of an error: the resulting output is
incomplete, and therefore an error. An unescaped ampersand is an error
in HTML5 (and previous versions of HTML), but browsers are able to
recover from the error: it's still considered an error in that it is
something that should be fixed.

> In particular, if we get that second item baked into the spec we've gotten
> what we really need. THAT to me is what is really important - we have a
> mechanism that solves a problem, and who cares what that problem is called,
> we have a way to (hopefully) fix it. If anything, I would modestly propose
> the (minor edit) following:

This is where we disagree. I consider the name of the problem
important, as errors need fixing, and warning are things you could
have done better. I don't consider an erroneous border attribute on an
image element the same as a missing text alternative.

Gez


-- 
_____________________________
Supplement your vitamins
http://juicystudio.com
http://twitter.com/gezlemon

Received on Monday, 12 April 2010 10:07:39 UTC