I have been busy making an interactive tab layout using only CSS and I've had someone tell me that this is not the intended semantic meaning of <input> tags. Now, I know that HTML5 focuses a lot more on semantics than previous versions of HTML did, so I was wondering, is something that does something like the following against the input semantics:
<label for="toggleTab" class="togglelabel">Toggle tab</label>
<input type="checkbox" id="toggleTab" class="toggleinput">
<div class="toggletab">Look at this thing hide and show</div>
CSS:
.toggletab, .togglelabel {border:1px solid #AAA;display:block;}
.toggleinput, .toggletab {display:none;}
.toggleinput:checked + .toggletab {display:block;}
(demo)
The standards[1][2] both say the same thing:
The input element represents a typed data field, usually with a form control to allow the user to edit the data.
So to me this seems like this is indeed against what the input tag should be used for (since this has nothing to do with data, but just with displaying certain things to the user or not).
And then of course my followup question would be, if this is indeed not what input tags should be used for according to the standard, is it bad to go against the semantics standards?
Well structurally this will be quite difficult. Inputs need go inside form elements, and if you are going to be using these all over the page, most of your page will be wrapped as one giant form, potentially will nested forms, for search bars, user input and the like.
As your quote says:
The input element represents a typed data field, usually with a form control to allow the user to edit the data.
The control you are suggesting isn't for editing data its for adding graphical user functionality. If you were to bing the input to a form, either by placing the input inline into a form, or using the #form attribute as your comment suggests, what exactly is the semantic of that form? If would have no action, it would have no site to post to, and if an accessibile browser were to try and render the elements of that form in a different way it would have no semantic content.
For the kind of hide/show toggle functionality, I'd recommend instead using an a link and hanging some javascript off that. As stated:
If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor) labeled by its contents.
In this context Hyperlink does not preclude the use of javascript as the acting force on the page, if it did most pages would be non-compliant to the spec. This is backed up by the first type of link suggested in the definition of hyperlink suggests that the link can be "used to augment the current document".
As a side note, in accessible browsers, inputs like these maye be rendered or presented in ways different to what you expect. Each form might be pulled out into a list of possible data editing options, and this would not fit the semantics of what a user might expect.
Semantics & custom behaviour
If the question is about which element has the least implied semantics, I reckon your best bet is the <button type="button"> element: the HTML5 spec describes it as « a button with no additional semantics» which, without scripting, « does nothing » — unlike the <a> element, which has implicit behaviour as a hypertext link and anchor.
The HTML4 forms spec refers to these as 'push buttons', which « …have no default behavior. Each push button may have client-side scripts associated with the element's event attributes ».
Furthermore, the HTML4 spec cites buttons repeatedly in its description of scripts: they are the only element referenced specifically in the introduction to scripts, although inputs also feature in the examples of DOM-event triggered scripts — however, as buttons are non-self-closing, they can contain other DOM nodes, which may make them more flexible depending on your needs.
Non-<input> solution
Using the push button, custom behaviour can be inferred by using data-* attributes for CSS selectors:
.toggleinput[ data-checked ] + .toggletab {
display:block;
}
…and scripted as follows:
// Use Array's forEach to loop through selection
Array.prototype.forEach.call(
// …of all `.toggleinput` elements
document.querySelectorAll( '.toggleinput' ),
function bind( input ){
input.addEventListener( 'click', function toggleCheckedState(){
// `dataset` is an object representation of data-* attributes
if( this.dataset.checked ){
// Remove the attribute if it exists
delete this.dataset.checked;
}
else {
// Declare it if it doesn't
this.dataset.checked = true;
}
}, false );
}
);
Forked code demo
Related
please , I need to know difference between area-placeholder and placeholder ? when area-placeholder will appear in input field
<input type="search" placeholder="Search" aria-placeholder="Search2" />
edit (added a deeper explanation)
ARIA labels are used to express semantics that HTML can't express on its own, i.e bridging areas with accessibility issues that can't be managed with native HTML. It works by allowing you to specify attributes that modify the way an element is translated into the accessibility tree.
for example, let's use a list item as a custom checkbox (the CSS class 'checkbox' gives the element the required visual characteristics.
<li tabindex="0" class="checkbox" checked>
Receive promotional offers
</li>
for sighted users, this will work fine, but a screen reader won't give an indication that this element is a checkbox, so users with low vision might miss this element.
using ARIA will give the element the missing information for the screen reader to properly interpret it.
there are many ARIA attributes, and if you plan on using them (you should!) i recommended reading more here
Aria-label allows us to specify a string to be used as the accessible label. This overrides any other native labeling mechanism, such as a label element — for example, if a button has both text content and an aria-label, only the aria-label value will be used.
A placeholder is a text that appears in the form control when it has no value set. The HTML placeholder attribute enables providing a sample value or a brief description of the expected format for several HTML types and .
If you are creating a textbox using any other element, the placeholder is not supported. That is where aria-placeholder comes into play. The aria-placeholder attribute can be used to define a short hint to help the user understand what type of data is expected when a non-semantic form control has no value.
<p id="date-of-birth">Birthday</span>
<div contenteditable role="textbox" aria-labelledby="date-of-birth"
aria-placeholder="MM-DD-YYYY">MM-DD-YYYY</div>
The placeholder hint should be shown to the user whenever the control's value is empty, including when a value is deleted.
The aria-placeholder is used , in addition, to, not instead of, a label. They have different purposes and different functionality. A label explains what kind of information is expected. Placeholder text provides a hint about the expected value.
ARIA is only modifying the accessibility tree for an element and therefore how assistive technology presents the content to your users. ARIA doesn't change anything about the function or behavior of an element. When not using semantic HTML elements for their intended purpose and default functionality, you must use JavaScript to manage behavior.
for a more detailed explanation, you can visit the aria-label page on Mozilla
I have the following input on a site I'm currently reviewing:
<input type="submit" name="executeSearch" value="" alt="Execute search" title="Execute search" class="iconButton searchBtn">
Through the class attribut the input button is replaced by an search icon.
According to accessibility is this the right way? Or should the value attribute be used? The screenreader I tested this element with (NVDA) was able to read the text ("Execute search button").
An empty value and an icon added via CSS to convey the only important information is a failure according to WCAG 2.0: F3 - Failure (…) due to using CSS to include images that convey important information
Simplest solution: use an input[type="image"], keep that alt="Execute search" ("Search" would be more concise IMHO), add an src="/path/to/img" of course and remove both title and value attributes. Image can be an SVG and can be encoded in base64 (ideal when it's light for performance reasons: that's 1 resource not to be downloaded).
That [type="image"] seems outdated because it was widely used circa IE6, way before RWD but it isn't (proof of concept with an 8x16 viewBox and width*height SVG: it scales®)
Otherwise you can use a button element with type="submit". This element can contain SVG, HTML images, text hidden to screen readers (better known as .visually-hidden, .sr-only or .element-invisible in Bootstrap, WordPress, Drupal, etc). That's what I use when a "submit" has both text and image or icon because no :pseudo with input and text-only through #value
Some notes on your current markup:
#alt should only be used with input[type="image"]
#value shouldn't be used with type image and otherwise should never be empty
#title should only be there (on links and "buttons") if it adds something to the existing information (like Subscribe ⇒ Subscribe to the newsletter or Edit ⇒ Edit something in particular)
According to accessibility is this the right way? Or should the value attribute be used?
An input[type='submit'] button does not accept an alt attribute
Some screenreaders may use the title attribute, but it's still useful for non screenreader users
Using the value attribute is the recommended approach for screenreader users
This is silly, but I'm about to explode - inputs, selects, textareas, checkboxes, radio buttons... what is the general name of this type of elements?
I'm creating an AngularJS set of form/input directives that wrap single form field in an object called "input", which consists of "element"-DOM, "scope"-Scope and I want to be able to extract its form element like input, select, etc., but I can't find a proper name for it...
They are called “controls” in HTML 4.01. HTML5 uses the same word, as well as the longer “form control”, but it has some more fine-grained terminology for “form-associated elements”. In practice, controls are often called “form fields”.
The use of “form” in the names is partly misleading, since controls are syntactically permitted outside any forms, too, and such controls can be successfully used when handled with client-side JavaScript.
They are called form controls or form elements or html inputs tags
I have a form within another form:
<form id="a">
<form id="b">
<input type="submit">
When the submit button is clicked, it seems that the outer form is submitted.
Is there a way to target which form is submitted?
No, nested forms aren't supported:
There can be several forms in a single document, but the FORM element can't be nested.
-- http://www.w3.org/MarkUp/html3/forms.html
The HTML DTD specifically forbids a form element from containing another form element:
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form -->
http://www.w3.org/TR/html401/interact/forms.html#edef-FORM
Like others have said...nested forms aren't allowed.
However, that doesn't mean some browsers won't do something with such. In the example that you have presented, the browser appears to be ignoring the second <form> tag in a similar fashion to how an unknown tag (i.e. <notAValidTag>) is also ignored. Since JavaScript also doesn't allow for embedded form collections, the best way to ensure that FormB's information is submitted is to make it no longer a nested form. This will break up your markup and UI into more distinct sections which may be beneficial from a UX perspective as well.
i think this is not allowed by the html standard.
In HTML 5, yes. Each input element can have a "form" attribute signalling which form it belongs to. However, it is still invalid to nest forms in HTML and HTML parsers won't allow this to happen.
However, it is possible to construct nested forms via JavaScript. In the absence of the form attribute, the rules for determining which form an input belongs to are quite complex, but they are described in full with an example at http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#association-of-controls-and-forms
Specifically, step 5 of Reset the Form Owner says:
Otherwise, if element has an ancestor form element, then associate element with the nearest such ancestor form element.
Clearly, "nearest" would not need to be said if form nesting was impossible.
Then step 4 explains how the required form can be targeted, by associating the submit button to the required form though the "form" attribute on the button.
If element is listed, has a form content attribute, and is connected, then:
If the first element in element's tree, in tree order, to have an ID that is identical to element's form content attribute's value, is a form element, then associate the element with that form element.
I was recently corrected, and according to the HTML4 DTD, it is legitimate to use a fieldset outside of a form:
http://www.w3.org/TR/html401/sgml/dtd.html#block
Previously I had not known this, and wonder if anyone can think of a legitimate use case for doing so. I feel like using one to decorate would be frowned upon by most designers. So is there a legitimate use case, or can you link to a site where this has been found appropriate and used as such?
I used a field set to decorate sections when printing documents. For example an invoice might have a Bill To and a Ship To, and drawing the frame around them with the legend text embeded in the frame can look really slick.
I think its more than legit to use it for decoration. Its simple and elegant and with the use of tag its pretty nice.
Check w3schools example out
I don't think there is a legitimate case to semantically have a fieldset outside a form element, since a fieldset is a set of (input) fields - the clue's in the name! If you have input fields, you will likely always have a form, even if you're not posting back to the server.
I have occasionally used from a presentational aspect, because the fieldset+legend combo is impossible to replicate exactly in CSS, specifically, the broken line behind the legend.
It is acceptable to use all form field control outside of a form element, including fieldset.
This is appropriate wherever you have fields that only talk to JavaScript, instead of ever being submitted back as to the server side.
(This didn't originally used to work in Netscape 4, but that's hardly a concern this century...)
Well, using it to decorate can be frowned upon by designers AND be legitimate, so there is a legitimate use case.
A form is simply a container for the fields you wish to submit via post back. Most regular site pages may not even have one. That said, using a fieldset as a styling tag is legitimate and has nothing at all to do with whether a form tag exists or not.
You can use a fieldset to wrap multiple form controls that you need to disable together:
<fieldset disabled>
<input type="text" placeholder="disableable input" />
<button type="button">Some action that needs to be disabled</button>
<button type="button">Some other action</button>
</fieldset>