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

Gez Lemon wrote:
>
> 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.

Agreed. It is broken - no argument. However, that is the reality today: by 
our definitions the browsers are broken too! The accurate word - the word 
that you yourself used, is INCOMPLETE.

>
> 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. 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

Standing hard and firm on a word, on a principle, does not solve the 
problem, and it is the _problem_ that I want to solve, not argue about 
semantics and the use of words. We can call it an ERROR - I in fact have 
expressed my preference for that term - but if it is not treated as an ERROR 
(and it's not), then is it really an error? The problem is, what we have is 
something that is significantly more than a WARNING item, but slightly less 
than a full-on ERROR in your analogy of software compilers.

How do we reconcile this?


> 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".

>
> 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.


> 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.

No, it's about what happens when an image is INCOMPLETE - when it is broken, 
and what happens when it is discovered to be INCOMPLETE.  Since it will 
still continue to render in the browser, it is already in many ways not an 
ERROR, as it is 'working' for a significant majority. (That BTW is the rub 
and the crux of the matter)

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.


> 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.

Yes, I understand all of this, I really do.


> Suggesting that something as important as a text alternative
> for images is a "SHOULD", rather than a "MUST" is absolutely lowering
> standards.

Gez, I don't see SHOULD in there anywhere. The Proposed Resolution reads:

 "RESOLUTION: Modify Laura's change proposal to have the conformance checker 
_normatively_ (my emphasis - JF) emit a warning as opposed to an error. This 
warning MUST refer to the appropriate WCAG document and section that 
provides remedial guidance to the author." 
[http://www.w3.org/2010/04/07-html-a11y-minutes.html]

It is also worthwhile re-stating 2 very important parts of Janina's 
clarifications:

 "As I understood things, this would not be available to us in the [current] 
HTML5 conformance checker. There would be no way to know what triggered the 
error. Something did, but [what] specifically triggered it is not 
identified. To continue this behavior in HTML5 conformance checking, and to 
get the additional direct pointers to WCAG, we had to agree to warning 
rather than error."
http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0100.html

 "Our compromise is contingent. The WCAG pointers are required or there's no 
deal. That's why we say 'normative'."
http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0110.html

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:

 "RESOLUTION: Modify Laura's change proposal to have authoring tools and 
conformance checkers normatively emit a warning as opposed to an error. This 
warning MUST refer to the appropriate WCAG document and section that 
provides remedial guidance to the author, and authoring tools and 
conformance checkers MUST NOT suppress (or allow for the suppression of) 
warning messages of this nature."

Respectfully

JF

Received on Monday, 12 April 2010 03:12:02 UTC