Re: role="text" and text frames

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

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?


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

Received on Thursday, 28 January 2016 15:04:37 UTC