-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
[Android] label -> contentDescription #293
Conversation
</TouchableOpacity> | ||
|
||
<TouchableOpacity onPress={this.onButtonPress.bind(this, 'ID Working')}> | ||
<Text testID='UniqueId345' style={{color: 'blue', marginBottom: 20}}>ID</Text> | ||
<Text testID='UniqueId345' style={{color: 'blue', marginBottom: 20}} accessibilityLabel={'ID'}>ID</Text> |
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.
@simonracz explain, please, why testID
and accessibilityLabel
have different values? I'm using react-native-testid
at Tipsi. And we have both parameters the same
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.
AccessibilityLabel is user visible. TestId is not.
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.
@isnifer Bad idea.
tipsi/react-native-testid#1
@@ -29,7 +29,7 @@ export default class ActionsScreen extends Component { | |||
<TouchableOpacity onPress={this.onButtonPress.bind(this, 'Tap Working')} | |||
onLongPress={this.onButtonPress.bind(this, 'Long Press Working')} | |||
> | |||
<Text style={{ color: 'blue', marginBottom: 20, textAlign: 'center' }}>Tap Me</Text> | |||
<Text style={{ color: 'blue', marginBottom: 20, textAlign: 'center' }} acccessibilityLabel={'Tap Me'}>Tap Me</Text> |
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 like these changes.
Can you please explain why we need to require users to add accessibilityLabel
on each element?
On iOS, accessibilityLabel
is used by Voice Over, for example, and is not always linked 1:1 with the content. The developer can certainly change it if they feel they can provide a better label for the content.
How does this work on Android?
Perhaps we should change the tests on iOS to by.text(‘’)
, but requiring users to add accessibilityLabel
on each element is not something I can live with.
Also please note you misspelled “accessibilityLabel” here (“ccc”).
docs/APIRef.Expect.md
Outdated
@@ -52,6 +53,13 @@ await expect(element(by.id('RandomJunk959'))).toNotExist(); | |||
await expect(element(by.id('UniqueId204'))).toHaveText('I contain some text'); | |||
``` | |||
|
|||
### `toHaveLabel(label)` | |||
- Similar to `toHaveText(text)`, but searches by accessibilityLabel (iOS) or by contentDescription (Android) |
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.
The two shouldn’t be linked in such nonchalant manner. On iOS, text and label can have multiple meanings, and they wouldn’t be similar in cases where users care about the accessibility of their application. The documentation should split those completely.
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.
You probably read much more out of the "similar" word that was meant there. But, I agree, I'll rewrite 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.
My issue is that some users l, particularly in RN ecosystem, are not familiar with iOS concepts, and learn half-truths because of imprecise text they see here and there. I’m sure it’s the same for Android. This is why I try to push for accuracy, so everyone gets the correct picture.
docs/APIRef.Matchers.md
Outdated
@@ -42,14 +43,22 @@ Find an element by text, useful for text fields, buttons. | |||
```js | |||
await element(by.text('Tap Me')); | |||
``` | |||
|
|||
#### `by.label(label)` | |||
Find an element by accessibilityLabel(iOS) or contentDescription(Android), useful for text fields, buttons. |
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.
Accessibility label is useful for almost any UI element on iOS. As per documentation, this should be properly set to any element with custom appearance, such as images. The system helps by trying to set a value to this property be similar to the title of elements such as text fields or buttons, but also for other elements. The “useful” comment implies incorrect here.
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.
Ok. I'll remove the useful part.
<Text style={{height: 30, backgroundColor: '#e8e8f8', padding: 5, margin: 10}} accessibilityLabel={'Text5'}>Text5</Text> | ||
<Text style={{height: 30, backgroundColor: '#e8e8f8', padding: 5, margin: 10}} accessibilityLabel={'Text6'}>Text6</Text> | ||
<Text style={{height: 30, backgroundColor: '#e8e8f8', padding: 5, margin: 10}} accessibilityLabel={'Text7'}>Text7</Text> | ||
<Text style={{height: 30, backgroundColor: '#e8e8f8', padding: 5, margin: 10}} accessibilityLabel={'Text8'}>Text8</Text> | ||
</ScrollView> |
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 still don’t understand why, if tests are now by.text()
, why this label was added to all views?
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.
Not all tests search by text, even after this commit.
I followed the following pattern:
For fixed elements, I set accessibilityLabel. For dynamic elements I didn't. (The reason behind this was that blind people could read out the structure of the app from the fixed elements.)
I can remove nearly all accessibilityLabels and search only by text if you prefer. (I'll leave the accessibilityLabel for the Matcher tests, where we explicitly test for accessibilityLabel.)
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 think this will be best. What do you think? It will also show best practice to users that wonder how to use the API.
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 think detox users should almost always search by text
. And only use label
, if they really want to search by accessibilityLabel/contentDescription.
This is why I found it important to also change the docs, sample codes and detox init
e2e file.
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.
100% agree. That’s why I think all the labels in the test are unnecessary.
But the most accurate is to match by identifier. By text is problematic if you use localization.
Maybe you'll find the discussion(s) here helpful: |
People abusing |
5a472f9
to
37b5c40
Compare
I addressed the comments in the latest commit. |
@@ -5,6 +5,7 @@ | |||
|
|||
<uses-permission android:name="android.permission.INTERNET" /> | |||
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/> | |||
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/> |
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.
Can't get the point of this line in this PR
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.
It was missing for an Android test. (Which is not triggered by CI yet.)
The whole point of the PR was to make the test suite cross platform.
I rewrote
label
handling on Android to make it search bycontentDescription
instead oftext
.This showed that the detox test suite is actually tied to iOS. Therefore, I had to touch nearly all screens and tests to make it cross-platform.
iOS vs Android example
A
TextView
has no defaultcontentDescription
on Android. From RN's perspective this means that you have to setaccessibilityLabel
directly on a<Text>
. On iOS this works without this.I also updated the docs and
detox init
's default e2e file.