RE: feedback requested on WAI CG Consensus Resolutions on Text alternatives in HTML 5 document

Catching up on a lengthy thread:


Maciej Stachowiak wrote:
> 
> 
> Let's take the three points one at a time:
> 
> (2) The Consensus Resolutions document does allow <figure> <legend>
> like the spec, but it does not allow @title or a heading for an image-
> only section to describe an image. The current spec allows this, only
> in the case where the contents of the image are unknown.
> 
> - I believe the rationale I cited explained why the HTML5 spec offers
> some extra options for describe images in the case where the contents
> of the image are unknown. However, it's not clear to me if this
> difference is an explicit change request, which is why I asked for
> clarification first. Steve already clarified that some of the
> differences I identified were not deliberate.

FWIW, I believe that there should be room enough in the shed for any
number of solutions, and here I think *all* should be included; the key
being that they are programmatically linked to the asset.
[ http://html4all.org/pipermail/list_html4all.org/2008-April/000797.html ]



 
*****************
> (6) The Consensus Resolutions proposal recommends an explicit
> reference from HTML5 to WCAG 2.0.
> 
> - I don't believe Ian has given a reason for not referencing WCAG.

[ ]

> Tentatively, my recommendation would be to add a citation of the
> latest WCAG for additional accessibility advice, in a general section
> such as the introduction or conformance criteria. WCAG provides
> additional advice on many features of the spec, and will likely be
> updated over time. But I'd like to verify that this satisfies the
> goals of those who would like to add a WCAG reference.

I believe that overall, the specification structure would be more robust
if we had a means to 'flag' an item, issue or overall area (canvas
anyone?) with a point-back to WCAG; this could be extremely useful as a
general overall design goal not just for accessibility issues, but other
areas where extended education and explanation are desired.  While I
cannot speak for PFWG, I would happily second your recommendation as I
believe it meets the spirit of the request.



*****************

Jim Jewett wrote:
> 
> (1)  Is it OK to omit the Short Text Alternative if a Long Text
> Alternative is provided?
> 
> Yes, because it fills the need?
> No, because it might be "too long", and people won't want to listen
> through it?

It has been my experience (based upon feedback) that most users of screen
reading technology (as but one user group) prefer terse prose when
encountering @alt values.  It is a balancing act, to be sure, but the
analogy I generally like to use is that it should be the auditory
equivalent of 'a glance' versus 'an in-depth study' of the image.  Is it
OK?  I suspect that if the choice were to be *only* between a verbose
description versus *no* description (on a critical image) then the longer
description would be preferable, (but the terse description would be the
ideal).

> 
> It would be best to be explicit with your authoring advice and the
> reasoning behind it, as well as with the recommended effect on
> validity.

I agree. Does the above help?

> 
> (2)  Warning on alt="" without role="presentation".
> 
> Please be explicit on the reasoning.

An image with an empty alt value can be either deliberate or accidental.
If it is deliberate, it should be noted as such, if it is accidental than
the content author should be given the opportunity to improve their
content, either by adding appropriate alt text, or by signifying that the
image is presentational only.  I've suggested earlier that the word
"Warning" might be modified to "Advisory" instead, as it has less negative
connotations.

> 
> Is it (as a later email suggested) an attempt to promote the more
> general solution (aria)?  If so, that needs to be in the document, so
> that people will more easily realize role="presentation" applies to --
> and should be used with -- far more than just images.

Such as?


> 
> (3)  Auto-generated text:   "(Note: It is important that this marker
> is not included in the alternative text string itself.)"
> 
> Please be far more explicit in the reasoning.

I believe it does, but if it does not, I agree that the information should
be precise.  


> 
> I would personally want such a marker in my own pages, so that I could
> later find the ones that still needed human verification.  If that has
> to stay outside the attribute itself, then so be it -- but please say
> that explicitly.


The reasoning is that @alt should not be used for such a purpose: it's
purpose is clearly to be a text alternative to the image.  Since the
'alternative' of any image is subjective and dependant on context,
auto-generated text here is 'harmful'.  Here I believe role="img" [
http://www.w3.org/TR/wai-aria/#img ] is both truthful and accurate, and
could be a comparable marker to address the needs you noted.
Auto-generation of this has no real harm (outside of the potential of
overstating the obvious - this image is an image) It is worth noting
however that the image role states: "In order to be perceivable, elements
with a role of img SHOULD have alternative text or a label associated by
the accessible name calculation." 


> 
> As a user, I would prefer to know when an alt text is auto-generated,
> because it gives me some hints about reliability. 

Interestingly enough, this is why the recommendation states to *not*
populate the alt value with auto-generated text, it is simply unreliable
more often than not.


> But I do realize
> that I may be in an extreme minority here; if there are usability
> studies saying that the extra time to convey that information is truly
> annoying, then please say so explicitly.

I am not aware of any studies, but through inference it would need to be
"on-demand" queried information, and not automatically supplied, in
keeping with the "glance vs. study" analogy of above. The screen reader
users I have worked with in have generally suggested that they want the
minimum information required to make sense on the first pass, with the
ability to revisit and expand upon information as required.

> 
> Would it be acceptable for a GUI tool to add an extra attribute saying
> whether or not attribute values had been verified by a human?

I personally suspect that any such attribute would be gamed very early on
and lose its value quickly.  Good @alt values are proof enough that a
brain was involved in the process


> 
> (4)  Use case 2:  Please make it explicit that the photo site MUST NOT
> add role="presentation"; or at least not without user confirmation.

Agreed!



*****************

Jonas Sicking wrote:
> 
> 
> My general impression of @alt is that relatively speaking it has been
> pretty successful, as far as "bolt-on" accessibility attributes go.
> This makes me wonder why. I can think of two reasons:
> 
> 1. @alt is required, and thus a missing @alt is flagged by validators
> 2. @alt used to be displayed by IE as a tooltip
> 
> I don't know which has been the more important reason, but the
> important part is I think that 1 has helped.

+1  This is also the number one reason why accessibility advocates have an
issue with making @alt optional - it has been the number one 'tool' we've
had to start the accessibility dialog.  Accessibility is significantly
more complex than just having @alt text, but this is the starting point in
virtually all educational endeavors about the subject.  That said, I
believe that the proposal, while acknowledging the value and importance of
@alt, also allows for other means of supplying relevant information about
an image through other means, and I long ago opined that as long as one of
those means was present that the image could be conformant.  My reading of
the current proposal appears to back up this suggestion.

JF

Received on Wednesday, 19 August 2009 05:35:46 UTC