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

Hi, all

I had a discussion with john F last night in regards to how the
presence of a generated image, without without an alt attribute but
with the proposed attribute, should be exposed in accessibility APIs.
simply having the attribute present in the DOM is not enough due to
the various accessibility API dependent methods AT use to access
representations of the DOM.

So the question is how should we advise browsers to identify images
with attribute X via acc APIs?

A potential method is by advising browser implementers to provide a
text string to use as the accessible name value.

For example;

"Description not provided."

This would result in the the image presence being announced by a
screen reader (for example) as
 "graphic - Description not provided."

Why have I used the word 'description' here when an text alternative
or alt text is  not meant to be a 'description' of the image?
Because I think the jargonistic terms used in web standards to
describe the text contained with an alt attribute are not necessarily
appropriate for end users. if this is not the case please disabuse me.

A potential issue with this is that the text may be mistaken for an
actual alt text for the image as it will be delivered through the same
property as alt text is provided i.e. somebody may think it is a true
represenation of the image content.

I think that this is a side effect that could be ameliorated by use of
a common, agreed, text string across browsers, so such images are
consistently identified. AT could then provide further options to the
user if they so choose, for example later versions of JAWS include an
OCR feature.

It may also be practical to couple the use of the string with a
currently defined accessibility  property/state to provide
diambiguation of the acc name string as true alt. For example the
'alert low' state in MSAA or via an object attribute in IAccessible 2.

Advantages of a browser supplied text string over an author supplied
text string are the potential for consistent identification and also
consistent localization of the text string across languages.

It should also be considered whether it should be advised the same
text string is displayed visually by browsers when images are disabled
or not available.I would advise that this does occur as it offers
visual users the opportunity to further investigate the image, where
as currently (in Firefox for example) there is no visual indication
that an image without an alt is present within the page.


regards
SteveF

On 1 August 2012 01:58, Michael[tm] Smith <mike@w3.org> wrote:
> Edward O'Connor <eoconnor@apple.com>, 2012-07-31 15:13 -0700:
>
>>          http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-206
>>
>> While this Change Proposal is both concrete and complete, I intend to
>> solicit comments from conformance checker developers which may result in
>> testimonials I would like to cite in the Rationale section.
>
> Speaking personally and only with my conformance-checker-developer hat on,
> I strongly support this change proposal. I've not talked with Henri about
> it yet, but if he were also supportive of it, then it's something we would
> implement support for in the validator.nu sources (on which both the
> validator.nu service and W3C Nu Markup Validation Service are based).
>
> Some specific parts of the CP that lead me to express support for it:
>
> 1. I agree with the statement in the CP which asserts that the general use
> case this CP is attempting to address is an important use case to address.
> The use case is valid, and I think we should all work together to try to
> find out a way to address it that we can all agree on. This CP seems to me
> to be the most viable CP for this issue so far that we actually have a
> chance of getting agreement on.
>
> 2. The observations in this CP about the need for "granular relaxation" for
> this use case are particularly important and need to be considered; I
> believe in particular the following statement makes an important point:
>
>   "The markup of large Web applications is typically partly generated from
>   code and partly sourced from hand-authored HTML templates. With an
>   all-or-nothing mechanism, there's no way to relax the conformance
>   criteria for only the portions of the document corresponding to
>   user-generated content, while retaining strict requirements on the
>   portions of markup from the hand-authored HTML templates.
>
> This CP addresses that particular use case. The meta@name=generator
> exception currently in the spec does not.
>
> 3. Related to #2, I agree with the following assertion about the positive
> effects of this proposed change:
>
>   "We enable engineers of large Web applications to catch markup errors that
>   they can do something about, without bothering them about markup errors
>   they can't do anything about."
>
> That's something which is of real-world concern to validator developers.
> When users attempt to validate documents and end up getting a large amount
> of error messages about potential problems which they have no means to
> correct directly themselves, we risk having them just give up and quit
> using the validator altogether. This is of very practical concern for
> anybody maintaining a validator: You want users to keep using your validator
> and to have the validator match their real-world needs as much as possible.
>
> Anyway, in summary and as I mentioned in #1, I think this CP provides a
> resolution that we have a good chance of getting agreement on among the
> people in the group who so far have been unable to reach agreement on it.
> So I hope everybody involved can consider it very carefully, with an open
> mind.  It's not a perfect solution for the problem. We're not going to find
> a perfect solution. But this is the best solution I've seen so far.
>
>   --Mike
>
> --
> Michael[tm] Smith http://people.w3.org/mike
>



-- 
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 08:14:15 UTC