So I decided I'd better make my little survey form generator accessibility compliant. Doing this for single multiple-choice questions presented no problem, whether they used radio buttons or checkboxes, since each multiple choice was itself the label. But what about when an array or panel of questions all have the same multiple choices?
For example:
I have this code:
<tr><td></td><td>Small</td><td>Medium</td><td>Large</td></tr>
<tr><td>3. What size Coke do you prefer?</td>
<td><label for="Q3.1"></label><input id="Q3.1" type="radio" name="responses[0]" value="1"></td>
<td><label for="Q3.2"></label><input id="Q3.2" type="radio" name="responses[0]" value="2"></td>
<td><label for="Q3.3"></label><input id="Q3.3" type="radio" name="responses[0]" value="3"></td></tr>
<tr><td>4. What size popcorn do you prefer?</td>
<td><label for="Q4.1"></label><input id="Q4.1" type="radio" name="responses[1]" value="1"></td>
<td><label for="Q4.2"></label><input id="Q4.2" type="radio" name="responses[1]" value="2"></td>
<td><label for="Q4.3"></label><input id="Q4.3" type="radio" name="responses[1]" value="3"></td></tr>
My questions:
1.- The W3.org validator passes the code as valid, but is it really "accessible?" Will a competent web page reader interpret this correctly to a visually impaired user?
2.- If not, is there a way to have some kind of hidden label that the reader reads but that is not visible to the eye?
3.- If not, is it design decision time, where you either have this type of question, or you have good accessibility, but not both?
No, it is not accessible. A label element with empty content is useless or worse. It is worse than useless when the user, when focused on a control, asks for the label of the control and the user agent supports the label element as intended. It will then announce an empty string as the label, adding to the user’s confusion. (Accessibility checkers perform very limited testing. Most of accessibility issues cannot be checked programmatically.)
There are several ways to provide a “hidden label”, but this would cover only some of the purposes of a real label. A user who has no problem with eyesight may need to know what a radio button means, e.g. due to a cognitive disability. A different approach is to use the aria-labelledby attribute. In this case, you would need to specify id attributes for the elements containing the texts “Small”, “Medium”, and “Large” and use each id attribute value in aria-labelledby attributes for the radio buttons. But support to this is rather limited; this attribute would help a small fraction of users only.
It’s a design decision where you primarily need to decide on the type of controls and overall setup. The problem vanishes if you use a select element instead of each set of radio buttons. This might be unacceptable to people who think that on-screen forms need to imitate paper forms, or for other reasons. The problem changes its type if you instead use a text input field, expecting the user to type S, M, or L. This would have the potential accessibility problem that the user might not remember what the alternatives are, even when they were explained at the start of the form.
Without retracting the answer I accepted, I'm adding an answer because I've since discovered additional information that more completely answers my question. The issue was what to do in the context of accessibility in the case where radio buttons did not each have their own label. How to add labels that a reader for the visually impaired will see but that the unaided human eye won't see? Reasonably enough, the answer was to use CSS to hide the label from the latter but not the former.
It turns out that w3.org has a section on its website called WCAG (Web Content Accessibility Guidelines), and there I found technique H65, "Using the title attribute to identify form controls when the label element cannot be used." It specifically mentions a survey form, and it recommends using the title attribute.
Example 4: A data table of form controls
A data table of form controls needs to associate each control with the column and row
headers for that cell. Without a title (or off-screen LABEL) it is difficult for non-
visual users to pause and interrogate for corresponding row/column header values using
their assistive technology while tabbing through the form.
For example, a survey form has four column headers in first row: Question, Agree,
Undecided, Disagree. Each following row contains a question and a radio button in each
cell corresponding to answer choice in the three columns. The title attribute for every
radio button is a concatenation of the answer choice (column header) and the text of the
question (row header) with a hyphen or colon as a separator.
http://www.w3.org/TR/WCAG20-TECHS/H65.html
Ok, I hope this helps somebody. I've had so many questions answered on StackOverflow not because I posted them but because some else had the same question!
Your labels have no content, so non-sighted users won't know what the inputs represent. I'd put the small, medium, large text in the relevant labels and then visually hide the labels. Use the offscreen or clip technique, so screenreader software will pick it up but sighted users won't have to see it repeated for every question.
What you have done is fine.
You can make an input that has a value of hidden. Though I don't know what you meant by not seen by the eye.
<input type="hidden" value="whatever">
This can be seen by the server though not the user.
Related
Hello any accessibility gurus,
I want to have this button element, when tabbed on, would trigger the screen read of an input element instead.
I tried pointing the aria-labelledby from the button to the input, to have the input's aria-label being read out. But the button still reads out its own description, when tabbed on.
<fieldset>
<input type="radio" id="inputid" aria-label="read me">
<button aria-labelledby="inputid">don't read me</button>
</fieldset>
Is there a way to read another element's content?
Thank you,
2022-12-06 Edit:
Following Andy's comment, the input element is only visually hidden, so it was moved offscreen with css left: -10000px.
I believe aria-labelledby is not used according to the standards, which might explain undefined behaviour.
The Accessible Name and Description, step C mentions the following:
If the embedded control has role textbox, return its value.
That means that if an <input>, which has implicit role textbox, is used as part of an accessible name, not its label, but its value is used as the name.
Further, the ARIA standard on aria-labelledby reads:
If the interface is such that it is not possible to have a visible label on the screen, authors SHOULD use aria-label […]
The main purpose of aria-labelleby is to refer to part of the visible contents of an element like a <form> to label it. Most commonly, this would be a heading like <h2>.
The use case of this question is currently unclear to me. The example provided does not make sense with a single radio input.
If the <input> is completely hidden, visually and from assistive technology, why is it there in the first place? <input type="hidden"> would be the more correct input to use if the form data is needed
If it’s only hidden visually, both the button and the input can be focussed, which is terribly confusing. Does the input appear on screen once it receives focus?
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
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>
Hey a bit of an odd question..
I am building a web app and I want to make use of form inputs but in some cases I feel the form tag bloats the html. I know that a form tag is not required for validation or for the website to work. But in regards to accessibility does the form tag offer any semantic support for those users?
I have a button which will use the data in the input field so there is no use for submitting a form.
Also the tab index won't matter if there is only one input followed by a button..
<label>
Some Label: <input type="text" id="input">
</label>
VS
<form>
<label>
Some Label: <input type="text" id="input">
</label>
</form>
Elaborating a bit on my comment, it's probably fine to omit the <form> tag. Since you mention that there is both an <input> element and a <button> on the page, though, I can think of one possible scenario where the <form> tag could help. Presumably, sighted users won't have a problem making the connection between the <input> and the <button>, probably because of the visual layout of the page. If the connection between them is not clear except from the visual layout, however, then users with assistive technology might find the page confusing. In that case, you could make the connection between the elements explicit by wrapping both the <input> and the <button> in a single <form> and giving that form a <legend>. The text of the legend could elaborate on or otherwise clarify the connection. Since sighted users wouldn't need the legend, you could hide the legend from them (by positioning it offscreen, e.g. position: absolute; left: -999999px;) This seems like a pretty rare edge case, but perhaps it applies in your situation. Otherwise, I can't think of any good reason to include the <form>.
But in regards to accessibility does the form tag offer any semantic support for those users?
It could.
If you read one of the techniques for forms in the WCAG
(http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/G184), you will see that assistive technologies might enable the user to loop back to the very first text in the form to seek instructions when needed.
So if the user had this possibility (although i don't think it has been implemented), it won't find anything if there is no form tag.
This is not required. You might want to outline your form so it could be easily navigated to, i.e.:
<form id="myform" role="form" aria-label="My greatest form">
If you do this, then a screen reader user could easily navigate to the form with his/her region navigation keys. And he/she would easily know where the form starts and ends.
I reiterate, this is not required, it's just more comfortable for screen reader users. If, however, you don't want to attract their attention to the form as a whole, let this alone and do not follow this suggestion.
In-field labels are extremely popular now. They save space and look cool. There are many, many ways to accomplish them. It is now very easy to do using the HTML5 placeholder parameter for form inputs. You can even then create backwards compatibility with a bit of jquery if you want to.
But, is it semantically correct to use placeholder="Name" instead of <label>Name</label> or should a label element always be included and placeholder reserved to guide the user like this:
<label for="name">Name</label><input id="name" type="text" placeholder="Jane Doe">
If it's generally considered ok to use placeholder as either a label or an example, then that's definitely the easiest way to accomplish this effect. No javascript needed for modern browsers, no chance of submitting the label as the input value, etc. What are the semantic and practical drawbacks of doing this, if any?
The HTML5 specification explicitly calls this out. It says:
The placeholder attribute should not be used as a replacement for a
label. For a longer hint or other advisory text, place the text next
to the control.
Use of the placeholder attribute as a replacement for a label can
reduce the accessibility and usability of the control for a range of
users including older users and users with cognitive, mobility, fine
motor skill or vision impairments. While the hint given by the
control's label is shown at all times, the short hint given in the
placeholder attribute is only shown before the user enters a value.
Furthermore, placeholder text may be mistaken for a pre-filled value,
and as commonly implemented the default color of the placeholder text
provides insufficient contrast and the lack of a separate visible
label reduces the size of the hit region available for setting focus
on the control.
HTML5 spec notwithstanding, It's becoming popular to use the "Float Label Pattern". The label starts as a placeholder, but then moves up above the field once text has been entered.
There's a handy tutorial for it here....
http://webdesign.tutsplus.com/tutorials/ux-tutorials/implementing-the-float-label-form-pattern/