Two things that may be worth consideration: 

1. The possibility of responsive text alternatives that could parallel the responsive images if needed. The <picture> proposal allows for different sources for images at different sizes. But authors could use different images at different sizes and not just a cropped down version of a single image. No text alternative mechanism is provided for that use case. Allowing alt on <source> could provide for that use case. Something like the following might work:

<picture>
<source src="mobile.jpg  alt="text alternative">
<source src="medium.jpg"  alt="text alternative" media="min-width: 600px">
<source src="fullsize.jpg"  alt="text alternative" media="min-width: 900px">
<img src="mobile.jpg" alt="text alternative">
</picture>

2. A 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>

copied from email http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0127.html

I am concerned about the use of the
alt attribute on <picture> when it would be much better to allow text
alternatives inside the picture element.
Some of the advantages are:
Markup can be used to structure text alternative content.
The length of the alt text is no longer a constraint, as it is currently
for assistive tech.

current example
<picture alt="Description of image subject.">
<source srcset="small.jpg 1x, small-highres.jpg 2x">
<source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
<source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg
2x">
<img src="small.jpg" alt="Description of image subject.">
</picture>

Is there any reason why you think the use of alt attribute on picture is
preferable to

<picture role="img">

<p>alt text</p>

<source srcset="small.jpg 1x, small-highres.jpg 2x">
<source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
<source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg
2x">
<img src="small.jpg">

</picture>

note:role=img is just of polyfill purposes.

or


<figure>
<picture>
<source srcset="small.jpg 1x, small-highres.jpg 2x">
<source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
<source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg
2x">

<img src="small.jpg">

</picture>
<figcaption>caption text</figcaption>
</figure>

I can understand that backwards compatibility may be of concern in the
first example, but that can be resolved through the use of CSS to clip or
hide text content if so desired.

> I am concerned about the use of the
> alt attribute on <picture> when it would be much better to allow text
> alternatives inside the picture element.

I agree Steve. Check consult comment 1. 

I think we would to think about the best way to handle both short and long text alternatives and well as the adaptive functionality of the element.

Getting a picture element with accessibility thought out from the start would be a big win.

(1) Proposal:  Perhaps someone should file a separate bug to track the accessibility of <picture>?

(2) To reuse @alt would have backward compatibilty issues for AT tools. How? 
     FIRSTLY: Today @alt is only supported on a finite number of elements. And, frankly, it is only supported (quite) well on the <img> elemetn. (It is not at all supported that well on <area> and <input> - I could mention a numnber of issues.) Even screenreaders do - at least in theory - only look for @alt on elements where they know that it ought to exist. 
     SECONDLY: If instead we use mark-up as fallback/alternative text, the - until support is there - one can use @aria-describedby and @aria-labelledby in order to point to the fallback. By contrast, if one went for @alt, then the only way to be backward compatible would be by duplicating the @alt content with an @aria-label - like so: <picture alt="alternativ text" aria-label="alternative-text" >... </picture>

(In reply to comment #2)

> <picture role="img">
> 
> <p>alt text</p>
> 
> <source srcset="small.jpg 1x, small-highres.jpg 2x">
> <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
> <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg
> 2x">
> <img src="small.jpg">
> 
> </picture>


> I can understand that backwards compatibility may be of concern in the
> first example, but that can be resolved through the use of CSS to clip or
> hide text content if so desired.


Is it not as simple as setting  

    <p>alt text</p>

to
    <p style="display:none">alt text</p>

?

Keep in mind that whenever one do <foo role="img">, then the content of <foo> is considered hidden from AT *anyway*. For an <foo role=img>, then one *MUST* use an @aria- attribute in order to hold or point to the accessible text. *OR* one must use an attribute (such as @alt) and - perhaps?- even an element that is especially designated for alterantive text.

Some comments about this. First of all I think it's great if we can get so called "responsive images" into a spec so that there is a recommended way to do it. But I see some issues about this and alternate text.

In the proposal [1] it is said that all source elements in a picture element should represent the same subject matter. I don't think that will be the case. Take this example, someone makes a so called "mobile" design for their site. Both the regular site and the mobile design have a top banner image (but the mobile design's banner image takes up less space than the regular one). But they don't share the same subject matter. When the site is viewed with a width that is less than say 15em then the site switches to the mobile design. 

The problem now is that if we only have alt text for 1 image and the mobile design doesn't have the same content then the alt text would be incorrect. One way to solve this would of course be to have a alt attribute for each source attribute.

On the other hand the specification could clearly state that all different source elements needs to share the same subject matter. But if people start (ab)using it the way I described above then there is no way for a validator to check this.

I generally feel that if style="display:none" is needed then the design usually needs to be rethinked because it assumes that CSS is available everywhere, which it isn't. So it really only solves it for a subset of the user agents.

[1] http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal

