Confirmed users
1,396
edits
Accessibility/CustomWidgets: Difference between revisions
Jump to navigation
Jump to search
→Why isn't ARIA enough?
mNo edit summary |
|||
| Line 16: | Line 16: | ||
==Why isn't ARIA enough?== | ==Why isn't ARIA enough?== | ||
Widget may want to have full control over accessible object which is created for. The following scenarios show possible usecases where ARIA can't be used: | |||
=== Control accessible operations=== | |||
For example, xforms:trigger (analogue of button in HTML and XUL) provides <code>click</code> action and xforms:item (may be analogue of HMTL option element) provides <code>select</code>action. Here we could use ARIA to set up role on the widget and add some code into accessibility code to expose specific actions to AT for the chosen role but we don't know what events we should listen to fire proper events to AT. So that HTML uses <code>click</code>, XUL uses <code>command</code> and XForms uses <code>DOMActivate</code>. We can't be sure what events can be used for the specific widget. | |||
===Control the accessible tree=== | |||
Some widgets may want to control the accessible tree underneath them. For example, xul:textbox doesn't expose html:input element that is used as a base for xul:textbox. Another example is xul:select@apperatance="compact" (analogue of html:select) which can have hierarchical DOM sturcture but it is exposed to AT as linear structure. So custom widgets should have control over its tree and decide which accessible should be created, which not. | |||
=What can we do= | =What can we do= | ||