413394 - ARIA role="presentation" adds whitespace to AT-SPI IText output

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, enhancement)

Description

[Scott Haeger]

What I am seeing is that elements with role="presentation" contribute a space to the text string available via the Text interface.  The behavior is similar to an element that does not have role="presentation" where this element contributes an embed character in it's parent text string.  

To test this I looked at the Mozilla ARIA checkbox http://www.mozilla.org/access/dhtml/checkbox and manipulated (added additional <img>, removed/added role="presentation" etc.) the image element. You will see embed characters being added when role="presentation" is not present (and the object itself) and whitespace added when role="presentation" is present.

This mainly affects Orca's Braille output where this added space is mixed within the output string.  I often see 4-5 extra characters before labels as a result.  This is not a blocker but is far from trivial as well.

Comment 1

[Aaron Leventhal]

Probably related or the same: bug 414976.

Comment 2

[Aaron Leventhal]

Sorry, that was wrong, I meant bug 415070.

Comment 3

[Aaron Leventhal]

Here's what's happening. The rendering engine is actually rendering a space between the checkbox image and the text, because of the newline. In HTML a newline will cause whitespace to happen between things. This helps to make sure that there is a space rendered between crazy and friend here:
My <i>crazy</i>
friend

So in this test case, if the newline is removed so is the space and you can see the difference in the rendering. The label becomes jammed up against the checkbox:
<div>
 <span>
   <img src="checked.gif" role="presentation" alt="" />Jammed together
 </span>
</div>

as opposed to your example which is like:

<div>
  <span>
    <img src="checked.gif" role="presentation" alt="" />
    Space between image and this label
  </span>
</div>

So, I'm not sure what to do. We're faithfully representing what the rendering engine says is there, although perhaps for widgets you want us to trim whitespace off of the beginning and end. Ideas appreciated.

Comment 5

[alexander :surkov (:asurkov)]

Sorry if text is rendered then why shoudn't we expose it?

Comment 6

[Aaron Leventhal]

Right, I think we actually have to expose it because the caret could land there, and we need to be able to expose a caret position for that.

Scott, what do you think?

Comment 7

[Scott Haeger]

Admittedly, I am a little weak at knowing the details of how Firefox handles text.  I apologize if we are chasing a red herring.  With that said, I understand the problem with the checkbox example and yes, I do believe it should be exposed.  However, I do not understand the buttons on the first toolbar in this example  http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Toolbar.html .  I see two spaces (ascii 32) tacked on to the text interface.

I will also ping Joanie on this one.

Comment 8

[Joanmarie Diggs]

And admittedly I am a little weak at knowing how ARIA works. :-)  That said, I see the two spaces as well. One seems to be associated with a div; the other with a span.  It would be nice to just have one space. :-)

Comment 9

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 10

[alexander :surkov (:asurkov)]

I'm not sure what whitespaces you talk about, could you please look at the testcase again and point where are they?

Comment 11

[Marco Zehe (:MarcoZ)]

Alex, look at the " Include decorative fruit basket" (yes, I put that intentionally there). The img that represents the checked checkbox symbol is of role "presentation", but the string includes a whitespace there. I see this in NVDA's virtual buffer, where the checkbox label starts with a whitespace.

Comment 12

[alexander :surkov (:asurkov)]

ok, thank you, it's rendered whitespace (I can navigate it by keyboard), but can we do anything with that?

Comment 13

[Marco Zehe (:MarcoZ)]

No, it's superflous whitespace that cannot be acted on.

Comment 14

[David Bolter [:davidb] (NeedInfo me for attention)]

We generally strip out a node with role="presentation" but leave any child text nodes. I'm not sure if that's correct.

Comment 15

[alexander :surkov (:asurkov)]

I tend to wontfix it. This issue should be addressed by widget author I think. Are you fine with that?

Comment 16

[Eitan Isaacson [:eeejay]]

I will be more aggressive than Alex, and kill this bug :)