You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, when a site uses an element, they may provide an accessibilityLabel property, commonly referred to as alt text. When RNW interprets the image, it will create two elements: an outer View and an inner-hidden img.
When set, the accessibility label is applied to the View and as alt to the img.
When not set, nothing is applied to the View, but the img gets an empty alt set (alt='').
Empty alt implies that the image is decorative only in nature, an example of an appropriate alt='' image might be an avatar on Twitter, because the visual information is duplicative with the username shown next to it (usually).
Separately, Chrome provides interesting functionality I just learned about to auto-caption images that are unlabeled. https://support.google.com/chrome/answer/9311597?hl=en. This potentially makes sites, especially those with user generated content, much more accessible to users. This functionality works by searching for img tags without alt, and using ML to label them for the user.
However, because the hidden img tag always has an alt set (albeit empty), Chrome will not label or detect any such images.
I'm proposing to reconsider a little bit how accessibility labels are handled in Image, primarily to enable this functionality for users.
Describe a solution you'd like
Right now, the View accessibilityLabel duplicates the hidden img label. Instead, we could generate DOM ids, and have View be labelled-by img. This creates one source of truth. (optional)
From there, I'd propose only setting alt on img, if accessiblityLabel is explicitly set (including '' or null which would set it as today). If accessibilityLabel = undefined, no alt prop would be set on img.
Describe alternatives you've considered
Another option would be to completely separate the img label and allow that to be manually controlled. One potential perk of doing it this way, is that I think the reason for setting '' as the default alt is to prevent clutter of unlabeled images from screen reader users or devs who don't leverage altText. So this would provide an opt-in path, but I don't think is aligned with RN spec.
Additional context
Currently with the suggested pointer label approach, Chrome will not use the ML generated caption for the outer View. I will separately ask them to consider this based on the outcome of this discussion (https://bugs.chromium.org/p/chromium/issues/detail?id=1093364). Until then, we'll provide a hidden text of "image" so that users navigating with j/k understand there is an image/graphic there.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently, when a site uses an element, they may provide an accessibilityLabel property, commonly referred to as alt text. When RNW interprets the image, it will create two elements: an outer View and an inner-hidden img.
When set, the accessibility label is applied to the View and as
alt
to the img.When not set, nothing is applied to the View, but the img gets an empty alt set (alt='').
Empty alt implies that the image is decorative only in nature, an example of an appropriate alt='' image might be an avatar on Twitter, because the visual information is duplicative with the username shown next to it (usually).
Separately, Chrome provides interesting functionality I just learned about to auto-caption images that are unlabeled. https://support.google.com/chrome/answer/9311597?hl=en. This potentially makes sites, especially those with user generated content, much more accessible to users. This functionality works by searching for img tags without alt, and using ML to label them for the user.
However, because the hidden img tag always has an alt set (albeit empty), Chrome will not label or detect any such images.
I'm proposing to reconsider a little bit how accessibility labels are handled in Image, primarily to enable this functionality for users.
Describe a solution you'd like
Right now, the View accessibilityLabel duplicates the hidden img label. Instead, we could generate DOM ids, and have View be labelled-by img. This creates one source of truth. (optional)
From there, I'd propose only setting alt on img, if accessiblityLabel is explicitly set (including '' or null which would set it as today). If accessibilityLabel = undefined, no alt prop would be set on img.
https://github.com/necolas/react-native-web/blob/master/packages/react-native-web/src/exports/Image/index.js#L259
Describe alternatives you've considered
Another option would be to completely separate the img label and allow that to be manually controlled. One potential perk of doing it this way, is that I think the reason for setting '' as the default alt is to prevent clutter of unlabeled images from screen reader users or devs who don't leverage altText. So this would provide an opt-in path, but I don't think is aligned with RN spec.
Additional context
Currently with the suggested pointer label approach, Chrome will not use the ML generated caption for the outer View. I will separately ask them to consider this based on the outcome of this discussion (https://bugs.chromium.org/p/chromium/issues/detail?id=1093364). Until then, we'll provide a hidden text of "image" so that users navigating with j/k understand there is an image/graphic there.
The text was updated successfully, but these errors were encountered: