I tend to try and steer clear of using ID's outside of functionality purposes. Which brings me to my question, when labelling items in forms there are multiple methods. I have always done this a specific way to avoid ID's; however, what are the pro's and con's of the alternate methods? Does one way have more semantic meaning to the browser than the other? How does accessibility play a role in it?
My usual method of implementation:
<form role="form" action="#" method="post" name="form" novalidate>
<label>
<span>Search</span>
<input role="search" type="search" placeholder="Search" name="s">
</label>
<button role="button" type="submit" name="s-btn">Search</button>
</form>
However, you can also use for="" and label an ID for the corresponding field. Which is obviously better served for type="radio" and type="checkbox" but does it hold any better semantic value than the above?
<form role="form" action="#" method="post" name="form" novalidate>
<label for="s">Search</label>
<input role="search" type="search" id="s" placeholder="Search" name="s">
<button role="button" type="submit" name="s-btn">Search</button>
</form>
And you can even use WAI-ARIA to label as well with ID's, should this be used in cohesion with for="" or is it a stand alone labelling method?
<form role="form" action="#" method="post" id="Form" novalidate>
<label id="s" for="sf">Search</label>
<input role="search" aria-labelledby="s form" id="sf" type="search" placeholder="Search" name="s">
<button role="button" aria-labelledby="form" type="submit" name="s-btn">Search</button>
</form>
I guess this question is brought on due to the never ending pursuit of balancing maintainability, optimizations, semantics, and accessibility.
the two methods, nesting controls into labels (implicit) and using id and for attributes (explicit) have different positives and negatives, however the current trend i've seen from professionals is to move away from implicit and more into explicit.
explicit allows more flexibility within your document(s), and html5 allows form controls to be placed anywhere within the document, so they go hand in hand in this case.
implicit can't be used for checkboxes and radios, as the label element is required to come after the input form control, so there is one limitation. implicit also had poor browser support a few years ago, and seems to still have trouble with screen readers. implicit does add to accessibility and usability, because the label's size adds to the form control's clickable surface area.
wai-aria still isn't finished, and also has problems with browser/screen reader support, but that certainly shouldn't stop you from implementing it when possible. ideally, if not supported, it will simply fail silently (like html5 inputs do with non-html5 supporting browsers), but i would be wary here and test vigilantly. different supports can also have one screen reader/browser/user agent reading both, instead of seeking wai-aria, and defaulting to imp/exp labeling.
semantics: meh. ask 10 devs, you'll get 10 answers. but the correct answer is are you using that form control properly? is it labeled correctly? properly and correctly meaning will it validate and pass accessibility testing? properly and correctly also meaning, in your personal context, in this use-case, are you using the correct control/label for the interaction you are providing the user? only you can answer the latter...if you're using posh principals, you shouldn't have any problem with either.
side note: about avoiding ids, in this case, ids are optimal and they are being used for functionality...i'm assuming the form controls are being processed on submit? i could be wrong about functionality in regards to your intended use, but they are still optimal here, if you are avoiding them for wpo: you can use ids, just don't target them in your style sheets.
Related
With so many articles on the "proper," "semantic," and "accessible" use of forms and architecture, I'm rethinking how I approach forms. There are literally so many variations of what is "right" that I'm not 100% on what is really accurate anymore.
In an MDN article (here), it mentions:
With this example, a screen reader will pronounce "Fruit juice size small" for the first widget, "Fruit juice size medium" for the second, and "Fruit juice size large" for the third.
<form>
<fieldset>
<legend>Fruit juice size</legend>
<p>
<input type="radio" name="size" id="size_1" value="small" />
<label for="size_1">Small</label>
</p>
<p>
<input type="radio" name="size" id="size_2" value="medium" />
<label for="size_2">Medium</label>
</p>
<p>
<input type="radio" name="size" id="size_3" value="large" />
<label for="size_3">Large</label>
</p>
</fieldset>
</form>
Now, I can see the benefit of this for something like the example above, however, say I made a multi-step shopping cart, I wouldn't want assistive technology to speak "Checkout: cc-number," "Checkout: cc-date" using "checkout" prior to every label. Especially in cases where steps are labelled. This would be repetitive and sometimes confusing I would assume... But I've always grouped sections of a form within a <fieldset>. Now I'm rethinking using fieldset and legend at all, but does it now go against semantics? What's the trade-off? Is there a balance?
Additionally, and I'll use the same MDN article so I'm not sending you all over the web,
Note that even without considering assistive technologies, having a
formal label set for a given widget lets users to click on the label
to activate the corresponding widget in all browsers. This is
especially useful for radio buttons and checkboxes.
Some assistive technologies can have trouble handling multiple labels
for a single widget. Because of this, you should nest a widget inside
its corresponding element to build an accessible form.
<form>
<p>
<input type="checkbox" id="taste_1" name="taste_cherry" value="1">
<label for="taste_1">I like cherry</label>
</p>
<p>
<label for="taste_2">
<input type="checkbox" id="taste_2" name="taste_banana" value="1">
I like banana
</label>
</p>
</form>
Now, in this instance, the labeling for both these items are reasonably common, I have used both methods, but is there a balance between accessibility and semantics here? I tend to put the label not wrapping the input for consistency in code and I know their is strong debate on this subject (mainly the ability to drop the for and not need the id and/or having labels in different areas of the markup). So, I'm not trying to rehash the debate here, I tend to use the for and id regardless if I wrap elements in a label or not. But if there is an accessibility concern for one then why isn't the latter the golden standard?
Yet another point, WAI-Aria rules now contribute, so how much do these rules really impact the accessibility and semantics of a form?
<p>Required fields are followed by <strong><abbr title="required">*</abbr></strong>.</p>
<form>
<fieldset>
<legend>Fruit juice size*</legend>
<p>
<label for="size_1">
<input type="radio" name="size" id="size_1" value="small" aria-labelledby="size_1_label" />
<span id="size_1_label" required aria-required="true">Small</span>
</label>
</p>
<p>
<label for="size_2">
<input type="radio" name="size" id="size_2" value="medium" aria-labelledby="size_2_label" />
<span id="size_2_label">Medium</span>
</label>
</p>
<p>
<label for="size_3">
<input type="radio" name="size" id="size_3" value="large" aria-labelledby="size_3_label" />
<span id="size_3_label">Large</span>
</label>
</p>
</fieldset>
</form>
I'm really just curious whether or not there is a standardized method of approach when dealing with Semantic and Accessible markup. So far it seems people just do whatever they feel is right and then vocalize their thoughts all over the internet.
I've read through W3C's drafts and recommendations but even they use varying examples. Does anyone have evidence of what approach really improves accessibility and semantics in relation to forms? Are their any particular websites that have the time an resources to test this and draw an accurate conclusion that I'd be able to review?
The answer to your question really is "it depends".
All of the accessible markup you list above is valid. So if you are simply looking for accessible markup, you can use any of the examples. The rest of the decisions really come down to
error handling, and
additional instructions
Error Handling
When errors appear in your form, they need to be programmatically associated with the form fields that they reference. There are two ways to do this while maintaining the label itself:
Add the error to the label
You can add the error text to the label itself. Having a wrapped label gives you more flexibility over the order that this error text occurs in the DOM. you can place the error before the label, after the label, after the input or before the input. For this reason, you might choose to use the wrapping technique instead of the non-wrapping technique:
<label>My Input
<input type="text" aria-invalid="true" id="myinput" name="myinput"/>
<span class="error">The input field must be a valid username</span>
</label>
Associate the error using ARIA
The second technique is to associate the error using ARIA. This is very flexible because it allows multiple elements to form the label of the input and can also be used for additional instructions.
<label id="mylabel">My Input</label>
<input type="text" aria-invalid="true" aria-labelledby="mylabel myerror"/>
<span id="myerror" class="error">The input field must be a valid username</span>
Now if your input is a checkbox or radio button, you will want to maintain the for and id association so that the user can click (or touch) the label in order to activate the checkbox/radio.
Additional Instructions
As mentioned above, using ARIA labelling techniques, you can associate multiple elements with a single input field. This is useful for providing additional instructions and hints. aria-labelledby is used for the accessible name (label) whereas aria-describedby can be used for a hint and can also reference multiple elements by using multiple ids.
<label id="mylabel">My Input</label>
<input type="text" aria-invalid="true" aria-labelledby="mylabel myerror" aria-describedby="unameinstructions"/>
<span id="myerror" class="error">The input field must be a valid username</span>
<span id="unameinstructions">A valid user name must contain at least one alpha, one numeric character and must be at least 8 characters</span>
Here is a presentation I created on accessible dynamic forms http://www.slideshare.net/dylanbarrell/accessible-dynamic-forms-27169766 it references some example code that can be found here https://github.com/dylanb/a11yvalid and the running example of good best practices (except perhaps the CSS styling choices) can be found here http://dylanb.github.io/bower_components/a11yfy/examples/form-validation.html
<input type="search" placeholder="search" />
The screen reader ignores this when search field is focused! What attribute to be added so that the screen reader would say "This is a search box " Thanks.
The way to make it accessible is use text and markup around the input element rather than attributes. This way, you don’t rely on any specific support to some special attributes (which greatly varies across browsers). Example:
<form action=... role="search">
<h2>Search this site</h2>
<label for="q">Keywords:</label>
<input type="search" id="q" name="q">
<input type="submit" value="Search">
</form>
Then it is OK that the input field is spoken as a normal text field, since the user already knows it’s for entering keywords for a search.
If you are forced to play with small input box without a label, due to site layout requirements, then accessibility is inevitably reduced. You can try to help some users with some attributes that might get recognized and used by some browsers, e.g.
<input type="search" name="q" placeholder="keywords"
title="Keywords for a site-wide search"
aria-label="Keywords for a site-wide search">
Note: The placeholder attribute should contain text that acts a hint of the expected input, rather than a general name for some functionality.
Reference for role and aria-* attributes: Using WAI-ARIA in HTML (WD).
I've been a developer for a long time, however forms have always been my least favourite part, more specifically designing them!
I'd really like to know how you do you forms, and why. I've had a few discussions with fellow developers over <div> vs <p> on form fields. Which one would you stick with, and why?
An example of what I am talking about:
<form action="" method="post">
<p>
<label for="username">Username:</label>
<input type="text" name="username" id="username" />
</p>
<p>
<label for="submit"></label>
<input type="submit" name="submit" id="submit" value="Log In" />
</p>
</form>
VS
<form action="" method="post">
<div>
<label for="username">Username:</label>
<input type="text" name="username" id="username" />
</div>
<div>
<label for="submit"></label>
<input type="submit" name="submit" id="submit" value="Log In" />
</div>
</form>
When it comes to styling, it seems you can do pretty much the same with both, so is it just personal preference, or is there logic behind using one over the other?
Thanks for your time :)
UPDATE
I ended up following a nice article on HTML5 forms and have actually found it to allow MUCH better styling of forms. They are much more organised from a development perspective too. For anyone interested, it is located here: http://24ways.org/2009/have-a-field-day-with-html5-forms
HTML is all about semantics. There is no reason username or submit should be inside a paragraph (<p>) because it's not a paragraph.
So I would go using <div> instead. Ok, maybe <div> has no meaning at all. But it's better than <p>.
I prefer the <div> variant, because its semantics is closer on what you want to express and markup.
A <p> tag is for text paragraphs, whereas a <div> is a general block of any kind.
One option I'd like to suggest:
You could consider wrapping the input inside its label. That way you possibly can avoid additional elements. Also (if you don't need to support IE6) then this allows you to drop the for. And finally if the input is a check box or radio button, then it allows the user to click on the whole text instead of just the tiny control, just like in most operating systems:
<label>Username: <input type="text" name="username" /></label>
Also I'm not sure what the point of an empty label for the submit button is good for, except being lazy when writing the style sheet.
Just thought I'd throw my 2 cents in (assuming we all agree that semantic markup is the goal):
While one can argue that form elements themselves are not semantic, this doesn't mean that the context in which they appear is not as well. There is no "one true way" to markup all form controls.
If the control is actually appearing in a paragraph of text, that is fine - but that pretty much never happens.
If it is an ordered list of checkboxes for example, put them in an <ol> tag.
If order is not relevant, use a <ul> in that case.
If it is a label/text_input pair, one could argue that a <dl> element is appropriate
If it is a spreadsheet, use a <table> (Yes, tables can be appropriate! In fact, I've heard the (questionable) argument many times that form data is tabular)
By the way it is considered a description list in HTML5 to clear up confusion about meaning, and whether or not it's appropriate for things other than literal definition terms.
Almost no one will ever say a <p> is appropriate, but very few will argue that a <div> is inappropriate because there are no attached semantics.
Semantically, each label is bound to its control through the for attribute. There's no need to wrap the pair for semantic reasons, although you may wish to do so for styling reasons. So div is appropriate.
Similarly, grouping of controls has a dedicated element fieldset so there's no sense in using ul, ol or dl for that purpose, and using them is simply a form of listitis.
What about fieldsets ? - it is more logical for forms
And in fact you can style anything the way you want
Semantically I'd say divs make more sense simply because they have no semantic meaning and the only reason to use a block container like this is for layout purposes. That said, I use paragraphs, but completely out of habit. It's the only place I use paragraphs while not considering their semantic meaning.
I'd like to take advantage of the improved semantics of html5. I'm creating a search area, and the search area should have a background and contain search related things, like autocomplete and search hints.
Is there some consensus around what type of element something like a search area should be wrapped in?
Should it be a NAV because searching is a method of navigation?
Should it be a SECTION because it's a discreet section of the page?
Should it be a DIV because the wrapping of search related elements has no clear semantics?
The markup is something like this:
<?whatElement?>
<input type="search" placeholder="Search for a name or ID..." required />
Search
</?whatElement?>
Thanks for your thoughts.
I am aware this question already has a chosen answer, but it ranked so high in my Google search for "semantic search form" that I feel the need to contribute what I believe to be a slightly better answer, semantically and from a standards standpoint.
<section role="search">
<form action="#" method="get">
<fieldset>
<legend>Search this website:</legend>
<label for="s">
<input type="search" name="s" id="s" placeholder="Search..." maxlength="200" />
</label>
<button type="submit" title="Search this website now">Submit</button>
</fieldset>
</form>
</section>
Of course, I made a series of assumptions and populated the HTML with some default values (action, get, the id and name of the input, etc) and with no classnames for the elements (which I always tend to use in favor of generic element names or, Heaven forbid, IDs) but you should adapt to your own needs.
For example, some additions on top of the excellent contributions above: the first child of any form should always be a <fieldset> tag and have a <legend> attached (visible or not - https://www.w3.org/TR/WCAG20-TECHS/H71.html ), and all <input> tags should have a connected <label> tag through the for and id properties (https://www.w3.org/TR/WCAG20-TECHS/H44.html - I find it easier to just wrap the input in the label so as not to forget connecting them). All call to action elements should have a title (for SEO and usability, to reinforce the action the user is about to make just before she makes it), etc.
The HTML5 specification says this about the section element:
Role must be either region, document,
application, contentinfo, main,
search, alert, dialog, alertdialog,
status, or log
so I would use that.
How about:
<form>
<input type="search" name="" value="" />
<input type="submit" value="Search" />
</form>
<section role="search">
The role attribute is an ARIA landmark:
A landmark region that contains a collection of items and objects that, as a whole, combine to create a search facility.
So I've been reading a lot of "Designing with Web Standards" and really enjoying it. I'm a big CakePhp user, and as I look at the source for various form elements that Cake creates with its FormHelper, I see all sorts of extraneous
In the book, he promotes semantic HTML, and writing your markup as simple / generic as possible.
So my question is, am I better writing my own HTML in these situations? I really want to work in compliance with XHTML and CSS standards, and it seems I'd spend just as much time (if not more) cleaning up Cakes HTML, when I could just write my own
thoughts?
p.s. Here's an example in an out of the box form that CakePhp generates using the FormHelper
<form id="CompanyAddForm" method="post" action="/omni_cake/companies/add" accept-charset="utf-8"><div style="display:none;"><input type="hidden" name="_method" value="POST" /></div> <div class="input text required"><label for="CompanyName">Name</label><input name="data[Company][name]" type="text" maxlength="50" id="CompanyName" /></div> <div class="input text required"><label for="CompanyWebsite">Website</label><input name="data[Company][website]" type="text" maxlength="50" id="CompanyWebsite" /></div> <div class="input textarea"><label for="CompanyNotes">Notes</label><textarea name="data[Company][notes]" cols="30" rows="6" id="CompanyNotes" ></textarea></div> <div class="submit"><input type="submit" value="Submit" /></div></form>
EDIT: An in an indented form (indentation does not effect the standards compliance issue, but the above one-liner style is nearly impossible to read):
<form id="CompanyAddForm" method="post" action="/omni_cake/companies/add" accept-charset="utf-8">
<div style="display:none;">
<input type="hidden" name="_method" value="POST" />
</div>
<div class="input text required">
<label for="CompanyName">Name</label>
<input name="data[Company][name]" type="text" maxlength="50" id="CompanyName" />
</div>
<div class="input text required">
<label for="CompanyWebsite">Website</label>
<input name="data[Company][website]" type="text" maxlength="50" id="CompanyWebsite" />
</div>
<div class="input textarea">
<label for="CompanyNotes">Notes</label>
<textarea name="data[Company][notes]" cols="30" rows="6" id="CompanyNotes" ></textarea>
</div>
<div class="submit">
<input type="submit" value="Submit" />
</div>
</form>
In the above, there's those couple divs that seem unnecessary like the one that has inline CSS "display:none". I realized I can change classes and IDs of all the fields, but if I'm doing do that for each one, I might as well write the HTML myself...
My answers to your two questions are as follows:
Is CakePhp 'standards compliant' when
generating HTML, Forms, etc?
Yes.
In [Designing with Web Standards], he
promotes semantic HTML, and writing
your markup as simple / generic as
possible. So my question is, am I
better writing my own HTML in these
situations?
Sometimes you are better off, sometimes you're not. If your goal is to use minimal, semantic markup, you could be better off writing your own HTML most of the time. However, if your goal is to generate standards compliant HTML quickly, then allowing Cake to be what it's meant to be—a rapid development framework—is a good idea.
That said, you can tell Cake not to print some of its markup when you find it unnecessary. For example, you can suppress the div elements that wrap form inputs by using a value of false with this option: http://book.cakephp.org/view/1397/options-div
The markup output by Cake helpers is certainly standards compliant, as you can check at any time. What it could possibly be is simpler, but not much more so. The <div style="display:none;"> container with hidden input fields may be superfluous, but it's nicely grouping these fields and getting them out of the way. If you're using the SecurityComponent you'll find many more of these necessary hidden fields, which makes the wrapping <div> less superfluous. Apart from that, I have a hard time finding any really extraneous markup.
If you're not happy with the <div><label><input>[error]</div> structure, you can use the specialized $this->Form->label() etc. methods to produce only the input elements and wrap them in your own container elements. Just remember to include the $this->Form->error() as well somewhere.
I think the best way is to start prototyping your apps using basic $this->Form->input() groups of elements. Often these are perfectly serviceable in the final app as well. If during development you realize you need different markup than what Cake offers you, you can start transitioning to more custom markup. The one thing you should not do is write your own <input> elements, you should always use the FormHelper methods to produce those, since it's taking care of a lot of details that are a pain to reproduce properly by hand.
Apart from the FormHelper, I don't think there's anything to complain about in Cake's HTML markup, since you're writing most of the rest yourself.
According to the CakePHP book, the generated HTML is standards compliant.
You could override the default HTML output from the FormHelper methods by extending the Helper class.
More information here
Question already answered but maybe worth adding that this depends on which standards, and which version of CakePHP.
HTML5 form input types are not supported by the FormHelper in 1.2.x and 1.3.x, for example
echo $this->Form->input('User.email', array('type' => 'email'));
will output something like
<div class="input textarea">
<label for="UserEmail">Email</label>
<textarea id="UserEmail" name="data[User][email]"></textarea>
</div>
Apparently this will be fixed in 2.0.x.
Another edge case is if you have more than one form on the page with the same model you may end up with duplicate HTML identifiers.