Develop Reference

Screen Reader reporting of *valid* input after user change

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.

Populating Quick Type Bar Options on IOS Devices

I have an input type email.
<form>
E-mail:
<input type="email" name="email">
</form>
As soon as the user start typing, I would like to give them the option of most popular emails. Ex. #gmail.com ...
See the image below for details.
How would one go about and implement something like this?
Is there any plug-in or framework that help me achieve this kind of task?
Will HTML/CSS/JS have the ability to do that or only swift2 can ?

QuickType is part of the built-in iOS keyboard, and here is no way to access and/or modify it with JavaScript from a simple website. Unfortunately, you can't even detect the keyboard's height, and position some fake QuickType-like buttons over the keyboard, because the keyboard animates up from the bottom, over the current application without resizing or moving anything.
I'm afraid your only option is to add these as small buttons under the input, or maybe you can create something similar to the iOS copy/paste menu, that becomes visible, when the user starts typing in the input, and append the email endings on a click/touch.

I agree with #frzsombor, but I can think of a different workaround. It would take a lot of code though, so it might not be worth it. Anyway, what you could do is periodically take a screenshot and check for one of the colors on the keyboard in a certain position, maybe #ACB3BB (the return button color). If it is there, you could display another Quick Type Bar above the built-in one. The only problem would be if an update to iOS changes what the bar looks like, but you could always update your website. Another possible way to detect the keyboard is here. I think you need jQuery for that, though...

defaultChecked; why this property even exist?

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!

Read only textfield editable via inserted javascript?

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.

Is automatically assigning focus bad for accessibility?

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.