I have an application with drawer navigation that uses buttons to navigate to different screens.
In terms of accessibility, should I use accessibilityRole='button' or accessibilityRole='link' for the buttons.?
React Native AccessibilityRole docs say
link Used when the element should be treated as a link.
For external links accessibilityRole='link' is clearly the best option. But should I use it for internal navigation, too?
Note: I do not use deep links in my application.
Thank you for your help.
The Link component
renders a component that can navigate to a screen on press.
The Button component is a component that performs a certain action if the user presses it. A Button could be considered a Link if its onPress function navigates to a screen, by definition of the Link component. The Link could be styled to look exactly like a Button and vice versa. There would be no difference.
If we refer to general URL linking which includes deep linking, then we notice that the link functionality needs a UI component as well in order to function. This could be Markdown, the Link component or again the Button.
I personally would use accessibilityRole='button' for every UI component that is the actual Button component or functions (and 'looks') like a button in my application (TouchableOpacity, Pressable, ...), since this is what a user whose disability prevents him from noticing needs to know or wants to visualize. This includes the Drawer buttons.
I would use accessibilityRole='link' for text which is styled too look like a link (text with some highlighting) and navigates somewhere (this could be a website as well).
In general, I would keep in mind that the user wants to visualize the component. While a button, that navigates to a screen, is technically a link by definition of its functionality, it is not a 'typical link' when speaking of visual appereance (but again, we could style our button exactly like that...).
What is generally more important is the accessibilityHint which
helps users understand what will happen when they perform an action on the accessibility element when that result is not clear from the accessibility label.
The 'what will happen if I click' is certainly more important than 'what the component looks like'.
Related
I have been developing a Vue project and something caught my attention today. I used checkboxes with some sytling (I use them as toggle switches) throughout the project and thanks to these elements, I show or hide some elements and components. Toggle elements control specific data within each component. When the data istrue, some elements are displayed on the page and when false, they are hidden. What I noticed today is a little interesting. There is probably a simple solution, but although I have been searching the internet for a while, I haven't found a solution yet.
Here is the thing;
Let's say I am at the About page of my project. I used my toggle switches and now some of my elements and some sub components are displaying in the About.vue. Then I go and visit my Services.vue page and showing and hiding some elements and sub components as well. By the way, almost all of these pages have forms and I save these forms to local storage. When I return to My About page from my Services page, I see that the elements I activated have been restored. In other words, each component welcomes me with its default state when it is returned from another component. What I want to see is, If I go and check some checkboxes to show some element, No matter how long I roam between other routes, I want those elements to remain visible or hidden when I come back. For example, a toggle element must be activated to write a username and password on a component. After activating the toggle element, the user types the username and password and clicks the Save button. Then he continues to browse many areas of the project and when he returns, he sees that the toggle element is inactive and the username and password are not entered. I don't want it to be that way. How do I fix this?
you can use vuex for solved this problem.
https://vuex.vuejs.org/
Vuex is a state management pattern + library for Vue.js applications. It serves as a centralized store for all the components in an application, with rules ensuring that the state can only be mutated in a predictable fashion. It also integrates with Vue's official devtools extension (opens new window)to provide advanced features such as zero-config time-travel debugging and state snapshot export / import.
Above screenshot is a main body which contains a search and a sidebar component.
When I click on search drop down component, items appear and then when I click on an item, the sidebar will be updated. When the user clicks on a sidebar item (e.g. the close button) or unselects the item from the dropdown, it should disappear from the sidebar.
So now is it good to use $emit or scope-slot?
Better to use vuex if you are going to do more complex things in future but if you are planning to do the above implementation only then I think $emit is better since it is more simple than scope-slot (According to my knowledge).
Is this correct? I'm afraid it will read the word 'switch' twice to the user.
<Switch
accessible={true}
accessibilityLabel="Switch button"
accessibilityHint="Double tap to toggle setting"
accessibilityRole="switch"
/>
Many thanks in advance.
A couple notes on accessibility here:
As of 0.60, all interactive React Native components are accessible by default. (accessible=true)
Beware when using the accessible parameter. It will bundle any child elements into one accessible component and a screen reader will not allow users to select individual components when true. (You may need to override the default behavior because of this.)
Particularly with labels, remember to use full punctuation, or you may create unintended and overwhelming run-on sentences.
For UX, your label should read the purpose of the switch in a concise manner. Reading it without context, I have no idea what this toggle would actually do.
To answer your question:
You are correct that this setup would read out "switch button" twice, followed by the hint.
I tested the <Switch> component on an iPad just now with VoiceOver. By default, it is accessible and reads with a role of "button". Giving it a parameter of accessibilityRole='switch' reads with a role of "switch button" and automatically includes the "Double tap to toggle setting." hint.
The following component will read to the user as, "Airplane mode. switch button ... Double tap to toggle setting."
<Switch
accessibilityLabel="Airplane mode."
accessibilityRole="switch"
/>
accessibilityRole communicates the purpose of a component to the user of assistive technology.
For more information please find the below in official documentation
https://reactnative.dev/docs/accessibility#accessibilityrole-android-ios
I am using react-native, nested react-navigation, SectionLists, ActionSheet, etc and I am having hard times setting up a decent way of refreshing components / screens. As I have a few different cases, I have also tried different approaches with no luck.
Examples:
- Sending a callback function as a param in the navigator when transitioning from one screen to another for state change.
- Assigning AsyncStorage.getItem straight to a state variable (e.g: used on a ListView) and expect it to refresh.
I've seen many questions in the react-navigation git repo (mainly on how to refresh a screen), and recent suggestion to the project on the best approach for future releases, that got me asking if this is something that is in place already.
I can say though, that I've successfully used redux to check the connection state (NetInfo), that although I couldn't yet port the same idea to a different schenario, I think that it is my best approach.
At the moment I have one schenario, that if solved, I believe will answer a few questions I have. For example:
I have a list of news in my Home screen and a few options in my Drawer navigator that I would like to, when clicked, to sort the Home list, without having to call navigate('screen_name') as I would like to, to still keep the Drawer opened after clicked.
What would be the best approach for this ?
Thanks in advance!
One approach you could follow is:
On click on a DrawerNavigator item, you can dispatch an action which would intern change the state by a value. Eg: filterBy: . This store value can be passed as a prop to your home screen, which would intern contain a logic to filter based on that value.
I havent worked with DrawerNavigator but i feel onPress on each item in drawer navigation can be prevented and a action can be invoked at the same place.
I would like to know the best practice for implementing shared states between components in Vuejs.
Imagine situation A: you have a web app that shows a modal. The modal has the boolean state show. This state should change if the modal OK-button is clicked, but also if any part of the background is clicked, and perhaps even on some server pushed state change. Thus the modal should be able to change the state as should the parent app.
Situation B: you have a web app that shows input fields inside different components that share a common data value. If the user changes value through the field in one component, it should also update in the other. Again both should even update on a server push event.
Questions:
I am right that the correct way to go about this would be to use vuex and make the shared state a store field that is observed by and changed through emitted actions by all components / parents that need to modify that value?
Does that not introduce this kind of dangerous (since hard to handle) magic reactivity that we know from Meteor?
How to best document the flow, what depends on what?
A: For a modal component, I'd say that show should be a prop. So the parent component can control the modal whatever it wants. In this case there is no shared state at all.
The modal itself doesn't need to know anything about the server. If the prop show is true, just display the modal and vice versa.
I think the mask layer is a part of the modal, so when the mask is clicked, the modal emits an event. The parent component receives the event and can decide to hide the modal or not to.
Vue has an official modal example here (thanks #craig_h for mentioning): https://v2.vuejs.org/v2/examples/modal.html
B: Just bind the vuex state to the inputs. Nothing wrong.
Note that not all the components need to access the vuex store directly. For some pure UI components, just use props. So the parent components have the right to control them and increase flexibility.
I recommend you to read these docs:
https://facebook.github.io/react/docs/lifting-state-up.html
https://medium.com/#dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.j7ry4a3as
http://redux.js.org/docs/basics/UsageWithReact.html
Yes these are React / Redux docs. Since Vue is relatively young, react community has more documentation / articles. But both Vue and React are component-based libraries. The idea of how you design a component is basically the same.
You can also take a look at this vuex example: https://github.com/vuejs/vuex/tree/dev/examples/chat
This is a very simple example but it does use all the things I mentioned above. Emitting an event, some pure UI components...