Client-side validator for contact information form (name, phone, e-mail) My recent post had some things to fix. I think this should be well structured and written for you.

How does this code look to you? If something needs to be changed please tell me.

// Gets all elements by ID's
function elem(id) {
    return document.getElementById(id);
};
//


//Check box id"RadioGroup1_0" will be checked on start up of page (Phone)
window.onload = function () {
    document.querySelector("#RadioGroup1_0").click();
    //

//Gets my Form name (form) and on submission (submit) checks the rules below...

/* first name must be greater than 0
last name must be greater than 0
email must be greater than zero and follow the email reg ex
phone must be greater than 7 but shorter than 11
*/
    var form = document.getElementById('form');
    form.onsubmit = function (e) {
        var rules = [
        ['first-name', elem('first-name').value.length &gt; 0],
        ['last-name', elem('last-name').value.length &gt; 0],
        ['email', elem('email').value.length &gt; 0 &amp;&amp; /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-z0-9]{2,4})+$/.test(elem('email').value)],
        ['phone', elem('phone').value.length &gt; 7 &amp;&amp; elem('phone').value.length &lt; 11 ]

    ];


   //This is the (reqMsg) error, it follows the ID's listed above above and if there is an error it must be "inline" and if there is no error it will be "none",     
        var valid = true;
        var firstFocus = null;
        for (var i = 0; i &lt; rules.length; i++) {
            var parent = elem(rules[i][0]).parentNode;
            if (!rules[i][1]) {
                valid = false;
                parent.children[2].style.display = "inline";
                if (firstFocus == null) firstFocus = parent.children[1];
            } else {
                parent.children[2].style.display = "none";
            }

        }
          if (!valid) {
            firstFocus.focus();
            return false;
        }

        return true;
    };
};

// Using only alphabet keys NO Numeric for certain field boxes...
// First Name and Last Name
function onlyAlphabets(e) {
    try {
        if (window.event) {
            var charCode = window.event.keyCode;
        } else if (e) {
            var charCode = e.which;
        } else {
            return true;
        }
        if ((charCode == 64) ||
        (charCode == 32) ||
        (charCode &gt;= 65 &amp;&amp; charCode &lt;=90) ||
        (charCode &gt;= 97 &amp;&amp; charCode &lt;=122))
        return true;
        else return false;
    } catch (err) {
        alert(err.Description);
    }
}


/* isNumeric
*/

// This is for the phone field, only allowing NUMERIC numbers so no alphabets. It's referencing my above JS minimum 8 and maximum 10.

var specialKeys = new Array();
function IsNumeric(e) {
    var keyCode = e.which ? e.which : e.keyCode
    var ret = ((keyCode &gt;= 48 &amp;&amp; keyCode &lt;= 57) || (keyCode === 8));
    return ret;
}
Validation problems
Beware of overzealous validation. It's easy to create bugs by rejecting valid input. For example:

Some people have only one name, so the one of the name fields must be allowed to be empty.
Names often contain non-ASCII characters. Validation must not tell the user their name is invalid!
Email addresses can contain more characters than you think. For example, &quot;Hello, world!&quot;@localhost.localdomain is a valid address. The validity rules are complex, so if you try to implement them with a regex, you will get it wrong. Fortunately you don't need to reject all invalid addresses, only the most common mistakes. So /@/ is enough validation for practical purposes.
Phone numbers can be long, because of country codes and extensions. They can also contain characters like +-()x.

You can avoid these problems by not doing much validation. Don't do unnecessary work that creates bugs!
I wouldn't bother with the event filters at all, especially for the name, where any character should be accepted.
Style
onlyAlphabets should be called onlyLetters (it allows letters, not whole alphabets!), or onlyNameChars, since it also allows some other characters.
e.which ? e.which : e.keyCode can be simplified to e.which || e.keyCode.
This conditional...
if ((charCode == 64) ||
    (charCode == 32) ||
    (charCode &gt;= 65 &amp;&amp; charCode &lt;=90) ||
    (charCode &gt;= 97 &amp;&amp; charCode &lt;=122))
    return true;
    else return false;

...can be simplified to:
return charCode == 64 ||
       charCode == 32 ||
       charCode &gt;= 65 &amp;&amp; charCode &lt;= 90 ||
       charCode &gt;= 97 &amp;&amp; charCode &lt;= 122;

...but character codes are hard to read. It might be better to use the string form instead, via operations like String.fromCharCode and charCodeAt.
There are too many blank lines. It's OK to leave one blank line to separate sections (like a paragraph break), but (like anything that consumes lines) they reduce the amount of code that fits on one screen, they should be used only when they improve clarity enough to be worth the extra scrolling.