-
Notifications
You must be signed in to change notification settings - Fork 39
Donburi/don 335 UI tests flights place selector additional #1944
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
Donburi/don 335 UI tests flights place selector additional #1944
Conversation
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.
Hi!
The identifier look all ok to me, but the actual accessibilityLabels leave some questions! More than happy to hop on a call!
@@ -86,12 +86,13 @@ public struct BPKAppSearchModal: View { | |||
.accessibilityHidden(false) | |||
.accessibilityRemoveTraits(.isImage) | |||
.accessibilityAddTraits(.isButton) | |||
.accessibilityLabel(closeAccessibilityLabel) | |||
.accessibilityLabel(closeAccessibilityLabel.lowercased()) |
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 we should lowercase the accessibility label, is there any specific use-case where you see this go wrong?
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.
we pretty sure need to remove that
I did it because UITests didn't see any element with non-lowercased localisable string in it
the issue was 100% reproducible...until I restart my machine (which I did just in case)
so, now I don't see any problems with that
BPKText(title, style: .heading5) | ||
.padding(.vertical, .sm) | ||
.accessibilityAddTraits(.isHeader) | ||
.accessibilityLabel(title) |
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.
Applying the label should not make a difference, as the BPKText already has the same visible label, did you hit any issues with this?
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, you're right and this line was removed from the initial PR, this change here is outdated
.accessibilityElement(children: .ignore) | ||
.accessibilityLabel(accessibilityLabel) | ||
.accessibilityAddTraits(.isButton) | ||
.opacity(text.isEmpty ? 0.0 : 1.0) |
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.
Should we make the if case check if text.isEmpty and not add the clear button?
I'm worried that setting opacity might not be foolproof for the screen reader?
What happens if the button is activated and it is then set to 0, does the focus linger on it?
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.
Actually, it's working great with the accessibility reader. But only if it's after accessibility modifiers. Make it inside if statement is not recommended due to performance possible issues.
f698e55
to
e23c04f
Compare
Remember to include the following changes:
README.md
Backpack.h
header fileIf you are curious about how we review, please read through the code review guidelines