(In reply to comment #5)
> On the other hand the specification could clearly state that all different
> source elements needs to share the same subject matter. But if people start
> (ab)using it the way I described above then there is no way for a validator to
> check this.

Hi Peter,

I too worry that nothing is stopping authors from using different images and suggested possibility using responsive alt on source (see comment #1).

Alternatively we would need some very strong spec text to outlaw different images. Suggestions? Maybe in the future it could be made machine testable? There are such things as TinEye.
https://addons.mozilla.org/en-US/firefox/user/3304309/?src=api

(In reply to comment #6)
> (In reply to comment #5)
> > On the other hand the specification could clearly state that all different
> > source elements needs to share the same subject matter. But if people start
> > (ab)using it the way I described above then there is no way for a validator to
> > check this.
> 
> Hi Peter,
> 
> I too worry that nothing is stopping authors from using different images and
> suggested possibility using responsive alt on source (see comment #1).
> 
> Alternatively we would need some very strong spec text to outlaw different
> images. Suggestions? Maybe in the future it could be made machine testable?
> There are such things as TinEye.
> https://addons.mozilla.org/en-US/firefox/user/3304309/?src=api

I think it’s going to be important that this be posed as a means of providing alternate sources for *content* images ( http://www.bostonglobe.com/magazine/2012/07/22 or http://www.apple.com, for example ). A banner that displays different decorative banners would be most appropriately done in CSS -- this would likely be simpler for the authors as well, especially given the new `img-set` CSS syntax. I’m sure we’re apt to see `picture` used incorrectly for decorate images but no more than we already see with `img`, I wouldn’t think.

It doesn’t hurt our case that this is such a high-profile issue in the dev community, and that `picture` is likely to see use from advanced and highly visible developers right away -- I think we’re likely to see a number of great examples of `picture` usage springing up almost immediately, paving the way for responsible usage in the future.

2 questions:

1/ Is it possible to allow width and height attributes on the source tags, this way the browser knows the dimensions before loading the image?

2/ Is it possible to allow the class attribute on the source tag and/or the picture tag?

Regarding 1, see also http://www.w3.org/community/respimg/2012/06/18/florians-compromise/#comment-1673

Strike question 2, class is supported on picture tag


(In reply to comment #8)
> 2 questions:
> 
> 1/ Is it possible to allow width and height attributes on the source tags, this
> way the browser knows the dimensions before loading the image?
> 
> 2/ Is it possible to allow the class attribute on the source tag and/or the
> picture tag?

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: No spec change.
Rationale: There are now a couple of extension specifications being
actively pursued by members of the WG which address this feature
request:

http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html
http://dev.w3.org/html5/srcset/

Instead of trying to separately address this feature in HTML5, we should
wait for one or both of the extension specifications meet the CR exit
criteria. This is why I've resolved this as LATER, instead of moving the
bug into the HTML.next component (as we've been doing with other feature
requests).

(In reply to comment #10)
> Instead of trying to separately address this feature in HTML5, we should
> wait for one or both of the extension specifications meet the CR exit
> criteria. This is why I've resolved this as LATER, instead of moving the
> bug into the HTML.next component (as we've been doing with other feature
> requests).

I think this is the right approach. 

I don't want the Responsive Images CG (RICG) to replicate work; And I think Hixie is in a much better position to specify the normative text needed to meet the use cases that the RiCG is pursuing. The RICG is focusing on the use cases to see if img@srcset meets all of them. 

The RIGC are working from the hypothesis that img@srcset does meet the use cases, but have identified a few places where it may not (Work in Progress): 

https://github.com/Wilto/draft-prop/blob/master/UseCaseComparisons.md

We've also moved work to github: 
https://github.com/Wilto/draft-prop/

Suggested Tracker Title: Add an adaptive image mechanism to HTML5.0

Suggested Tracker Description: Add an adaptive image mechanism per:
http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html

This mechanism should be incorporated into HTML5.0 proper and not pushed off into a ghettoized "extension".

Does this feature have either a thorough test suite or a single reasonably complete implementation?

(In reply to comment #12)
> This mechanism should be incorporated into HTML5.0 proper and not pushed off
> into a ghettoized "extension".

There's nothing "ghetto" about being in an extension spec. What matters is that a feature is implemented. Fighting over which document it goes into is the wrong battle.

https://www.w3.org/html/wg/tracker/issues/207

(In reply to comment #14)
> (In reply to comment #12)
> > This mechanism should be incorporated into HTML5.0 proper and not pushed off
> > into a ghettoized "extension".
> 
> There's nothing "ghetto" about being in an extension spec. What matters is
> that a feature is implemented. Fighting over which document it goes into is
> the wrong battle.

If the responsive images group wants to pursue incorporating the picture element into HTML5.0, they can do so. But I withdraw my tracker request. I wish them the best.

ISSUE-207 covering the questions of whether an adaptive image mechanism should be included in HTML 5.0 or published as an extension specification was resolved by a WG CfC:
http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0185.html