646222 - present text all at once when possible for objects containing multiple objects which implement nsTextAccessible

Status: NEW

(Core :: Disability Access APIs, enhancement)

Description

[Fernando Herrera]

We should try to present complete text for objects containing multiple objects which implement nsTextAccessible (for example links)

Comment 1

[James Teh [:Jamie]]

If I understand correctly, if this is done, semantic info about the content of the node will be lost. For example, if you have a link containing a graphic as well as text, you won't know which part was the graphic and which was just text.

Comment 2

[Joanmarie Diggs]

In the case of the image, it would presumably still be represented by an embedded object character, would it not?

Comment 3

[James Teh [:Jamie]]

(In reply to comment #2)
> In the case of the image, it would presumably still be represented by an
> embedded object character, would it not?
Perhaps I'm misunderstanding what this bug is requesting. I thought the request was to merge the text of multiple contained objects for links, etc.

Comment 4

[Joanmarie Diggs]

Not "etc." Textual links. In other words,

  <p>This is a <a href='foo'>link</a> and here is <a href='bar'>another one</a>.

gives us a paragraph whose full text is currently:

   This is a EOC and here is another EOC.

What I would like to see (and what WebKitGtk, OpenOffice, and LibreOffice) do is return text that is:

  This is a link and here is another one.

That's what the text is on the screen, after all. By correctly implementing Hypertext and Hyperlink, we should be able (and currently do for WebKitGtk, OpenOffice, and LibreOffice) easily identify that 'link' and 'another one' are links.

Images and widgets would still be represented as embedded object characters. And the children of the paragraph (i.e. the objects of ROLE_LINK) would presumably remain as-is.

Comment 5

[James Teh [:Jamie]]

That makes links inconsistent with everything else. What about clickables, buttons, etc.? By that logic, the entire document should be one big piece of text with no embedded objects at all, using hypertext/hyperlink to get at the individual objects. This is actually an idea I've seriously considered; I'm not saying it would be a bad thing. However, imo, if we're going to do it, we should go the whole way, not just for links. Otherwise, there is major inconsistency, and inconsistency sucks more than complexity.

Comment 6

[James Teh [:Jamie]]

The other problem with this idea is that the child objects have to duplicate the text of the parent. This makes for redundancy and may be a performance/memory problem on the Firefox side.

Comment 7

[alexander :surkov (:asurkov)]

The proposal could be (or it is): do not expose accessible containing a text until it contains hyperlinks (well, hyperlinks can be treated wide, currently Gecko defines it as any accessible represented by embedded char).

So for example

DOM:
<p>text<a>link</a></p>
a11y tree:
paragraph ('text link')

but

DOM:
<p>text<p><a>link</a></p></p>
a11y tree:
section ('text' + embedded char)
  section ('link')

This approach should be reasonable and we should define hyperlink term.

Comment 8

[James Teh [:Jamie]]

Note that a change like this will break any existing ATs using IA2 (or ATK for that matter).

I'm still concerned about the inconsistency this introduces as per comment #5. Why take this approach only half way?

Comment 9

[alexander :surkov (:asurkov)]

It sounds my suggestion makes hyperlink interface out of low in certain cases. But this bug is not about accessible tree reduction, it's about to get rid the embedded chars from text in certain cases?

Comment 10

[alexander :surkov (:asurkov)]

Working draft: https://wiki.mozilla.org/Accessibility/TextImplementation