- From: Antony Kennedy <antony@silversquid.com>
- Date: Mon, 19 Nov 2012 10:58:44 +0000
- To: James Craig <jcraig@apple.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
- Message-Id: <936E7923-39FA-47D2-B772-0CE763DB0AE5@silversquid.com>
Changed topic. But following on from:Need fallback alternatives for CSS generated *text* content containing unicode glyphs I'm worried about this statement: In this vein, I'm not opposed to a similar approach, where we define an "alt" property that only applies to pseudo-elements and takes a <string> as its value. The presence of 'alt' means that 'content' is decorative, and you should read 'alt' instead. Absence means you should read 'content' as normal. It suggests that we either: a) Read the alt b) Read the content There doesn't seem to be a scenario wherein it is just decorative, and neither should be read out. Your example shows an empty alt - but this was not called out as meaning "do not read anything". It might be good to be very clear on the behaviour. It's completely valid for images, but not other types of content. Say I want to insert a colon for visual purposes, but not have it read out: label:after { content: ':' } I'm actually surprised that this content is read out and that we want to cater for scenarios where CSS is inserting content rather than just decorative elements that are safe for assistive technologies to ignore. To my mind, CSS is for presentation, not content. Regardless, using the method described would I add an alt of ""? This is what I think is unclear. I should be able to call out specifically that this element is decorative. It's very common that we use hacky CSS to clip elements or apply negative indents and so on to make content perceivable to Google and AT but not visually. And also, it seems there is a need to make content perceivable visually, but not to AT or Google. The "accessibility" or "visuallyhidden" classes exist in countless boilerplates. So my request would be a new property to state what technologies an element is perceivable by. Something like: perceivable: none; /* effectively display:none; */ perceivable: at; /* assistive technologies i.e. screen readers/braille displays */ perceivable: robots; /* search engine spiders - is there a better term for this? */ perceivable: all; /* initial value */ Is this something that can be sensibly achieved with media queries? @media not speech and @media speech seem like they should work great here. However, the screen reader attaches to the output of the browser (what the browser sends via Operating System APIs) and not the browser itself, so when the browser is parsing the CSS it never understands to expose or not expose these pieces. aria attributes work correctly here though, so there must be a solution! This is one of those situations where authors are commonly hacking around a problem, and we should provide a real solution. Any thoughts? On 15 Nov 2012, at 23:34, James Craig <jcraig@apple.com> wrote: > On Nov 15, 2012, at 3:25 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > >>> 1. Should the 'alt' property only apply when content has been replaced, or would it apply at all times? >>> .foo:before { alt: "This text only available to assistive technology?"; } /*e.g., no visibly rendered content for the pseudo-element. */ >> >> If 'content' isn't set to a non-"none" value, the pseudo-element isn't >> generated at all, so no. > > Okay. > >>> 2. Would you also expect this to override content of native DOM elements, rather than just pseudo-elements? >>> <foo style="alt:'baz';">bar</foo> <!-- Potentially confusing to authors. I'm not sure it'd be a good idea on actual elements. --> >> >> No, just pseudo-elements. Specifically, just ::before and ::after for now. > > I concur. > >>> PS. How should I track this request? File a bug? WG Issue? >> >> We track these things through WG email, so you're already covered. > > Great. Thanks. > > James > > PS. I don't actively follow www-style anymore, so please let me know if you'd like any more feedback on the idea as it progresses. > >
Received on Monday, 19 November 2012 10:59:14 UTC