Re: Proposed adaptive image element

Hi Mat,

On Tue, Jul 24, 2012 at 10:26 AM, Mathew Marquis <mat@matmarquis.com> wrote:
>
> On Jul 24, 2012, at 7:48 AM, Laura Carlson wrote:
>
> With regard to accessibility 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>
>
>
> I wouldn’t want to run the risk of encouraging authors to use drastically
> different sources for an image

I wouldn't either. But what is to stop them?  We would need some
strong spec text to outlaw it. Suggestions? Maybe it could be made
machine testable? There are such things as TinEye [1].
BTW Peter Winnberg just commented on this problem on the bug [2].

> There has
> already been some discussion around how the `alt` attribute would “cascade,”
> so to speak, here:
> http://lists.w3.org/Archives/Public/public-html/2012Jun/0118.html

Thanks.

> 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>
>
>
> I’m very much in favor of this approach, provided that assistive technology
> would have the ability to “reach into” the `picture` element and access the
> more descriptive text.

Yes. That would be the idea.

Best Regards,
Laura
[1] https://addons.mozilla.org/en-US/firefox/user/3304309/?src=api
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18384#c5
-- 
Laura L. Carlson


On Tue, Jul 24, 2012 at 10:26 AM, Mathew Marquis <mat@matmarquis.com> wrote:
>
> On Jul 24, 2012, at 7:48 AM, Laura Carlson wrote:
>
> Hi Mat,
>
> With the above in mind I’d love to discuss the next steps in working towards
>
> a specification, and keep our momentum up. There was mention of filing a bug
>
> to have this proposal officially entered into the WG system — is that our
>
> next course of action?
>
>
> Filing a bug is step one in the HTML Working Group decision process.
> http://dev.w3.org/html5/decision-policy/decision-policy-v2.html
>
> With regard to accessibility 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>
>
>
> I wouldn’t want to run the risk of encouraging authors to use drastically
> different sources for an image (in my nightmares I see banners reading
> “welcome to my website” being swapped for “welcome to my iPhone website” at
> small sizes). I think it’s worth having it codified that the alternate
> sources are meant to provide different crop/zoom/representation of a single
> subject, and one should be able to accurately describe it a single string of
> assistive text. For example: Jason Grigsby’s example at
> http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/#artdirection
> can still be accurately described by “photo of President Obama speaking at a
> Chrysler plant.”
>
> I think it stands to reason that `alt` could be specified on `picture`. If
> the `alt` is omitted from `picture` but specified on the fallback `img`,
> that `alt` should likely apply to the `picture` element overall. There has
> already been some discussion around how the `alt` attribute would “cascade,”
> so to speak, here:
> http://lists.w3.org/Archives/Public/public-html/2012Jun/0118.html
>
>
> 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>
>
>
> I’m very much in favor of this approach, provided that assistive technology
> would have the ability to “reach into” the `picture` element and access the
> more descriptive text. Alternately, `picture` is a prime candidate for use
> within `figure`, so it’s possible that role would be best served be
> `figcaption` — rather than leaving authors to specify fallback content as an
> afterthought strictly for a11y purposes, having that content readily
> available to all users might encourage them — and could be further improved
> through the use of `aria-describedby`.
>
> There’s similar discussion taking place in parallel on the WHATWG list,
> here:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/036675.html
>
> Best Regards,
> Laura
>
>



-- 
Laura L. Carlson

Received on Wednesday, 25 July 2012 13:35:18 UTC