Pressing ctrl+d yields the "context menu" from Window-eyes. Accessing the same functionality through the menus yields no speech. The dialog, if there is one, can't be found by reviewing the window either. Could someone with Accerciser tell me what they get on the Linux side. I'll try to get accexplorer to cooperate ude Windows and find out what's going on.
Assignee: nobody → aaronleventhal
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Target Milestone: Firefox 3 M8 → mozilla1.9 M8
This seems to be another instance of a re-purposed menu that's not really a menu (see my comment on bug 393248). What I'm seeing in Linux is a menu that is the direct descendant of the application frame. The children of this menu are not menu items (as one would expect), but instead labels and entries and push buttons. It would seem that when menus are pretending to be dialogs, not only do assistive technologies get confused, but keyboard navigation does as well. The logical way to move in something that looks like a dialog would be to press Tab. But when I do this, I move among focusable items (links, form controls, etc.) in the page I'm viewing. In addition, admittedly minor given the above, the text for the Delete and Done push buttons seems to be mis-aligned so that the vertical center of each word is the bottom edge of the button. See attached screenshot.
This broke with the 2007-08-17 build. The 2007-08-16 build is still OK. Here are the checkins of that given period: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-08-16+00%3A00&maxdate=2007-08-17+06%3A30&cvsroot=%2Fcvsroot
(In reply to comment #1) > This seems to be another instance of a re-purposed menu that's not really a > menu Could this be a <panel> bug then? If I understand the purpose of that widget correctly, it shouldn't pretend to be a menu.
Assignee: aaronleventhal → nobody
Component: Disability Access APIs → Bookmarks
Product: Core → Firefox
QA Contact: accessibility-apis → bookmarks
Target Milestone: mozilla1.9 M8 → Firefox 3 M8
Component: Bookmarks → Places
QA Contact: bookmarks → places
Priority: P1 → --
Target Milestone: Firefox 3 M8 → ---
An upcoming version of Jaws can successfully interact with the interface, but the panel doesn't get focus on activation of the Add Bookmark menu item or ctrl+d. It still characterizes the interface as a menu, yet it lets you tab through it like a dialog. I'm never come across anything quite like it.
12 years ago
Target Milestone: --- → Firefox 3
12 years ago
Priority: -- → P1
This has been updated so at least escape will close the panel, but it's still reported as a menu and Window-eyes can't track focus movement within it. How about Orca?
This is nicely fixed in the 09-11-04 build. Thanks, someone. This looks fine with inspect32 and windows screen-readers. I'm marking this as resolved-fixed since Windows and Linux seem to jibe very closely on things like this. Someone should certainly confirm it on Linux, though.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
This does now seem to be working much better on linux. There is a problem of no labels for the two edit fields in this dialog but that should probably be another bug.
I'm going to reopen this, because Window-eyes still doesn't track this correctly and claims it's a menu, in addition to the edit field problems. I apologize for jumping the gun on this. I'm not sure what happened on my end when I claimed everything was mysteriously working. It does work with Jaws, and there are improvements with Linux, but there's still work to be done.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Priority: P1 → --
Target Milestone: Firefox 3 → Firefox 3 M10
While Orca can deal with this "dialog", I still question why it has the role of menu rather than dialog.
keywording relnote for b1
I have a partial fix for this in bug 407359, although when it closes focus needs to go somewhere reasonable.
(In reply to comment #12) > I have a partial fix for this in bug 407359, although when it closes focus > needs to go somewhere reasonable. I would suggest to return to the page content. This is how the popup behaves without your patch for bug 407359, which I am testing right now.
I should have been more specific. There's a problem with where focus goes after you hit Escape. That isn't affected by my patch in bug 407359.
(In reply to comment #14) > I should have been more specific. There's a problem with where focus goes after > you hit Escape. That isn't affected by my patch in bug 407359. Yes it is affected. :-) Without your patch, hitting ESCAPE from Add Bookmarks drops me back to Page Content. With your patch, hitting ESCAPE puts me in la-la-land, and I have to hit TAB to get to the Location bar.
I tested in nightly builds which don't have the patch. Pressing Escape puts focus in lala land there too. You have to hit tab to move focus.
Fixed by checkin to bug 407359.
Status: NEW → RESOLVED
Last Resolved: 12 years ago → 11 years ago
Resolution: --- → FIXED
This is still broken on today's build with Window-eyes. Did this fix work for Orca users? Pressing ctrl+d speaks the name edit box, but no more. Tab results in nothing, however, if I down-arrow in the list of folders, Window-eyes will read that sluggishly. Hitting escape returns me to the page content.
(In reply to comment #18) > This is still broken on today's build with Window-eyes. Did this fix work for > Orca users? Yes, it definitely did fix things for Orca users. Note that you have to have the January 24, 2008 build or newer for the fix to be in.
marco, has this fix been verified on trunk? if so, please mark the status to "Verified", and include the build ID you verified it on. thanks.
Window-eyes still doesn't seem to be able to track the focus. I haven't noticed an appreciable change from prior to the January 24 build. Window-eyes doesn't treat it like a dialog the way Jaws does. Tabbing yields nothing, as before. If there's nothing more you can do on this end, I'll talk to the GW Micro folks and see what they can do.
Tim, I suspect we need to get feedback from Window-Eyes on what the issue is.
(In reply to comment #21) > Window-eyes still doesn't seem to be able to track the focus. I haven't > noticed an appreciable change from prior to the January 24 build. Window-eyes > doesn't treat it like a dialog the way Jaws does. Tabbing yields nothing, as > before. If there's nothing more you can do on this end, I'll talk to the GW > Micro folks and see what they can do. > Hi Tim, if this is still an open issue, can you reopen the bug? thanks.
This was fixed on GW Micro's end.
Mike, please update the final relnotes for Firefox 3 as follows: - Remove the sentence that says "Using JAWS iss recommended". - Add a sentence to the effect "GW Micro has fixed this problem in an upcoming Window-Eyes release." Thanks!
fwiw, I updated the release notes to note that this is fixed in an upcoming Window-Eyes release.
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.