Label tag should allow for htmlFor #1651

Activity

1. necolas commented on Jun 26, 2020

   

   necolas

   on Jun 26, 2020

   Owner

   More actions

   Use of for isn't really necessary because you can do the same thing (and more) with aria-labelledby: https://www.w3.org/WAI/tutorials/forms/labels/. The htmlFor attribute is web-only and I think we can do better by avoiding adding more platform-specific APIs to React Native where general approach work just as well.
2. walidvb commented on Jun 26, 2020

   

   walidvb

   on Jun 26, 2020

   Author

   More actions

   @necolas appreciate being platform agnostic, but aria-labelledby does not allow clicking on the label, example here.
   Maybe there's a better API to use? name? or other? 🤔

   👍React with 👍3Reacted by Chrıs Seelus, Marko Kajzer and Albert
3. necolas commented on Jun 26, 2020

   

   necolas

   on Jun 26, 2020

   Owner

   More actions

   The web label behavior doesn't happen on native either
4. walidvb commented on Jun 26, 2020

   

   walidvb

   on Jun 26, 2020

   Author

   More actions

   This asks a more general question then, should this library allow to do as much as the web does, or not? An alternative would then be to have a Label.web.js just for that one, which outputs html(kind of defeats the purpose, i think?)

   My question is does this library plan on limiting behaviour that is cross-platform only? Meaning anything that is web based will be dismissed? My opinion is that it shouldn't, as the platforms are inherently different, and the code should be able(as much as possible) to provide functionality for both, rather than limiting to a subset.

   This said, I really appreciate the work you and others did on this, and hoping it can fit my entire project!

   👍React with 👍2Reacted by Chrıs Seelus and Keitel Jovin
5. necolas

   closed this as completedon Aug 7, 2020
6. brucelawson commented on Jun 5, 2021

   

   brucelawson

   on Jun 5, 2021

   More actions

   I'd like to consider re-opening this. I'm doing accessibility testing of an R.N. project. The HTML output from react-native-web does a really good job of producing accessible code and mapping R.N. to wai-aria. However, the fact that the html 'labels' can't be clicked to put focus into the associated form field means that I can't use the generated web version, as it breaks user expectation and prohibits WCAG validation.

   Given that React native web 'knows' which fields are associated with which 'labels' (as it takes the field's aria-label text from the contents of the labelling div) it would seem to be possible for it to (a) generate an id to uniquely identify the field, and use label for="generatedID" instead of div for the label (perhaps as a switch that can be turned on for those who need it, so it doesn't much up CSS or markup of existing projects?)

   👍React with 👍4Reacted by Walid, Rainer Martinez, Chrıs Seelus and Albert
7. necolas commented on Jun 7, 2021

   

   necolas

   on Jun 7, 2021

   Owner

   More actions

   Hi Bruce,

   I'm doing accessibility testing of an R.N. project

   Can you share the RN code snippet that's being run on web?

   However, the fact that the html 'labels' can't be clicked to put focus into the associated form field means that I can't use the generated web version

   This can be re-implemented in JavaScript, which will make the behavior cross-platform too.

   Given that React native web 'knows' which fields are associated with which 'labels'...

   React DOM might know that internally, but it doesn't expose any way for us to get that information.

   ...generate an id to uniquely identify the field...

   This isn't straight-forward if there's server rendering and client hydration involved. React was meant to add a new hook to help with this, but it's caught in limbo and hasn't been shipped.

   ...use label for="generatedID" instead of div for the label

   You can still output a <label> element by setting the accessibilityRole to "label". That could be used to wrap fields in a <label>. IIRC not every screen reader likes that pattern, which is why using accessibilityLabelledBy (web-only) along with JS to move the focus has benefits.

   ---

   I like the idea in principle of inferring the for attribute from the accessibilityLabelledBy. That would reduce redundancy while retaining the historical behavior of clicking on labels. But AFAIK we can't do that. It would have to account for multiple labelling elements too. Creating a new prop just for use with label also seems quite heavy handed.

   A different option is to drop down to the unstable_createElement API. You can do something like this:

   // Label.js (for native)
   import {Text} from 'react-native';
   export function Label({ for, ...props }) {
     return <Text {...props} />
   }
   
   // Label.web.js (for web)
   import {unstable_createElement} from 'react-native-web';
   export function Label({ for, ...props }) {
     return unstable_createElement('label', { htmlFor: for, ...props });
   }

   This would allow you to use the same Label component in the cross-platform code, and use it like this <Label for={id} />. The id will do nothing on native but on web it will be added to the <label> element with the desired for attribute. This is my preferred option, as I think a framework should provide 90% of what you need but still give you APIs that allow full access to the host platform when needed. For example, RN has no way to markup tables in the public API either, but with this unstable_createElement API (and native equivalents) you could create your own React table components that render with the correct HTML tags.

   Another option is to set the DOM attribute in JS using a ref callback, but this only works for client-side rendering:

   const ref = React.useCallback((node) => {
     if (Platform.OS === 'web' && node != null) {
       node.setAttribute('for', id);
     }
   }, []);
   
   return (
     <>
       <Text ref={ref}>label</Text>
       <TextInput nativeID={id} />
     </>
   )

   👎React with 👎1Reacted by Albert

   😕React with 😕1Reacted by Jack Coy