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

Hi Ben,

> I know! That's a behavior chosen by the AT and we shouldn't be trying
> to override it. Some ATs have different default behavior (e.g,
> VoiceOver). Most popular AT allow users to configure it.

I will try and provide some clarity in roder to further the
discussion, As I said previously I can agree that the provision of a
text string as originally suggested is problematic, so lets place that
to one side.

Provision of a semantic indicator via an accessibility API state or
property will not override anything. It will only offer AT the
opportunity to convey such information to the user.

>> Likewise some graphical browser do not indicate such an image when
>> images are disabled.
>
> Even if we wanted to encourage them to do something else, that
> wouldn't require a change to the existing accessibility hierarchy.

I did not say it did, I was suggesting that the information that there
is an image that is a key part of the conetnt, not eye candy, may be
information worth conveying.

> They are indicated to the accessibility hierarchy and AT do give users
> options, so this requirement (which I agree with) is already met. And
> some AT already have default behavior that alerts users.

the following,

image 1 is a diagram of a process it does not have an alt.

<img src=123.gif>

image 2 is an image used for layout purposes it does not have an alt.

<img src=456.gif>


both images are  represented in the accessibility tree as:

example MSAA
	accName;
	accRole;graphic;
	accState;normal
	accDescription;
	
The first is an image containing complex information, the second
contains no useful information. This difference is not conveyed via
the accessibility tree.

> If we think the default behavior of JAWS should be different based on
> the information already in the hierarchy, we should take that up with
> Freedom not try and override their defaults by changing what goes into
> the hierarchy.

Changing what is represented in the accessibility tree does not mean
AT must act upon that information. The information that an image
contains important content, but does not have an alt is not already
provided in the accessibility tree, thats why I have brought it up for
discussion.

regards
steveF


On 3 August 2012 09:59, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
> On Fri, Aug 3, 2012 at 9:36 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>> the default beahviour for most AT under most circumstances, when no
>> alt is present is to not inform the user that the image is present.
>
> I know! That's a behavior chosen by the AT and we shouldn't be trying
> to override it. Some ATs have different default behavior (e.g,
> VoiceOver). Most popular AT allow users to configure it.
>
>> Likewise some graphical browser do not indicate such an image when
>> images are disabled.
>
> Even if we wanted to encourage them to do something else, that
> wouldn't require a change to the existing accessibility hierarchy.
>
>> I can agree that the generation of a text string may be problematic ,
>> but do not agree that the presence of images "that are a key part of
>> the content" but "whose contents are not known" ( to use HTML5
>> terminology [1])  should not be indicated in some way via an agreed
>> method that allows allows user agents to flag their presence and
>> provide users with options.
>
> They are indicated to the accessibility hierarchy and AT do give users
> options, so this requirement (which I agree with) is already met. And
> some AT already have default behavior that alerts users.
>
> If we think the default behavior of JAWS should be different based on
> the information already in the hierarchy, we should take that up with
> Freedom not try and override their defaults by changing what goes into
> the hierarchy.
>
> --
> Benjamin Hawkes-Lewis



-- 
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 Friday, 3 August 2012 19:20:42 UTC