RE: role="text" and text frames

That’s close. We don’t want to expose it as an accessible (in UIA-speak, it is not an object in the Control Tree).  There is a text pattern for the whole page, and it is part of that. To get the right text to add to the text pattern, we would need to perform name calculation.  To continue with the example


1)      Once upon a <img alt=”foo”> time

Page text pattern is “Once upon a [image object] time”

Accessible tree is

Page -->  Image [name=”foo”]

2)      Once upon a <img tabindex=”0” alt=”foo”> time

Page text pattern is “Once upon a [image object] time”

Accessible tree is

Page -->  Image [name=”foo”]



3)      Once upon a <img alt=”foo” role=”presentation”> time

Page text pattern is “Once upon a [format break?] time”

Accessible tree is

Page



4)      Once upon a <img alt=”foo” role=”text”> time

Page text pattern is “Once upon a foo time”

Accessible tree is

Page



5)      Once upon a <img alt=”foo” role=”text” tabindex=”0”> time

Page text pattern is “Once upon a foo time”

Accessible tree is

Page --> Text “foo”



4 and 5 are the same as
<span>foo</span>
And
<span tabindex=”0”>foo</span>

Again, I’m not at all sure we need this. But, if we do it, this is how I think I’d map it.


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

Hi, Cynthia. Please correct me, if I didn't captured it correctly. UIA doesn't want an accessible for role="text", it doesn't want to expose it via Text pattern, but it wants to expose it as part of accessible name computation.
About 2nd. I agree role='text' usage should be restricted to certain cases, like role=none or role=table.



On Tue, Feb 2, 2016 at 4:53 PM, Cynthia Shelly <cyns@microsoft.com<mailto:cyns@microsoft.com>> wrote:
Hi Alex,
We discussed this at length on the AAPI call today, and here is where we landed.


1)      We’re making a change to the UIA mapping to make it more clear what is happening.
“UIA: Text Control Pattern. Run name calculation, and add the resulting string to the text pattern for the overall page, at the point where the element occurred.”

This is different than what happens with presentation, where we just remove the element from the tree. So, for this example
Once upon a <img alt=”foo”> time
The element would not be in the UIA control tree with either role=text or role=presentation
For role=text, the text pattern for the page would be “Once upon a foo time”
For role=presentation, the text pattern for the page would be “Once upon a time”

As a side note, we don’t generally map spans to controls, unless they have a tabindex, certain aria properties, or an onclick handler that’s bound directly to the element (not bubbled).


2)      We created this issue, saying the same exclusions that apply to role=presenation and role=none ought to apply to role=text as well.

https://www.w3.org/WAI/ARIA/track/issues/1011


Does the combination of these two things resolve your issues?



From: Alexander Surkov [mailto:surkov.alexander@gmail.com<mailto:surkov.alexander@gmail.com>]
Sent: Thursday, January 28, 2016 7:53 AM
To: Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>
Cc: James Teh <jamie@nvaccess.org<mailto:jamie@nvaccess.org>>; Richard 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 Thu, Jan 28, 2016 at 10:03 AM, Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>> wrote:
On 2016-01-28 8:06 AM, Alexander Surkov wrote:
Everything that is a text should be accessible via text interface (like IAccessibleText in IA2) and should be navigable by the user. role="text" providing a text doesn't meet these criteria. If we could require the browsers to support text interface for the role, but it seems we can do nothing about the second part. It's just one extra step towards to semantics disconnected from UI like aria-hidden true/false.

We (the AAPI task force), discussed that last fall, and I wrote (Fri, Oct 16, 2015 at 11:33 AM):

Oh, right. As for any controversial thing the discussions on this stuff goes on and on :) and we all repeating ourselves from time to time as time goes. I'm sorry though for making a blast from the past.

...
We spent the better part of one of our AAPI meetings on whether
role="text" should support IA2 and ATK's AccessibleText interfaces. The
problem was that the character/word information is problematic in
certain cases, e.g.,

<span role="text" aria-label="3 of 5 stars">★★★☆☆︎</span></p>

The string "3 of 5 stars" has four words and 13 characters, whereas
"★★★☆☆︎" is one (?) word with five characters.

Joanie's suggestion was along the lines of stating that role="text"
might implement an accessible text interface, with the caveat that it
may not make sense in all cases.  (I'm certain I've not captured
Joanie's thoughts accurately here).

Jamie replied:
Right. However, I see that there are cases where it *might* make sense, such as this example from the spec:
<div role="text">
  <p>I</p>
  <p>like</p>
   <p>turtles</p>
</div>
In that case, the accessible *does* need IAccessibleText. And now things
get confusing: should the AT expect IAccessibleText or not for this role?
Where IAccessibleText is present, an AT certainly shouldn't just use the
name.

FWIW, NVDA should handle either case with no problems as it is.

If ATs can handle both cases (caret navigation makes sense vs. it doesn't make sense), then we are good to go.  But, I remain uncertain.

Yeah, this is controversial. Anyway why UIA mapping is different? Is it on purpose?


You wrote:
Then, if we do the statictext role which is a leaf, then I'm not clear how we proceed with <p role="text">Oh, yeah, this is a whole paragraph</p>. We may want to require the browsers to be smarter, stating that either 1) role is ignored or 2) text container role is applied in cases where role="text" is used on complex content.

One effect of using of role="text" is to flatten the content, or, remove the structure.  Using the turtle example that Jamie cited, the result is the string "I like turtles".  That again leads to a disconnect between caret navigation within the browser vs. what the AT is given.  In the browser window, the words "I", "like", and "turtles" are vertically stacked, and users can move among them using up/down arrows.  That vertical arrangement is lost when the text of flattened, and only left/right works.  Is this a bad thing?

Here is an even more disturbing case:  <table role="text"> ... many rows, columns, and cells ... </table>.  That means all the text in the table becomes one long flat string.  Or, is this a case where the spec states that authors MUST NOT do this?

I guess I would go with the approach to ignore the role in such cases, as it wasn't present at all. Was there any agreement on this topic (I may be missing some of past discussions)?



--
;;;;joseph.

'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
                 - C. Carter -