We are currently working improve the accessibilty of a previously written site. We have a number of forms where the question/answers would be displayed like so:
<label for="answer1">Can you answer this question?</label>
<input type="text" id="answer1" />
(These can be fairly long forms, with a number of questions). We then have a set of pages that display the data that you previously entered and saved for these forms (using the same layout, effectively just replacing the inputs with text, something like this:
<label>Can you answer this question?</label>
<span class="answer">No</span>
Now, when I assess this page from an accessibility point of view, I get a number of violations, due to the fact that the labels are not associated with a control. I understand the point of this, and what I am wondering is what is the best way to layout these pages? Logically (in my mind at least), this is still a label for the answer, however I understand that this is not what labels are intended for from the accessibility point of view.
Ideally I'd like to keep using the labels, as it stops a requirement for duplicate styling for whatever we use, however I think we may need to go through and change this to something like this:
<span class="question">Can you answer this question?</span>
<span class="answer">No</span>
I can't find any specific advice on this (or at least am unable to narrow a search enough to return a pertinent result). I am looking for a way to lay this out in the most accessible fashion?
I'd mark that up with a definition list:
The dl element represents an association list consisting of zero or
more name-value groups (a description list). A name-value group
consists of one or more names (dt elements) followed by one or more
values (dd elements), ignoring any nodes other than dt and dd
elements. Within a single dl element, there should not be more than
one dt element for each name.
Name-value groups may be terms and definitions, metadata topics and
values, questions and answers, or any other groups of name-value data.
<h1>Your Answers</h1>
<dl>
<dt>Can you answer this question?</dt>
<dd class="answer">No</dd>
</dl>
The best layout (at least, for the blind) would be just to add a readonly attribute to the input. I.E.:
<label for="answer1">Can you answer this question?</label>
<input type="text" id="answer1" value="No" readonly />
I consider this ideal because blind people still could navigate the page with their quick navigation keys and quickly jump to edit fields.
You could look into some
<div class="thread">
<p>Can you answer this question?</p>
<p>No</p>
</div>
CSS
.thread p:first-child
{
font-size:18px;
}
.thread p:last-child
{
font-size:12px;
}
You could also use .thread label{ };
Not sure if this helps.
Related
I have a form that has a set of checkboxes. The user needs to check one or more of these. I'm confused as to how to deal with this via form validation and markup. I have an Error summary box that I can add a message, but my other form fields also have a message under each field that specifies the error, but since this is an issue with the set, I don't think that would be appropriate, so I assume just having it in the error summary box and being able to click on a link to the first of the set of checkboxes would be acceptable? Secondly, what about aria tagging? Would aria-required be appropriate? If so, how do you specify this for the entire set of checkboxes rather than each one individually, since none of these are required in and of themselves?
There isn't good markup to say a group of stuff is required but each one individually isn't necessarily required (although at least one is required). It's hard enough to express that in English :-)
With aria, you can sort of get around that.
<div role="group" aria-label="my list of checkboxes, you must select at least one">
<input type="checkbox"...>
...
<input type="checkbox"...>
</div>
aria-required="true" isn't allowed on the group.
A strange question, but I'm struggling over semantics vs accessibility vs appearance. Please note this question isn't related to CSS, but the underlying HTML5 code. Usually I wouldn't post this type of question, but this has really erupted into a debate.
I have a business statement on a website that defines why my organisation is the best (actually a sample statement...):
TL;DR What is the best HTML5 element used to display this, from a semantics/accessibility perspective?
Our initial guess was that a simple list would suffice:
<ul>
<li>Footballs:</li>
<li>Rounder</li>
<li>Better</li>
<li>Stronger</li>
</ul>
But then the argument is that sentence structure was more important, so perhaps:
<div>
<span>Footballs:</span>
<span>Rounder,</span>
<span>Better,</span>
<span>Stronger</span>
</div>
However, this approach then renders in the commas, which is unsightly. However, the counter-argument in my mind says commas should be there for screen readers...
We've even considered the DataList, but it doesn't feel quite right...
<dl>
<dt>Footballs:</dt>
<dd>
<span>Rounder</span>
<span>Better</span>
<span>Stronger</span>
</dd>
</dl>
Is there a specific HTML5 element that covers this type of statement?
You have a list of something (in this case, the benefits), and HTML offers four ways to convey this. You cover three ways, and the fourth is using ol, but this is only appropriate if the order is relevant, which doesn’t seem to be the case here, so we can ignore it.
Natural language
Just a sentence with punctuation:
<p>Footballs: rounder, better, stronger.</p>
You can add span element for styling purposes. And you could even visually hide the commas, but there is no need to go this way, simply use one of the markup alternatives instead.
Markup: ul
Having "Footballs" as part of the list doesn’t make sense. This "label" should be outside of the list.
<p>Footballs:</p>
<ul>
<li>Rounder</li>
<li>Better</li>
<li>Stronger</li>
</ul>
Markup: dl
The three benefits should either be a ul in one dd, or each one should be its own dd. There is a semantic difference, but it’s not a clear decision in this example case.
<dl>
<dt>Footballs</dt>
<dd>
<ul>
<li>Rounder</li>
<li>Better</li>
<li>Stronger</li>
</ul>
</dd>
</dl>
<dl>
<dt>Footballs</dt>
<dd>Rounder</dd>
<dd>Better</dd>
<dd>Stronger</dd>
</dl>
Which one to choose?
If you are fine with having and displaying the punctuation, go with the natural language solution.
If there should be no punctuation, go with the ul. It’s less complex than dl, and as you don’t have additional name-value groups, dl isn’t really "worth" it.
If you want to go with a list then write:
Footballs:
<ul>
<li>Rounder</li>
<li>Better</li>
<li>Stronger</li>
</ul>
Because Footballs is not part of the list footbals are. You my want to add Footballs into some h tags.
The elements of second one have no semantic meaning and would be as if you would write:
Footballs: Rounder, Better, Stronger
So it is correct, if you think commas are required.
The third one would be as if you write:
Footballs: Rounder Better Stronger
So if you think it is not understandable that way and commas would be needed, then you cannot go with this approach.
I would go with the ul li version, for the business statment because I see dl more in a dictionary like context.
I have a form in a few input fields. For one of the input field I have a length validation, for which I have used maxlength="20".
The issue here is that the JAWS users don't come to know that the max length has been reached in the input field, as JAWS continues to keep on reading the key they press on their keyboard.
Is there a way to make this accessible?
Regards,
Zeeshan
Three approaches, not mutually exclusive:
Include a statement about maximum number of characters before the element.
Implement a JavaScript-driven check on the number of characters when leaving the element.
Implement a JavaScript-driven check that is triggered by any input event on the element and that checks the number of characters on the fly.
Method 1 is simplest, but it might be too disturbing if we expect that in the vast majority of cases, the length is not an issue. Method 3 takes more programming effort than method 2 but provides for better accessibility: the user gets a message as soon as he tries to exceed the limit.
As #Quentin comments, this is really something that should be handled by JAWS. The maxlength attribute for input has been in HTML as long as it has had the element, from HTML 2.0 (1995), so there is little excuse for not having implemented it. I cannot check whether JAWS actually supports it, so I have written my answer assuming that it does not.
When the limit is reached you can detect that with JS and then announce it to assistive technologies e.g. screen-readers by insert the following after the <input/>
<p class="visually-hidden" aria-live="assertive" role="alert">Limit reached. You can only use 20 characters in this field.</p>
Note: remember to remove it if/when within the limit again.
You can hide .visually-hidden off-screen with CSS.. or this information could actually be useful for everyone so you could omit the .visually-hidden class if it fits your design.
And to let screen-reader users know about the limit you could put <span class=visually-hidden>Max 20 characters</span> inside your <label>
element. (and same goes here, perhaps all users could benefit from having that info visible..)
you can try it, mws-stat is your input field class name
<input type="text" class='mw' maxlength='20'/>
var a=$('.mw').attr('maxlength');
console.log(a);
and then
$('.mw').keyup(function(){
console.log($(this).val().length);
});
Use title attribute of the text field to convey the max length. It worked great for us on government project with users using JAWS. I believe NVDA also uses title attribute to convey the information. In addition you can use JavaScript to give audible "ding" to notify user that the field has reached the max limit.
You can do something like this
<script>
function show(){
var x=document.getElementById("text1").value;
var y=x.length;
document.getElementById("p1").innerHTML="Characters left" +(20-y);
}
</script>
<input type="text" id="text1" maxlength="20" onkeydown="show()">
<p id="p1"></p>
Here is the fiddle http://jsfiddle.net/EVrqP/1/
To get additional ID information (like the page name) about the page when it's submitted.
Thanks
No, it shouldn't matter, as long as it is within the form.
It must be within the form. It doesn't matter where, unless you do something like this:
<form>
<input type="text" name="data[]" value="value1" />
<input type="hidden" name="data[]" value="value2" />
<input type="text" name="data[]" value="value3" />
</form>
In this case the data array isn't associative, so the position of the elements does matter.
Similarily, if you'd traverse your POST / GET data with a foreach loop without paying attention to the array keys, you could get problems (but if you have an associative array, you should use the associations, especially in user input).
I mention these things just to make the answer more complete. In most cases the simple answer applies - position of hidden fields does not matter.
No. Values from an HTML form are mostly treated as being an associative array. To that end, the order in which the elements appear are of hardly any concern.
It matters in the sense that the order of data fields in submitted form data normally corresponds to the order of fields in HTML markup. You can see this easily if you use the default method (GET), so that the fields will appear in the URL.
There is no requirement on this; it is just how browsers tend to behave. Any robust form data processing does not count on any particular order.
I have sometimes observed browser rendering oddities that seemed to depend on the placement of hidden fields. It sounds weird, because hidden fields should not affect rendering.
I've read this and I GENERALLY use spans or strongs to describe "text-labels". Is this true for best practices? It seems is also a semantic way but why is it limited to just form elements?
What if I wanted to display information as this:
Name: FOo Bar
Age: 27
Weight: 151 kg
etc?
name, age, and weight can all be described as labels, but since the items they're describing aren't input tags, it isn't semantically correct(for html and w3c at least). I usually use
<span class="label"> or <span class="description"> or <span class="person-detail"> etc
but generally there should also be a tag for labels that don't pertain to input fields. As this might be a bit subjective I don't mind this turning into a community wiki or something
You should use a definition list (dl with dt and dd):
<dl>
<dt>Name</dt>
<dd>FOo Bar</dd>
<dt>Age</dt>
<dd>27</dd>
<dt>Weight</dt>
<dd>151 kg</dd>
</dl>
The spec states that it could be used for
terms and definitions, metadata topics and values, questions and answers, or any other groups of name-value data.
I think a table (with th) could be used, too. But I would only use it when I want to compare several people, not just listing the data of one person.
I'd avoid using a label tag unless it's in combination with a functional HTML form (with editable fields); otherwise, using it may be semantically confusing.
A span tag has no semantic meaning, regardless of the id or class added to it, and regardless of the context in which it's used. You don't gain anything semantically by using a span (though it does no harm).
A strong tag has a generic meaning (this content has extra importance) that doesn't vary based on the context in which it's used. It's sometimes useful when there's nothing else more appropriate.
In this particular case, a definition list (as suggested by #unor) seems like the way to go. If advanced styling is required, put each name-value pair into a separate definition list (which may be awkward semantically, but it allows greater flexibility with styling the content).
I guess if you wanted to be 100% semantically correct you'd have to use labels in conjunction with disabled or readonly text boxes that have been styled to look a bit different.