I have a search field that does not (visually) require a <label>.
I add a title attribute on input to reminder (with the tooltip) the field description. The submit button has offscreen description to explain its function. [Q1] : Maybe it would be better to use an aria-label here?
[Q2] : To be compliant, do you always have to provide a label even if it means removing it from the screen via the sr-only class or it's not always necessary?
<div class="field field-search">
<form action="" method="GET">
<button type="submit" class="btn-search">
<span class="sr-only">Search</span>
<svg class="icon icon--search" aria-hidden="true »>…</svg>
</button>
<input title="Search in events" placeholder="Search in events" id="search" type="search" name="search">
</form>
</div>
[Q2.1] Same question for those fields where the user must add links.
Is a title on the input sufficient or a label is mandatory? If so, can I also set it to "sr-only"?
<form method="post" action="">
<ul class="social-links social-links--inline">
<li class="social-links__item">
<div class="social-links__icon">
<svg class="icon" aria-hidden="true »>…/svg>
</div>
<input title="My website" placeholder="My website" id="website" type="text" name="user_website_url">
</li>
</ul>
<br>
<input aria-label="Save links" type="submit" value="Submit">
</form>
There are two kinds of answers to this:
What do I minimally have to do to be accessible
What's the best user experience
From a minimal perspective, what does WCAG require? Remember that WCAG is a baseline. Just because you pass WCAG does not mean you have a pleasant user experience.
WCAG 3.3.2 says your input field needs a label, but that label does not have to be a text label. It can be an icon, provided the icon has an accessible name so that it can be associated with the input field.
So in your search field example, having a magnifying glass to serve as the input field's label is ok. It's generally accepted that that icon means search. But there could be some users that are not familiar with the icon so having a real text label would benefit them. Is the text label required (by WCAG)? No, but it's a better user experience.
With your other link fields, those icons may or may not be recognized. YouTube and Twitter might be reconigized but there's a chance the person filling in the fields is not a social media person so they might not know what the icons mean. Does having the icon pass WCAG? Yes. Is it good for the user? It depends on your target audience. If your page is intended for people who are social media savvy, then it's probably ok. If the page is meant for people in general, then it might not be sufficient.
Remember that the placeholder attribute disappears as soon as the user starts typing so the visible label provided by the placeholder won't be visible anymore and could be confusing for some users.
From a user experience perspective, I would recommend both an icon and a real text label. For the text label, you can make it a "floating" label.
Float Label Pattern
Avoid Placeholder Text by Animating Form Labels
Testing Placeholder Method
Related
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.
I'm working on an HTML form for a web app. I'm adding the enterkeyhint attribute to indicate and navigate to the next input until the last one submits the form.
The problem is that enterkeyhint doesn't navigate to the next input if its type is type=text.
This happens on Chrome/83.0.4103.101 for Android 7. In Safari the hints button appears but they all do nothing.
Example:
<form (submit)="submitForm()">
<div>
<label>Name</label>
<input type="text" enterkeyhint="next" inputmode="text" />
</div>
<div>
<label>Email</label>
<input type="email" inputmode="email" enterkeyhint="next" />
</div>
<div>
<label>Comments</label>
<input type="text" />
</div>
</form>
Focusing on Name input, the Next button doesn't do anything.
Focusing on Email input, it navigates to any next input (Comments)
Now, if I change the type=email for type=text it doesn't navigate to the next input.
Similar behavior happens for type=tel. It does navigate to the next input of the form.
Am I missing something to make this work?
Thanks
enterkeyhint is just a hint to the browser what to display on the virtual keyboard, but you need to implement the actual behaviour yourself. See for example Focus Next Element In Tab Index, or How to focus next input field on keypress if your DOM is simple enough that the input fields are siblings with the default tab order.
From the spec:
The enterkeyhint content attribute is an enumerated attribute that specifies what action label (or icon) to present for the enter key on virtual keyboards. This allows authors to customize the presentation of the enter key in order to make it more helpful for users.
There is nothing in the spec to suggest that enterkeyhint actually affects the behaviour of the Enter key.
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 just noticed that even Google doesn't use a form to wrap their input fields. I thought this was bad in terms of accessibility because screen readers then won't know what it is?
From a pure screen reader perspective, having a <form> is a way to group a set of controls together and works best if you specify a label for the form, such as <form aria-label="contact info">.
If you have a simple search field, and presumably an associated search button, then a <form> isn't necessarily needed. However, you should nest your elements in a search landmark by using role="search".
<div role="search">
<input aria-label="search term">
<button aria-label="search">
<i class="magnifier"></i>
</button>
</div>
It looks like the literal, "search", appears a lot in that code fragment, but the only time "search" has to appear literally is the role attribute.
The aria-label for the input can be whatever string you want. It's what will be read by the screen reader when focus moves to the field. If you have a <label> for your <input>, then the aria-label is not needed.
The <button> just has a magnifier icon and no text so it will require an aria-label too, for the screen reader. If your icon were an <img> instead of an <i>, you could specify the button's label in the img's alt attribute, in which case the <button> wouldn't need an aria-label.
<div role="search">
<label for="findit">search term</label>
<input id="findit">
<button>
<img src="magnifier.jpg" alt="search">
</button>
</div>
So the simple answer is, "no", you don't have to put your search in a <form>. But it is strongly encouraged to wrap it in a "search" landmark by using role="search".
You don't necessarily need to but you should always use form tag for any kind of data submission from form elements and google also does (you'll find, if you traverse up in DOM).
Though, you can submit data using AJAX, but not when JavaScript is not running.