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