Re: [REVIEW REQUESTED] Rewrite of the text role

Hi all,

OK, I might be opening a can of worms here, but I believe this creates even
more headaches for Jamie and other AT vendors on Windows than ARIA, and
especially aria-label and aria-labelledby already do.

First, if you have not read Jamie Teh's blog post about his difficulties
with aria-label/ledby, go read
http://blog.jantrid.net/2015/12/woe-aria-surprisingly-but-ridiculously.html.

And now that you've come back here, you might begin to understand what
problems the role "static" can cause. First, if there's no text interface,
the mapping be better one that doesn't expect an IAccessibleText interface.
IIRC, text, and statictext, both expect that interface. I suspect this is
true in one form or another for ATK as well.

Second, role "static" should nuke all child content except the text if no
aria-label/ledby is present, but only take the text bits of it, and treat
everything else as presentational. Right now, what role "presentation" does
is nuke the semantics of an element, but not its inner text. so <span
role="presentation">*some whacky unicode character*</span> will take away
the accessible for the span, but leave the whacky unicode character in the
tree, just as a text leaf.

So in essence, role "static" is to its child elements a hybrid of
aria-hidden and role "presentation", because implementors need to nuke both
the semantics, and the text leaf children that result from the former, but
retain the text from the sub tree as a resource for the accessible name if
aria-label/ledby isn't present. Did I get this right?

Marco



2016-06-29 7:59 GMT+02:00 James Craig <jcraig@apple.com>:

> Thanks for the thorough summary and explanation Joanie.
>
> Now that the group understands the goal, I'm happy to abide by the group's
> decision of whether this should be included in 1.1 or 1.2.
>
>
> > On Jun 28, 2016, at 11:38 AM, Joanmarie Diggs <jdiggs@igalia.com> wrote:
> >
> > Hi all.
> >
> > tl;dr: Please read
> > https://rawgit.com/w3c/aria/action-2086/aria/aria.html#static
> > How that draft came to be is detailed below.
> >
> > In response to the concerns raised by Apple regarding the removal of the
> > text role, and their request that we restore it for 1.1, I sent an
> > extremely long (5 pages in print) and very ATK-specific email to James
> > in which I went through all of the text role examples, and added some
> > variants of my own, in order to figure out just what was expected for my
> > platform. Because, like I said to James, if I have no clue how to
> > *properly* implement support for this role on my own platform, we have a
> > problem.
> >
> > This was very late on Friday evening. Throughout the weekend, James and
> > I emailed back and forth, with the emails getting even longer and even
> > more in-the-weedsy, until finally we realized what the problem was. The
> > problem was that my understanding of the text role was completely and
> > utterly different from what this role is meant to be. For the purposes
> > of documentation, and perhaps help others reach the "AHA!" moment I did,
> > here is the relevant bit I sent to James in which I finally "got it.":
> >
> > ==================
> > On 06/25/2016 05:28 PM, James Craig wrote:
> >>>
> >>>>> On Jun 25, 2016, at 1:24 AM, Joanmarie Diggs <jdiggs@igalia.com>
> wrote:
> >
> > [...]
> >
> >>>>> EXAMPLE 15
> >>>>> <div role="text">
> >>>>>   <p>I</p>
> >>>>>   <p>like</p>
> >>>>>   <p>turtles</p>
> >>>>> </div>
> >>>>>
> >>>>> Can we implement AtkText? Absolutely! Do we have that name vs content
> >>>>> conflict like we did above? Nope! So on this one, the answer seems
> to be
> >>>>> clear: Yes, user agents SHOULD implement AtkText to expose the
> content,
> >>>>> as if the paragraphs weren't there. In other words, functionally we
> have:
> >>>>>
> >>>>> <div>I<br>like<br>turtles<br></div>
> >>>
> >>> Example 15 should be functionally equivalent to:
> >>> <div role="text" aria-label="I like turtles"></div>
> >
> > Dude. THAT needs to be in the spec. Because that totally was NOT my read
> > of how this role works or what implementors should be doing. That
> > statement clears up so, so much in my mind.
> >
> > [...]
> >
> >>>>> From the above all I can conclude is one of the following is true:
> >>>>>
> >>>>> 1. The answer to "Should you implement AtkText for the text role?" is
> >>>>>  "maybe"/"it depends."
> >>>>> 2. The answer to "Should you implement AtkText for the text role?" is
> >>>>>  "no."
> >>>
> >>> IMO, it's #2. No.
> >
> >> From what you've stated, I wholeheartedly agree.
> >
> >>> If the answer MUST instead be yes, then I support the postponement to
> >>> 2.0, as WebKit and Chrome would also need additional implementation.
> >
> > No. I don't want or need that. I'm thrilled that AtkText should not be
> > implemented for this role. Less so with your taste in role names.
> >
> >>>>> If the true statement is 2, we have a role named "text" whose stated
> >>>>> purpose is to cause things to be exposed as "plain text" which should
> >>>>> not implement the "text" interface. This should bother you.
> >>>
> >>> I think an editorial change could fix this.
> >
> > ==================
> >
> >> From there we started on the editorial changes.
> >
> > To confirm that my new understanding was correct, I did a complete
> > rewrite of the text role with the aim of not changing the role's
> > functionality at all, but making that functionality and the associated
> > user experience more clear. James reviewed my draft and agreed with what
> > I had written.
> >
> > On Monday, Rich realized that we were in danger of my suggesting the
> > group consider including this in the spec. He did not seem pleased with
> > me. <grins> But then he read the draft and provided his concerns and
> > suggestions, and after a few iterations yesterday and today, we arrived
> > at something Rich seems to find reasonable and which I fully agree with.
> >
> > As you may have gathered from the URL at the top of this message, in
> > addition to the re-write, we have renamed the role from "text" to
> > "static." The reason for doing so is that "text" implies the presence of
> > rendered text, which may or may not be present for this role. "Static"
> > does not have that implication, and it does imply "non interactive,"
> > which is a key characteristic of this role. In addition, AXAPI and
> > ATK/AT-SPI2 map the text role to StaticText and ROLE_STATIC
> > respectively. Thus "static" seemed like a reasonable replacement for
> > "text."
> >
> > I realize that we really need to lock things down. And if you told me
> > last week that I would be championing the restoration of the text role
> > -- a role I truly detested -- I would have told you that you were nuts.
> > But my loathing was the result of totally not understanding how the role
> > was meant to work. I guess I got too hung up on the role being called
> > "text," because "text" to me means... Well... text. Regardless.... That
> > we got to this point seems to have been the result of a number of
> > communication failures within the group by multiple people (including
> > myself). I hope that I have "atoned" for my part by doing this rewrite.
> > If everyone has time to review these changes and has no serious
> > concerns, then I would like to propose restoring this role before 1.1 is
> > frozen. Otherwise, we can wait until 1.2 or 2.0 as Rich previous
> > suggested.
> >
> > Thanks in advance for your review and feedback!
> > --joanie
> >
> >
> >
>
>
>