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

I like Johns addendum to Lauras resolution text regarding not  
suppressing warnings in the validator.

Rather than lowering standards that would raise the floor.

Cheers

Josh

On 12 Apr 2010, at 04:11, "John Foliot" <jfoliot@stanford.edu> wrote:

> 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 acc 
> essible?
> 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 08:50:17 UTC