New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add on/off accessibility labels to CupertinoSwitch #39993
Conversation
It looks like this pull request may not have tests. Please make sure to add tests before merging. While there are exceptions to this rule, if this patch modifies code it is probably not an exception. Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
@@ -144,6 +144,7 @@ class _CupertinoSwitchState extends State<CupertinoSwitch> with TickerProviderSt | |||
onChanged: widget.onChanged, | |||
vsync: this, | |||
dragStartBehavior: widget.dragStartBehavior, | |||
enableOnOffLabels: MediaQuery.onOffSwitchLabelsEnabled(context) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I switched (pun semi-intended) the position of the word "enabled" so as to avoid suggesting that this method somehow enables on/off labels. That said, I'm worried that having a slightly different name may be confusing. What do you think?
I also remove the word "switch" from the equivalent parameter to RenderCupertinoSwitch since it seems redundant. Not sure if it's better to use the exact same name ("enableOnOffSwitchLabels") everywhere or to adapt for intuitiveness, as I've tried to do.
@brandondiamond this will need tests. Some good cases to start with:
|
@@ -827,6 +842,12 @@ class MediaQuery extends InheritedWidget { | |||
return MediaQuery.of(context, nullOk: true)?.boldText ?? false; | |||
} | |||
|
|||
/// Returns the enableOnOffSwitchLabels accessibility setting for the nearest | |||
/// MediaQuery ancestor, or false if no such ancestor exists. | |||
static bool onOffSwitchLabelsEnabled(BuildContext context) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't add any new APIs to media query
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this comment to the original issue, probably belongs here. I agree with Jonah.
I think it would be best if we interested a new InheritedWidget in the cupertino library, rather than extending MediaQuery et al. Most of the features exposed by MediaQuery are more or less cross-platform. This "on/off labels flag" is specific to iOS and there are more flags like it. Instead of extending MediaQuery you could create a similar widget in the cupertino library called, say, CupertinoSystemSettings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds awesome -- thanks for the detail. One question: if I go that route, would the AccessibilityFeatures interface still be best for passing the bit from the platform? (I see a similar iOS-only bit managed there: "reduceMotion")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes good point: It looks like AccessibilityFeatures is the right place to plumb this value through from the engine. WidgetsApp already rebuilds when AccessibilityFeatures changes. That should be good enough for now, I think we can forgo creating an inherited CupertinoSystemSettings widget.
/// enabled. | ||
/// | ||
/// Value derived from a screenshot of a switch with on/off labeling. | ||
static const Color contrastingGray = Color(0xFFB8B8B8); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a widely used color that is worth exposing? Also the color value I got from inspecting the native component using Xcode is 0xFFB3B3B3
(White:0.7 Alpha:1).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so -- I just felt guilty adding a color constant to switch.dart 😜
If that seems reasonable, I'll remove the constant from here and add it to the constants section (as 0xFFB3B3B3 -- I used the OS X color meter utility, but I think you're 100% right that Xcode is more accurate).
Goldens change (sorry for the ugly merge): |
Engine change is in review, too: flutter/engine#12404 |
It looks like this pull request includes a golden file change. Please make sure to follow Handling Breaking Changes. While there are exceptions to this rule, if this patch modifies an existing golden file, it is probably not an exception. Only new golden files are not considered breaking changes. Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
These all look to be new golden files. Disregard the breaking change request. :) |
Engine change has now been merged. Once it rolls out in the next few hours, this should be good to go! |
@brandondiamond Heads up that there appear to be some legitimate things in the analyze check that's failing. |
Thanks for the review, Justin! It looks like the errors are likely a result of building with the old engine. (My engine PR is blocked on flutter/infra#62 which should hopefully get resolved today). Once that rolls out, I'll re-run the checks to make sure all is okay. |
Ah got it, sounds good. |
I know this may still be on hold, but for when it is ready: When this is ready for an update, take a look at the updated Writing a golden file test for package:flutter, and let me know if I can help migrate this change to the new system. :) |
@@ -147,6 +147,7 @@ class _CupertinoSwitchState extends State<CupertinoSwitch> with TickerProviderSt | |||
onChanged: widget.onChanged, | |||
vsync: this, | |||
dragStartBehavior: widget.dragStartBehavior, | |||
enableOnOffLabels: SemanticsBinding.instance.accessibilityFeatures.onOffSwitchLabels, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than use this directly, it's better to add this field to MediaQueryData
, populate the data there from the binding (take a look at how we do this for accessibleNavigation
) then use the field from MediaQueryData
here.
You should have a test that verifies that the rendering changes correctly if the value reported by the engine changes. |
@brandondiamond Do you have plans to come back to this PR and address the feedback? |
Hey Michael! Yup -- I do. (I had to wind down my 20% for a bit but will tackle this after hours; I'll try to get to it this week or, at the very latest, next week) |
This pull request has not been updated in a while. Please update this pull request to receive results from Gold, or close it. |
This has not been updated in a long while, so I am going to close it for now. If you would like to return to this, feel free to re-open! Thanks! |
Description
This PR adds accessibility labels to CupertinoSwitch. These labels match their counterparts in iOS 13. When the switch is active, a vertical "|" fades in; when inactive, a vertical "O" fades in.
Experimentation with iOS indicates that these icons are not typographical. They do not respond to text size or language changes. However, like the switch in general, the labels are sensitive to text direction. This PR ensures that the labels are rendered on the correct side of the switch.
This change will be implemented in two stages. The engine change (flutter/engine#12404) is currently in review. Meanwhile, this change implements the UI and updates tests. Once the engine change rolls out this PR will be ready to merge. Once merged, accessibility labels will be enabled automatically.
Related Issues
#4830: add accessibility labels to CupertinoSwitch.
#33797: update CupertinoSwitch to match iOS 13 styling.
Tests
I added the following tests:
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]
). This will ensure a smooth and quick review process.///
).flutter analyze --flutter-repo
) does not report any problems on my PR.Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?
Images
Measurements
Normal Speed
⅕ Speed
cc @LongCatIsLooong @johnsonmh @willlarche