GNOME Bugzilla – Bug 620299
Orca does not treat editable document frames as entries
Last modified: 2010-09-20 10:54:44 UTC
This blocks 404403 bug impacts accessibility for sites that use large text input areas such as: http://xltweet.com and > http://notepub.com It is possible to navigate most parts of the site including registering and login, but the main function of both sites is missing. Orca skips over the text area where new entries can be added. It gives no indication that such a box even exists. It appears that the text areas are claiming to be web pages because they give an ATK_ROLE_DOCUMENT_FRAME identification. It would be more helpful if they were identified as ATK_ROLE_ENTRY or ATK_ROLE_TEXT because they are basically text areas. They do show ATK_STATE_EDITABLE though.
Hi Storm, Thanks for the report. Glad to see you active on bugzilla :) The accessibility and blocking fields are usually not visible when creating the bug, but once it is created, if one goes to the bug again, the fields for keywords, and blocks become available, and one can enter the required info there. So if you are reading this using the bugzilla website, then you should be able to find the keywords and blocks fields further down the page. I have added the info there now. Thanks.
Stayed up to catch Marco Zehe. (01:34:30 AM) MarcoZ: joanie: Yes, this is by design. This is a rich text document, realized through an iframe. (01:34:37 AM) MarcoZ: And it can contain other items like headings, links etc. (01:34:45 AM) MarcoZ: So yes, this is definitely by design. I'll take this one.
Created attachment 162880 [details] [review] take 1 This patch is intended to address the following issues related to the fact that these "entries" are not really entries, but editable document frames: 1. Structural navigation by entry 2. Structural navigation by form field 3. Caret navigation 4. Focus tracking (i.e. when you Tab amongst items) In all cases, it should cause Orca to behave as if the objects were entries. I've done quite a bit of functional testing and so far it seems okay. I still need to run the automated regression tests. In the meantime, testing love would be appreciated. Note: 1. XLTweet did not properly mark up their page. As a result, label guess is kicking in and guessing some text which are functional (but not proper) labels of some combo boxes above the entry-which-is-not-an-entry. That is not an issue which is to be addressed as part of this bug; that's a separate issue. One bug per issue. Yadda, yadda, yadda. 2. This should not impact Thunderbird. But it most certainly could have impacted Thunderbird. Testing would be appreciated here. Thanks!
This patch works great as far as I can tell. Xltweets doesn't work, but that was to be expected. Notepub.com works great now, the box shows up as an edit field, and the rest works great.
Comment on attachment 162880 [details] [review] take 1 http://git.gnome.org/browse/orca/commit/?id=4c64737e2f24e72cc8f0ec515864a887094e2793
(In reply to comment #4) > This patch works great as far as I can tell. Xltweets doesn't work, but that > was to be expected. Notepub.com works great now, the box shows up as an edit > field, and the rest works great. Thanks Storm. It also regression tests well, so I've committed it. As for Xltweets, what do you mean it doesn't work? I can now move into it and Orca treats it as an entry for both speech and braille. I can use Orca + Tab to move focus into it. Label guess isn't working, but like I said, that's not this bug. Before I close this out as fixed, I'd be interested in knowing more about why Xltweets isn't working for your Storm.
On xltweets I can use Orca+tab to move between text fields. There is a text field followed by userName, followed by password. I assume the first box is the box for entering the long tweet, so I tried to type there. The text I type ends up in the userName box instead though. I tried several times but each time the focus moves to the userName.
(In reply to comment #7) > On xltweets I can use Orca+tab to move between text fields. There is a text > field followed by userName, followed by password. I assume the first box is the > box for entering the long tweet, so I tried to type there. The text I type ends > up in the userName box instead though. I tried several times but each time the > focus moves to the userName. There is some other text object on that page I think and it seems to be claiming to be editable. Here's what I just did and it worked for me: 1. Let the page (and apparently all it's subpages) load. 2. Ctrl+Home (insurance. Seems like we start reading the page and then more subpages somewhere start loading. Something I need to think about how to handle. But in the meantime,...) 3. Orca + Tab. Orca says "text", the braille display shows the cursor and the EOL indicator. 4. Type a tweet. 5. Tab to next entry (Twitter Username). Fill this out. 6. Tab to next field (Password). Fill this out. 7. Tab to the Tweet This! button and press it. The tweet posted as expected. (Not in my timeline because I deleted it.)
As best as I can tell, this bug is fixed and there have not been any side effects. If there are additional issues, please open a new bug. Thanks!