Skip to content
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

why is the accessibilityHint enforced as mandatory? #142

Open
rveruna opened this issue Jul 19, 2022 · 3 comments · May be fixed by #163
Open

why is the accessibilityHint enforced as mandatory? #142

rveruna opened this issue Jul 19, 2022 · 3 comments · May be fixed by #163

Comments

@rveruna
Copy link

rveruna commented Jul 19, 2022

From your documentation

"An accessibility hint helps users understand what will happen when they perform an action on the accessibility element when that result is not apparent from the accessibility label."

Therefore, if the result is apparent from a label, and the hint is not added, the linter shouldn't flag it as an error. But hint is flagged as an error each time the label is added to an element.

An example:

<Image accessibilityLabel='Facebook logo' accessibilityRole="image" />

will give me an error - error has accessibilityLabel prop but no accessibilityHint react-native-a11y/has-accessibility-hint
But there is no other information I would want to convey for a logo... so no hint is needed.

I guess this can be improved by not including images?

@gregdburns
Copy link

I'm not a fan of this rule either, for the same reasons. I just disabled it in my .eslintrc config:

rules: {
    'react-native-a11y/has-accessibility-hint': 'off'
}

jaworek added a commit to callstack/eslint-config-callstack that referenced this issue Sep 6, 2022
'react-native-a11y/has-accessibility-hint' is too strict and incorrect in some cases.
I think it would be a good idea to turn it off by default.

FormidableLabs/eslint-plugin-react-native-a11y#142
thymikee pushed a commit to callstack/eslint-config-callstack that referenced this issue Sep 6, 2022
'react-native-a11y/has-accessibility-hint' is too strict and incorrect in some cases.
I think it would be a good idea to turn it off by default.

FormidableLabs/eslint-plugin-react-native-a11y#142
@kueda
Copy link

kueda commented Feb 7, 2023

I'm by no means an a11y expert so take this for what it's worth, but Apple explicitly says,

You should provide a hint only when the results of an action are not obvious from the element’s label.

That would suggest that hints are not always required. And as mentioned above, not all items that require labels actually support actions, so there's no result of an action you need to hint at, even if there is a need for a more explicit label (e.g. "99 comments" for an element that has a a speech bubble icon next to a number).

I think it's ok for this package to be opinionated and leave this in, but it would help my team out if there was an option for it to only apply for Pressable, or maybe for any component that has an onPress prop.

@Drew-Gerber
Copy link

Agree- there seems to be a fair amount of nuance as to when accessibilityHint should be used. We've also found that there's times when you want to customize an accessibilityLabel and adding accessibilityHint doesn't add value.

For our use case, I'm thinking we can enforce the use of hint w/ label on our pressable elements via TypeScript:

type AccessibilityLabel = {
    accessibilityLabel?: undefined
}

type AccessibilityLabelWithHint = {
    accessibilityLabel: string
    accessibilityHint: string
}

type AccessibilityLabelProps = AccessibilityLabel | AccessibilityLabelWithHint

const props: AccessibilityLabelProps = { // GOOD - no custom label

}

const propsWithLabel: AccessibilityLabelProps = { // FAILS - no hint
    accessibilityLabel: 'Profile icon'
}

const propsWithLabelAndHint: AccessibilityLabelProps = { // GOOD - has hint and label
    accessibilityLabel: 'Profile icon',
    accessibilityHint: 'Navigates to profile screen.'
}

Since we have the lower level Pressable/Touchable* components wrapped, this should work if someone using our wrapped pressables needs to set a label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants