RE: img@relaxed CP [was: CfC: Close ISSUE-206: meta-generator by Amicable Resolution]

Henri Sivonen wrote:
> 
> 
> If it's believed to be true that <img src="567dfg.jpg"> always
> provides a worse user experience to the point of "harm" than <img
> src="567dfg.jpg" alt="">, it seems to me the logical conclusion is
> that the behavior of JAWS is harmful is should change, because it's
> obvious that JAWS could be programmed to make <img src="567dfg.jpg">
> exactly like <img src="567dfg.jpg" alt="">.

Hi Henri,

JAWs, NVDA, VoiceOver, Orca, EMAC-Speak, Hal/SuperNova, ChromeVox, SA-To-Go/System Access... (and those are just some of the Screen Readers targeted to "Western" consumers). There are numerous screen readers out there, and so please forgive me if I confused the issue by stating what the most popular Western-based screen reader is doing today.

Then there are also different types of conditions where the pain inflicted on the non-sighted end user can change.

In actual fact, in JAWs today, if all you have is <img src="567dfg.jpg">, then yes, JAWS is now silent on that image. However, wrap a link around that image: <a href="http://validator.nu"><img src="567dfg.jpg"></a> and with JAWS/IE it reads out the file name of the image; meanwhile with NVDA/FF it reads out the full URL, which given some of the dynamically named URLs we see today can be down-right painful. On the Mac side of the aisle, VoiceOver today will read the file name (I believe whether it is a link or not, but cannot confirm at this writing).

Asking all of these different tools to "change" because today alt-less images throw too many annoying errors to a code validation tool is somehow an upside down proposal to me.  How about Validator.nu change to allow for better filtering of what is clearly and obviously a problem to your consumers?


> 
> > Here's Some Real Harm:
> >
> > How does changing the above to <img src="567dfg.jpg" relaxed="">
> improve the
> > end experience for the non-sighed user?
> 
> I believe Ted's proposal hinges on the assumption that it's useful to
> be able to distinguish between images that don't have alternative text
> but whose existence is acknowledged by screen readers and images whose
> existence isn't acknowledged by screen readers.

But he has not stated *why* he presumes that it is useful, especially to the end user. Neither have you.

I think Mike Smith has made a clear case and helped me understand why this distinction is useful to code validators, and even why. But to the blind end user, knowing that there is an important image there, but tough luck, 'the system' can't or won't bother to accommodate you is, frankly, a giant, auditory version of the 1-finger salute: "Here's an import image, too bad, so sad".


> 
> Do you believe this assumption is incorrect? In the specific context
> of JAWS? In principle?

I do not understand where the assumption is coming to be honest. Do I disagree with the conclusion that Ted's assumption has wrought? Absolutely.


> 
> Two years ago, you said 'dummying up the image element with either
> alt="" or role="presentation" is wrong, and yet forcing a screen
> reader to read aloud the image file name is also wrong', which to me
> suggests you agreed with the assumption at least on the level of
> principle two years ago.
> http://lists.w3.org/Archives/Public/public-html/2010Aug/0155.html 

Let me clarify what I mean, and meant there.

I believe that for non-sighted users, all visual data of importance should have an accessible name, and hopefully an accessible description (as defined in the various Accessibility APIs). Traditionally, in HTML (since almost the introduction of the <img> element) the means of providing that has been @alt for the accessible name (and for the accessible description, the earliest attribute is @longdesc).

I believe that not providing, at the absolute minimum, an accessible name to a visual asset (via either @alt, or now today using any number of other methods - http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H67) should not be accepted. Period. That image/asset is broken, it has no value to many users, and the page is incomplete in almost exactly the same way as if the actual binary image file (PNG) was 404 or otherwise corrupted: 2 conditions that I am quite confident you would be loathe to filter out of your results as a default setting.

I believe that it is wrong to accept an image without a textual equivalent, and that it should be a conformance error plain and simple.

I also believe however that it is equally wrong to inject code, be it alt="", role="presentation" (or now, the proposed relaxed="" or generator-unable-to-provide-required-alt) as a means of silencing error messages, or gibberish output to synthesized voices / screen readers.

The right answer, the only correct answer, is to supply the alternative text. Anything less than that *is* a failure, and we should be honest about stating as such. 

