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> 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]
> *Sent:* Thursday, January 28, 2016 7:53 AM
> *To:* Joseph Scheuhammer <clown@alum.mit.edu>
> *Cc:* 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
>
>
>
>
>
>
>
> On Thu, Jan 28, 2016 at 10:03 AM, Joseph Scheuhammer <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 -
>
>
>