Closed Bug 346833 Opened 15 years ago Closed 10 years ago

:before and :after text no longer exposed

Categories

(Core :: Disability Access APIs, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: aaronlev, Unassigned)

References

Details

(Keywords: access, regression)

Attachments

(2 files, 2 obsolete files)

Text in the frame tree that is rendered needs to be exposed to screen readers, no matter what.

:before and :after text used to be exposed, now it is not.

In any case it is static text and needs to be exposed with static=true.
Blocks: 340670
No longer blocks: newatk
Attached file Testcase
Eventually list bullets and :before/:after text will get a text attribute
"static:true". That's bug 340670.

In addition, we need to deal with all of the GetText[At|Before|After]Offset
implications when static text is part of a paragraph. Filed bug 348907 for that and any other nsHyperTextAccessible issues we'll need to handle.
Attachment #234069 - Flags: superreview?(roc) → superreview+
Attachment #234069 - Flags: review?(ginn.chen) → review+
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
I don't understand this patch.  Is there a reason that we don't handle :before and :after for positioned inlines, table captions, table cells, HTML <button>s, <select>, <legend>, <fieldset>, MathML, SVG?

If you actually want to test whether the frame is a container, just check !frame->IsLeaf().  If you want to test something else, the comment probably needs changing.
I backed out this fix because it caused bug 349533. Need to address bz's concerns as well.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #234069 - Attachment is obsolete: true
Attachment #234809 - Flags: review?(ginn.chen) → review+
Attachment #234809 - Flags: superreview?(roc) → superreview+
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
the patch caused a regression described on bug 349860.
reopen.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This also regressed bug 352150!

For <span>x<br>y</span>, no accessible object is created for "y"
This fixes bug 352150. Evan, give this a try for bug 349860 as well. 

Dbaron wants us to walk the DOM tree because of Aural CSS. Since that's not really used on the web today, I'd prefer to leave that for the future. Walking the frame tree lets us continue our trunk work and makes it easy to get list bullet text, :before and :after text. Also will make it easier to get scrollbars.

Here's dbaron's comment:
you need to ask only for those display types that support :before and :after (which roughly means non-replaced elements)

Dbaron wrote:
> I suppose it depends on what you're trying to do but it moves you 
> significantly farther away from being able to do something like aural CSS
In response to my comment that we don't expose display:none elements, he said:
> What if it's @media screen { display: none; } ?

I think it's okay that we follow this approach for now
Attachment #234809 - Attachment is obsolete: true
Attachment #238525 - Flags: superreview?(roc)
Attachment #238525 - Flags: review?(Evan.Yan)
Comment on attachment 238525 [details] [diff] [review]
Walk all the next siblings

it doesn't work for bug 349860. 
we need to do something in the "if" statement.

281     if (mState.frame && mState.siblingIndex < 0) {
       // need do something here

because we removed " && mState.frame->GetContent()->IsNativeAnonymous()" from the "if" condition.
see
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/accessible/src/base&command=DIFF_FRAMESET&file=nsAccessibleTreeWalker.cpp&rev1=1.18&rev2=1.19&root=/cvsroot
Attachment #238525 - Flags: review?(Evan.Yan) → review-
Comment on attachment 238525 [details] [diff] [review]
Walk all the next siblings

Evan, what you're doing to the if() statement is making it so that frames are not walked. I'm trying to fix both this bug and the regression by making it walk frames correctly. Changing that if() isn't the way to do that, it just makes it not walk the frames for the problem scenarios.
Attachment #238525 - Flags: superreview?(roc)
Blocks: 349860, 352150
No longer blocks: 349860, 352150
Depends on: 349860, 352150
I have put fixes in both regressions: bug 349860 and bug 352150

We can close this bug again after those are marked fixed.
No need to reopen this. We didn't break it via any backouts -- we found other fixes.
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
need a fix without walking frames
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Do you want to create accessibles for :begin and :after? So

<style>
p:begin, p:after {
  content: text
}
</style>

<p>hello</p>

has accessible tree:

hypertext acc (p)
  text acc (:before)
  text acc (text content of p)
  text acc (:after)

right?
Alex, that was the plan.

Realistically, there is no point in fixing this until IE gets :before and :after. Until then authors won't use that.
(In reply to comment #16)
> Alex, that was the plan.

Ok.

> Realistically, there is no point in fixing this until IE gets :before and
> :after. Until then authors won't use that.
> 

It's still important if we care about XUL. Though probably not hight priority.
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Fixed on Gecko 2.0 by bug 530081, covered by mochitest - http://mxr.mozilla.org/mozilla-central/source/accessible/tests/mochitest/tree/test_gencontent.html?force=1
Status: REOPENED → RESOLVED
Closed: 15 years ago10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Alex, are you sure this is fixed completely? I don't see the "enter a number" and the other text that are declared on input as :before and :after. Am I missing something?
(In reply to comment #20)
> Alex, are you sure this is fixed completely? I don't see the "enter a number"
> and the other text that are declared on input as :before and :after. Am I
> missing something?

There's no generated content for input visually, iirc it was a bug but I failed to find it. Though once it's fixed then possibly we should tweak a11y support to expose it to AT (because we prune children for inputs).
All right, then this is verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.