I feel that I'm being driven crazy by this question CONSTANTLY and I'm looking for more definitive answers to the idea as I can't find any information regarding this idea.
Normally a non-sighted user is (should be) presented with an accessible error when they have entered invalid information into a form. No problems there.
Is there any methodology or precedent to report form (field) validity from a previously invalid field to a non-sighted user when it becomes valid?
I know the former is typically handled by leveraging a javascript construct to manipulate the aria-invalid property to present an appropriate notification to the non-sighted user upon error, then removing that once the error has been resolved. Is the success of that only just dependent on the field no longer rendering an error or should there be an explicit notification to inform a non-sighted user that, in fact, "yes the field is valid"?
thanks again
Short Answer
When aria-invalid changes to false most screen readers will announce this, worst case they will announce it when the input is focused again.
There is nothing else you need to do to tell a screen reader user a field is valid as this is expected behaviour.
Long Answer
You do not need to do anything special here, but implementing aria-invalid in the correct way is important.
The field should start without the attribute, the last thing you want is every field saying it is invalid when it is empty on page load as this can cause confusion.
Additionally do not use this on required fields to indicate they need to be filled in as that is what the required attribute is for!
Then as the user types you update the value accordingly (so add it on first key press and then change it when the field becomes valid, aria-invalid="true" to aria-invalid="false" when correct).
Most screen readers will announce changes to aria-invalid instantly, worst case they will announce it when the field receives focus.
The key to accessibility is expected behaviour. It is expected behaviour for some screen reader users to refocus a field to check validity if their screen reader does not announce the aria-invalid change live. Sometimes you can make accessibility worse by trying to fix something like this as users get confused.
What is more important is making sure there are easy ways to know what errors there are on a form when a user tries to submit it and making it easy to identify and navigate to fields that need correcting.
I have tried not to stray from the question in hand but make sure you use techniques such as:
intercepting onsubmit on a form rather than intercepting the submit button key press when there are errors (as keyboard users will probably submit using Enter)
using aria-decribedby to provide additional information (and also more meaningful error notifications on a field)
placing all errors at the top of the form and the number of errors
using role="alert" or aria-live to announce the errors in the first place and explain what needs to be fixed.
If you really want to announce fields are valid
The above advice covers 99% of scenarios but I am sure there is an edge case somewhere that needs you to announce when a field is valid live.
As such you should use an aria-live region and update it with the current field validity (with some throttling so it doesn't flood the announce queue).
I would go for something like "first name - error - too short" and change it to "first name - correct" or "first name - valid".
As I said I cannot think of a scenario where this would be needed but that is how you could handle this.
Related
Taking JavaScript this semester. I cannot grasp how this property can be useful at all. This property gives a Boolean value of true IF the checked attribute was used in tag for the check box object...BUT if I am the one writing the program ...I should know if I wrote that into the program correct? I just do not see the logic in this property. Anybody have a better reason for the use of it?
First, to answer your question, "Don't I know?". Of course not. If you are thinking of a form that is only used to add records, I could see your point but forms are also used to update records and we have no idea what the initial value is for any given record that may need to be updated.
The next thing to understand is that the same concept applies to more than check boxes. For example the text input elements have a "defaultValue" property that parallels the logic of default checked property.
The next point, is these properties would be better understood by novices had they been named "initialxyz" rather than "defaultxyz". Novices think that they are used to identify what should be sent to the server if not populated by the user but that is not what they are at all. They are the initial value, as sent by the server to the client, before the user starts interacting with the screen.
To answer your larger question, these propertied are extremely useful in two cases. The first has already been mentioned which is the "reset" button or as I jokingly call it the "oops" button or "start over". That can occur at the record level that resets every element on the form but it can be used on a field by field basis where only the field that has focus is reset. For example, the escape key is often used for this purpose. The second use for this is to know if the form is "clean" (unchanged) or dirty (changed, in at least one small way somewhere). This is used in too commentary places that you did not think about. The first is to avoid submitting a form with no changes to the server. Why waste resources. The complementary is to pop up the "are you sure you want to lose your changes" when someone attempts to navigate away from a form with changes. You walk the form and compare the current valued to the initial value for each element. If no elements changed the form is clean and allow the user to leave without a prompt. If at least one element is different than it's initial value and take appropriate action which might be to prompt to confirm leaving or it might be to submit the form changes to the server before leaving or something that neither of us have thought of yet.
Hypothetically, you might have a form with lots of fields written in html, and you may want to have a "reset" button which resets all of the form fields back to their initial values. (I don't really know why that used to be a common form button, I've never seen a use for it...) The code to reset checkboxes would then be:
input.checked = input.defaultChecked;
which would be the same for all checkboxes, and then you wouldn't need to track the difference between default checked and no default checked ones separately.
Really though, it doesn't appear to have much use, and I've never used it before.
One scenario would be when you are creating checkboxes dynamically, on-the-fly, in your code. The creation may be dependent on a couple of parameters, some of them depending in turn on selections by the user, from the current screen/page.
You may wish to set what is the state of these newly created checkboxes by default, before the user performs any actions on them.
Exemplifying: Say you have a textbox where the user has to tell you how many new checkboxes you should create for whatever further actions. Then after the user enters the input, your javascript creates N checkboxes, accordingly. And their initial state is set according to "defaultChecked".
Just yesterday I found myself using this same attribute. It comes in very handy when trying to set certain values to default.
Have you ever signed up for something ad then found yourself receiving TONS of unwanted newsletters? or you install one thing and two more things start installing? This happens because there was an option somewhere with a checkbox that had the checked attribute to make that decision for you.
Mostly it is used to make decisions for the user. Comes in handy sooner than later!
BTW: Welcome to the sweet world of JavaScript!
We have an autosave and an explicit save for a particular form (it's a long form, and we don't want the user to lose data). For an explicit save, invalid data will block the save from occurring and an XHR will not be sent back to the server. However, for the autosave, we want the data to be saved (if possible) regardless of front-end validation.
What we need to have happen is, if the save is successful on the backend, the front-end should mark the form as no longer being dirty. But... and here's the sticker - it should not remove any validation errors/error messages from the form.
From what I'm seeing (or at least from what I understand), .$setPristine() will un-dirty the form, but it will, problematically, also remove validation errors.
Is there a way to un-dirty the form without removing the validation errors so that the autosave doesn't run when it's already performed a save, but so that the user still has the feedback of which fields are invalid so that they can fix the issues?
Thanks!
A form's $pristine/$dirty states are not connected to the $valid/$invalid states.
Your error messages shouldn't be removed (unless you use $pristine/$dirty in the condition that shows/hides the messages).
So, you can call the FormController's $setPristine() method in your autosave function, which will "un-dirty" the form, but will not affect the validation and error messages.
See, also, this short demo.
E.g.:
* In the fiddle above, enter something in one field (so it becomes valid and the form becomes dirty).
* The Save button gets enabled.
* Pressing the Save button sets the form's state to $pristine, so the button gets disabled (this simulates the autosave).
* The errors messages are still visible though (and the form's validity state does not change).
I have a form with a read only field for display/submit to the next page purposes.
However, I noticed using developer tools in Chrome, I was able to add an id to an element, use the javascript console to select that element, and change its value. I submitted the form and what do you know - the next page acted on it as if it was the original value.
Now, there shouldn't be any problem with the people using the site I'm building, but it seems like a huge security flaw to me. Isn't the point of read-only to remain constant? If a savvy user to change it around, doesn't that pose a big problem? In fact, I didn't even think you could add and change attributes in chrome.
Please post your thoughts below, and let me know if there's a solution ("disabled" textfield, but setting the disabled property doesn't send the data to the next page).
NEVER trust input from a web form.
The user could, just as easily, remove the readonly attribute and edit the value. The readonly attribute is only something to help the user when filling out the form, so they don't edit a value expecting it to change, when your server actually won't let it be changed. So, always remember to code the behavior on your server first, and have the HTML form be a helpful guide for users to make the form easier to fill out (without having to submit the form several times to get relevant error messages).
To overcome this, if something is readonly and you do not want it edited, you could store the value in your database. Also, values provided by users should always be checked (and sanitized) as no amount of JavaScript, HTML, or CSS is going to prevent someone who knows what they're doing from adding new or changing/removing existing values.
My web-based app allows users to override values in certain textboxes. If they don't override the value, the system will display (and use) a default.
I would like to support a scenario where the user has overridden the value, but now wants to revert back to the system default value, but doesn't know what value to enter. I would like to provide an intuitive UI for causing the system to revert the field's value back to its default. Does anyone have any suggestions?
Fields occur both on edit forms (where space is plentiful), as well as on edit grids (where space is scarce).
Requiring the user to clear the field is not an option, as sometimes the user's override is an empty value. Would rather not use a keystroke, like Ctrl-Z or ESC.
Best thing I can think of is the user hovers over the field and a popup displays giving the user the option to use the system default. I could use the same popup to capture/display a comment related to the override.
I've used a 'rewind' type icon after a textbox (like an arrow in a circle that points backwards) where there is plenty of space to allow a user to revert to the default or original version.
Also used grey text to show the default - which disappears (using a keyup event) as the user overwrites.
If space is short your popup sounds like a good idea.
How about
<input type="text" value="Enter text here, a space will clear it"
onfocus="this.title='Clear field to revert to '+this.defaultValue"
onblur="if (this.value=='') this.value=this.defaultValue;
else this.defaultValue=this.value" />
I always suggest to look at how others have solved a UX problem before deciding on an answer. Ask yourself what applications (web or otherwise) have supplied default values and allowed you to revert back to them.
I think the problem you're likely trying to solve is not the interaction of reverting to default values, but rather, to inform users what the default values are. If this is the case I would lean away from a button and towards inline help.
Hope this helps.
-
Nik.ca
If I have a form that is the main part of a page's content, will assigning focus to the first form field via JavaScript on page load have any negative effects on accessibility?
The short answer is no it doesn't make things inaccessible but it can make it confusing. The longer answer follows. Will your users know that there going to a page with a form, and does there need to be any descriptive text you should read before filling out the form? I'm a screen reader user and it can be annoying having focused put in random fields. It's clear why your focus winds up in the Google search box so that doesn't bother me. If my focus were automatically placed in the answer edit field every time I viewed a question on Stackoverflow I would be annoyed since I'd have to force my screen reader to navigate away from the form field and to the top of the page.
It might a bit, if we've got a keyboard user (either using a screen-reader, or just a habitual keyboard user) who's expecting to be navigating the links at the top of the page on first Tab press. For screen readers, you could also consider adding WAI-ARIA to add directions if users who don't expect to be dumped into the middle of a form.
If it's much more likely that the user's going to be wanting to type in the field straight away, then I think the autofocus is worth it. But for the reason above I wouldn't use it on every page with an input field.
If you do autofocus, make sure to do it right away, in a script as soon as possible following the input element, or in future using the HTML5 autofocus attribute. Don't do it as late as window.onload. It's annoying to have clicked the focus elsewhere only to have the document belatedly finish loading and steal the focus onto another element as you type.
A lot of sites will do this, google is a good example, the only issue is when you are typing something into the address bar, or into the search input in your browser, the action of focusing the form field tends to steal focus from where you are typing. It's a small nuisance.
will assigning focus to the first form field via JavaScript on page load have any negative effects on accessibility?
I can't think of any. In between fields might irritate whatever assistive software a user might be running, but the first field - hardly. I have no experience with braille and similar clients.
Seeing as even Google do it on their front page, I don't think it can be that big a deal either way.
Quoting MDN autofocus -> accessibility considerations (retrieved 9/28/2022):
Automatically focusing a form control can confuse visually-impaired people using screen-reading technology and people with cognitive impairments. When autofocus is assigned, screen-readers "teleport" their user to the form control without warning them beforehand.
Use careful consideration for accessibility when applying the autofocus attribute. Automatically focusing on a control can cause the page to scroll on load. The focus can also cause dynamic keyboards to display on some touch devices. While a screen reader will announce the label of the form control receiving focus, the screen reader will not announce anything before the label, and the sighted user on a small device will equally miss the context created by the preceding content.
To add some practical examples, at the time of writing, https://www.google.com autofocuses on the search box, while Wikipedia and Amazon don't. If typing into a search box is the sole purpose of the page and the risk of confusion is low, then it's worth considering autofocusing on it. Otherwise, probably skip autofocusing.
I wouldn't say so, fragments are an ingredient of HTTP and they set the focus of an *html page..
I wouldn't say so. A screenreader will probably not even notice this since it doesn't interpret the JavaScript on the page.
Another user which has a "normal" browser will get the advantage of having the cursor already at the right place which facilitates the navigation by using just the keyboard.