W3C home > Mailing lists > Public > public-html@w3.org > August 2010

RE: Specific points of controversy relating to alt text (ISSUE-31, ISSUE-80)

From: John Foliot <jfoliot@stanford.edu>
Date: Fri, 13 Aug 2010 19:56:40 -0700 (PDT)
To: "'Maciej Stachowiak'" <mjs@apple.com>, "'HTMLwg WG'" <public-html@w3.org>
Message-ID: <01ed01cb3b5c$51ab9360$f502ba20$@edu>
Maciej Stachowiak wrote:
> 
> 
> ** Query for the Working Group: can we compromise, and agree to have
> alt information *both* in a detailed standalone document *and* in the
> HTML5 spec? None of the arguments presented seem to require the
> information to be exclusively in one form or the other.

IMHO, the location of the information is of lesser import than the value,
credibility and usefulness of the information. 

Many from the accessibility community have significant issue with some of
the current guidance the Draft HTML5 specification, and prefer
http://dev.w3.org/html5/alt-techniques/ as more accurately being in synch
with WAI-WCAG guidance, and delivering to those who require alternative
text. The suggestion of using SSI as a method to include the guidance in
the monolith tome is, to me, non-controversial so long as the editor has
no issue with it. *IF* however this also involves further editorial
embellishments by the editor then I would likely oppose this.


> 
> ** Query for the Working Group: can we agree to remove this exemption,
> as largely superseded by the generator exemption?

I see this as non-controversial at this time, with my personal preference
of the per-element mechanism as being the most scalable and robust.


> 
> ** Query for the Working Group: can we compromise on a per-element
> generator exemption mechanism, rather than outright removal or
> retention of the current per-document mechanism?

See above. If pressed, I personally like @noalt (or is that noalt="noalt"
for our XHTML5 friends?), but am not religious about it. 

It doesn't solve any real problems, but it *is* "truth in advertising". If
after all best efforts a content creator simply chooses to not do the
right thing, dummying up the image element with either alt="" or
role="presentation" is wrong, and yet forcing a screen reader to read
aloud the image file name is also wrong. Having an image with an
auto-generated @noalt (or equiv) essentially says "yes, this author is
inconsiderate, but he chooses to be so" (maybe we should consider an @jerk
attribute <grin>)


> 
> ** Query for the Working Group: can we set aside the call to remove the
> figcaption exemption, particularly given a favorable outcome on (2) and
> (3)?
> 
> ** Query for the Working Group: can we set aside the call to add aria-
> labeledby to the list of exemptions, particularly given a favorable
> outcome on (2) and (3)?
> 
> ** Query for the Working Group: can we set aside the call to add
> role=presentation to the list of exemptions, particularly given a
> favorable outcome on (2) and (3)?

So long as 'setting aside' does not equate to "bury out back somewhere and
forget about it", then addressing larger issues first makes sense from a
work-flow perspective. Thus, mark me as a tentative and feeble yes...


> 7) Should we remove the title attribute exemption to the alt
> requirement?
> 
> This is a point that we may not be able to resolve by consensus, even
> if we resolve the others.

I am uncommitted at this time.


> 
> 
> 8) Should the semantic definition of the img element be changed, from
> saying it represents "an image", to saying that it represents "content
> that can be rendered visually (as an image) and textually"?
> 
> Perhaps we can drop this mostly-editorial change, if we can get closer
> to consensus on the more technical points above.

I personally prefer "content that can be rendered visually (as an image)
and textually" as there is a long term pedagogical win there as we
continue to teach emergent web developers (the developers of tomorrow)
about issues of Universal Design and Accommodation for Person with
Disabilities, by continually reminding authors that a complete <img> in
the markup language requires both imagery and text to be 'complete'. The
reality is that on the street, most authors will continue to refer to it
as 'an image', but if official documents and specifications make the
effort of using the 'fuller definition' there is residual pay-off.  While
it truly is a semantic nuance, I believe it is none-the-less valuable. 

That said, I respectfully disagree with aspects of Laura's Change Proposal
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100504 which
continues to insist that the "textually" part of an image *MUST* come from
the alt attribute, as having a more flexible means of associating such
text to an image will likely improve the overall accessibility of images
on the web. To that end, I am in agreement with the current WAI CG
Consensus Resolutions on Text alternatives in HTML 5
(http://www.w3.org/2009/06/Text-Alternatives-in-HTML5.html) 

Cheers!

JF
 
Received on Saturday, 14 August 2010 02:57:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 14 August 2010 02:57:17 GMT