Closed Bug 703198 Opened 8 years ago Closed 8 years ago

JAWS doesn't announce combobox navigation in collapsed combobox

Categories

(Core :: Disability Access APIs, defect)

x86
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla11
Tracking Status
firefox10 --- fixed

People

(Reporter: surkov, Assigned: surkov)

References

Details

(Keywords: access, Whiteboard: [qa-])

Attachments

(3 files)

Attached patch patchSplinter Review
regression from bug 673958. JAWS expects focus event for changed option. Similar to Orca. I contacted to FS to check if they can do IE way for Firefox (i.e. based on value change events), that's should be consistent across browsers and ATs (NVDA picks up value change event well). In either way I think we should add a hook for JAWS to keep it working.
Attachment #575099 - Flags: review?(marco.zehe)
Comment on attachment 575099 [details] [diff] [review]
patch

r=me, even though I think this is rather hacky. ;) But at least it will get JAWS working with those comboboxes.
Attachment #575099 - Flags: review?(marco.zehe) → review+
(In reply to Marco Zehe (:MarcoZ) from comment #1)
> Comment on attachment 575099 [details] [diff] [review] [diff] [details] [review]
> patch
> 
> r=me, even though I think this is rather hacky. ;) But at least it will get
> JAWS working with those comboboxes.

absolutely, in bug 673958 we ended up that we shouldn't fire focus event for options when they aren't visible so I do this for JAWS only. Marco, would you mind to check how other screen readers feel about that like WE or Supernova?
https://hg.mozilla.org/mozilla-central/rev/8914d038bd09
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
Comment on attachment 575099 [details] [diff] [review]
patch

need to be ported into Firefox 10 where regression was introduced (bug 673958). The bug prevents JAWS (major screen reader) to work with comboboxes. Patch is trivial, the code is JAWS specific (nobody else is affected).
Attachment #575099 - Flags: approval-mozilla-aurora?
then it means ::GetModuleHandleW() call is high expensive
Comment on attachment 575099 [details] [diff] [review]
patch

canceling request until perf problems are figured out
Attachment #575099 - Flags: approval-mozilla-aurora?
Attached patch patch2Splinter Review
let's see if it helps
Attachment #576441 - Flags: review?(marco.zehe)
Comment on attachment 576441 [details] [diff] [review]
patch2

r=me. Good idea to switch these checks around so the ::getModuleHandle call doesn't get executed each time.
Attachment #576441 - Flags: review?(marco.zehe) → review+
Great, thanks! :-)
Comment on attachment 576441 [details] [diff] [review]
patch2

see comment #5 (perf regression is fixed)
Attachment #576441 - Flags: approval-mozilla-aurora?
Alex, you might want to put up a unified patch for Aurora that just shows the diffs against the current Aurora code. This patch2 depends on patch1, which is confusing, esp if none of us ends up transplanting the patch in case we get approval. So my recommendation is to make a patch specific to Aurora that only contains the fixed version of the code, and request approval for that.
Attached patch combined patchSplinter Review
Attachment #576870 - Flags: approval-mozilla-aurora?
Attachment #576441 - Flags: approval-mozilla-aurora?
Attachment #576870 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Thanks, Marco!
Is this something QA can verify?
Whiteboard: [qa?]
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #20)
> Is this something QA can verify?

yeah, you need JAWS for this though. If you have JAWS running then you should tab into HTML select (combobox) and then arrow down through its options. If JAWS reads them then bug is fixed.
Unfortunately, this is not something I'm set up to test. For now I will mark this qa- in the hopes that someone from the community can help verify this fix.
Whiteboard: [qa?] → [qa-]
You need to log in before you can comment on or make changes to this bug.