355540 - accessible objects for xforms upload and some inputs

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

Comment 1

[alexander :surkov (:asurkov)]

Attachment: testcase

Comment 2

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 3

[aaronr]

Comment on attachment 241346 [details] [diff] [review]
patch

I have no problem with the code.  But none of the code comments really explain why this is necessary (what does accessibility do with this information) or what are the indicators that my control should/should not be of this type?  You mention, "for XForms elements that provide accessible object for itself as well for anonymous content" and then you give examples, which is great.  But what is so different about input[type="xsd:gMonth"] that makes it this type and a normal xforms:input isn't of this type?

r-'ing for now, just until I see and understand the requested code comments.

Comment 4

[alexander :surkov (:asurkov)]

Attachment: patch2

Do additional comments makes things more clear?

Comment 5

[aaronr]

(In reply to comment #4)
> Created an attachment (id=243746) [edit]
> patch2
> 
> Do additional comments makes things more clear?
> 

The new comments are very good, but I still don't see a distinction of when to use nsXFormsContainerAccessible and when not to.  In your description you write, "You should use this class if accessible XForms element is complex, i.e. it is composed from elements that should be accessible too. For example, this class is used by accessbile objects for XForms input[type="xsd:gMonth"] that contains combobox element to choose month".  xf:input[type="xsd:string"] is composed of an element (html:input) that should be accessible, right?  Just like xf:input[type="gMonth"].  So I still don't see enough information in the comment to help me to decide when and when not to use it.  But you are certainly headed in the right direction.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to comment #5)
> (In reply to comment #4)
> > Created an attachment (id=243746) [edit]
> > patch2
> > 
> > Do additional comments makes things more clear?
> > 
> 
> The new comments are very good, but I still don't see a distinction of when to
> use nsXFormsContainerAccessible and when not to.  In your description you
> write, "You should use this class if accessible XForms element is complex, i.e.
> it is composed from elements that should be accessible too. For example, this
> class is used by accessbile objects for XForms input[type="xsd:gMonth"] that
> contains combobox element to choose month".  xf:input[type="xsd:string"] is
> composed of an element (html:input) that should be accessible, right?

Not right. html:input is not accessbile because it can provide nothing special what xforms input do.

>  Just
> like xf:input[type="gMonth"].  So I still don't see enough information in the
> comment to help me to decide when and when not to use it.  But you are
> certainly headed in the right direction.

Please help me to make comment clearer.

Comment 7

[aaronr]

Here's what I came up with:

+/**
+ * This class is accessible object for XForms elements that provide accessible
+ * object for itself as well for anonymous content. You should use this class
+ * if accessible XForms element is complex, i.e. it is composed from elements
+ * that should be accessible too.  Especially for elements that have multiple
+ * areas that a user can interact with or multiple visual areas.  For example,
+ * objects for XForms input[type="xsd:gMonth"] that contains combobox element
+ * to choose month.  It has an entryfield, a drop-down button and a drop-down
+ * list, all of which need to be accessible.  Another example would be
+ * an XForms upload element since it is constructed from textfield and
+ * 'pick up file' and 'clear file' buttons.  Most XForms elements will end
+ * up in this category.
+ */
+class nsXFormsContainerAccessible : public nsXFormsAccessible
+{
+public:
+  nsXFormsContainerAccessible(nsIDOMNode* aNode, nsIWeakReference* aShell);
+

Comment 8

[alexander :surkov (:asurkov)]

Attachment: patch3

I removed one line: "Most XForms elements will end up in this category." from your comment because I can't say most xforms elements will use it. I assume these are some of selects, month and day inputs and upload. Right now I can't see what's more.

Comment 9

[[e-mail]]

Comment on attachment 244161 [details] [diff] [review]
patch3

>-    <implementation implements="nsIXFormsUIWidget">
>+
>+    <implementation implements="nsIAccessibleProvider">
Why don't these bindings have to implement nsIXFormsUIWidget any more?

Comment 10

[aaronr]

(In reply to comment #9)
> (From update of attachment 244161 [details] [diff] [review] [edit])
> >-    <implementation implements="nsIXFormsUIWidget">
> >+
> >+    <implementation implements="nsIAccessibleProvider">
> Why don't these bindings have to implement nsIXFormsUIWidget any more?
> 

When I was reviewing, I noticed that.  But I thought that would get picked up via: <binding id="xformswidget-input-month-base"
         extends="chrome://xforms/content/xforms.xml#xformswidget-base">

Because nsxformswidget-base implements that interface.

Or am I wrong?

Comment 11

[alexander :surkov (:asurkov)]

(In reply to comment #10)
> (In reply to comment #9)
> > (From update of attachment 244161 [details] [diff] [review] [edit] [edit])
> > >-    <implementation implements="nsIXFormsUIWidget">
> > >+
> > >+    <implementation implements="nsIAccessibleProvider">
> > Why don't these bindings have to implement nsIXFormsUIWidget any more?
> > 
> 
> When I was reviewing, I noticed that.  But I thought that would get picked up
> via: <binding id="xformswidget-input-month-base"
>          extends="chrome://xforms/content/xforms.xml#xformswidget-base">
> 
> Because nsxformswidget-base implements that interface.
> 
> Or am I wrong?
> 

You are right. I don't drop support of nsIXFormsUIWidget, this ability is inherited from base widget.