[REVIEW REQUESTED] Rewrite of the text role

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

Received on Tuesday, 28 June 2016 18:39:02 UTC