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

Hi all,

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

I disagree with this. adding alt="" is a sign that the image has no
important information, using it for any image takes away any chance
for the image to be recognised as significant

Note that in HTML5 an image with alt="" maps to role=presentation,
when implemented in browsers this will result in the image being
removed from the accessibility tree. So for any AT that relies on the
accessibility tree represent content to the user, the image will not
exist.


regards
Stevef

On 2 August 2012 07:57, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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/
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

Received on Thursday, 2 August 2012 07:47:41 UTC