Closed Bug 1383051 Opened 2 years ago Closed 2 years ago

Add a visual indicator when accessibility is enabled

Categories

(Core :: Disability Access APIs, enhancement, P1)

enhancement

Tracking

()

VERIFIED FIXED
mozilla57
Tracking Status
relnote-firefox --- 57+
firefox57 --- verified

People

(Reporter: jimm, Assigned: yzen)

References

(Depends on 1 open bug)

Details

Attachments

(5 files, 10 obsolete files)

4.26 KB, application/zip
Details
962 bytes, image/svg+xml
Details
38.66 KB, patch
yzen
: review+
Details | Diff | Splinter Review
25.25 KB, patch
yzen
: review+
Details | Diff | Splinter Review
3.83 KB, patch
jaws
: review+
Details | Diff | Splinter Review
A proposal: to cut down on 3rd party desktop apps that access web content through accessibility apis, consider adding a visual indicator to browser ui linked to support info explaining what accessibility is, the impact it has on browser performance, etc..

We may also want to give users the ability to force disable accessibility through preferences.
I support this (and it would complete the intention of bug 527003 comment 0). This needs product/ux to weigh in depending on visibility of the UI.
Peter this would be a useful tool to help us with a11y issues, particularly as we need to identify risks with e10s windows a11y rollout. NI for your awareness and thoughts here.
Flags: needinfo?(pdolanjski)
I filed bug 1384567 about adding about:preferences entries. This bug can be about a front end browser indicator.
See Also: → 1384567
Like, how about an icon in the identity block? That would probably only be effective when showing once an accessibility UI was actually accessed, not constantly. Is it technically possible to send an observer notification when that happens?
Yura just got a haircut, so he's taking this bug.
Assignee: nobody → yzenevich
Status: NEW → ASSIGNED
P2 seems like a fair estimate for this one?
Priority: -- → P2
(In reply to Johann Hofmann [:johannh] from comment #4)
> Like, how about an icon in the identity block?

Accessibility instantiation applies to the browser generally, and is not per page, otherwise this would be a great idea IMO.
(In reply to David Bolter [:davidb] from comment #7)
> (In reply to Johann Hofmann [:johannh] from comment #4)
> > Like, how about an icon in the identity block?
> 
> Accessibility instantiation applies to the browser generally, and is not per
> page, otherwise this would be a great idea IMO.

It might be not that bad idea. I realize that a11y is enabled nowadays for the whole browser, I anticipate though that web tools may enable a11y per page soon.
Hi Michelle,

Amy suggested I loop you in regarding a copy for the doorhanger item that we are likely adding for accessibility (when it is enabled in the browser). It would be something similar to permissions item that currently has:

Permissions
You have not granted this site any special permissions

But in our context we want to say:

Accessibility [or Accessibility Features Enabled [or something shorter]]
Accessibility features are enabled and might impact your browser performance. Click here to find out more.

This item would be actionable and would open a about:accessibility tab.
Flags: needinfo?(mheubusch)
Amy mentioned that there might be a refresh of the private browsing indicator in the titlebar/tabbar to be square, Stephen, do you think this is going to be included in 57 or it's post 57?
Flags: needinfo?(shorlander)
(In reply to Yura Zenevich [:yzen] from comment #10)
> Amy mentioned that there might be a refresh of the private browsing
> indicator in the titlebar/tabbar to be square, Stephen, do you think this is
> going to be included in 57 or it's post 57?

An accessibility indicator up in this area would be perfect. We could provide a hidden pref to disable it for users who know a11y is on and don't care.
Attached file Icon Assets.zip (obsolete) —
Hi, 

I've attached the spec and assets for the accessibility and privacy icon. As discussed, we are holding off on including a door-hanger. The user clicks on the icon and it will take them to the accessibility web page for more information. Let me know if you have any questions.

Spec: https://mozilla.invisionapp.com/share/CGD1KQX8K
Flags: needinfo?(amlee)
Attached file Icon Assets.zip
Attachment #8897439 - Attachment is obsolete: true
(In reply to Amy Lee [:amylee] UX from comment #12)
> Created attachment 8897439 [details]
> Icon Assets.zip
> 
> Hi, 
> 
> I've attached the spec and assets for the accessibility and privacy icon. As
> discussed, we are holding off on including a door-hanger. The user clicks on
> the icon and it will take them to the accessibility web page for more
> information. Let me know if you have any questions.
> 
> Spec: https://mozilla.invisionapp.com/share/CGD1KQX8K

A couple of questions on the spec:

- What does the icon do in compact and touch mode (the window controls are always the same height as the tabs in Windows 10)? Does it resize with the window controls?
- Where does the icon go when the menubar is enabled?
- Where does the icon go on Mac and Linux?

(I presume the answer to the last two questions is: the same as the private browsing indicator right now, I just want to be sure).

Thanks!
Flags: needinfo?(amlee)
Hi Johann, 
I've updated the Invision doc to answer these questions but I'll comment below as well.


(In reply to Johann Hofmann [:johannh] from comment #14)
> (In reply to Amy Lee [:amylee] UX from comment #12)
> > Created attachment 8897439 [details]
> > Icon Assets.zip
> > 
> > Hi, 
> > 
> > I've attached the spec and assets for the accessibility and privacy icon. As
> > discussed, we are holding off on including a door-hanger. The user clicks on
> > the icon and it will take them to the accessibility web page for more
> > information. Let me know if you have any questions.
> > 
> > Spec: https://mozilla.invisionapp.com/share/CGD1KQX8K
> 
> A couple of questions on the spec:
> 
> - What does the icon do in compact and touch mode (the window controls are
always the same height as the tabs in Windows 10)? Does it resize with the
> window controls?

The icon is sized at 24x24px. This size stays the same in default, compact, and touch. The difference would be the spacing above and below the icon.

> - Where does the icon go when the menubar is enabled?
Do you mean the title bar? I've updated the spec to cover layout if title bar is enabled 

> - Where does the icon go on Mac and Linux?
> 
> (I presume the answer to the last two questions is: the same as the private
> browsing indicator right now, I just want to be sure).
 
Yes :-)

> 
> Thanks!
Flags: needinfo?(amlee)
Hi Amy, a couple of follow up questions: if the indicator is a link, what's the expected keyboard interaction with it? hover/active/focused styling? Do we want a tooltip to show up, and if so, what should be the copy there? Thanks
Flags: needinfo?(amlee)
(In reply to Yura Zenevich [:yzen] from comment #16)
> Hi Amy, a couple of follow up questions: if the indicator is a link, what's
> the expected keyboard interaction with it? hover/active/focused styling? Do
> we want a tooltip to show up, and if so, what should be the copy there?
> Thanks

Also, with private browsing for example, we add a title bar bit "(Private browsing)" to every title. Do we need to do anything similar about a11y indicator?
(In reply to Yura Zenevich [:yzen] from comment #17)
> (In reply to Yura Zenevich [:yzen] from comment #16)
> > Hi Amy, a couple of follow up questions: if the indicator is a link, what's
> > the expected keyboard interaction with it? hover/active/focused styling? Do
> > we want a tooltip to show up, and if so, what should be the copy there?
> > Thanks
> 
> Also, with private browsing for example, we add a title bar bit "(Private
> browsing)" to every title. Do we need to do anything similar about a11y
> indicator?

Hi Yura, 

I don't think it's necessary, NI Michelle to see if she has feedback on this.
Flags: needinfo?(amlee)
(In reply to Yura Zenevich [:yzen] from comment #16)
> Hi Amy, a couple of follow up questions: if the indicator is a link, what's
> the expected keyboard interaction with it? hover/active/focused styling? Do
> we want a tooltip to show up, and if so, what should be the copy there?
> Thanks

Hi Yura, 

Can you make the hover state #008ea4. Michelle do you have a recommendation for the tooltip? Maybe something like "Accessibility Features Enabled"
Removing NI since implementation is well in progress.
Flags: needinfo?(pdolanjski)
Hover/Pressed state for the accessibility icon.
Depends on: 1392753
I'm not sure which bug is the best place to ask this, but is it even technically possible for Firefox to know or display which apps are currently utilizing accessibility?

If so is this something we might want to reveal somewhere? If not on hover perhaps in about:support or preferences.
(In reply to Caspy7 from comment #22)
> I'm not sure which bug is the best place to ask this, but is it even
> technically possible for Firefox to know or display which apps are currently
> utilizing accessibility?
> 
> If so is this something we might want to reveal somewhere? If not on hover
> perhaps in about:support or preferences.

At least on Windows we are now showing a11y clients in about:support, see bug 1384672. This indicator is for showing if Firefox accessibility engine is started. All this elements together with a11y privacy pref are all interconnected. And hopefully the Support page that all of them point to will help explain the details for those interested.
Attachment #8902367 - Flags: review?(jmathies)
Attachment #8902368 - Flags: review?(jmathies)
Try with all builds for all affected platforms and appropriate b-c tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=38c5825d8c6e16ab0d56d312a931a5147458a6f4
Comment on attachment 8902368 [details] [diff] [review]
1383051 part 2 - accessiblity service indicator.

See comment 26 for a link to a try job with builds for all platform to test the UI for.
Attachment #8902368 - Flags: ui-review?(amlee)
Comment on attachment 8902367 [details] [diff] [review]
1383051 part 1 - private browsing indicator refresh

I'm not qualified to do front end markup reviews. I bet Jared can or can help route this to the right reviewer.
Attachment #8902367 - Flags: review?(jmathies) → review?(jaws)
Comment on attachment 8902368 [details] [diff] [review]
1383051 part 2 - accessiblity service indicator.

Review of attachment 8902368 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/app/profile/firefox.js
@@ +672,5 @@
>  pref("accessibility.typeaheadfind.linksonly", false);
>  pref("accessibility.typeaheadfind.flashBar", 1);
>  
> +// Accessibility indicator preferences such as support URL, enabled flag.
> +pref("accessibility.services.url", "https://support.mozilla.org/%LOCALE%/kb/accessibility-services");

Do we want this to match up to the Learn more link in Options with the check box? If so we should update one of these.

http://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2fe7d7b6e75ad6b6b5da223/browser/components/preferences/in-content-new/privacy.js#1618

@@ +673,5 @@
>  pref("accessibility.typeaheadfind.flashBar", 1);
>  
> +// Accessibility indicator preferences such as support URL, enabled flag.
> +pref("accessibility.services.url", "https://support.mozilla.org/%LOCALE%/kb/accessibility-services");
> +pref("accessibility.services.indicator.enabled", true);

I think we can get rid of the 'services' in the prefs above. Maybe 'accessibility.support.url' and 'accessibility.indicator.enabled'?
Attachment #8902368 - Flags: review?(jmathies) → review+
Comment on attachment 8902367 [details] [diff] [review]
1383051 part 1 - private browsing indicator refresh

Review of attachment 8902367 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the following cleanups.

::: browser/themes/shared/browser.inc.css
@@ +84,5 @@
> +.private-browsing-indicator {
> +  background-image: url("chrome://browser/skin/private-browsing.svg");
> +}
> +
> +#main-window:not([privatebrowsingmode=temporary]) .private-browsing-indicator {

s/#main-window/:root/

::: browser/themes/shared/icons/private-browsing.svg
@@ +1,2 @@
> +<?xml version="1.0" encoding="utf-8"?>
> +<!-- Generator: Adobe Illustrator 21.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->

Please remove this line.

@@ +1,3 @@
> +<?xml version="1.0" encoding="utf-8"?>
> +<!-- Generator: Adobe Illustrator 21.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
> +<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"

The ID, xmlns:xlink, x, and y attributes are unnecessary here.

@@ +1,4 @@
> +<?xml version="1.0" encoding="utf-8"?>
> +<!-- Generator: Adobe Illustrator 21.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
> +<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
> +	 width="24px" height="24px" viewBox="0 0 24 24" style="enable-background:new 0 0 24 24;" xml:space="preserve">

I *think* the viewBox attribute is unnecessary. Same for the style and xml:space attribute. Please test after removing these attributes.

@@ +4,5 @@
> +	 width="24px" height="24px" viewBox="0 0 24 24" style="enable-background:new 0 0 24 24;" xml:space="preserve">
> +<style type="text/css">
> +	.st0{fill:#8000D7;}
> +	.st1{fill:#FFFFFF;}
> +</style>

Please remove this <style> element, and then just use fill="#8000D7" on the first path. And set fill="#ffffff" on the second path.

@@ +6,5 @@
> +	.st0{fill:#8000D7;}
> +	.st1{fill:#FFFFFF;}
> +</style>
> +<title>Group 15</title>
> +<desc>Created with Sketch.</desc>

Please remove the <title/> and <desc/>

@@ +7,5 @@
> +	.st1{fill:#FFFFFF;}
> +</style>
> +<title>Group 15</title>
> +<desc>Created with Sketch.</desc>
> +<path id="Rectangle" class="st0" d="M12,24L12,24C5.4,24,0,18.6,0,12l0,0C0,5.4,5.4,0,12,0l0,0c6.6,0,12,5.4,12,12l0,0

Please remove the ID and class attributes.

@@ +9,5 @@
> +<title>Group 15</title>
> +<desc>Created with Sketch.</desc>
> +<path id="Rectangle" class="st0" d="M12,24L12,24C5.4,24,0,18.6,0,12l0,0C0,5.4,5.4,0,12,0l0,0c6.6,0,12,5.4,12,12l0,0
> +	C24,18.6,18.6,24,12,24z"/>
> +<path id="Fill-1" class="st1" d="M15.4,11c-1-0.1-1.9,0.5-2.1,1.5c0,0.3,1.2,0.7,2.3,0.7s2.1-0.7,2.1-0.9C17.7,12.1,17,11.1,15.4,11

Please remove the ID and class attributes here too.
Attachment #8902367 - Flags: review?(jaws) → review+
Comment on attachment 8902368 [details] [diff] [review]
1383051 part 2 - accessiblity service indicator.

Review of attachment 8902368 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/themes/shared/icons/accessibility-active.svg
@@ +1,2 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<!-- Generator: Adobe Illustrator 21.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->

Please make the same changes to this file that I requested for private-browsing.svg

::: browser/themes/shared/icons/accessibility.svg
@@ +1,2 @@
> +<?xml version="1.0" encoding="utf-8"?>
> +<!-- Generator: Adobe Illustrator 21.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->

Please make the same changes to this file that I requested for private-browsing.svg
Comment on attachment 8902368 [details] [diff] [review]
1383051 part 2 - accessiblity service indicator.

Hi, 

This was the feedback I had provided offline to Yura. The following issues were resolved.

1. Go into customize panel when private window/accessibility features are turned on. A 2nd accessibility icon appears beside the 1st one which shouldn’t be there. 


2. You’re able to drag around the accessibility icon when in customise mode and make it disappear but it goes back into place when you exit out of customise. You shouldn’t be able to drag the icon.


3. Hover/Onclick should be the same colour (#008ea4). It looks like the white in the icon gets darker on hover. It should be #ffffff and only the background colour goes darker.

4. When you go into customize. The Private browser icon stays the same colour but the accessibility icon is faded out. Please remove the fade in the accessibility icon. It should remain unchanged.
Attachment #8902368 - Flags: ui-review?(amlee) → ui-review+
Carryover r+ with comments addressed.
Attachment #8902367 - Attachment is obsolete: true
Attachment #8903584 - Flags: review+
Carry over r+ ui-review+ with comments addressed.
Attachment #8902368 - Attachment is obsolete: true
Attachment #8903586 - Flags: ui-review+
Attachment #8903586 - Flags: review+
Pushed by yura.zenevich@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/633d738656d5
updated private browsing indicators. r=jaws
https://hg.mozilla.org/integration/mozilla-inbound/rev/b440aaae26a1
added accessibility service indicators. r=jimm
Removing NI's
Flags: needinfo?(shorlander)
Flags: needinfo?(mheubusch)
Priority: P2 → P1
https://hg.mozilla.org/mozilla-central/rev/633d738656d5
https://hg.mozilla.org/mozilla-central/rev/b440aaae26a1
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Depends on: 1396240
Depends on: 1396281
Depends on: 1397401
No longer depends on: 1397401
Flags: needinfo?(yzenevich)
Yep, on my radar, will try to get a re-review by Monday.
Flags: needinfo?(yzenevich)
Status: REOPENED → ASSIGNED
Target Milestone: mozilla57 → ---
Attached patch fix for bug 1396281 (obsolete) — Splinter Review
Attachment #8906445 - Flags: review?(jaws)
Comment on attachment 8906445 [details] [diff] [review]
fix for bug 1396281

Review of attachment 8906445 [details] [diff] [review]:
-----------------------------------------------------------------

I'm redirecting to Dao since I'll be away for the next two days. Also, if this solution is ideal then we should probably use something more specific than `toolbarbutton` for the right hand side of the selector.
Attachment #8906445 - Flags: review?(jaws) → review?(dao+bmo)
(In reply to (Away until Sept 13th) Jared Wein [:jaws] (please needinfo? me) from comment #41)
> Comment on attachment 8906445 [details] [diff] [review]
> fix for bug 1396281
> 
> Review of attachment 8906445 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I'm redirecting to Dao since I'll be away for the next two days. Also, if
> this solution is ideal then we should probably use something more specific
> than `toolbarbutton` for the right hand side of the selector.

Thanks! Just for clarification, it could be .titlebar-button (perhaps for the better), I did not do that because the container had a unique titlebar-buttonbox id.
Attached patch fix for bug 1396281 (obsolete) — Splinter Review
Updated to what Jared suggested: not using plain toolbarbutton
Attachment #8906445 - Attachment is obsolete: true
Attachment #8906445 - Flags: review?(dao+bmo)
Attachment #8906732 - Flags: review?(dao+bmo)
Attached patch fix for bug 1396240 (obsolete) — Splinter Review
Attachment #8906733 - Flags: review?(dao+bmo)
Attached image fixed.PNG (obsolete) —
sceenshot of the fix for bug 1396281
Attached image win7fix.PNG (obsolete) —
Screenshot of the fix for bug 1396240
Blocks: 1399385
[Tracking Requested - why for this release]: This bug updates indicator for private browsing and adds a new indicator for accessibility services (https://support.mozilla.org/en-US/kb/accessibility-services) enabled in Firefox.
Attachment #8906732 - Flags: review?(dao+bmo) → review+
Attachment #8906733 - Flags: review?(dao+bmo) → review+
Comment on attachment 8903584 [details] [diff] [review]
1383051 part 1 - private browsing indicator refresh v2

> #titlebar-secondary-buttonbox {
>-  margin-right: 7px;
>-  margin-left: 7px;
>+  align-items: center;
>+  display: flex;

Please avoid mixing flex with -moz-box since it's undocumented how these layout models should interact. This is what likely lead to the regressions.
Hi Yura, will you be able to respond to Dao's feedback in comment 48?
Flags: needinfo?(yzenevich)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #49)
> Hi Yura, will you be able to respond to Dao's feedback in comment 48?

Yes I am removing display: flex solution, will hopefully have a patch to take a look at asap.
Flags: needinfo?(yzenevich)
Attached patch 1383051.1.patchSplinter Review
Carry over.
Attachment #8903584 - Attachment is obsolete: true
Attachment #8903586 - Attachment is obsolete: true
Attachment #8906732 - Attachment is obsolete: true
Attachment #8906733 - Attachment is obsolete: true
Attachment #8906735 - Attachment is obsolete: true
Attachment #8906739 - Attachment is obsolete: true
Attachment #8910464 - Flags: review+
Attached patch 1383051.2.patchSplinter Review
Carry over.
Attachment #8910465 - Flags: review+
Attached patch 1383051.3.patchSplinter Review
Removing all flex styling.
Attachment #8910466 - Flags: review?(jaws)
Comment on attachment 8910466 [details] [diff] [review]
1383051.3.patch

Review of attachment 8910466 [details] [diff] [review]:
-----------------------------------------------------------------

I noticed one issue in testing this that we should fix before landing.

Once the Accessibility indicator becomes enabled, it doesn't hide until the browser is restarted. I used Windows 10 and enabled the Narrator to test.

Disabling the Narrator doesn't remove the Accessibility indicator, and also checking the checkbox in Preferences "Prevent accessibility services from accessing your browser" doesn't hide the accessibility indicator. I assumed either of these would hide it without requiring a restart. The indicator appears if the Narrator is enabled after Firefox is started, so it should also disappear while Firefox is running if it is disabled through either means.
Attachment #8910466 - Flags: review?(jaws) → review+
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #54)
> Comment on attachment 8910466 [details] [diff] [review]
> 1383051.3.patch
> 
> Review of attachment 8910466 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I noticed one issue in testing this that we should fix before landing.
> 
> Once the Accessibility indicator becomes enabled, it doesn't hide until the
> browser is restarted. I used Windows 10 and enabled the Narrator to test.
> 
> Disabling the Narrator doesn't remove the Accessibility indicator, and also
> checking the checkbox in Preferences "Prevent accessibility services from
> accessing your browser" doesn't hide the accessibility indicator. I assumed
> either of these would hide it without requiring a restart. The indicator
> appears if the Narrator is enabled after Firefox is started, so it should
> also disappear while Firefox is running if it is disabled through either
> means.

Yes so the behaviour you're describing is expected. A11y services will not shut down if screen reader is turned off. Currently it is not possible on the platform level. My expectation of the checkbox was that it would get turned off. But evidently it is not. That might actually be a bug on the platform level. ni? jimm, david just in case.
Flags: needinfo?(jmathies)
Flags: needinfo?(dbolter)
So I dug into the code a little, and that preference is only checked when accessibility starts up (whether it should be enabled or not) so until the browser restarts it will still be enabled. This is also confirmed by the https://support.mozilla.org/en-US/kb/accessibility-services#w_how-do-i-disable-accessible-services that both the pref and the indicator button link to. Removing ni? sorry for the noise.
Flags: needinfo?(jmathies)
Flags: needinfo?(dbolter)
(In reply to Yura Zenevich [:yzen] from comment #56)
> So I dug into the code a little, and that preference is only checked when
> accessibility starts up (whether it should be enabled or not) so until the
> browser restarts it will still be enabled. 

This is the type of UX sin we keep commuting. As someone who does user support frequently, it leaves users either frustrated or misguided when troubleshooting when they change a setting and we don't communicate that they need to restart for the setting to take effect (or force the restart).

Can we add a notification when this pref is checked? People will be expecting an immediate effect otherwise.
(In reply to Caspy7 from comment #57)
> (In reply to Yura Zenevich [:yzen] from comment #56)
> > So I dug into the code a little, and that preference is only checked when
> > accessibility starts up (whether it should be enabled or not) so until the
> > browser restarts it will still be enabled. 
> 
> This is the type of UX sin we keep commuting. As someone who does user
> support frequently, it leaves users either frustrated or misguided when
> troubleshooting when they change a setting and we don't communicate that
> they need to restart for the setting to take effect (or force the restart).
> 
> Can we add a notification when this pref is checked? People will be
> expecting an immediate effect otherwise.

This is a valid point. The preference has shipped already though. I could open a follow up bug for this as this bug only deals with an indicator that is on iff platform a11y is enabled.
Pushed by yura.zenevich@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/aa83d846b65e
updated private browsing indicators. r=jaws
https://hg.mozilla.org/integration/mozilla-inbound/rev/1d059590a69b
added accessibility service indicators. r=jimm
https://hg.mozilla.org/integration/mozilla-inbound/rev/0f94bac50b37
fixing windows 10 window control alignment and indicator alignment in windows 7. r=jaws
(In reply to Yura Zenevich [:yzen] from comment #58)
> (In reply to Caspy7 from comment #57)
> > (In reply to Yura Zenevich [:yzen] from comment #56)
> > > So I dug into the code a little, and that preference is only checked when
> > > accessibility starts up (whether it should be enabled or not) so until the
> > > browser restarts it will still be enabled. 
> > 
> > This is the type of UX sin we keep commuting. As someone who does user
> > support frequently, it leaves users either frustrated or misguided when
> > troubleshooting when they change a setting and we don't communicate that
> > they need to restart for the setting to take effect (or force the restart).
> > 
> > Can we add a notification when this pref is checked? People will be
> > expecting an immediate effect otherwise.
> 
> This is a valid point. The preference has shipped already though. I could
> open a follow up bug for this as this bug only deals with an indicator that
> is on iff platform a11y is enabled.

Yes, please open a follow up bug. Even though this may have shipped first with Firefox 56, this will now be much more noticeable with this new indicator. Ideally we should not require a restart for this, but in that case we should prompt for a restart the same way we do when changing the e10s pref.
Flags: needinfo?(yzenevich)
Depends on: 1401980
Depends on: 1401982
Release Note Request (optional, but appreciated)
[Why is this notable]: new accessibility feature to let the user know when accessibility services are enabled
[Affects Firefox for Android]: no
[Suggested wording]: Accessibility indicator will now appear in the title bar of the window when Accessibility services are enabled.
[Links (documentation, blog post, etc)]: https://support.mozilla.org/en-US/kb/accessibility-services
relnote-firefox: --- → ?
Flags: needinfo?(yzenevich)
Depends on: 1403867
This was added to 57 beta release notes. Should it be removed from 57.0 release notes? Jared?
Flags: needinfo?(jaws)
(In reply to Ritu Kothari (:ritu) from comment #63)
> This was added to 57 beta release notes. Should it be removed from 57.0
> release notes? Jared?

Yes, we disabled this by default in 57.
Flags: needinfo?(jaws)
See Also: → 1444397
You need to log in before you can comment on or make changes to this bug.