FF 3.0 ATSPI node tab order and possible bugs

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

FF 3.0 ATSPI node tab order and possible bugs

Steve Lee-3
I'm iterating iAccessible nodes in the document and cannot determine
how to do that in tab order.  The child nodes are in document order
and I cannot find any property etc for tabindex (whether implicit or
explict).

Have I missed something?

I'm iterating over all nodes that have an IAction, state = ENABLED |
VISIBLE | FOCUSABLE and also checking against a bunch of potential
roles which is really redundant. I expect this to give me all form
controls and links.

Where are the symantics of the various states defined?

All nodes seem to have state_sensitive. What is this? I expect
paragraphs etc not to have it. I was thinking that an action and
sensistive would give me all controls

I've noticed the following which may be bugs. I'm being timid in case
I'm on the wrong tangent

* input type=file appear as a single text and no button. The text does
not have  state_focusable
* Option items are state_visible even when not actually showing . This
may be necessary due to different display possibilities
* Links have no useful info in the Hyperlink interface. All controls
seem to have a hyperlink interface but with empty URI and isValid() ==
false. A valid link has URI but isValid() is still false.
* Readonly text inputs can have focus but have no visual cue that they have it.
  A lack of caret is probably correct given the limited interaction
but you loose where focus is. This is only partially an a11y issue.

--
Steve Lee
--
Open Source Assistive Technology Software
PowerTalk - your presentations can speak for themselves
www.fullmeasure.co.uk
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: FF 3.0 ATSPI node tab order and possible bugs

Ginn Chen
Hi Steve,

On Sep 26, 2007, at 8:07 PM, Steve Lee wrote:

> I'm iterating iAccessible nodes in the document and cannot determine
> how to do that in tab order.  The child nodes are in document order
> and I cannot find any property etc for tabindex (whether implicit or
> explict).
>
> Have I missed something?
>
> I'm iterating over all nodes that have an IAction, state = ENABLED |
> VISIBLE | FOCUSABLE and also checking against a bunch of potential
> roles which is really redundant. I expect this to give me all form
> controls and links.
>
> Where are the symantics of the various states defined?
>
> All nodes seem to have state_sensitive. What is this? I expect
> paragraphs etc not to have it. I was thinking that an action and
> sensistive would give me all controls
>
> I've noticed the following which may be bugs. I'm being timid in case
> I'm on the wrong tangent
>
> * input type=file appear as a single text and no button. The text does
> not have  state_focusable
Bug, possible Bug 345195

> * Option items are state_visible even when not actually showing . This
> may be necessary due to different display possibilities
VISIBLE but not SHOWING, I think it's correct.

> * Links have no useful info in the Hyperlink interface. All controls
> seem to have a hyperlink interface but with empty URI and isValid() ==
> false. A valid link has URI but isValid() is still false.
Bug

*aIsValid = (state & nsIAccessibleStates::STATE_INVALID) != 0;

shouldn't it be opposite?

Sorry, I got to go home now, somebody please fix it, or I'll do it  
tomorrow.

> * Readonly text inputs can have focus but have no visual cue that  
> they have it.
>   A lack of caret is probably correct given the limited interaction
I saw a caret in readonly text.
WFM

Thank you, Steve.

Ginn

> but you loose where focus is. This is only partially an a11y issue.
>
> --
> Steve Lee
> --
> Open Source Assistive Technology Software
> PowerTalk - your presentations can speak for themselves
> www.fullmeasure.co.uk
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility

--------
Ginn Chen
Software Engineer, Browser Team
Sun Microsystems, Inc.
Phone: x82869 / +86-10-62673869
Fax: +86-10-62780969


_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: FF 3.0 ATSPI node tab order and possible bugs

Steve Lee-3
Thanks Ginn

>> * Option items are state_visible even when not actually showing . This
>> may be necessary due to different display possibilities
> VISIBLE but not SHOWING, I think it's correct.

My bad, I doubled checked in accerciser and all seems to be as should be.

> * Links have no useful info in the Hyperlink interface. All controls
> seem to have a hyperlink interface but with empty URI and isValid() ==
> false. A valid link has URI but isValid() is still false.
> Bug
>
> *aIsValid = (state & nsIAccessibleStates::STATE_INVALID) !=
> 0;

(state & nsIAccessibleStates::STATE_INVALID) !=
nsIAccessibleStates::STATE_INVALID

is generally safest depending on exact bit patterns involved.

> I saw a caret in readonly text.
> WFM

<input type="text" readonly='readonly' value='wibble' name="text">
has none on trunk on linux. You can select the text

--
Steve Lee
--
Open Source Assistive Technology Software
PowerTalk - your presentations can speak for themselves
www.fullmeasure.co.uk
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: FF 3.0 ATSPI node tab order and possible bugs

Aaron Leventhal-3
In reply to this post by Ginn Chen
STATE_INVALID = 0
So, state & STATE_INVALID is always 0

It doesn't mean the same thing as STATE_INVALID_ENTRY

- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility