Open
Bug 1160785
Opened 10 years ago
Updated 2 years ago
Reader Mode availability could be announced by accessibility
Categories
(Firefox for iOS :: Browser, defect)
Tracking
()
NEW
People
(Reporter: dusek, Unassigned, NeedInfo)
References
(Blocks 2 open bugs)
Details
(Keywords: access)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/600.5.17 (KHTML, like Gecko) Version/8.0.5 Safari/600.5.17
Steps to reproduce:
1. Load webpage with Reader Mode available
Actual results:
Sighted user noticed reader mode button appeared.
VoiceOver user did not notice it, unless they took the effort to with VoiceOver cursor to the location bar.
Expected results:
Sighted user noticed reader mode button appeared.
VoiceOver user noticed availability of Reader Mode without any effort as VoiceOver spoke announcement that Reader Mode is available (this is what Safari does).
Updated•10 years ago
|
Reporter | ||
Updated•10 years ago
|
Assignee: nobody → dusek
Reporter | ||
Comment 1•10 years ago
|
||
I looked at this. The problem is that the order of these 2 events is not deterministic:
1. Reader Mode button state change
2. webView:didFinishNavigation: (where we post AXScreenChanged)
I.e. most of the time, 2. happens after 1., so we can pass AXScreenChanged the parameter to say that reader mode is available (when it is, as learned from the Browser's ReaderMode helper's state). But sometimes 2. happens before 1., which makes it unreliable.
So currently this is not reliably possible without some more involved tracking of state and of this actual order.
Comment 2•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months.
:jeevans, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee: dusek → nobody
Flags: needinfo?(jeevans)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•