- From: Michiel Bijl <michiel@agosto.nl>
- Date: Wed, 11 Nov 2015 17:28:51 +0100
- To: Joanmarie Diggs <jdiggs@igalia.com>
- Cc: www-style list <www-style@w3.org>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
- Message-Id: <D44E698C-D9B3-46B0-94EA-FEE9A488F25F@agosto.nl>
> On 11 Nov 2015, at 15:29, Joanmarie Diggs <jdiggs@igalia.com> wrote: > > Does VoiceOver have commands to read rendered text by unit (character, > word, line)? If so, what happens when you use those commands to read > text with generated content? Yes it does. It announces a h1 with a before and after as “heading level 1, 3 items”. So it sees all nodes (which pseudo elements are I guess) separate. If I use the arrow keys to navigate by character, VoiceOver ignores the generated content. Trying to navigate by word has the same result. > In the case of line, is the line spoken the > same as the line rendered? Or does VoiceOver, like at least some Windows > screen readers, have its own definition of "line" (e.g. > 125-characters-long slices of the text within the element)? Not sure about its definition, but it doesn’t speak the whole line/sentence. > Some background: From what I have seen, generated content IS exposed to > ATs when you ask for the entire text of this element. BUT it fails to be > exposed on some platforms if you ask for a specific unit (line, word, > character) for a given offset. If you ask me, generated content should come from attributes (via content: attr(attribute-name);). So to make generated content accessible, would it be possible to do something like button::before { content: attr(aria-label) } with the following HTML: <button aria-label=“Save to disk”><img src=“icon.svg”></button>. This might not be the best example, but I can’t think of anything where you would put handy information in generated content instead of in your HTML. > As a result of that failure, ATs that provide navigation based on the > layout of the rendered text, e.g. so the screen reader's next/previous > line commands read the same, full line displayed to sighted users, might > not be able to get that text using their platform's accessibility API to > get text by a specified unit. Instead, they would have to suspect that > their API didn't give them all the text and then implement workarounds > to figure out what the actual line is. Thank you for the explanation :) > HTH. > --joanie —Michiel
Received on Wednesday, 11 November 2015 16:30:19 UTC