- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sun, 28 Nov 2010 10:11:28 +0000
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: CSS 3 W3C Group <www-style@w3.org>
On Sat, Nov 27, 2010 at 2:41 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 11/26/10 2:40 AM, Benjamin Hawkes-Lewis wrote: >> >> But note in WAI-ARIA's "Text Alternative Computation" algorithm: > > This isn't exactly the first time WAI specs are ... somewhat divorced from > reality (in this case, by introducing a direct conflict with CSS2.1, as you > note). I think reality is a bit more messy than that. Consider the discussion of how generated content should be added to content copied to the clipboard: http://www.w3.org/Search/Mail/Public/advanced_search?keywords=&hdr-1-name=subject&hdr-1-query=CSS+Generated+content+selection&hdr-2-name=from&hdr-2-query=&hdr-3-name=message-id&hdr-3-query=&period_month=&period_year=&index-grp=Public__FULL&index-type=t&type-index=www-style&resultsperpage=100&sortby=date-asc Consider also the discussion of generated content in: http://www.w3.org/TR/CSS-access#Generated Hiding generated content from assistive technology introduces a certain disparity between what non-screenreader-users and screenreader-users can do with user stylesheets (or Stylish skins or whatever). Consider a user who wants to add text "START INSERT" and "END INSERT" to "ins" elements. A non-screenreader-user can do so by tweaking the CSS in their browser. But if that generated content is not exposed to AT, then it cannot represent it in speech or braille. This isn't necessarily the end of the world, in that screenreaders can provide UIs for customizing how they represent document semantics, but it still bears thinking about as it implies an extra layer of interpretation between the browser and the screenreader providing an interface to that browser. >> "Text nodes are often visited because they are children of an element >> that uses rule 2C to collect text from its children. However, because >> it is possible to specify textual content using the CSS :before and >> :after pseudo-elements, it is necessary for user agents to combine >> such content with the text referenced by the text nodes to produce a >> complete text alternative." > > Do UAs actually do this? Safari and Opera do. Details follow. Safari 5.0.2 Mac: * In the Apple Accessibility API tree (as inspectable with Accessibility Inspector), content in ":before" is placed into AxGroup (a generic grouping) as a parent of the AxStaticText. I can't see content in ":after" in the tree, but (critically for your question) VoiceOver reads out text in ":before" and ":after" alike. * "list-style-type" determines the grouping of list items in the accessibility tree (even when bullets are applied to an ordered list, or numbering to an unordered list). The bullet/number is placed in the AxGroup as a parent of the AxStaticText. VoiceOver will read numbers out as you navigate through lists, and if you interact on a character-level, you can gain access to the precise bullet character (e.g. "black square"). * "quotes" is unimplemented. * Text replacement unimplemented. * Image replacement results in the image going into the accessibility API and not the text. VoiceOver just reads "image". * Icon replacement unimplemented. Opera 10.63 Mac: * ":before" and ":after" exposed as AxStaticText and read out by Voiceover. * "list-style-type" not exposed to the accessibility tree. * "quotes" is unimplemented. * Text replacement: new text exposed as AxStaticText. VoiceOver reads the new text, then the original text, then the new text again (can't see why this happens from Accessibility Inspector). * Image replacement: neither the image nor the text are exposed to the accessibility tree. * Icon replacement unimplemented. Firefox 3.6.9 Windows: * Inspecting with UI Spy, text in ":before" and ":after" is not placed into the accessibility tree. JAWS 12 does not read it. * Inspecting with UI Spy, "list-style-type" generated content is placed as an additional text item inside the list item text. JAWS 12 reads the generated bullet (as "bullet") or numbering (e.g. "i"). * Inspecting with UI Spy, "quotes" content is not exposed to the accessibility tree. JAWS 12 does not read it. * Text replacement unimplemented. * Image replacement unimplemented. * Icon replacement unimplemented. Firefox 4 Beta 7 Windows: * Inspecting with UI Spy, text in ":before" and ":after" is placed into the accessibility tree, although JAWS 12 does not read it. * Inspecting with UI Spy, "list-style-type" generated content is placed as an additional text item inside the list item text. JAWS 12 reads the generated numbering (e.g. "i") though not the generated bullet. * Inspecting with UI Spy, "quotes" content is exposed to the accessibility tree. JAWS 12 does not read it. * Text replacement unimplemented. * Image replacement unimplemented. * Icon replacement unimplemented. IE8: * Inspecting with UI Spy, text in ":before" and ":after" is not exposed in the accessibility tree and JAWS does not read the generated text. * Inspecting with UI Spy, "list-style-type" generated content is not exposed in the accessibility tree. JAWS reads "bullet" for an ordered list styled as an unordered list, but "bullet" for an unordered list styled as an ordered list. * Inspecting with UI Spy, "quotes" content is not exposed in the accessibility tree. JAWS does not read the quotes. * Text replacement unimplemented. * Image replacement unimplemented. * Icon replacement unimplemented. -- Benjamin Hawkes-Lewis
Received on Sunday, 28 November 2010 10:12:02 UTC