It is not a weakness of a validation tool to report all errors, it is (IMHO) a strength. That multiple errors are being reported to engineers who cannot control the whole end-to-end output can be annoying, that I get. Good! Be annoyed, fight hard to make them go away by pushing within your organization to actually fix the errors, rather than mask them behind a special switch that does the end user no practical good. It's a false solution: Quality Control without the quality is nothing but control...

Look, nobody likes to admit failure - I get that. But crafting some kind of magic bean so that you can pretend that you are not failing, or that allows you to shift the failure onto somebody else's lap ("hey, *MY* code validates") is not the solution, and I strongly resist the desire to make that part of the markup language.


> 
> I think Ted's proposal makes sense if the assumption I stated above is
> correct, and I believe it to be correct.

Why?

> 
> If the assumption is correct, 

Well, no one has been able to show why the assumption is correct. No evidence has been brought forth, and instead what we have is Ted's (and now your) assertion that the assumption is correct. 


> it's important that the relaxation be
> controlled by the markup generator rather than the person running the
> validator,

One of the critical flaws of this assertion is that you have no way of policing who and how the inserted magic bean is being applied. More importantly, inserting the magic bean does not improve the end experience for the actual user who requires the alt text ("Wow, you should see this important image - oh, right, ya, sorry"), it instead is a mechanism designed primarily to silence validators and other reporting tools.


> because the sort of developers of markup generators who
> want the output of their generator to validate would make it so that
> the output validates with the default settings of validators, since
> they would assume that people who judge the generator by the validity
> of its output would judge it with the default settings.

Am I the only one then who thinks that adjusting the default output of the Validator is an equally viable solution?

Ted's proposal states:
 "To enable large Web applications to effectively monitor their own markup quality, without enroaching on markup generators' existing efforts to market their tools, we should mint a new relaxed="" attribute for <img> elements which allows for the granular relaxation of certain author conformance requirements."

I am completely lost to understand how not reporting critical errors will at the same time "effectively monitor [their own] markup quality". Silencing an error does not make it go away, not now, not in the future, not ever.


> Thus, if we
> want to avoid the developers of markup generators inserting alt="",
> role="presentation" or alt="IMG1234.jpg", we should make sure that the
> default behavior of validators gives no incentive to insert that sort
> of things.

So instead the proposal suggests inserting a different magic bean: @relaxed. 

The insertion of that attribute is as non-useful as inserting alt="" from the final perspective of the (non-sighted) end user, and does nothing to actually remedy the real problem. Since a null value is in fact an acceptable value for @alt however, it *is* conformant, it does silence screen readers, and validators need not report it as a critical error: it can be a second tier report (the following images lack any alt text, is this what you want?).

In actual fact, we have examples of that today: http://achecker.ca/checker/index.php 


> 
> > Nope, not from me - I will be objecting to this at WBS Survey time.
> 
> Two years ago, Maciej asked: "can we compromise on a per-element
> generator exemption mechanism, rather than outright removal or
> retention of the current per-document mechanism?"
> 
> And you replied (still in
> http://lists.w3.org/Archives/Public/public-html/2010Aug/0155.html ):
> > If pressed, I personally like @noalt (or is that noalt="noalt"
> > for our XHTML5 friends?), but am not religious about it.
> >
> > It doesn't solve any real problems, but it *is* "truth in
> advertising". If
> > after all best efforts a content creator simply chooses to not do the
> > right thing, dummying up the image element with either alt="" or
> > role="presentation" is wrong, and yet forcing a screen reader to read
> > aloud the image file name is also wrong. Having an image with an
> > auto-generated @noalt (or equiv) essentially says "yes, this author
> is
> > inconsiderate, but he chooses to be so" (maybe we should consider an
> @jerk
> > attribute <grin>)"
> 
> Have you changed your mind or is your objection to the name "relaxed"
> and names "noalt" or "jerk" would still be okay with you?

Upon reflection, I guess I've changed my mind. If we *MUST* inject something into the source code, I think we have enough options already: I very much dislike inserting alt="" or role="presentation", but those options are better than minting a new attribute that does essentially the same thing for validators, BUT does nothing for the end user or the screen reading tools they use today. 

Introducing @relaxed (or any other new attribute) is pretty much an apparent re-invention of the wheel, that solves a problem for validators and their user-base, but does nothing of any real use or value to the end user, and can in fact open the door to a poorer user-experience not to mention one more attribute that can be misused and abused.

So if a generator tool *MUST* insert something into the code, the least objectionable solution to me would be to insert alt=""

JF

Received on Wednesday, 1 August 2012 23:58:54 UTC