make input accessible tree consistent

RESOLVED WORKSFORME

Status

()

Core
Disability Access APIs
RESOLVED WORKSFORME
8 years ago
7 years ago

People

(Reporter: surkov, Unassigned)

Tracking

(Blocks: 2 bugs, {access})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
1) we expose placeholder text as accessible text. We might want to figure more  proper solution than to expose is as an accessible content (bug 545817).

2) if there is no placehoder text, we have anonymous content for it any way (it should be removed in bug 553097)

3) if editor is not initialized then it has empty text node (which is accessible)

4) if editor is initialized then it has bogus br node (which is not accessible since there is special case for it in a11y code)

I think it's ok to to not expose empty text node (while editor is not initialized), it'll be consistent with its tree when it's initialized. Probably we could hack nsIContent::GetChildren() or nsIAnonymousCreator::GetAnonymousContent(). So that while editor is not initialized then do not expose content for its temporary nodes.

Comment 1

8 years ago
(In reply to comment #0)
> 1) we expose placeholder text as accessible text. We might want to figure more 
> proper solution than to expose is as an accessible content (bug 545817).

Agreed.

> 2) if there is no placehoder text, we have anonymous content for it any way (it
> should be removed in bug 553097)

Right.

> 3) if editor is not initialized then it has empty text node (which is
> accessible)

This can't be removed for performance reasons.

> 4) if editor is initialized then it has bogus br node (which is not accessible
> since there is special case for it in a11y code)

This is bug 240933.

> I think it's ok to to not expose empty text node (while editor is not
> initialized), it'll be consistent with its tree when it's initialized. Probably
> we could hack nsIContent::GetChildren() or
> nsIAnonymousCreator::GetAnonymousContent(). So that while editor is not
> initialized then do not expose content for its temporary nodes.

That won't probably be an acceptable solution, because the frame constructor also uses nsIAnonymousCreator to create frames for the anon content, right?
(Reporter)

Comment 2

8 years ago
(In reply to comment #1)

> > 3) if editor is not initialized then it has empty text node (which is
> > accessible)
> 
> This can't be removed for performance reasons.

I didn't meant I want to change content or layout and I think I don't want to do this. However I like to get filter content we deal in accessibility.

> > 4) if editor is initialized then it has bogus br node (which is not accessible
> > since there is special case for it in a11y code)
> 
> This is bug 240933.

It has a long history, I afraid to estimate when we get it fixed to rely on it :)

> > I think it's ok to to not expose empty text node (while editor is not
> > initialized), it'll be consistent with its tree when it's initialized. Probably
> > we could hack nsIContent::GetChildren() or
> > nsIAnonymousCreator::GetAnonymousContent(). So that while editor is not
> > initialized then do not expose content for its temporary nodes.
> 
> That won't probably be an acceptable solution, because the frame constructor
> also uses nsIAnonymousCreator to create frames for the anon content, right?

you're right nsIAnonymousContentCreator is used to create frames. But nsIContent::GetChildren() and nsIAnonymousContentCreator:: AppendAnonymousContentTo have been added by me for a11y purposes only, so we might be allowed to change them.

So that if we could change nsIAnonymousContentCreator:: AppendAnonymousContentTo or nsIContent::GetChildren() to not return anonymous content if editor is empty then it should be fine for a consistent tree.

Comment 3

8 years ago
(In reply to comment #2)
> (In reply to comment #1)
> 
> > > 3) if editor is not initialized then it has empty text node (which is
> > > accessible)
> > 
> > This can't be removed for performance reasons.
> 
> I didn't meant I want to change content or layout and I think I don't want to
> do this. However I like to get filter content we deal in accessibility.

OK, makes sense.

> > > 4) if editor is initialized then it has bogus br node (which is not accessible
> > > since there is special case for it in a11y code)
> > 
> > This is bug 240933.
> 
> It has a long history, I afraid to estimate when we get it fixed to rely on it
> :)

It does!  :-)  But it's on my list.

> > > I think it's ok to to not expose empty text node (while editor is not
> > > initialized), it'll be consistent with its tree when it's initialized. Probably
> > > we could hack nsIContent::GetChildren() or
> > > nsIAnonymousCreator::GetAnonymousContent(). So that while editor is not
> > > initialized then do not expose content for its temporary nodes.
> > 
> > That won't probably be an acceptable solution, because the frame constructor
> > also uses nsIAnonymousCreator to create frames for the anon content, right?
> 
> you're right nsIAnonymousContentCreator is used to create frames. But
> nsIContent::GetChildren() and nsIAnonymousContentCreator::
> AppendAnonymousContentTo have been added by me for a11y purposes only, so we
> might be allowed to change them.
> 
> So that if we could change nsIAnonymousContentCreator::
> AppendAnonymousContentTo or nsIContent::GetChildren() to not return anonymous
> content if editor is empty then it should be fine for a consistent tree.

Could you express this idea in terms of a patch?  :-)
(Reporter)

Comment 4

8 years ago
(In reply to comment #3)
> 
> Could you express this idea in terms of a patch?  :-)

Sure. I think I'll ask David since this should be on his radar as well ;). I'm afraid to sidestep a lot from a11y perf problems since if bz knows about this then I afraid he will decide to punish me soon :)
(Reporter)

Comment 5

7 years ago
placeholder text is not exposed as accessible children (filtered in nsIContent::GetChildren), we create accessible for text leaf if they contain rendered text. The bug can be closed as worksforme now I think.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.