I have a form on my website and to show what the user needs to input I use placeholders. However, screen readers wont read that text.
I do not want to add a label to each input in the form because that doesn't fit the desired visuals.
What would be the best solution to still create this functionality, without changing the styling of the page?
I'm open for suggestions.
First option: Insert a hidden label that references the input field. It will not be visible on screen, but screen readers can access and read its content to the user:
<p>
<label class="class-to-hide" for="search">Enter search term</label>
<input type="text" id="search" name="search" />
</p>
Make sure, however, that the reference is intact (i.e. for == id), otherwise it remains unclear which element the label belongs to.
Second option: Use WAI-ARIA attributes to define labels that are only available for screen readers. This way there is no need to clutter the code with hidden elements.
<input type="text" aria-label="Enter search term" name="search" />
Additional advice: The placeholder, in general, is a bad option for visually impaired users. In most browsers the placeholder text is printed in light gray and has a low contrast, which makes it hard to read for partially sighted users.
Furthermore, the placeholder disappears once you enter text in the input field. That makes it hard, too, and may lead to misunderstandings, if you cannot actually see the site. Better use a descriptive labels for screen readers instead.
Related
I have 2 forms on one page having the same fields and labels. When I run accessibility check, it runs into an issue saying
Control labels should be unique on a page or be close to text providing context.
Controls with the same visible label need extra context (such as a heading) near the control to explain the differences between the fields. Note that the aria-label does not set the visible label.
Reference Link - https://www.powermapper.com/products/sortsite/rules/acchtmlformcontrolduplicatelabel/
The fields have unique for and id
FORM 1
<div class="form-field__item form-field__item--text">
<input id="whitepaper_signup_first_name" class="input form-field__input input--text" name="firstName" type="text" required="">
<label for="whitepaper_signup_first_name" class="form-field__label form-field__label--dynamic">First name</label>
</div>
FORM 2
<div class="form-field__item form-field__item--text">
<input id="homepage_lead_form_first_name" class="input form-field__input input--text" name="firstName" type="text" required="">
<label for="homepage_lead_form_first_name" class="form-field__label form-field__label--dynamic">First name</label>
</div>
Is there a way with aria-label or aria-labelledby?
This error appears to be more of a UI best-practice, as opposed to a WGAG failure. The idea is that the user needs to be able to differentiate between what you're asking for in each field.
If you are asking for the first name of the same person in both inputs, then there's nothing you need to do here and you can ignore the warning. If not, maybe you should update both labels to be more descriptive.
When navigating in forms mode, screen readers will not read any text around an input field. This includes headings and any adjacent text that's not part of the label element. For this reason, it's important that each label accurately describes what the user is expected to enter.
The advice to distinguish the accessible names seems to go beyond WCAG 2.1 Success Criterion 2.4.6.
However, if you want to prevent this tool from making this complaint, then you can accomplish that by changing the labeling mechanism. It is currently a label element. You can change it to an aria-labelledby attribute on the input element. That allows you to chain more than one element’s text content together as the label. Then one part of each label can be an element whose text content describes the form itself. That form-level label can be referenced by the aria-labelledby attribute of each control in the form.
If you address this issue in that way, you will still leave another accessibility flaw to be addressed. When you ask a user for the user’s first name, you are creating an input that is subject to WCAG 2.1 Success Criterion 1.3.5. To satisfy that criterion you can add an autocomplete="given-name" attribute to the input element.
I have a text input which requires the user to enter a password with specific constraints. The help text for these constraints are specified in a separate DOM element.
I would like the screenreader to read this help text when the user focuses on the input field. I have found two ways of doing this:
use aria-describedby="help-text-id" on the input text.
<label for="password"> Password </label>
<input type="text" aria-describedby="help-text" id="password" />
<span id="help-text"> The password should at least be 8 characters</span>
use aria-labelledby="label-id help-text-id" on the input text to read the corresponding label as well as the help text as label
<label id="password-label"> Password </label>
<input type="text" aria-labelledbyby="password label help-text" />
<span id="help-text"> The password should at least be 8 characters</span>
I like the first one because semantically this help text is something that describes the input, not something that labels the input.
I am just not sure if this is the right way to handle this. Are there any other patterns for announcing help text?
Also aria-describedby doesn't seem to work with ChromeVox extension, nor with windows 10 screenreader.
References: https://developer.paciellogroup.com/blog/2018/09/describing-aria-describedby/
You could always include the help text within the label associated with the input element. That would guarantee 100% compatibility with any screen reader/browser combination.
In addition to overall instructions, it is also important to provide relevant instructions within the labels of the form controls. For example, to indicate required input fields and data formats in the text of the labels.
https://www.w3.org/WAI/tutorials/forms/instructions/
You could even use CSS to offer this text only to screen reader users within the label, since this was the behavior you offered in your original examples.
Between the two solutions that you offered, I would go with aria-describedby as it offers a higher level of supported usage across browsers.
I'm looking for advices and feedback, as I can't decide what's the way to go.
I'm building HTML5 form and I want them to be as easy as possible to use.
That's why, I always used label to explain what to enter in a field, and placeholder as an example of a value with a good format.
So, my code always looks like:
<form>
<fieldset>
<p>
<label for="origin-field">Please enter your origin address</label>
<input type="text" name="origin" id="origin-field" placeholder="23th Street, New York City" required />
</p>
<p>
<label for="destination-field">Please enter you destination address</label>
<input type="text" name="destination" id="destination-field" placeholder="Ashbury Street, San Francisco" required />
</p>
</fieldset>
<p>
<input type="submit" />
</p>
</form>
This code is accessible, labels are linked to inputs using the for attribute, in short, it respects the best practices. It has other UX advantages: if the user clicks in the input and then is distracted, the label is always displayed next to it and can easily remind them what information the input is waiting.
However, my product owner and my designer deeply want me to remove the label and use the placeholder instead, so the code would be
<form>
<fieldset>
<p>
<input type="text" name="origin" id="origin-field" placeholder="Origin address" required />
</p>
<p>
<input type="text" name="destination" id="destination-field" placeholder="Destination address" required />
</p>
</fieldset>
<p>
<input type="submit" />
</p>
</form>
The two arguments are, it uses less space on screen / is more beautiful and also, users mistake the example value as something they could have entered and don't get why the field isn't empty (this is of course a contrast problem, the placeholder is light grey and should not be mistaken with a really value, in deep black, but eh, according to the PO, they do).
What should I do? Should I fight to try to keep the label in the design? If I put a display: none on the label, will it be still read by screen-readers? Should I put a position: absolute; left: -9999px; top: -9999px; instead?
What's the current best practice?
The official spec for the placeholder attribute specifically says to not use the placeholder as a label.
Warning! Use of the placeholder attribute as a replacement for a label can reduce the accessibility and usability of the control
There are lots of issues with placeholder text:
the text can be mistaken for content that's already entered
the text has insufficient color contrast
the text disappears when the input field receives focus
Many of these are cognitive issues, which is a huge area in accessibility.
Even if all of these reasons seem "silly" because you would never have any of these problems, you are not a representative sample of everyone.
Some alternatives are to have a "floating" label that appears "inside" the input field but when the field receives focus, the label floats outside the field. Brad Frost has a really nice example. CSS-Tricks has one but I don't like the aesthetics (but you could certainly tweak that). To see a live example, Discover Card uses them in their login area.
If you want instructional text to be associated with the input field, for example to show a date format (mm/dd/yy vs ddmmmyy vs whatever) or email format or phone number format, etc, the text should be visible on the screen and separate from the field but associated with the field via the aria-describedby attribute. For example:
<label for="phone">Phone number</label>
<input id="phone" aria-describedby="info">
<span id="info">(xxx)-xxx-xxxx</span>
Of course, from a general UX perspective, you shouldn't have input fields that the user can type invalid text. You should try to figure out what they typed and format it for them. There are lots of phone number algorithms for letting the user type whatever format they want, or letting them type a date in any format (although something like 1/2/18 can be hard to decide whether it's Jan 2 or Feb 1, but using locality can help), or using a "selector" widget to choose a date or a country or whatever.
Having just placeholder text instead of labels have some problems.
Placeholder text disappears when user starts typing in the input field. Then it violates SC 3.2.2 as there's no visible label or instructions.
When text is entered over top of the placeholder text, some Screen reader and browser combinations will populate the placeholder value as an accessible name in the Accessibility API when there is no other label in the code and some Screen readers don't. So they are not evenly supported yet.
Even if labels are provided as Screen reader only or Offscreen text, it benefits SR users, but having no visual label is a problem for users with Cognitive disabilities, low attention deficit etc.
One solution would be to use Floating labels. These are place holder text that moves out of the input field to become a label when user starts typing.
Answering your questions:
What's the best practice to create a modern form, accessible etc?
Especially, label vs placeholder fight
Use bootstrap and font awesome, if you combined them, you will get an awesome bootstraped form :) use form-group
What should I do? Should I fight to try to keep the label in the
design? If I put a display: none on the label, will it be still read
by screen-readers? Should I put a position: absolute; left: -9999px;
top: -9999px; instead?
What's the current best practice?
Same as before, use bootstrap an get the things done with less effort. Please forget that kind of things like hidding stuff on the DOM because that is not SEO friendly :(
Bootstrap
Fontawesome
I am currently working on an html form with proper disability access. I have inputs labelled by labels with the for-attribute. But now I want one input getting a different text for the screenreader than the label displays:
<div class="cc_form_w50 t5">
<label id="lbl_city" for="input_city">City / Town</label>
</div>
<div class="cc_form_w50 t5">
<input type="text" required name="city" title="City / Town" placeholder="Enter your city or town" class="w100" id="input_city">
</div>
The screenreader ready the "/" as symbol in the system language, so I want to make the screenreader "or" instead, like the title or placeholder. As long as I use the "for"-attribute or "aria-labelledby" the text of the label is read. Any "aria-label"-attribute is ignored by the reader.
Without the "for"-attribute the cursor doesn't enter the input by selecting the label.
Is it possible to tell the screenreader to read something else than the content of the label-tag?
There are two ways to fix it.
The first hides the '/' from screen readers (using aria-hidden) then adds visually hidden text that is read by screen readers. You can do a google search on the sr-only class. It comes from bootstrap but lots of other frameworks define it too. You can copy the definition of the class from this stackoverflow answer.
<div>
<label for="input_city">City <span aria-hidden="true">/</span> <span class="sr-only">or</span> Town</label>
</div>
<div>
<input type="text" required name="city" placeholder="Enter your city or town" id="input_city">
</div>
Another way to fix it (and this is a little simpler) is to hide the label completely (again, using aria-hidden) from the screen reader then specify an aria-label on the <input>.
<div>
<label for="input_city" aria-hidden="true">City / Town</label>
</div>
<div>
<input type="text" required name="city" placeholder="Enter your city or town" id="input_city" aria-label="city or town">
</div>
Both solutions still allow the mouse user to click on the label and have it move the focus to the <input> field.
I also removed the title (tooltip) attribute because it seemed overkill having a label, a placeholder, and a tooltip. Plus, some screen readers incorrectly include the tooltip in the name of the label when it's read, so sometimes you still hear the '/' in the label if you have the tooltip. (The tooltip is the last attribute examined when determining the accessible name of an element. See step 2I in the "Accessible Name and Description Computation")
I've seen lots of ways to label things in a form such as <label>, <div>, <span>, etc. Is there a right or wrong answer for this? Are there any advantages/disadvantages to any of these?
Thank You
Label is best for accessibility (tab order, screen readers, etc)
See more at:
http://www.communitymx.com/content/article.cfm?cid=02310
I tend to prefer this:
<label for="myInput">My Label</label>
<input type="textbox" name="MyInput" value="" />
Take a look at what Phil Haack thinks...
The proper way to provide a label to a form element is to use <label>:
Some form controls automatically have labels associated with them (press buttons) while most do not (text fields, checkboxes and radio buttons, and menus).
For those controls that have implicit labels, user agents should use the value of the value attribute as the label string.
The <label> element is used to specify labels for controls that do not have implicit labels
Since it is a semantic element providing meaning to your markup user agents can make sense of it and tend to helpfully direct clicks on the label to the element itself (very helpful for tiny controls like checkboxes). Also you're providing helpful assistance to people using screen readers or other accessibility features.
You shouldn't use <div> or <span> to actually label an element. For auxiliary help text, however, they might prove useful. But imho you should stick to the semantic capabilities of HTML where possible and sensible. This is such as case in my eyes.
The best way is this one :
<label for="anInput">This is the input</label>
<input type="text" name="anInput" />
This is especially interesting for checkboxes. If you click the label it will check/uncheck the checkbox. If you click on the label of an input field it selects it.
The tag defines a label for an
input element.
The label element does not render as
anything special for the user.
However, it provides a usability
improvement for mouse users, because
if the user clicks on the text within
the label element, it toggles the
control.
The for attribute of the tag
should be equal to the id attribute of
the related element to bind them
together.
via