I have come across a couple of react-native third party modules that don't pass on the props accessibilityLabel and testID to the underlying components e.g. <Text /> and <View />. While it is completely up to the module author to implement this it makes it much harder to test apps using these components as test frameworks like Appium for example rely on these IDs to be set in order to be able to uniquely identify a component. (Okay there's XPath but that is not a great option)
How should this be addressed? I can think of the following options
Let react-native handle it automatically
Include a note in the docs to remind authors that this is important
Have react-native display a warning if the props are not being passed on
Posting here since their Github page seems flooded and this doesn't need to be tracked as an issue yet. Would love to see some opinions.
Related
I'm adding accessibility to my project and I have a basic vuetify data table, just like this example, but I can't find a way to make the checkboxes accessible using the tab key on the keyboard, Is there any way to do this? I know there's something called 'tabIndex' and I've used it before, but I don't know how to use it here. Can you guys help me or guide me on how to do it? Thanks!
It is very difficult to impossible to “add accessibility” at the end of a project.
Getting keyboard navigation and aria attributes right in 3rd party components is nearly impossible. You’d need to apply plenty of hacks or bind deeply into the component’s DOM, which breaks once the library gets updated.
With Vuetify you chose a library that has accessibility on top of their list, but unfortunately the data table with checkboxes cannot be used by keyboard at all, and is lacking plenty of other ARIA attributes. They don’t seem to keep up to that promise for that component.
As with any 3rd party library, if you find an issue, you should try to report a bug upstream and fix it together with their developers.
Correct behaviour of data grids
The expected behaviour of tables in web applications is that of a Data Grid.
A data grid is a composite UI component, so it’s expected that the whole component receives focus only once by means of Tab. Then, you’d navigate with arrow keys inside the table, using Space to select rows or Enter to interact with a cell.
See Keyboard Navigation Inside Components
You can try keyboard navigation in AG-Grid
The pattern to apply in code would be a roving tab index:
Only one child element of the table has tabindex="0", while all others have tabindex="-1". Key bindings then will move the 0 around in the component.
So this is quite some effort to implement.
Simple Alternative
As far as I known, it is acceptable—sometimes even expected—by concerned users, for web applications to behave more like websites, where everything is focussed by means of Tab.
This might be ok if the only possible interaction in your table is to select checkboxes, and if you provide possibilities to Bypass Blocks by offering landmarks or headlines. You should test it with some screen reader users.
For this to work, you would indeed only need to add tabindex="0" to the checkbox.
Then, again, the checkbox does not expose any other accessibility information, it’s an ignorant <div>. It should at least be:
<div role="checkbox" aria-label="Select row 5" aria-checked="false" tabindex="0">
See the Checkbox Pattern
All this might be possible, see Vuetify Accessibility (a11y)
Other Accessibility Criteria
Right now, you mention keyboard navigation. This is a great place to start with, since it is the foundation necessary for most assistive technology.
The Web Content Accessibility Guidelines (WCAG) are the reference to look for if you want to achieve compliance. Level AA (including level A) is the one recommended as a baseline.
But be aware that keyboard navigation is only one of 13 guidelines. Exposing state (checked, selected) to assistive technology, or getting contrasts right are examples for other criteria.
For web applications, it’s a good approach to advance the improvements based on critical paths in the story map, similar to an MVP, meaning that you would advance per process/task and make sure that each step in that process is accessible to the audience you prioritised based on the nature of the application.
Usability testing with people with disabilities is also a very good approach that can be applied in parallel, which centres the initiative more on the actual use cases.
I have this message in the Chrome console since I updated react-admin to version 3.10.0, I tried to dig into the document but can't find any information or example. Anyone encounter this, or luckily any members of react-admin seeing this, please help!
Edit or Create child components must be used inside a <SaveContextProvider>. Relying on props rather than context to get persistence related data and callbacks is deprecated and won't be supported in the next major version of react-admin.
I have a form component, using <SimpleForm>, that is used in <Edit> and <Create> components. There is no warnings when app is running.
But I have the same issue when unit tests are running on the form component. I tried to wrap it inside a <SaveContextProvider> without success... if someone have solution ! 👋
So if you encounter the issue during runtime you should verify that your form component is well wrapped as mentioned in the warning.
Very often I'm seeing that third party react native components don't provide granular access to changing their styles. On web we can target and style different parts based on their CSS classes. If a react native component does not provide enough props for changing styles, how to go about changing its styles?
It's common to me to read the third party lib code on github and then write a component that do the same thing but with my styles, Generally speaking it's not much complex depending on the library of course, for small libs it works very well.
It's only worth when the lib doesn't provide a way of overriding styles as you have pointed.
You also can see the style implementation of lib's main component and override it's styles, using JSS or styled-components lib.
I want to use Polaris css components for my shopify app. I have go through their document https://polaris.shopify.com/components/get-started#navigation. As mentioned there I have include their css and html code for a component but some components are not working functionally like Date picker I have put html code on my page but I am not able to change month, select date etc.
I think I have to load js for get that working but I didn't found any js link in their document.
Can you please help me out?
If you are using the CSS-only version, we do not provide any JS. The CSS version is meant for someone who does not want to use React and is willing to write the scripts required for any interactive components. If you are using the React components, you will not find everything; as you've identified, this is not exactly like Bootstrap or similar frameworks. This is a more selective set of components that encompass patterns that have been established for Shopify's own applications. We will probably add more components in the future, though; if there's something you feel is obviously missing, please feel free to leave an issue.
It's easy to get a reference to navigator in the renderScene function, so calling navigator.push(newRoute) is simple when responding to an event that happens from within the JSX tree.
In my case, though, I want to call navigator.push(newRoute) from an external event. My app signs the user in with Google and fires an event when the sign-in is complete, and I want to navigate to a new route in that case.
How can I get a reference to the navigator? Is there any way to get it besides as a parameter to renderScene?
You can get the navigator through refs property: https://facebook.github.io/react/docs/more-about-refs.html. It's part of react (not specific to react native). It's not obvious from the react-native docs that there is a number of 'react' features that can be used in react-native, so i'd really advise to take a close look at react in general.
Note however, there is a good reason Facebook does not mention refs explicitly and loudly. Refs is really not a "go-to" way of accessing component. Your case might be of course different, but it's likely that the Google sign-up is not in-fact "external". It might actually be part of one of the components in the hierarchy tree above the navigator (in which case you can pass the state change down the tree).
Quoting from the summary of the "More about refs" document above:
If you have not programmed several apps with React, your first
inclination is usually going to be to try to use refs to "make things
happen" in your app. If this is the case, take a moment and think more
critically about where state should be owned in the component
hierarchy. Often, it becomes clear that the proper place to "own" that
state is at a higher level in the hierarchy. Placing the state there
often eliminates any desire to use refs to "make things happen" –
instead, the data flow will usually accomplish your goal.
Again - your case might be different and using refs might be perfectly justified, but if you are tempted (for example) to separate out all the Google-related stuff to separate object and if that makes the sign-up "external" - think twice. React really encourages putting all things related to a "component" logic in one place (the component) - even if that includes various technologies and external APIs.