719047 - Remove embedded character hack (flatten tree).

Status: NEW

(Core :: Disability Access APIs, defect)

Description

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

Plans/discussion: https://wiki.mozilla.org/Accessibility/TextImplementation

Comment 1

[James Teh [:Jamie]]

Questions:
1. What determines whether an object will expose text? Is it just block elements? In the example, there are two paragraph objects and each of those gets text. What about something more complex like <div>a<div>b<div>c</div></div></div>?
2. If you eliminate embedded object characters this way (i.e. by exposing multiple objects with unified text), how do we quickly determine selected text?
3. Will a block element always only span one object? If not, we will have the same traversal issues as the current model.

Comment 2

[Trevor Saunders (:tbsaunde)]

(In reply to James Teh [:Jamie] from comment #1)
> Questions:
> 1. What determines whether an object will expose text? Is it just block
> elements? In the example, there are two paragraph objects and each of those
> gets text. What about something more complex like
> <div>a<div>b<div>c</div></div></div>?

as I understand the proposal nothing changes in what implements text interface.  I believe the current state is
div1 a<EOC><EOC>
div2 b<EOC>
div3 C

and we would then have

div1 ABC
div2 bc
div3 C

> 2. If you eliminate embedded object characters this way (i.e. by exposing
> multiple objects with unified text), how do we quickly determine selected
> text?

doesn't this make your lifeeasier? with this all you'd have to do is get_selection() on the top level accessible.  Previously you'd have to do that and then decend into the children to get their text no?

> 3. Will a block element always only span one object? If not, we will have
> the same traversal issues as the current model.

that seems desirable.

Comment 3

[James Teh [:Jamie]]

(In reply to Trevor Saunders (:tbsaunde) from comment #2)
> > 1. What determines whether an object will expose text? Is it just block
> > elements? In the example, there are two paragraph objects and each of those
> > gets text. What about something more complex like
> > <div>a<div>b<div>c</div></div></div>?
> div1 ABC
> div2 bc
> div3 C
Ah. So ancestors do duplicate the text exposed by their children? This isn't clear from the proposal, unless I missed something. Does this mean that the body also exposes "abc"?

> > 2. If you eliminate embedded object characters this way (i.e. by exposing
> > multiple objects with unified text), how do we quickly determine selected
> > text?
> doesn't this make your lifeeasier? with this all you'd have to do is
> get_selection() on the top level accessible.
If text is exposed on all ancestors including the top level, then yes, this is easier.

If ancestors duplicate the text of their children, in the following example:
<div>a<div><a href="#">b</a>c</div></div>
would the body point at the div for b or the link? I'd think the link would be most logical, but you'd then have to walk up the ancestors if you wanted information about them.

Comment 4

[Trevor Saunders (:tbsaunde)]

(In reply to James Teh [:Jamie] from comment #3)
> (In reply to Trevor Saunders (:tbsaunde) from comment #2)
> > > 1. What determines whether an object will expose text? Is it just block
> > > elements? In the example, there are two paragraph objects and each of those
> > > gets text. What about something more complex like
> > > <div>a<div>b<div>c</div></div></div>?
> > div1 ABC
> > div2 bc
> > div3 C
> Ah. So ancestors do duplicate the text exposed by their children? This isn't
> clear from the proposal, unless I missed something. Does this mean that the

that's the way I interpreted it at least.

> body also exposes "abc"?

I'm not sure, it seems like this could cause problems with forms and such, thoughts?

> > > 2. If you eliminate embedded object characters this way (i.e. by exposing
> > > multiple objects with unified text), how do we quickly determine selected
> > > text?
> > doesn't this make your lifeeasier? with this all you'd have to do is
> > get_selection() on the top level accessible.
> If text is exposed on all ancestors including the top level, then yes, this
> is easier.
> 
> If ancestors duplicate the text of their children, in the following example:
> <div>a<div><a href="#">b</a>c</div></div>
> would the body point at the div for b or the link? I'd think the link would
> be most logical, but you'd then have to walk up the ancestors if you wanted
> information about them.

I'd think it points at the item one level below it, so the div.

Comment 5

[Ginn Chen]

I'm afraid it will introduce performance issues.

The document accessible will contains all the text of the web page.
So any reading of text of document accessible will require deep traversal of the whole accessible tree.

Comment 6

[James Teh [:Jamie]]

(In reply to Trevor Saunders (:tbsaunde) from comment #4)
> > body also exposes "abc"?
> I'm not sure, it seems like this could cause problems with forms and such,
> thoughts?
How so? If it did, we'd see the same problem if a form was inside a div.

> > If text is exposed on all ancestors including the top level, then yes, this
> > is easier.
What you say above suggests that text won't be exposed at the top level, in which case we can't query the top level accessible for the selection.

> > If ancestors duplicate the text of their children, in the following example:
> > <div>a<div><a href="#">b</a>c</div></div>
> > would the body point at the div for b or the link?
> I'd think it points at the item one level below it, so the div.
This could make life difficult in this example:
<div>a<div>b<a href="#">c</a></div></div>
Determining what object "c" refers to would be rather tricky.

Comment 7

[alexander :surkov (:asurkov)]

(In reply to Ginn Chen from comment #5)
> I'm afraid it will introduce performance issues.
> 
> The document accessible will contains all the text of the web page.
> So any reading of text of document accessible will require deep traversal of
> the whole accessible tree.

you could be right. Maybe we need to follow what webkit does, i.e. don't expose text interface on anything we see.

Comment 8

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #7)
> > I'm afraid it will introduce performance issues.
> > The document accessible will contains all the text of the web page.
> > So any reading of text of document accessible will require deep traversal of
> > the whole accessible tree.
> you could be right. Maybe we need to follow what webkit does, i.e. don't
> expose text interface on anything we see.
Can you (or someone else) clarify exactly what WebKit does? Imo, this will still be problematic and will actually break some of the use cases that the current implementation solves, if a little inelegantly.

Comment 9

[alexander :surkov (:asurkov)]

It appears webkit exposes text interface on accessibles having a text and not containing other text container accessibles. That will break existing ATs I think, you're right.

Taking into account Ginn's concerns I think we need to do something in the middle like do what we do but do not use embedded characters for inline accessibles. That allows us to fix word getting problem, stay fast and nearly backward compatible.