RE: role="text" and text frames

“I’m still not clear what problem role=text is solving.”

The most useful thing I can imagine for this role is to negate the effects of block level elements within interactive widget roles, so they aren’t as confusing to AT users like in screen readers.

For example, if you include three Divs within an A tag plus href as a standard link, plus a few images, plus a heading, and you wanted all of that content to linearize correctly as one string of text for the link name when conveyed, you could use role=”text” to force it to do so.

And yes, I have seen developers do this type of thing, so this is a real example.

Beyond that though, I’m not sure what else the role would be good for.




From: Cynthia Shelly [mailto:cyns@microsoft.com]
Sent: Wednesday, February 10, 2016 2:36 PM
To: James Teh <jamie@nvaccess.org>; Rich Schwerdtfeger <richschwer@gmail.com>; Matt King <a11ythinker@gmail.com>
Cc: Joseph Scheuhammer <clown@alum.mit.edu>; Alexander Surkov <surkov.alexander@gmail.com>; Rich Schwerdtfeger <schwer@us.ibm.com>; wai-xtech@w3.org; public-aria@w3.org
Subject: RE: role="text" and text frames

The equivalent in UIA would be
<p>foo <span onClick=";">bar</span> bas</p>

Text pattern:
Foo [format break]bar[format break] bas

Control Tree:
Page
Text with Invoke pattern

Without the onclick (or a tabindex, or a few other things)
Text pattern:
Foo bar bas

Control Tree:
Page

I think the Text element in the Control Tree is equivalent to a text frame in IA2.  I think we could put it in for <img role=text> but that would be different than how we handle text elements in general. For most text elements (span, em, h2, etc) we don’t create a control view item unless there is a tabindex or a few other special cases.

I’m still not clear what problem role=text is solving.

From: James Teh [mailto:jamie@nvaccess.org]
Sent: Tuesday, February 9, 2016 5:47 PM
To: Rich Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>>; Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>
Cc: Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>; Cynthia Shelly <cyns@microsoft.com<mailto:cyns@microsoft.com>>; Alexander Surkov <surkov.alexander@gmail.com<mailto:surkov.alexander@gmail.com>>; Rich Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>>; wai-xtech@w3.org<mailto:wai-xtech@w3.org>; public-aria@w3.org<mailto:public-aria@w3.org>
Subject: Re: role="text" and text frames

On 10/02/2016 2:52 AM, Rich Schwerdtfeger wrote:
If we make this the text role the AT should have enough knowledge that it is either a raster image or a vector drawing
How does it get this knowledge? By looking at the role of ancestors? Certainly, the static text role isn't sufficient to communicate this.

Static text is important in that it would allow the text to be read to the user when placed in a line of text. Text frame would not work that way. It would be treated as a separate entity much the same way we handle TDs when role=“presentation”  is applied to a  table.
I disagree. As I've pointed out before, text frame (at least as it's used in web browsers today) shouldn't be treated as a block element; it's actually inline. ATs might *choose* to present it on a separate line, but that's a choice, not something inherent in the role. Take the following example:

<p>foo <span onClick=";">bar</span> bas</p>

Firefox exposes "bar" with a role of text frame, but it's still very much inline and can thus be rendered on the same line unless an AT chooses to render it separately for UX reasons.

Jamie


--

James Teh

Executive Director, NV Access Limited

Ph +61 7 3149 3306

www.nvaccess.org<http://www.nvaccess.org>

Facebook: http://www.facebook.com/NVAccess


Twitter: @NVAccess

SIP: jamie@nvaccess.org<mailto:jamie@nvaccess.org>