I've got a profile screen with a few simple text and radio button fields. I want to avoid submit button but instead autosave the value of the field onblur event. That approach is becoming more and more common but I am wondering how to resolve that from the accessibility point of view - especially for the text reader viewers. How to inform them that the fields have that autosave functionality in the most effective and convenient way? Should I just add approriate information in aria-label or maybe there is a better way to do that?
Related
This should be a really simple thing that for some reason I can get to work.
I have an MS Word document which has a drop-down field. If I double-click it - a dialog comes up to add or remove things from the drop-down field.
I just need to be able to get out of this mode so that the drop-down field behaves like it should from a user's point-of-view rather than from a design point-of-view. Basically I just need it to display the items rather than a dialog to allow me to add and remove the items.
According to what I've read, it looks like I should be able to do this by going to Developer, and then toggling the Design Mode button. This doesn't work; whether the Design Mode button is on or off I still can't get it to just act like a drop-down.
Thanks much
It sounds like you're using a legacy form field dropdown. For those to operate as a dropdown, you must protect the document for forms:
On the Developer tab, click on Restrict Editing. The Restrict Editing task pane opens.
In the task pane, check the box beside Allow only this type of editing in the document.
In the next dropdown, choose Filling in forms.
Click on Yes, Start Enforcing Protection.
Protected forms don't allow text to be edited in protected sections. In those areas, only form fields allow you to enter text. If that's too restrictive, look into Content Controls, which don't require document protection.
I am developing an application for the desktop with Flutter. I had to implement the form with multiple input fields. I really need to make the whole focus flow and I have used the FocusNode class to move from one input field to another. Everything is based on the submit event, so when I hit the Enter button on the keyboard it moves to the next field. It is pretty ok, but I have to change it from Enter key to Tab key which is more natural for the desktop users. Have you got any idea what can I do here to achieve such a result? Is there a way to trigger the submit event by different key (than Enter)?
This bug is for making it easy to bind keys to actions. Once that's complete, one of the intended use cases is to add tab support for form field navigation. There's been a lot of work in that area recently, so I wouldn't recommend putting time into working around this yourself.
I have a multi-page form, using a vertical tabs UI, in redux-form, and I'd like to track the current tab selection in the redux-form store.
What's the best way of doing this?
I would track the current tab selection outside of redux-form, but I've integrated redux-form with redux-undo, and I'd really like for undoing a form change to go back to the tab of the modified control.
I tried using a selected redux-form field, but this means that changing the selected tab marks the form as dirty.
From reading the docs, I could probably use reducer.plugin to add arbitrary properties to the redux-form store, but I don't see any documentation of which arbitrary property names are "safe," and I'd have to update the plugin for every form that should behave this way.
Any ideas?
What is the efficient way to validate a form in iPhone? Basic validation like if the all required textFields are filled and some validation for email and phone.
Is there way to show all the error once the submit button clicked? (I'm basically highlighting the textField red)
Any help?
You could actually show the validation before the submit button has been tapped, by using the UITextField delegate methods.
So to achieve this you would just use the textFieldDidEndEditing delegate method (documented here) to detect when the user had moved from one text field to another, and then you could immediately highlight a field red if it didn't pass your validation test.
This is a nice approach, because the user immediately knows their input won't be accepted, which can save time and frustration.
There are obviously lots of different approaches to your question, so it's really a matter of visual preference and/or style, but definitely consider doing 'in-line' validation as described above.
I am trying to find the most usable/accessible way to implement a simple form dropdown list which will sort a list of products by pice and alphabetical order.
In your opinion is the dropdown more usable when there is a button that governs its submission or when it automatically submits onchange of the dropdown?
The research I have read is both for and against such methods and there is a variery of implementations on the web so interest to hear the thoughts of the community.
Thanks in advance
As a blind computer user either method works fine. I find that having a button to click is slightly easier for me then the onchange event firing. I wouldn't say it's a big enough difference to take into account though assuming the majority of your users will not be disabled. If your targeting specifically blind users I would not use the onchange event.
So long as you do not change focus or navigate to another page when the selection changes, either approach should work. The classic example of a problem dropdown is where it contains a list of other pages on the site, and navigates as soon as the selection changes. This prevents a keyboard user from using the list; they can't browse it, and can't navigate to any pages beyond the first selection, since it's impossible to navigate past those. So in cases where focus changes or the page navigates as a consequence, having a separate action (eg. Go button, or handling enter) to cause the navigation to take place is essential. This is likely where the advice you've read is coming from.
In this case, however, it sounds as though you are just updating content elsewhere on the page, and not changing focus or doing navigation. Simply resorting existing content should be fine.
Depends on your users and their respective expectations and the context in which it's presented.
As a blanket, general statement, you should have the drop down accompanied by very obvious submission button. That is the safer approach.
If you are refreshing page data or if the focus moves away after the dropdown option is selected, you should use a button to be accessible. If you fire the event on change, blind or keyboard-only users will not be able to use the dropdown menu at all if they are on windows with ie and chrome (so added together, a majority of the people on windows). As soon as they use the arrows to scroll down and make a selection, the first option they hit will be selected and the page data will refresh or the focus will move, making it impossible for them to navigate or select the second option, third option, etc. Below is a thorough explanation with examples so you can see what I mean.
Designers definitely don't like the buttons, but if you are blind and on chrome/ie, it is impossible to use a lot of dropdowns without it. I'm guessing Jared uses firefox or a mac.
http://pauljadam.com/blog/javascript/onchange-event-on-a-select-inputjump-menu-accessibility-problems/