The default bug view has changed. See this FAQ.

Add Bookmarks Dialog Inaccessible

RESOLVED FIXED in Firefox 3 beta3

Status

()

Firefox
Bookmarks & History
P3
major
RESOLVED FIXED
10 years ago
7 years ago

People

(Reporter: Tim Keenan, Assigned: Aaron Leventhal)

Tracking

({access, relnote, sec508})

Trunk
Firefox 3 beta3
access, relnote, sec508
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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

10 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

10 years ago
Created attachment 277901 [details]
screenshot

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

10 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

10 years ago
Flags: blocking1.9?
Blocks: 385266

Comment 3

10 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

10 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

10 years ago
Flags: blocking-firefox3?
Priority: -- → P1
Component: Bookmarks → Places
QA Contact: bookmarks → places
Priority: P1 → --
Target Milestone: Firefox 3 M8 → ---
(Reporter)

Comment 4

10 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

10 years ago
Target Milestone: --- → Firefox 3

Updated

10 years ago
Priority: -- → P1
(Reporter)

Comment 5

10 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

10 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
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Updated

10 years ago
Resolution: FIXED → WORKSFORME

Comment 7

10 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

10 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

10 years ago
Flags: blocking-firefox3? → blocking-firefox3+

Updated

10 years ago
Priority: P1 → --
Target Milestone: Firefox 3 → Firefox 3 M10
(Assignee)

Updated

10 years ago
Duplicate of this bug: 392580

Comment 10

10 years ago
While Orca can deal with this "dialog", I still question why it has the role of menu rather than dialog.

Updated

10 years ago
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Priority: -- → P1

Comment 11

10 years ago
keywording relnote for b1
Keywords: relnote

Updated

10 years ago
Priority: P1 → P3
(Assignee)

Comment 12

9 years ago
I have a partial fix for this in bug 407359, although when it closes focus needs to go somewhere reasonable.
Assignee: nobody → aaronleventhal
Blocks: 396346
Status: REOPENED → NEW
Depends on: 407359
(Assignee)

Updated

9 years ago
No longer depends on: 407359
(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

9 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.
(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

9 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.

Updated

9 years ago
Depends on: 409623
(Assignee)

Comment 17

9 years ago
Fixed by checkin to bug 407359.
Status: NEW → RESOLVED
Last Resolved: 10 years ago9 years ago
Resolution: --- → FIXED

Comment 18

9 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.
(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.

Comment 21

9 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

9 years ago
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.

Comment 24

9 years ago
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!
Hardware: PC → All
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.