After a lot of theory and examples on what not to do, today we’re finally going to put our hands on some codes, seeing how to create an accessible form and with a standard code.
In most cases, in fact, the forms we find around don’t respect the accessibility rules regarding keyboard commands and they are usually paginated inside tables: it seems that even the most brilliant web designer in front of a form has a sort of block that inevitably forces him to imprison the innocent input fields inside useless and irritating cells.
Yet it’s possible, with much less codes and a couple of lines of CSS, to have a form without tables, accessible, standard, and if wanted also appealing… let’s see how!
Notices on the code
In the example I use xHTML Strict, therefore possible “headed” tags will be written this way
, in the same way the input fields will be closed and the checkboxes or the radio-buttons will contain the valorized checked attribute, so checked=”checked”; if you use HTML you should know that “<br> and <input…> get closed without the slash (/) and checked doesn’t necessary need to be valued; lastly if you use xHTML Transitional, you could write as you prefer (being this a more flexible language), even if it’s advisable the first syntax presented.
Know the tags of the form
Obviously a fundamental tag is the tag <form> that has as a required action attribute that you have to valorize with the URL of page that will process the data. If we try to put whatever type of tag directly inside the tag form we’ll obtain a validation error, exception for the tags
: as <fieldset> is a tag of the form, that collects in fact, a set of fields, we’ll use this.
At this point we can enter our fields <input>, correlated with their labels,which is that must be valorized with the id value of the corresponding field. By words it can seem a bit complicated, so let’s go and see a demonstration
The tag <label> can contain the input field like in the previous example, or be separated as follows: in both cases the code is valid according to the w3c standards.
For convenience, for setting the CSS style, I prefer the first alternative.
The label (the tag label) is important under the accessibility profile because it gets activated by clicking on the related input field.
We began showing the input tag mostly used, which is ; and deciding when and why is really easy: for all data in a string form as name, surname, telephone number, e-mail address and so on… let’s pass instead to other kinds of tag that sometimes can trigger a dilemma, beginning with checkboxes.
In this example (like in the next one) I used another fieldset (nested in the main fieldset) to group the inputs that form the answer and to exploit the tag in which to place the request.
To clarify the choice between checkbox and radio-button, we explain the differences: checkboxes are used to select none, one or more items (multiple choice) while the radio-buttons are used when you obligatorily can select only one alternative among the present (single choice).
For accessibility reasons it’s advisable to select a choice (checked attribute) when it is necessary to specific a choice like in the shown example. In this case we also added the name attribute, necessary to ensure that the two radio-buttons are connected and it is not possible to select them both. The name attribute is generally used to read data (for example with PHP).
The use of radio-buttons should be limited to cases with not a lot of possible choices, approximately with more than 5 options it is advisable to use the option menu – select (the so called drop-down menu).
Through the attribute selected=”selected”, we set an empty default option, in order that the user doesn’t find that he has “already given” an answer that in reality isn’t true.
In the case where the choices are really many, it is advisable to subdivide them in groups using the tag <optgroup>: eg. The provinces of Italy can be divided by region and thus making easier to consult the list (for obvious reasons, the example is limited).
There’s a possibility to use the select also for multiple choices: in this case the drop-down menu will be visualized opened showing the list of items (often by sliding the scroll-bar) and that can be selected by pressing the ctrl key or cmd and click; however the operation isn’t immediately clear (rarely used) and it’s not an accessible choice for persons with a reduced mobility as also just a click erroneously pressed can deselect the choices made till there, therefore even if the options are many in case of a multiple choice it is advisable to use checkboxes.
After that, we are interested in buttons as they can be inserted in two ways: either with the tag<input> or with the tag <button>.
are equal to
I prefer and recommend the second way, which is to use the tag button for a better setting of the CSS: in fact to give to the buttons a different style respect to the input fields we could use the pseudo-selectors or add a class, but having an apposite tag for buttons, why not using it?
Just to finish the presentation of the various tags that compose the form we still have the <textarea>, as the name suggests, is an area of the text (tag with an opening and closing, where rows=”” and cols=”” are obligatory, even if it’s possible not to valorise them); the tag <input type=”file” /> that allows to attach a file to the form uploading it from ones computer , the tag which obsures the text that is written showing only a dot corresponding at every typing to block the reading of other persons present in front of the monitor, lastly the tag <input /> that serves to pass hidden values to the user (less experienced).
Structuring the form
Now that we saw what tags to use and how to use them, we decide on the information that we want to ask in our form: name (text), surname(text), gender (radio-button), province of residence (select with optgroup), consent to the treatment of personal information (checkbox), personal message (textarea).
Making the form accessible and usable
Theoretically, to improve accessibility and the usability of the site, we have the accesskey attribute and the tabindex attribute . Let’s see what they are and why (or why not) to use them.
The accesskey attribute may be added to every active element of the page (anchor-link, input…) and it serves to navigate between them using keyboard shortcuts: like for all the shortcuts you have to press a key, alt or ctrl, different according to the browser or operating system and the letter or number chosen as the value of the attribute. If we valuate accesskey=”a”, pressing ctrl/alt + “A”, we would activate the related element.
We could choose, for example, to give to the accesskey “N” to the name field, “”S” to surname and so on.
As the relationship between the key and the element is a completely free choice, we should provide a user’s manual in order to know how to use the shortcuts. We also have to consider that always using the initial logic, some conflicts can arise: for example if in the menu we have a “News” page with the accesskey “N”, this will be in conflict with the “name” input field.
How come we don’t use it
This cam make us sleep peacefully at night , but the reason is that instead of simplifying the consultation of the contents , the use of accesskey seemed to complicated it.
As we have already said, the choice of the keys (letters or numbers) to use is completely free: this involves that we could decide to follow a logic for which we choose the accesskey on initial basis or according to the order of the contents in the page or following no logic. This means that there’s no standard and that the user should consult a manual each time he approaches a new site, also study it, instead of consulting it every time he wants to turn the page; sometimes it can also be very hard to find the manual that allows the navigation… so what should our user do? Confide in a lucky chance?
Apart conflicts withine the site, it isn’t infrequent conflicts with the shortcuts of the browsers (for example the fast keys to add a site to your favourites , search for a text in the page, save…) and that each browser behaves in its own way in terms of precedence.
In short, the use of the accesskey can create nothing but confusion.
The tabindex attribute as the accesskey, can be added to every active element of the page and it serves to navigate among them with the simple pressure of the tab key: its use in the form is very convenient , as for the compliance of the form is mostly an activity done via keyboard, therefore once one filed is completed it is much more simpler to pass to the next field with the pressure of the tab key. The valuation of the of the attribute is nothing but the order with which the elements are integrated – in this case activating the fields of the form to be filled in, in other cases to open the links – and it consists in an increasing number.
Unfortunately you may come across forms that badly manage the keyboard navigation, therefore pressing the tab key some fields get skipped off , this problem I greater when the form is paged inside a table (if we’re lucky only one, otherwise nested tables): if in fact the tabindex isn’t specified, at the key pressure, the following field of the code gets activated, that probably doesn’t match with the next one in the presentation.
Another problem probably is given by plagarized forms without effectively checking the code and therefore putting the inputs with the related tabindex in a random order, valuating only the id., creating an order that doesn’t have an order: I happened to see forms where one passes from the first to the second last field, then to the second, to the last, to the third, or having to press more than once to activate any other following field. When things like this happen to me, I personally hate the person that created the code and I resign myself to use the mouse, but the average user usually is frustrated and doesn’t understand what doesn’t work, handling a site that doesn’t respond as expected to the standard commands that he has assimilated . If then we talk about cases of users with reduced mobility, you can imagine…
Giving private information to various sites that form the net is one of the task mostly hated by users: the fear about the privacy and the awareness that probably they’ll start receiving more e-mails to throw in the trash, slow down the registration or the compilation of a form …if we then add all the difficulties that one can encounter during the compilation of a form created without the due attention, the mess is done!
How come we don’t use it
Now that I explained what’s taindex , you’re probably wondering why in our example there isn’t any.
It’s easily said: we don’t need it.
We don’t need it because the field to fill in are already in order: to present the form we’ll use the CSS and not tables that mix up the fields, making the page, among the other things unnecessarily heavy; in reality the markup is already all here, or almost.
If we were to use the tabindex attribute in this case all we should do is enter the numbers from 1, in the order in which the items are already succeeding.
Okay, but you told me that we would make the form accessible, so what should I do?
You’re right, but you know what the truth is? The form, as is, is already accessible.
In reality, it’s a just to give it a bit a style and to add a few more markups to make it appear as we like… and this is just want we’re going to do in the second part of this article!
In this article we took a quick look on the tags that make a form and we created it with a (x)HTML code , clean and precise, without nested tables, with no div and without a lot of useless markup elements. We have seen how the attributes that should help us create a more accessible site, in reality are not that useful compared to the benefits of a standard and optimized code.
Are you curious to know how you’ll transform this ugly duck in a beautiful swan (I’m talking about the form!!)?
And you, how do you handle the design of the forms? Do you use tabindex and accesskey, or you take in consideration other expedients? To you the word!
Original Post by: http://www.yourinspirationweb.com