Re: Adaptive Image Element Proposal

On Sep 5, 2012, at 8:19 PM, David Singer wrote:

> On Sep 4, 2012, at 10:47 , Mathew Marquis <mat@matmarquis.com> wrote:
> 
>> I think our best bet is to require that authors specify an `alt` attribute on both `picture` and the fallback `img`. 
> 
> I think it would be sad to propagate the problem with 'alt further than it has gone: that it places presented text in the markup, rather than in the content where it can be marked up.  Can you explain why this propagation should happen?

Sorry, I think we have a few swapped wires what with this thread now spanning multiple lists: that post of mine was from a bit earlier on. I think we’re now largely in agreement that `picture` should rely on the “fallback” content for the sake of accessibility.

Myself:

>> After some thought, perhaps both cases are served by the fallback `img`—both the visual fallback for non-supporting browsers and for assistive tech. At the very least, users browsing by way of assistive technologies would be able to access the fallback `img` and associated `alt` attribute—something authors will likely specify anyway, and not something that can be easily omitted by mistake (at least, not without receiving a flurry of bug reports). At best, authors could be encouraged — but not necessarily required — to provide more rich fallback content: descriptive text beyond what is specified in `alt`, tabular data in the event that the `picture` represents an infographic, that sort of thing. This rich content could then, optionally, be visually hidden in non-`picture`-supporting browsers if desired.
>> 
>> This solution prevents duplication, avoids any additional attributes on `picture`, enhances the semantic meaning of the subject represented by the `picture` element, and provides an accessible minimum with no additional effort on the part of authors. It starts us from a seamlessly accessible baseline for authors—to my mind, a huge win—and provides us with greater potential for a11y enhancements. 

Adrian:

>> I'd rather see <picture>'s fallback rely on the existing momentum <img> has with its @alt -- just rely on <img> to be the fallback both for the alternate image and the @alt text. Leave @alt off <picture> altogether.

Leif:

>> Perhaps the best thing with the canvas model that the child <img> 
>> element becomes an integrated part of the <picture>. Which in turn 
>> removes the need - or wish - to duplicate the alternative text in each 
>> (fallback) layer. (And thus also removes the need/wisth to get rid of 
>> duplication via aria-labelledby ...)

Steve:

>> So until UAs support picture, text alternatives can be supplied via the fallback image. It could still be supplied this way for browsers that support picture btw.
>> 
>> <picture>
>> <img alt="text alternative">
>> </picture>
>> 
>> When and if <picture> becomes implemented in browsers then the text alternative can be provided as text in the sub dom:
>> 
>> <picture> 
>> This is the text alternative
>> <img alt="">
>> </picture>

In terms of allowing for richer and more meaningful fallback/accessible content, I’ll update the proposal to reference ISSUE-30, as Laura described:

>> 
>> [… ]Build on the success of alt for the SHORT description.
>> 
>> As an on-page or off-page LONG description, full semantics are
>> provided with longdesc. And as soon as ISSUE-30 is settled
>> successfully, it could be made available to <picture>. Or the picture
>> element could allow for semantic programmatically determinable in-page
>> rich text long description, if a description element was added to the
>> proposal:
>> 
>> <picture>
>> <img src="image.jpg" alt="text alternative">
>> <desc>structured rich text description with headings, lists, tables, etc.</desc>
>> </picture>
>> 

I’ll be certain to notify everyone once I’ve made that update—likely mid-day tomorrow—so we can all review and ensure I’ve phrased and referenced everything properly.

By using the single `alt` attribute on the fallback content (at a minimum) and allowing for more meaningful markup as a fallback by way of <desc> (in whatever its final form may be), I feel we’re in a much better place than duplicating `alt` attributes—we’re providing an accessible baseline without any duplicated effort on the part of authors, and the potential for a far richer experience once ISSUE-30 is settled. I’m genuinely glad to have been able to participate in this discussion—the solution is all the better for it, and I’ve personally learned a great deal.

Thanks so much, all. I’ll be in touch soon.

-M

Received on Thursday, 6 September 2012 01:28:58 UTC