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: CFIT <joshue.oconnor@cfit.ie>
Date: Mon, 12 Apr 2010 09:49:52 +0100
Message-Id: <DE5DDA6B-BC5D-4759-B5F2-E9C20B973320@cfit.ie>
To: John Foliot <jfoliot@stanford.edu>
Cc: Gez Lemon <g.lemon@webprofession.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
I like Johns addendum to Lauras resolution text regarding not  
suppressing warnings in the validator.

Rather than lowering standards that would raise the floor.



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:35 UTC