Re: [css-content] Request for note regarding selection, search, and accessibility of generated content

> 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