Closed
Bug 393398
Opened 17 years ago
Closed 16 years ago
Add Bookmarks Dialog Inaccessible
Categories
(Firefox :: Bookmarks & History, defect, P3)
Firefox
Bookmarks & History
Tracking
()
RESOLVED
FIXED
Firefox 3 beta3
People
(Reporter: tkeenan, Assigned: aaronlev)
References
Details
(Keywords: access, relnote)
Attachments
(1 file)
11.38 KB,
image/jpeg
|
Details |
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.
Flags: blocking-firefox3?
Reporter | ||
Updated•17 years ago
|
Assignee: nobody → aaronleventhal
Component: Disability Access → Disability Access APIs
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Target Milestone: Firefox 3 M8 → mozilla1.9 M8
Comment 1•17 years ago
|
||
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.
Comment 2•17 years ago
|
||
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
Updated•17 years ago
|
Flags: blocking1.9?
Comment 3•17 years ago
|
||
(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.
Blocks: 279703
Reporter | ||
Updated•17 years ago
|
Assignee: aaronleventhal → nobody
Component: Disability Access APIs → Bookmarks
Flags: blocking1.9?
Keywords: sec508
Product: Core → Firefox
QA Contact: accessibility-apis → bookmarks
Target Milestone: mozilla1.9 M8 → Firefox 3 M8
Reporter | ||
Updated•17 years ago
|
Flags: blocking-firefox3?
Priority: -- → P1
Updated•17 years ago
|
Component: Bookmarks → Places
QA Contact: bookmarks → places
Updated•17 years ago
|
Priority: P1 → --
Target Milestone: Firefox 3 M8 → ---
Reporter | ||
Comment 4•17 years ago
|
||
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.
Updated•17 years ago
|
Target Milestone: --- → Firefox 3
Updated•17 years ago
|
Priority: -- → P1
Reporter | ||
Comment 5•17 years ago
|
||
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?
Reporter | ||
Comment 6•17 years ago
|
||
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
Closed: 17 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•17 years ago
|
Resolution: FIXED → WORKSFORME
Comment 7•17 years ago
|
||
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.
Reporter | ||
Comment 8•17 years ago
|
||
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 → ---
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Updated•17 years ago
|
Priority: P1 → --
Target Milestone: Firefox 3 → Firefox 3 M10
Comment 10•17 years ago
|
||
While Orca can deal with this "dialog", I still question why it has the role of menu rather than dialog.
Updated•17 years ago
|
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Updated•17 years ago
|
Priority: -- → P1
Updated•17 years ago
|
Priority: P1 → P3
Assignee | ||
Comment 12•17 years ago
|
||
I have a partial fix for this in bug 407359, although when it closes focus needs to go somewhere reasonable.
Assignee | ||
Updated•17 years ago
|
No longer depends on: mainscreena11y
Comment 13•17 years ago
|
||
(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.
Assignee | ||
Comment 14•17 years ago
|
||
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.
Comment 15•17 years ago
|
||
(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.
Assignee | ||
Comment 16•17 years ago
|
||
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.
Assignee | ||
Comment 17•16 years ago
|
||
Fixed by checkin to bug 407359.
Status: NEW → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → FIXED
Comment 18•16 years ago
|
||
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.
Comment 19•16 years ago
|
||
(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.
Comment 20•16 years ago
|
||
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.
Comment 21•16 years ago
|
||
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.
Assignee | ||
Comment 22•16 years ago
|
||
Tim, I suspect we need to get feedback from Window-Eyes on what the issue is.
Comment 23•16 years ago
|
||
(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.
Comment 24•16 years ago
|
||
This was fixed on GW Micro's end.
Comment 25•16 years ago
|
||
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!
Updated•16 years ago
|
Hardware: PC → All
Comment 26•16 years ago
|
||
fwiw, I updated the release notes to note that this is fixed in an upcoming Window-Eyes release.
Comment 27•15 years ago
|
||
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
Comment 28•5 years ago
|
||
Keywords: sec508
You need to log in
before you can comment on or make changes to this bug.
Description
•