So I read a lot of articles that say that HTML 5 form validation is accessible (things required attribute which will prevent the form from being submitted is a field is left blank), yet when I tested my form on NVDA on Chrome and BackTalk on Android, if I hadn't filled in the input, it focuses back to the input field (which is good!) but both screen readers announce "Please fill in this field" which is useless to the user, since they don't announce the label of the field.
So HTML5 validation alone isn't accessible? Also, can you combine HTML5 validation and custom JS?
Do you have to write custom client site validation in order to make forms accessible?
Short Answer
Yes the standard HTML5 validation is accessible and will pass WCAG2.1 AA, but you can do a lot better with some JavaScript.
Long Answer
If you need to support Internet Explorer 9 or below then you will need to use JavaScript (which according to WebAim survey - section "Browsers" still covers around 3.6% of screen reader users).
Native HTML5 validation is a very good starting point, but there are limitations (you gave one in a comment, some screen readers (NVDA) do not announce the label again, meaning a user has to physically ask for the label to be read via controls).
The other thing is that once you leave a field it doesn't normally tell you you have made a mistake until you have submitted the form (it is meant to but this is not always the case depending on your announce speed, settings and browser).
For example updating aria-invalid is useful for immediate feedback (and provides support for older browsers, while being more robust with 'unusual' screen readers).
Using an aria-live region to provide immediate feedback onblur (or throttled / debounced) is also useful and a better solution.
One other thing is that the native validation is not actually very effective. For example fff#fff shows as a valid email and will allow a form to submit on a type="email" field, same with type="url" it will allow https://fff to be submitted (in Chrome at least).
I could go on with other things such as providing better instructions on how to fix errors (especially for things like phone numbers) but you get the idea.
Basically, use as many native HTML5 features as possible to give a solid grounding and a good fallback for JavaScript errors / people not using JavaScript. Then use CSS and JS to improve the experience for everyone.
Also, can you combine HTML5 validation and custom JS?
You can and you should but be aware that you end up doubling up validation (which isn't a bad thing as I stated for fallback).
The beauty is you can use pseudo selectors in your JavaScript to target fields by type, saving the need for adding unnecessary classes etc.
e.g. document.querySelectorAll('input[type=email]') could be used to select any email input for validation or document.querySelectorAll('input[required]') to find all required fields.
You can also use things like max="100" on slider / numeric inputs to set your validation ranges 'on the fly' and still have a fallback for no JavaScript.
As you can imagine this let's you write a library if you can't find an off the shelf one that is reusable on nearly any form.
Related
I am creating a search form that has two elements an input field and a button. The input field does not have an label associated with it.
To make the field more accessible I can add <label for="searchfield">Search</label> and visually hide it so it will e.g. be accessible for screenreaders.
I could also add aria-label="search" to the input field and leave the input field without an label.
I have tested with "Voice Over" on a Mac and I get the same result/output. My question is are these approaches equivalent? Or is one approach better than the other one?
Here is a pen.
In the absence of having any knowledge of the site (how are other form fields labeled?) or the audience (what is their skill level or tech profile?), I approach these questions with a couple parameters:
The rules of ARIA (the first rule may apply here)
Progressive enhancement
That being said, I often code a page without ARIA and without CSS (as that may get blocked, chunked, etc) and make sure it is accessible.
That means I code a <label>. Then I visually hide it. If the CSS breaks, all is still well. If the user's screen reader does not support ARIA, all is still well. As an aside, if you think all screen readers of your users support ARIA, I encourage you to do to a tech assessment of users (local blind associations are a good start in the absence of any real users). Many people still run older versions of browsers and SRs.
For sighted users, I make sure I lean on contextual clues, like a clear search icon (or the word) in the button (as Unor references). Or maybe a placeholder with appropriate contrast (though you could use the <label> as a visual placeholder with some CSS trickery to hide it on focus).
If your submit button uses SVG, then I would be folding ARIA into that given the inconsistent support around SVG alternative text methods.
FWIW, I am also not a fan of the title attribute, partly because of inconsistent accessible name calculation and partly because I think it looks meh.
So, to answer your questions:
My question is are these approaches equivalent?
No, but the distance between them is shrinking.
Or is one approach better than the other one?
That depends on context we do not have.
Using aria-label is preferable to relying on CSS to visually hide a label element.
(Related Technique: Using aria-label to provide an invisible label where a visible label cannot be used)
But note that you don’t have to provide a label for a search form that only consists of the search field and the submit button. Assuming that you use a button labeled with something like "Search", it already makes clear which purpose the text field has.
(Related Technique: Using an adjacent button to label the purpose of a field)
In that case, while it doesn’t need a label, it should still get a name. One way to provide a name is to use the title attribute on the input element. The Technique Using the title attribute to identify form controls when the label element cannot be used shows this (a search form without label, with title attribute on input) in example 3.
I believe that aria-label="search" is the correct approach, as it produces cleaner markup (i.e. no unnecessary label tag) and no need for CSS to set visibility of the label - like in this example.
I believe visually hiding a label using CSS is a somewhat 'hacky' way to approach the problem, whereas ARIA is the standard for accessible markup, so it should be the obvious choice for situations like this.
On the other hand, it would be worth ensuring all browsers you intend to support can use ARIA correctly, and if not, it may be worth using the label approach to ensure compatibility across all browsers. Although, I think the support these days is pretty good, so that should not be a common scenario.
My question about AngularJs that I can't seem to google my way out of just yet has to do with the way Angular handles forms and form validation.
Ideally I want to make my form cross-browser compatible and use the 'Angular-way' of handling forms. Commonly one would set the novalidate attribute on the form tag because that disables any html5 related form validation the browser wants to do.
But, and this is the thing: does that also mean that Angular handles the way inputs of, say, type="email" and does the browser ignore them? Does Angular guard the fact that the user enters a properly formatted email instead of the browser's implementation of the input type="email" field? And thus does Angular mask the input as well?
I ask because there are several useful types (like email and url) that aren't strictly cross-browser, but I'd really like to make a universal form with Angular's goodies.
The answer depends a bit on what you expect your validation to do. Take the email field as an example. If you look at the quirks documentation you will see the automatic validation for the field type works in most browsers except for IE9 and Sarafi. Bringing angular into the mix doesn't change this at all so your standard validation isn't going to work in all browsers.
That said, Angular actually is binding the value of the field to a variable via model binding. So it doesn't rely on the browser validation entirely but actually provides its own validation. I checked this page, and even on Safari for Mac, the validation works excellently. Even with this in mind, I would still recommend opening the plunker and trying out what fields you need to validate on all browsers you really need to support.
One final thought is that Angular itself is no longer IE8 compatible. Although the team doesn't intend to break IE8, they aren't testing in it any more (See here for details). In other words - if you need really old browser support you are going to have to test that yourself!
I've been developing for some time now...every now and then I find out about more HTML tags, PHP functions etc that I never new I had at my disposal.
Today, I'm talking about the different HTML input types....well, only one and then some link->rel values...
Input type: search?
I have looked in several places and all I get is the obvious answer of what it's purpose is.
I can do fulltext queries just fine by making the field a text type...
so what's the technical difference between the text and search input types? and are there any benefits of using making the input field a search type?
And, I have similar misunderstandings with some of the rel values of the link tag:
Next, prev, search etc...
I can do the same things without using those rels...I can create a 'slideshow' of articles without using next/prev. search, i don't understand at all... I can only find the defeintion of it..'Links to a search tool for the document'...does this mean a tool like that which google provides so your users can search through a document?
I can do these things without using s altogether so I'm guessing the answer to my question is in the fact that I don't use for these tasks and maybe I should? Combine then with AJAX?
Thanks
At the moment, there are no differences between input type='search' and input type='text'. The reason these new HTML input types are put in place is so that functionality can be added later in the future. It's good practice to use type='search' when you are creating a search field, as it could become more useful in the future and it also makes your code more semantic.
There are really some differences are there between "search" and "text"
These two are rendered differently according to the browser. safari, Chrome like browsers adds a cross icon to clear the field more quickly than normal text field.
And in smartphones it changes the normal return button of the soft keyboard into magnifier or search button. which is more user friendly
some browsers will trigger certain applets while user is on a search field
HTML 5 defines a lot of new input types such as date, time, number, email, ... (you find a complete list here) which can be used by modern browsers to provide more functionality such as validation or support for input.
The browser can display a calendar for date inputs. On a touchscreen a different keyboard (containing #) is shown for an input field of type email or phone. For the search attribute an hourglass might be shown.
You should always use the new input types, as they provide more semantic information. An old browser will interpret them as <input type="text" />. A disadvantage is that different browsers display the same field differently and some browsers do not use the tags at all. For input type search a magnifier might be displayed.
Your second question is about link types. Again, this is semantic information mainly for search engines or user agents. The different link types might be displayed in a separate navigation bar.
There are several hidden form fields on my pages that are used for passing data to server side. For debugging purposes, I feel it easier to hide all eligible input fields by just making them all a part of hidden class than setting the type=hidden attribute on each input field.
Whenever I need to debug I could easily modify that class attribute to enter debug mode. Ofcourse both the approaches work in hiding the input fields but I am not sure as to why this approach(hiding via class) isn't much widely used in real life. Can you throw some light on what should be preferred approach ?
<input type="hidden"> won't trigger input validation, auto completion, and other user interaction related events. It's designed to save raw data, without user's direct input.
But a <input type="text">, visually hidden, are still going to be considered as a user interaction component. And on some devices enabled visual aid, it will serve as not hidden, and cannot provide the consistency you expected. That's why it's not preferred to do so.
Eg. a <input type="hidden"> won't auto complete it self, or preserve the inputted data before refreshing a page, or prevent the form from being submitted for a failed type validation can't even be seen.
The CSS approach is bad for usability, and accessibility. Think of someone with CSS disabled (very old mobile phones, people with a screen reader), they won't render your CSS as you might expect, and the input with all of its glory would be displayed to the user.
A hidden input should be used for implied user input, meaning, input that would come from the user, but is implied and does not need to be manually entered.
Your question falls more onto the type="hidden" approach.
I'd recommend using <input type="hidden" /> because it is the standard way of HTML to hold a user's input value. If you use another attribute for type and hide it with css, one problem may arise is that when the css fails to load, the input control will show up.
I think your question is about the best approach for debugging form fields. I recommend keeping them as type='hidden' in your HTML. This is best for you, for your users and for semantic interpretation of the page.
Instead, use a tool like the Chrome Developer Tools to do your debugging. This will let you easily see the values of your hidden fields.
In today's web applications where there are inline edits, enhanced by javascript etc, how do I markup forms. Eg. in the below web application Speckle
There are
input box for add task
check boxes for task stage
inline textbox to edit task
Is there a need to have a <form> element at all? Do I wrap the whole app with <form> or maybe I have multiple <form> for each inline edit like Speckle? But I don't find any <form> warping the checkboxes
this is a good question. given the nature of web apps tendency to deal in small/discrete ajax updates, then quite often a json object (or even a plain old javascrip array) might be serialized and sent to the server. This is great for client usability.
where the form will come into play is for scenarios where such an approach is not able to be used. many folk STILL keep their javascript settings switched off (for security reasons!!). thus, it may make sense to have the progressive addition of ajax functionality without forms in an environment where javascript is available and full page posts via forms where this isn't possible.
The trend will take some time to adjust before it can be claimed that the web is 100% javascript enabled.
horses and courses - of course... :0
<form> tag always comes with submit buttons. e.g. <input type='submit'> and <input type='image'>.
It is useful when you need to submit your data to somewhere (include this page itself), in which these data such as the checkbox values are handled.
If you don't need to handle this data at all, then <form> is just optional. But adding this tag will also benefit HTML semantic.