Closed
Bug 1353818
Opened 8 years ago
Closed 7 years ago
Slider does not function with JAWS screenreader
Categories
(Core :: Disability Access APIs, defect, P3)
Tracking
()
RESOLVED
DUPLICATE
of bug 1388409
People
(Reporter: u554753, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: multiprocess, Whiteboard: aes+)
Jaws Version:
18.0.2530
User Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/55.0
Steps to Reproduce:
1. Navigate to http://oaa-accessibility.org/example/32
2. Observe the page or attempt to move the slider while e10s/JAWS screenreader is active.
Expected Results:
The user moves the slider on the page and the JAWS screenreader reads the output of the value.
Actual Results:
Firefox Nightly occasionally becomes unresponsive when the page is opened, and occasionally crashes. If the page opens successfully, JAWS screenreader does not read the output value of the slider that the user selects. (Crash reports below)
Crash Reports:
https://crash-stats.mozilla.com/report/index/2a39d2f2-a262-4c66-827e-50cd32170405#tab-details
This works normally and does not crash when e10s is turned off as well as when the screenreader is not active.
This issue is still reproducible with the below specs - It functions as intended when e10s is disabled.
Firefox Nightly - 57.0a1
JAWS Version - 18.0.4938
Updated•7 years ago
|
Keywords: multiprocess
Updated•7 years ago
|
Flags: needinfo?(mzehe) → needinfo?(jmathies)
Comment 3•7 years ago
|
||
(In reply to Grover Wimberly IV [:Grover-QA] from comment #0)
> Jaws Version:
> 18.0.2530
>
> User Agent:
> Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101
> Firefox/55.0
>
> Steps to Reproduce:
> 1. Navigate to http://oaa-accessibility.org/example/32
> 2. Observe the page or attempt to move the slider while e10s/JAWS
> screenreader is active.
>
> Expected Results:
> The user moves the slider on the page and the JAWS screenreader reads the
> output of the value.
>
> Actual Results:
> Firefox Nightly occasionally becomes unresponsive when the page is opened,
> and occasionally crashes. If the page opens successfully, JAWS screenreader
> does not read the output value of the slider that the user selects. (Crash
> reports below)
Hey Grover, can you clarify your steps here? From my understand when working with JAWS you have to enter into form input mode [1] by tabbing to an input element and pressing enter.
In testing with this sample, I get the occasional bad hang when interacting with the page. If I wait those out I can successfully tab to the first slider, press enter, and then adjust the slider.
[1] http://www.htctu.fhda.edu/trainings/manuals/tutorials/readweb/forms.htm
Flags: needinfo?(jmathies) → needinfo?(gwimberly)
Updated•7 years ago
|
Summary: Slider does not function with JAWS screenreader, browser occasionally crashes → Slider does not function with JAWS screenreader
Comment 4•7 years ago
|
||
The following bugs are similar:
Bug 1356385 - JAWS Screenreader does not read selections from aria autocomplete inline
Bug 1353554 - Form field does not allow entry and JAWS screenreader reads varying statements when keys are pressed
Bug 1363881 - JAWS Screenreader does not read output when navigated with arrow keys
Bug 1369183 - NVDA/JAWS Screenreader does not read output from combobox when e10s is enabled
Bug 1379297 - JAWS does not read checkbox button selections when e10s is enabled
(In reply to Jim Mathies [:jimm] from comment #3)
> Hey Grover, can you clarify your steps here? From my understand when working
> with JAWS you have to enter into form input mode [1] by tabbing to an input
> element and pressing enter.
>
> In testing with this sample, I get the occasional bad hang when interacting
> with the page. If I wait those out I can successfully tab to the first
> slider, press enter, and then adjust the slider.
>
> [1] http://www.htctu.fhda.edu/trainings/manuals/tutorials/readweb/forms.htm
After letting it hang for 5-10 minutes, I am able to verify that slider controls are indeed read by JAWS screenreader with e10s enabled.
Flags: needinfo?(gwimberly)
Comment 6•7 years ago
|
||
(In reply to Grover Wimberly IV [:Grover-QA] from comment #5)
> (In reply to Jim Mathies [:jimm] from comment #3)
> > Hey Grover, can you clarify your steps here? From my understand when working
> > with JAWS you have to enter into form input mode [1] by tabbing to an input
> > element and pressing enter.
> >
> > In testing with this sample, I get the occasional bad hang when interacting
> > with the page. If I wait those out I can successfully tab to the first
> > slider, press enter, and then adjust the slider.
> >
> > [1] http://www.htctu.fhda.edu/trainings/manuals/tutorials/readweb/forms.htm
>
> After letting it hang for 5-10 minutes, I am able to verify that slider
> controls are indeed read by JAWS screenreader with e10s enabled.
Good news on the inputs!
Do you know how to take and save performance profiles? We'd love to inspect good profiles of jank/hangs with JAWS. Can you take some and post them to bug 1388409? If you need any guidance you can ping tracy walker.
Flags: needinfo?(gwimberly)
Comment 7•7 years ago
|
||
I can file a pi request if needed.
Acknowledged. I added a NI to myself for that bug and taking myself off NI here. I'll try and get some performance profiles for JAWS-related hangs.
Flags: needinfo?(gwimberly)
status-firefox56:
--- → affected
status-firefox57:
--- → affected
Updated•7 years ago
|
Priority: -- → P3
Updated•7 years ago
|
Whiteboard: aes+
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•