Closed
Bug 396025
Opened 17 years ago
Closed 17 years ago
Accessible object created for tbody/thead/tfoot even when ARIA role is on parent table
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
FIXED
People
(Reporter: aaronlev, Assigned: surkov)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(1 file, 2 obsolete files)
4.65 KB,
patch
|
aaronlev
:
review+
damons
:
approval1.9+
|
Details | Diff | Splinter Review |
Those accessibles should obey role="presentation" on the parent table -- that is, they should not be created.
Assignee | ||
Comment 1•17 years ago
|
||
Assignee: aaronleventhal → surkov.alexander
Status: NEW → ASSIGNED
Attachment #280842 -
Flags: review?(aaronleventhal)
Reporter | ||
Comment 2•17 years ago
|
||
Comment on attachment 280842 [details] [diff] [review] patch I should have said that any role on the table means don't create the tbody accessible. Use nsAccessNode::HasRoleAttribute(tableContent)) {) for that -- in fact you should be able to combine with the previous if. However, one other concern I have -- doesn't CreateHTMLAccessibleByMarkup() above create the accessible for the tbody? That used to come after these checks, I believe.
Attachment #280842 -
Flags: review?(aaronleventhal) → review-
Reporter | ||
Updated•17 years ago
|
Summary: Accessible object created for tbody/thead/tfoot even when role="presentation" on parent table → Accessible object created for tbody/thead/tfoot even when ARIA role is on parent table
Assignee | ||
Comment 3•17 years ago
|
||
I am blind because I didn't see my code won't ever work since HasRoleAttribute() is presented in the check above. So this bug is about we shouldn't create accessible for tbody/tfoot/thead in CreateHTMLAccessibleByMarkup() if table has role attribute, correct?
Reporter | ||
Comment 4•17 years ago
|
||
Right. I think we might want to move CreateHTMLAccessibleByMarkup() down just a little bit, but keep it before the frame->GetAccessible(). Because, it does the check for us already. We just need to use the info better, right?
Assignee | ||
Comment 5•17 years ago
|
||
Attachment #280842 -
Attachment is obsolete: true
Attachment #281079 -
Flags: review?(aaronleventhal)
Reporter | ||
Comment 6•17 years ago
|
||
Comment on attachment 281079 [details] [diff] [review] patch2 We're now using frame->GetAccessible() when we're on a table frame and there is an ARIA role on the table. That means we'll be creating accessibles for table cells etc. via nsTableCellFrame::GetAccessible() when we shouldn't be. Also, I think the name noTableRelatedAcc is confusing. How about allowTableCellFrame. And if it is false, don't call frame->GetAccessible() either.
Attachment #281079 -
Flags: review?(aaronleventhal) → review-
Assignee | ||
Comment 7•17 years ago
|
||
you're right, I should be more carefull
Attachment #281079 -
Attachment is obsolete: true
Attachment #281083 -
Flags: review?(aaronleventhal)
Reporter | ||
Comment 8•17 years ago
|
||
Comment on attachment 281083 [details] [diff] [review] patch3 Code is fine. Variable name: Hmm, I realize I asked you to change the name to allowTableRelatedAcc, but the |if (allowTableRelated)| { create acc based on tag or frame type)| is strange. We can't just return early, because we need to use the accessible for generic attributes block below. Maybe call it |PRBool tryTagNameOrFrame|.
Attachment #281083 -
Flags: review?(aaronleventhal)
Attachment #281083 -
Flags: review+
Attachment #281083 -
Flags: approval1.9?
Assignee | ||
Comment 9•17 years ago
|
||
Agree. I think your new name is fine. I'll change before checkin.
Updated•17 years ago
|
Attachment #281083 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Comment 10•17 years ago
|
||
checked in with changed name
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•