354832 - Buttons and list options should support nsIAccessibleText

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

Any element which shows text on the screen should support nsIAccessibleText.

This includes:
<button>
<input type="button">
<option>

This is important because the locale text attribute might need to be set for those elements.

Comment 1

[Håkan Waara]

Most of the things on nsIAccessibleText are about getting different info from different ranges of text - is that really useful on a button? I think it would be better to use it only for real text containers. A listbox also doesn't share much behavior with a text container. A listbox or popupmenu is about choosing between a predefined set of options, usually not editing them.  

If more accessibles implement almost everything, it's hard for a toolkit to determine what kind of behavior a specific accessible has, by looking at the interfaces it supports.

Is there no better way to solve the original problem (setting the locale text attr)?

Comment 2

[Aaron Leventhal]

We need this for ATK, which says that every leaf which has text must be AccessibleText.

Also, it makes sense becuase a button or a list option (not a list or menu, just the option) can have an embedded object such as an image, in the middle of text. Only nsIAccessibleText can expose that.

Comment 3

[Håkan Waara]

Does the cross-platform code need to change only to present already-available data (button title, etc) in a different way to ATK?

One of the reasons I care about this, is because my current code makes an assumption that anything that can be QI'd to nsIAccessibleText is a text container. This is quite nice, and makes for simple code.

If this goes away, it'll be even harder to know on runtime what an accessible's identity really is (I'll have to do lots of special-casing with roles, etc).

Comment 4

[Aaron Leventhal]

Yes, the cross platform code has to change so that 1) we can support the text interface methods for those objects, and 2) there currently is no exact way to expose text followed an embedded image with text inside a <button> or <option>.

Comment 5

[Aaron Leventhal]

Attachment: Fix for HTML. Will need followup bug for XUL buttons, menu items and options

1) Fix GetOffsetAtPoint() to work with items that the caret cannot be placed in, make it return NS_OK instead of throwing an exception when point isn't at an offset. The -1 offset already means not found.
2) Inherit from nsHyperTextAccessible on classes that can support nsIAccessibleText
3) Cleanup: get rid of unneeded nsFormControlAccessible class (although it requires eAction_Click to be defined for each class that uses it -- which should be the case anyway)
4) Cleanup: better radio button class code reuuse

Comment 6

[Ginn Chen]

Comment on attachment 240651 [details] [diff] [review]
Fix for HTML. Will need followup bug for XUL buttons, menu items and options

r=me

Comment 7

[Håkan Waara]

Comment on attachment 240651 [details] [diff] [review]
Fix for HTML. Will need followup bug for XUL buttons, menu items and options

>@@ -61,10 +61,11 @@ public:
> };
> 
> class nsXULCheckboxAccessible : public nsFormControlAccessible
> {
> public:
>+  enum { eAction_Click = 0 };
>   nsXULCheckboxAccessible(nsIDOMNode* aNode, nsIWeakReference* aShell);
>   NS_IMETHOD GetRole(PRUint32 *_retval); 
>   NS_IMETHOD GetNumActions(PRUint8 *_retval);
>   NS_IMETHOD GetActionName(PRUint8 index, nsAString& _retval);
>   NS_IMETHOD DoAction(PRUint8 index);
>@@ -72,10 +73,11 @@ public:
> };
> 
> class nsXULDropmarkerAccessible : public nsFormControlAccessible
> {
> public:
>+  enum { eAction_Click = 0 };
>   nsXULDropmarkerAccessible(nsIDOMNode* aNode, nsIWeakReference* aShell);
>   NS_IMETHOD GetRole(PRUint32 *_retval); 
>   NS_IMETHOD GetState(PRUint32 *_retval); 
>   NS_IMETHOD GetNumActions(PRUint8 *_retval);
>   NS_IMETHOD GetActionName(PRUint8 index, nsAString& _retval);

Instead of adding this constant to these classes, can they be defined in some central place and then reused? Are there also constants for other actions that could be grouped there?

Comment 8

[[e-mail]]

Comment on attachment 240651 [details] [diff] [review]
Fix for HTML. Will need followup bug for XUL buttons, menu items and options

While the rest looks reasonable, you need to get a layout sr to ok your nsIFrame change.

Comment 9

[Aaron Leventhal]

Hakan, the constants need to be local to the classes, because the actions available for each type of object are different. For a button, action #0 might be different than what it should be for something else. Although, it is true that for the moment, most of the time action #0 is like clicking.

We're going to eventually need to go through the actions and add more actions per item.