Semantic input error message inside label - html

I'm using <label> to wrap an input such that its success and error messages can appear inside its label for association. What do you think is the most semantic markup for this scenario?
<label>
<b>Username</b>
<input>
<strong>Username already taken :(</strong>
</label>
For errors is strong appropriate? Or is span better? Is role=status appropriate?

The WCAG provides an example of error displaying using both aria-invalid and aria-describedby properties.
In your example, the code would be:
<label>
<b>Username</b>
<input aria-invalid="true" aria-describedby="error">
<strong id="error">Username already taken :(</strong>
</label>
The strong is appropriate as it appears to be an important notice. An alert role (rather than status) would be more appropriate to be applied to the #error element according to the W3C.

Using a strong tag is appropriate.
Strong tags signify something is of bigger importance, and the password being incorrect is important, as it blocks the user from proceeding.

Technically both elements can be used to create the appropriate looking error message that you are looking for (with the proper css). The most semantic, in my opinion would be to use the Strong tag, purely because I would want to stress the importance of a password being incorrect, without needing to use the font-weight:bold;in css.
Also since the question of accessibility is involved, the Strong tag is better for screen readers and in turn makes it more accessible.
Overall, I think its quicker, easier and better to use <strong>over <span> in this scenario.

Strong is good because "Username is already taken" is a serious notice rather than a casual one.

I'd suggest to keep it strong tag
and also make use of CSS red color to display it as an error.

Related

For accessibility, In html what should I use to label non form control data?

The w3c defines a label as:
The <label> element represents a caption in a user interface
It then goes on to say
The caption can be associated with a specific form control
Strictly speaking form controls are buttons, check boxes, radio buttons, menus, text input, file select, hidden controls or object tags.
My question is, in the interest of accessibility what is best practise for representing a caption for just plain read only information. I don't want to use an input, I only want to display. Should I just use headings? Is there anything in ARIA to help?
For example
<label>Primary question
<div>What should I use to caption plain old informtion?</div>
</label>
<label>Potential answer
<div>Just use headings</div>
</label>
<label>Date asked
<div>10/01/2016</div>
</label>
Headings could be used, as screen reader support is good for them. However the association of a heading with the content below it is implied rather than strictly designated.
From a semantic html stance a definition list may be preferable. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dl provides examples of definition lists where the dt and dd tags are used to associate key/value pairs which should meet your use case. Unfortunately screen readers do not necessarily expose the correct semantics of the definition list.
http://snook.ca/archives/html_and_css/definition-lists-v-tables provides examples of screen reader tests and finds the definition list support in screen readers deficient. That article recommends the use of tables with scope attributes on header cells, as a better supported solution.
If I take your example, you use a perfect understandable sentence. You have no need to format anything for a screenreader. Also you can use specific markup; this can targets both sighted people with visual aid, and blind people with specific intonations
Primary question: “What should I use to caption plain old information?”
Potential answer: “Just use plaind old text.”
<strong>Primary question</strong>:
<quote>What should I use to caption plain old information?</quote>
<strong>Potential answer</strong>:
<quote>Just use plaind old text.</quote>
In fact, the biggest part of your example is how you should write the date in order to make it clear that it's the 10th of january or the first of october.
Date asked: 10/01/2016
This is not helping accessibility and the best choice would be to use the full formal date:
Date asked: October <abbr aria-label="First" title="First">1st</abbr>, 2016
In the above example, I explicited the "1st" abbrevation both providing a tooltip and an aria-label for this commonly used abbreviation.
EDIT: To answer one of my favorite reader, you can understand why we chose to use the strong element to markup the question by refering to the W3C documentation for the b element.
The b element should be used as a last resort when no other element is more appropriate. In particular, headings should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element.
Here we want to denote importance in a text which is not a heading. Using headings to markup question can be applicable if the question text does convey information for the document structure (within a FAQ page for instance which might be the case here). But in a general context, for a single element, this is not applicable.
I wonder if textarea is suitable? I know I said I didn't want to use inputs but I wonder if the following is a good answer or not?
label {
display: block;
margin-top: 20px;
}
textarea, input {
display: block;
}
textarea[readonly], input[readonly] {
border: none;
}
<label>Primary question
<textarea readonly>What should I use to caption plain old informtion?'</textarea>
</label>
<label>Potential answer
<textarea readonly>use readonly textareas?</textarea>
</label>
<label>Date asked
<input readonly value='10/01/2016' />
</label>
<label>Editable comment
<input/>
</label>

Semantically appropriate input title and field tag

I have a form that lists the name of the input, the input, and possibly some help text. It is generally going to appear to be tabular, but I don't want to use a table or div because I imagine there is a more semantically-appropriate option by now.
Here is what it would look like without styles:
Name: <name input>
Address: <address input>
<address help info>
Phone: <phone input>
Notice how it all lines up like a table.
Any ideas for the most appropriate HTML for this?
Why is a table not semantically-appropriate if the data will appear tabular? Use a table, problem, solved.
Use dl. It got redefined in HTML5 so that it’s a "description list" instead of a definition list.
<dl>
<dt>Name:</dt>
<dd>…</dd>
<dt>Address:</dt>
<dd>…</dd>
<dt>Phone:</dt>
<dd>…</dd>
</dl>
If it’s a form with input, don’t forget to use label.
Note that it’s not "required" to use an additional structure, so a form like this is totally fine without dl/table:
<label for="form-name">Name:</label>
<input type="text" id="form-name" name="form-name">
<label for="form-address">Address:</label>
<textarea id="form-address" name="form-address"></textarea>
<label for="form-tel">Telephone:</label>
<input type="tel" id="form-tel" name="form-tel">
A real good question for which it's hard to find one correct answer. According to what I've found, either a table and div would be OK. Even though I would agree neither one of them feels like a real good solution.
Tables:
At http://www.w3.org/TR/html5/tabular-data.html#the-table-element it says:
Tables should not be used as layout aids.
...and...
[...] tables in HTML as a way to control their page layout making it difficult to extract tabular data from such documents.
But you're not really using tables for layout purposes here. You would be using it to present the form input data in a readable manner. As stated in the following sentence (also found in the table spec):
The table element represents data with more than one dimension, in the form of a table.
To me, that means it should be OK to use tables in this case.
Divs
Regarding the div the W3 spec says:
Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable.
But when reading the section spec it says this about the div:
When an element is needed only for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead.
To me, that means that you can also choose to use div for styling or layout purposes. I've tried to put togehter some thoughts about the use of div in this blog post: http://htmlusedtobeeasy.wordpress.com/2013/07/01/divisions-and-sections/
Sorry for the long answer (my first), hope it helps!

aria - multiline purpose

I read from this site [Site]: http://msdn.microsoft.com/en-us/library/windows/apps/hh968006.aspx
that aria-multiline is to provide the multi line attribute.
But when i applied to textbox, it doesn't seem to work. Can anyone please tell why. I have one more question, can anyone please tell me the difference between these two elements
<textarea rows="4" cols="50" id="text"></textarea>
<textarea rows="4" cols="50" aria-labelledby="aria-text-label" id="aria-text" role="textbox" aria-multiline="true"></textarea>
Thanks
ARIA attributes are declarative (informative). They inform browsers and especially assistive software what functional properties elements have, mainly due to JavaScript code that processes them, instead of making elements have functional properties. For example, if you used JavaScript to make a div element a multi-line input area, it would be appropriate to set aria-multiline="true" on that element. See the W3C WAI Primer.
Thus, the attribute is redundant for textarea (browsers can be expected to know what that element is). For input type="text" it could be used, but only if you have somehow managed to turn it to a multiline control.
The differences between the two elements presented in the question are:
They assign different id attribute values.
The latter declares a role attribute, which matches the default semantics and is not recommended in Using WAI-ARIA in HTML. (It is allowed, but it may confuse people who read the HTML source and mislead them into thinking that it has some effect.)
It also redundantly declares the element as multiline.
It additionally specifies that the element has a label, which is an element with id="aria-text-label". This is not redundant, but it is normally better, more accessible, to have the label declared in normal HTML markup, using the label element.
Have you read Remarks part of your link? Since textarea is multiline by default, so setting aria-multiline="true" will have no efect. This attribute sets what ENTER key do. In textarea and when aria-multiline="true" it will continue input to second row. But if you set aria-multiline="false" for textarea, it will act as <input type="text"/> - it will submit form on Enter key press and will not jump to second row.

Is it wrong to use paragraph tags for html for inputs?

So far I mostly put labels and inputs inside a dedicated paragraph tag :
<p>
<label for="myInput">Blah</label>
<input type="text" ... />
</p>
But this tag is made for text paragraph. Is is semantically right to use it this way ? Should a div be used ?
Semantically, no, it is not correct. Your form inputs are not paragraphs in any sense of the word.
If you're a CSS expert, try using <ol> and <li> tags and restyling them to look how you like, since your form fields are an ordered list of items. See A List Apart's article on Prettier Accessible Forms for an example of the HTML and CSS necessary for this format.
You seem to have nearly answered your first question, in that it is semantically not a paragraph, so the use of <p> is -to me- wrong.
The second question of whether or not to use a <div> depends on your useage, but I don't see why not, other than the increasingly bulky code, though that'll probably not add much weight to the page.
My own tendency is to nest the <input /> within the <label> tag, though this is, again, semantically incorrect since the input is not a part of the label, being only its counterpart.
Of course, both ways work and produce much the same visual effect; I've never used an alternative -speech-converter or such- to a GUI browser, so I can't say if it adds weirdness for disabled users.

Is there a legitimate use-case for putting a fieldset outside of a form?

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>