Re: Updated ISSUE-206 CP

On Wed, Aug 22, 2012 at 3:33 AM, John Foliot <john@foliot.ca> wrote:
> Benjamin Hawkes-Lewis wrote:
>>
>> Yeah, fine, but …
>>
>> The proposed attribute would be a fairly weak signal of the importance
>> or non-importance of the image.
>
> How so? It would signal that there is an image that may or may not be important, but that the system does not know.

[snip]

> there is an image here that is probably not strictly decorative: it may or may not be important, but the system does not know.

Yes, that's what a "fairly weak signal" is … where's the disagreement here?

>> Conversely, its absence
>> means little: the web corpus will continue to overflow with critically
>> important images without @alt or this new attribute.
>
> I'm not looking to solve all problems overnight, and this is certainly one of those types of problems. Developing a solution that has incremental benefit is of equal value to me over seeking the Holy Grail of alt text.

I'm suggesting we pursue features with larger incremental
accessibility benefits before the feature you suggest, not a "Holy
Grail".

> We currently lack *any* mechanism that accurately conveys to the non-sighted user that there is an image on the page that most likely should have, but does not have, some alt text.

Absence of @alt is a weak signal that an image is important.

It's a signal used by AT today.

We could improve the information AT has to go on here by supplementing
absence of @alt with other signals such as dimensions. These signals
would be stronger than the signal you propose but more critically
they'd cover much more of the corpus. So the cost/benefit ratio of
exposing other signals is more favorable.

Whether AT would actually make use of additional signals for
determining image importance is questionable I guess. In practice,
most accessibility API clients could pull the relevant information out
of the DOM if they wanted to, it's not like failing to surface these
signals directly in the accessibility hierarchy is a serious blocker.
JAWS mostly seems to bypass the accessibility API exposed by Gecko.

> The overwhelming feedback I got was that non-sighted users want to know *that* fact.

And their software, appropriately configured, allows them to know it.

>> We should be practical and concentrate on improving the accessibility
>> mappings to support more effective heuristics, such as intrinsic
>> dimensions, color variation, filename, and repeated use, that would
>> apply to images with or without this attribute.
>
> Sorry Ben, but heuristics is just a fancy way of saying guessing, and I for one am adamant that guessing is a horrible way of moving forward.

I disagree that guessing is bad, and I think you're proposing a
different, far less effective guess.

> While I did not ask the dozen or so daily users I spoke with earlier this month, I feel fairly confident that they would all concur that taking a stab-in-the-dark guess at an alternative text can be even more useless than being told that here's an image with no other details - at least in the second case they have an accurate and honest response from the system, and the end user can ask for sighted assistance if they so desire.

I was not talking about heuristics to determine alternative text, but
heuristics to determine whether an image is likely to be "important"
or not.

(It is true that exposing the filename might help with repairing
missing text alternatives; that's just a positive by-product.)

> If you believe you have a specific solution that could be included in HTML5, please do bring it forward

I thought I already did several times: expose dimensions, color count,
and filename (possibly other fields) as distinct fields in the API. I
believe Steve already said he'd ask AT vendors what they might want
here when we had this discussion the first time round. An alternative
(or possibly parallel) approach would be to push the heuristics into
the browser so that the browser would be responsible for identifying
likely decorative images, just as Gecko tries to identify layout
tables.

Like your proposal to expose this attribute in accessible name, this
belongs in the accessibility API mapping guide not HTML5 proper.

> however until such time as such a solution exists, I myself will continue to seek a usable solution that solves user-problems now.

Your proposed solution (overloading accessible name to expose this
weak signal) creates new user problems by breaking existing
configurations and repair measures. Exposing it as a separate field
would create only opportunity costs, so that's not so bad.

--
Benjamin Hawkes-Lewis

Received on Wednesday, 22 August 2012 03:26:48 UTC