- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Tue, 24 Jul 2012 16:40:26 +0100
- To: whatwg@lists.whatwg.org
Hi Mat, >Yeah, this would be a bit tricky in terms of backwards-compatibility, as you said. I feel the gut reaction from a lot of authors would be “I don’t want that text >showing up in some browsers but not others,” then (sadly) omission. It’s hide-able with CSS, as you said, but it would add some complexity. I would have thought a <picture> polyfill would handle the hiding. and I am not sure that the possible backward compat issues should deter us from providing a better text alternative method in the longer term. besides thinking about it, providing the alt on the img would suffice until such times that lat text as a child of <picture> is supported (if implemented). which removes the need for alt on picture altogether, which is of no use anyway until it is implemented. <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" alt="Description of image subject."> > </picture> >This seems like a great candidate for `figcaption`, and could be pollyfilled, in a way, through the use of `aria-describedby`. I wouldn’t want to discourage the use of >`alt` tags on either `picture` or the fallback `img`, but — and correct me if I’m wrong — isn’t `aria-describedby` specced to take precedence over the `alt` attribute? >That might be the ideal approach — and even if not, a bit of redundancy may not hurt there. There is one current implenentation [1] (Firefox) of figure/figcation accessibility. this implementation can be illustrated using ARIA. although it does not use ARIA, the acc support is provided through IAccessible2 <figure role=group aria-labelelledby="caption1"> <img> <figcaption id="caption1"> caption text <figcaption> </figure> So the figcaption content labels the figure. Also note that the figcaption has a role=caption (from IA2), but that is not currently defined in ARIA In regards to aria-decribedby it does not override the alt attribute, aria-describedby provides the accessible description, it is not used in accessible name calculation. if aria-labelledby is on an img element it overrides that alt. [1] figcaption http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-43 figure http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-44 regards SteveF On 24 July 2012 16:05, Mathew Marquis <mat@matmarquis.com> wrote: > > On Jul 23, 2012, at 5:38 PM, Steve Faulkner wrote: > > > Hi Mat, > > as I previously previously mentioned, 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. > > > > > > <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> > > Yeah, this would be a bit tricky in terms of backwards-compatibility, as > you said. I feel the gut reaction from a lot of authors would be “I don’t > want that text showing up in some browsers but not others,” then (sadly) > omission. It’s hide-able with CSS, as you said, but it would add some > complexity. > > > > > 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> > > This seems like a great candidate for `figcaption`, and could be > pollyfilled, in a way, through the use of `aria-describedby`. I wouldn’t > want to discourage the use of `alt` tags on either `picture` or the > fallback `img`, but — and correct me if I’m wrong — isn’t > `aria-describedby` specced to take precedence over the `alt` attribute? > That might be the ideal approach — and even if not, a bit of redundancy may > not hurt there. > > > > > 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. > > > > regards > > Stevef > > > > > > > > On 23 July 2012 20:06, <whatwg-request@lists.whatwg.org> wrote: > > > >> Send whatwg mailing list submissions to > >> whatwg@lists.whatwg.org > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org > >> or, via email, send a message with subject or body 'help' to > >> whatwg-request@lists.whatwg.org > >> > >> You can reach the person managing the list at > >> whatwg-owner@lists.whatwg.org > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of whatwg digest..." > >> > >> > >> When replying to digest messages, please please PLEASE update the > subject > >> line so it isn't the digest subject line. > >> > >> Today's Topics: > >> > >> 1. Re: Media queries, viewport dimensions, srcset and picture > >> (Mathew Marquis) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Mon, 23 Jul 2012 11:39:14 -0400 > >> From: Mathew Marquis <mat@matmarquis.com> > >> To: whatwg@lists.whatwg.org > >> Cc: Florian Rivoal <florianr@opera.com> > >> Subject: Re: [whatwg] Media queries, viewport dimensions, srcset and > >> picture > >> Message-ID: <E4FEB344-8A53-438F-928A-9B9F0F3FE270@matmarquis.com> > >> Content-Type: text/plain; charset=windows-1252 > >> > >> WHATWG, > >> > >> The Responsive Images Community Group was recently asked to furnish a > >> formal draft proposal for consideration by the HTML WG. I thought it > best > >> to post it here along with some details, where Ian Hickson has mentioned > >> that he?ll be considering this issue again within a few days. > >> > >> More and more it seems that it?s a waste of effort trying to retrofit > the > >> original srcset proposal to cover all the use cases of the original > >> `picture` proposal. As we attempt to do so, the `srcset` msyntax grows > more > >> confusing, and shares an increasing amount of overlap with media > queries ? > >> though with some obvious holes, for example: units other than `px`. To > >> those ends, the Responsive Images Community Group has officially > published > >> a draft proposal based on Florian Rivoal?s proposed compromise ( > >> > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036160.html) > between the two markup patterns. In this way, `srcset` retains the > >> purpose for which it was originally proposed: a terse, > easily-implemented > >> syntax for switching image sources based on the client resolution. > >> > >> The draft proposal can be found here: > >> http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal > >> > >> Discussion with the HTML WG can be found here: > >> http://lists.w3.org/Archives/Public/public-html/2012Jun/0113.html > >> > >> ## Proposed Markup > >> > >> <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> > >> > >> The chain of events followed by the above markup pattern are: > >> > >> 1. If the `picture` element is unsupported, the `img` contained therein > is > >> shown as fallback markup. > >> 2. If picture is supported, use `media` attributes to determine which > >> source element best suits the user?s viewport, following the same logic > as > >> `video`?s specced use of `media` attributes. > >> 3. Once an appropriate source element has been selected, the `srcset` > >> attribute determines which image source is best suited to the user?s > screen > >> resolution. If only a single resolution is necessary, the `src` > attribute > >> will function as expected, instead. > >> > >> In terms of selecting a source element, this markup leverages all the > >> strengths of media queries ? the syntax created for this very purpose ? > to > >> handle the ?art direction? use case. > >> > >> However, as has been detailed at length here and elsewhere, > >> `device-pixel-ratio` media queries are poorly suited towards these > >> decisions. As an author, using vendor-prefixed `min-device-pixel-ratio` > >> media queries in the example above would involve a massive amount of > text > >> and twice as many source elements. This could get unwieldy for authors > very > >> quickly, a concern voiced numerous times in these ongoing discussions. > >> Further, implementation of MQ-based resolution switching is far more > >> difficult on the UA side: a very real concern. > >> > >> Once we?ve used media queries to determine the most appropriate source > >> element, srcset?s originally intended usage becomes absolutely ideal for > >> our purposes: simply determining the appropriate image source for a > user?s > >> resolution. > >> > >> It?s worth noting that this example is, in fact, the most convoluted > this > >> element can ever be. This pattern in no way precludes the use of srcset > on > >> an `img` tag for simply preforming resolution switching, nor does it > >> preclude the use of `picture` as originally proposed for the ?art > >> direction?/screen size use cases, with `src` in source elements rather > than > >> `srcset`. > >> > >> ## Bandwidth > >> > >> We cannot reliably make assumptions about bandwidth based on client > >> capabilities ? a MacBook Pro with a Retina display may be tethered to a > 3G > >> phone; a high-resolution mobile device is as likely to be connected to > WiFi > >> as it is an EDGE connection. > >> > >> Based on previous discussion on the list, I think we?re largely in > >> agreement that bandwidth decisions are best left to the browser. It > would > >> assume a great deal if authors were to make this decision for the > users. It > >> would add a point of failure: we would be taking the bandwidth > information > >> afforded us by the browser, and selectively applying that information. > Some > >> of us may do it wrong; some of us may find ourselves forced to make a > >> decision as to whether we account for users with limited bandwidth or > not. > >> To not account for it would be, in my opinion, untenable ? I?ve > expressed > >> that elsewhere, in no uncertain terms. The decision to download high vs. > >> standard resolution images should be made by user agents, depending on > the > >> bandwidth available ? and further, I believe there should be a user > >> settable preference for ?always use standard resolution images,? ?always > >> use high resolution images,? ?download high resolution as bandwidth > >> permits,? and so on. > >> > >> In discussing the final markup pattern, we have to consider the above. > >> Somewhere, that markup is going to contain a suggestion, rather than an > >> imperative. I think `srcset` affords us that opportunity: a new syntax > >> _designed_ to be treated as such. I wouldn?t want to introduce that > sort of > >> variance to the media query spec ? a syntax long established as a set of > >> absolutes. > >> > >> It seems `srcset` won?t be going anywhere, and that?s not an indictment. > >> There is a time and a place for `srcset`, and I feel that place is > >> resolution switching ? as it was originally intended. Our best efforts > to > >> bring srcset closer in-line with the originally proposed picture element > >> only stand to leave us with a siloed microsyntax that inconsistently > serves > >> the purpose of media queries. With that comes further opportunity for > >> errors by implementors and authors alike ? countless new potential > points > >> of failure. > >> > >> ## Updated Polyfill > >> > >> In order to better wrap my head around this pattern, I?ve updated Scott > >> Jehl?s Picturefill to make use of the proposed syntax. The source code > is > >> available on GitHub ( https://github.com/Wilto/picturefill-proposal/ ), > >> and I?ve posted a demo ( http://wil.to/picturefill/ ) as well. > >> > >> Thank you for your ongoing consideration, sincerely. I look forward to > >> finally putting this issue to rest. > >> > >> Mat Marquis > >> > >> > >> > >> ------------------------------ > >> > >> _______________________________________________ > >> whatwg mailing list > >> whatwg@lists.whatwg.org > >> http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org > >> > >> > >> End of whatwg Digest, Vol 100, Issue 28 > >> *************************************** > >> > > > > > > > > -- > > with regards > > > > Steve Faulkner > > Technical Director - TPG > > > > www.paciellogroup.com | www.HTML5accessibility.com | > > www.twitter.com/stevefaulkner > > HTML5: Techniques for providing useful text alternatives - > > dev.w3.org/html5/alt-techniques/ > > Web Accessibility Toolbar - > www.paciellogroup.com/resources/wat-ie-about.html > > -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Tuesday, 24 July 2012 15:41:41 UTC