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)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: aaronlev, Assigned: surkov)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(1 file, 2 obsolete files)

Those accessibles should obey role="presentation" on the parent table -- that is, they should not be created.
Attached patch patch (obsolete) — Splinter Review
Assignee: aaronleventhal → surkov.alexander
Status: NEW → ASSIGNED
Attachment #280842 - Flags: review?(aaronleventhal)
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-
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
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?
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?
Attached patch patch2 (obsolete) — Splinter Review
Attachment #280842 - Attachment is obsolete: true
Attachment #281079 - Flags: review?(aaronleventhal)
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-
Attached patch patch3Splinter Review
you're right, I should be more carefull
Attachment #281079 - Attachment is obsolete: true
Attachment #281083 - Flags: review?(aaronleventhal)
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?
Agree. I think your new name is fine. I'll change before checkin.
Attachment #281083 - Flags: approval1.9? → approval1.9+
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.

Attachment

General

Created:
Updated:
Size: