RE: [REVIEW REQUESTED] Rewrite of the text role

Steve,

 

In all cases that have been presented, I see suppressing the presence of the image as a problem, not a solution.

 

Matt

 

From: Steve Faulkner [mailto:faulkner.steve@gmail.com] 
Sent: Wednesday, June 29, 2016 5:38 AM
To: Joanmarie Diggs <jdiggs@igalia.com>
Cc: Marco Zehe <mzehe@mozilla.com>; James Craig <jcraig@apple.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: [REVIEW REQUESTED] Rewrite of the text role

 

hi all being one of the people that floated the text role I will provide you with my reasoning:

it is common that text is emebedded within an <img>. the advice is to provide the text in the <img> as an alt. The issue in this case is that the role of the object is still announced, role=text was considered a method to indicate that the role was not an image but text. This would mean that the announcement of the image role would be suppressed. so only the text would be announced. 




--

Regards

SteveF

Current Standards Work @W3C <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/> 

 

On 29 June 2016 at 13:21, Joanmarie Diggs <jdiggs@igalia.com <mailto:jdiggs@igalia.com> > wrote:

Hey Marco.

Thanks for the review! From my perspective, in answer to your question,
yes, you did get this right. I'll leave it to James to explain why this
is desirable.

However to be clear, it was and is my desire to not change the
functionality of the text role *at all*. And it is my understanding from
what James has said, that I have succeeded in not changing the
functionality. In other words, the text role turns what used to be text
into non-text. As a result, AtkText and presumably IAccessibleText
should *not* be implemented for the text role. And it's always been that
way. All I have done, I hope, is make that fact more clear.

--joanie


On 06/29/2016 05:40 AM, Marco Zehe wrote:
> 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 <mailto:jcraig@apple.com> 

> <mailto:jcraig@apple.com <mailto: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 <mailto:jdiggs@igalia.com> 

>     <mailto:jdiggs@igalia.com <mailto: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 <mailto:jdiggs@igalia.com>  <mailto:jdiggs@igalia.com <mailto: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
>     >
>     >
>     >
>
>
>