Issue metadata
Sign in to add a comment
|
Using accessibility Chrome API to set spoken feedback causes app to take ownership for entire system
Reported by
jason.so...@gmail.com,
Oct 14 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Platform: (Platform version: 9765.81.0) Steps to reproduce the problem: 1. Using the accessibility API to turn on spoken feedback (https://developer.chrome.com/apps/accessibilityFeatures#property-spokenFeedback) 2. Manage the accessibility features for the system and look at the Text to Speech area. 3. What is the expected behavior? The spoken feed back will turn on but the feature will not be enforced by an extension. What went wrong? Calling the accessibility API seems to grant the extension control of spoken feedback for the entire system. This doesn't allow the user to change the setting any more on the system. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 61.0.3163.100 Channel: stable OS Version: 61.0.3163.120 Flash Version: Shockwave Flash 27.0 r0 We using the accessibility API in our Chrome app to enable or disable spoken feedback (https://developer.chrome.com/apps/accessibilityFeatures#property-spokenFeedback), we have noticed that the control for the spoken feedback for the entire OS appears to be given to our app. See the attached screenshot. It appears that when this happens, the user can no longer turn spoken feedback on or off using keyboard shortcuts (CTRL ALT Z). This does not seem to be expected behavior and doesn't seem to be documented as an expected side effect of calling this API. The only sway to remove the control of spoken feedback by our app seems to be uninstalling it. We are calling the set() method with a single value of enable. Is there some other way we should be calling the API to not have our app take control of spoken feedback for the entire application?
,
Oct 18 2017
Thanks for the report. Can you explain a bit more your intended use case? We built that API so that something like a full-screen kiosk app with a touch screen could offer a way to enable or disable accessibility features. We didn't really intend for it to be used by normal windowed apps. Let us know what you had in mind and we can try to figure out a solution.
,
Oct 20 2017
Our app needs to be able to conditionally allow or disallow spoken feedback depending on the configuration of the user logging into the application. We won't know which way to set this until the user has logged in. If their user configuration allows them to have spoken feedback, we would like to turn it on automatically (if not already on). If the user configuration does not allow for spoken feedback, we want to turn spoken feedback off and not allow it to be turned on for the duration of the user session. Once the user logs out of our app, we want to return all spoken feedback settings to how they were prior to logging into the app. Trying to return everything back to how it was prior to the app changing the spoken feedback is where this becomes a problem.
,
Nov 3 2017
,
Dec 20 2017
@tbarzic, you originally implemented this API, I believe for kiosk apps that really did need to fully control the system. Any thoughts on what changes we could make so that this use case could be supported?
,
Dec 20 2017
The API should already support clearing the apps control of the spoken feedback setting: chrome.accessibilityFeatures.spokenFeedback.clear |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by artyradz...@gmail.com
, Oct 14 2017133 bytes
133 bytes Download