47 bytes, text/x-phabricator-request
|Details | Review|
spun off bug 1321960 comment #38 we have GetRect().IsEmpty() check  when deciding to create or not create HTML:caption accessible, which makes a caption inaccessible in the example <table> <caption style="width: 0; height: 0">Some text</caption> </table> It seems the behavior goes from 377783 with no explanation. Any objections for reverting the change? What do other browsers do?  https://hg.mozilla.org/mozilla-central/annotate/6fec4855b5345eb63fef57089e61829b88f5f4eb/layout/generic/nsBlockFrame.cpp#l6852
Inconclusive. Chrome renders it as a table caption, IE does render it as a regular div (or so it seems to NVDA), and Edge renders it as plain text as child of the table accessible. I'd say we follow Chrome's example and just render the thing. Caption is an exotic enough element that we can assume author intent if they bother using it, even if they style it so that it is invisible.
2 years ago
Priority: -- → P5
Summary: create HTML table caption accessible uncondionally → create HTML table caption accessible unconditionally
It's definitely not p5, we have to fix to depend on layout update less than we do now, which is tightly related with our performance. Ideally we should get a fix around a next release or so, so bumping up to p2 for now to not get it lost in the backlog.
Priority: P5 → P2
How does this relate to bug 995888?
(In reply to James Teh [:Jamie] from comment #3) > How does this relate to bug 995888? Sounds like this bug will address bug 995888 partially, i.e. I don't think this will fix table interface, because this info is computed by layout, but it will fix the caption accessible issue.
I've just started investigating this while working on display:contents and making us more independent from the frame tree. Removin that conditional as Alex suggests in comment #0 causes us to create accessibles for all caption elements within a table. So the test for two captions, the second being ignored, fails.  The second caption gets inserted first, but without text and without a text leaf child. It has zero height and width, even though the test file specifies text content.  https://searchfox.org/mozilla-central/source/accessible/tests/mochitest/tree/test_table.html#21
I think we'll need to test whether this is the first caption in the table. I guess that will involve querying the DOM. HTMLTableElement has a GetCaption method, but I'm not sure how to safely get from an nsIContent to an HTMLTableElement. It's *probably* safe to static_cast, but I'm not sure if there is a safer way in DOM. Note that GetCaption essentially just walks through the child nodes looking for the first caption, so at worst, we could do that ourselves. One problem is that dynamically inserting another caption before the first one (after the tree has been constructed) will result in two caption accessibles, the new (now correct) caption and the old (now incorrect) caption. However, you can fool our a11y engine into doing this already (since it only does the rectangle check when the accessible is created, not mutated), so I'm inclined not to care.
Assignee: nobody → mzehe
Status: NEW → ASSIGNED
Created attachment 9027190 [details] Bug 1380451 - create HTML table caption accessible unconditionally, r=Jamie Creates the HTML Caption accessible from the markup map, but only if it's the first caption. Other caption elements are ignored as before. This also creates caption accessibles for those captions that have been collapsed to zero height and width via CSS.
And the run is clean. :)
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/e9588334915f create HTML table caption accessible unconditionally, r=Jamie
Status: ASSIGNED → RESOLVED
Last Resolved: 3 months ago
status-firefox65: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in before you can comment on or make changes to this bug.