RE: role="text" and text frames

“The side effect of using role text in that case would be to hide the image and heading semantics. Even if you have that crappy kind of construct, it is better to have access to it than blur it all together into a single string that would likely become nonsense as a result.”

Actually I disagree. Yes you can hide the native role semantics using role=presentation, however you cannot nullify the effects of block level elements within such controls, and at present there is no way of nullifying the effects of these.

As a result you get ATs like screen readers reporting that there are four links when arrowing down a page when there is actually only one. I see this all the time, and it is extremely confusing.


From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Thursday, February 11, 2016 12:41 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; 'Cynthia Shelly' <cyns@microsoft.com>; 'James Teh' <jamie@nvaccess.org>; 'Rich Schwerdtfeger' <richschwer@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

>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.

The name calculation already does that when calculating the name of the link. So, what’s the point?

The side effect of using role text in that case would be to hide the image and heading semantics. Even if you have that crappy kind of construct, it is better to have access to it than blur it all together into a single string that would likely become nonsense as a result.

Because I have seen things like that, I am sure that 90%+ of the time accessibility would be worse if the text role were used.

The idea that people would use text role that way is a good reason to much more severely limit its applicability. For example, we could limit its applicability to graphics and spans that contain extended characters and have no children.

Have any valid use cases outside of the SVG drawings that Rich mentioned been proposed? I do find the idea that someone would use SVG to draw text intriguing.

Again, I also think the API implementation should give screen readers a way to reveal the content as if the text role were not present.

Matt

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Wednesday, February 10, 2016 3:01 PM
To: Cynthia Shelly <cyns@microsoft.com<mailto:cyns@microsoft.com>>; James Teh <jamie@nvaccess.org<mailto:jamie@nvaccess.org>>; 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>>; 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

“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<mailto:jamie@nvaccess.org>>; 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>>; 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

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>