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

On Thu, Aug 2, 2012 at 2:58 AM, John Foliot <john@foliot.ca> wrote:
> 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.

So if we accept your definition of harm, the default behavior of all
screen readers is harmful. :-(

> In actual fact, in JAWs today, if all you have is <img src="567dfg.jpg">, then yes, JAWS is now silent on that image.

Oh, OK.

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

It would be possible to have different default validator behavior for
images that are descendents of <a>.

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

The point of the proposal isn't to reduce the number of annoying
errors a validator gives for the sake of reducing the number of
annoying errors. The point is to avoid reporting errors that would
lead markup generator developers to make the page worse for
accessibility in order to make the error go away.

Do you really not understand this distinction? Do you really think
this is about making things nicer to validator users? After all these
permathreads? Even if you disagree about what markup generator
developers would do or disagree that what they would do would be worse
for accessibility, I think it's totally counterproductive to
mischaracterize what this discussion is about.

If you believe the markup generator developers adding the alt
attribute with the empty string value images for which they cannot
supply a text alternative that's based on the content of the image is
not harmful, please focus on making that point instead of
misrepresenting what this discussion is about.

>> > 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 presume that it's useful, because I expect image-oriented pages
disorienting to navigate if the fact that there is an image is
concealed from the user. Therefore, I presume that acknowledging the
presence of the image makes the page less disorienting to navigate
even if the lack of a text alternative doesn't help to make sense of
what's in the image.

Unfortunately, this is on the level of presumption, because I don't
have user testing data that would indicate whether users are better
off getting the acknowledgment of the existence of an image with
unknown content or better off having the existence of the image
concealed altogether.

> 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 have user testing data that indicates that users prefer not to
know an image exists at all in that case?

> The right answer, the only correct answer, is to supply the alternative text.

The question is, what outcome is the next most preferred if you take
it as a given that your most preferred outcome is unavailable. It's
entirely unproductive to hold the line that this question must not be
considered, because you want your most preferred outcome always.

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

Well, then, I suggest that it's more productive to focus on the
correctness of the assumption first than to argue that the conclusions
are wrong regardless of whether the assumption is correct or not.

> Upon reflection, I guess I've changed my mind.
...
> So if a generator tool *MUST* insert something into the code, the least objectionable solution to me would be to insert alt=""

That's the reasonable answer if you disagree with the assumption
underlying Ted's CP. Thanks. Do you have data or anecdotes about
whether screen reader users out there outside WAI agree with you?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 2 August 2012 06:58:19 UTC