Closed Bug 473733 Opened 11 years ago Closed 3 years ago

organize the code to simplify understanding what accessible class is used for the given DOM element


(Core :: Disability Access APIs, defect)

Not set





(Reporter: surkov, Unassigned)


(Blocks 1 open bug)


(Whiteboard: [auto-closed:inactivity])

Spun off bug 472326 comment #33.

Currently we have two ways to make element from native markup accessible. 1) nsIAccessibleProvider declaring constants that are used to create specific accessible class. This approach is used in XUL and XForms created by XBL bindings. 2) nsIFrame::GetAccessible is used for HTML elements - difference from XUL and XForms is accessible is defined by layout (not content).

Problems of nsIFrame::GetAccessible approach are:
1) The approach logic is to ask accessible module to create needed accessible and then return created accessible to accessible module. I think it's enough to return constant types like we do in nsIAccessibleProvider case.
2) It's impossible to find accessible class for the given HTML element until you don't know layout code. I think constants usage like nsIAccessibleProvider will help as well.
3) Currently file input control has hypertext accessible which has dynamic role based on element type. Here would be better to introduce approach of nsEnumRoleAccessible where we create accessible with constant role.
AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [auto-closed:inactivity]
You need to log in before you can comment on or make changes to this bug.