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.
Probably related or the same: bug 414976.
Sorry, that was wrong, I meant bug 415070.
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.
Sorry if text is rendered then why shoudn't we expose it?
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?
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.
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. :-)
Mass un-assigning bugs assigned to Aaron.
I'm not sure what whitespaces you talk about, could you please look at the testcase again and point where are they?
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.
ok, thank you, it's rendered whitespace (I can navigate it by keyboard), but can we do anything with that?
No, it's superflous whitespace that cannot be acted on.
We generally strip out a node with role="presentation" but leave any child text nodes. I'm not sure if that's correct.
I tend to wontfix it. This issue should be addressed by widget author I think. Are you fine with that?
I will be more aggressive than Alex, and kill this bug :)