<input type="search" placeholder="search" />
The screen reader ignores this when search field is focused! What attribute to be added so that the screen reader would say "This is a search box " Thanks.
The way to make it accessible is use text and markup around the input element rather than attributes. This way, you don’t rely on any specific support to some special attributes (which greatly varies across browsers). Example:
<form action=... role="search">
<h2>Search this site</h2>
<label for="q">Keywords:</label>
<input type="search" id="q" name="q">
<input type="submit" value="Search">
</form>
Then it is OK that the input field is spoken as a normal text field, since the user already knows it’s for entering keywords for a search.
If you are forced to play with small input box without a label, due to site layout requirements, then accessibility is inevitably reduced. You can try to help some users with some attributes that might get recognized and used by some browsers, e.g.
<input type="search" name="q" placeholder="keywords"
title="Keywords for a site-wide search"
aria-label="Keywords for a site-wide search">
Note: The placeholder attribute should contain text that acts a hint of the expected input, rather than a general name for some functionality.
Reference for role and aria-* attributes: Using WAI-ARIA in HTML (WD).
Related
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
I tend to try and steer clear of using ID's outside of functionality purposes. Which brings me to my question, when labelling items in forms there are multiple methods. I have always done this a specific way to avoid ID's; however, what are the pro's and con's of the alternate methods? Does one way have more semantic meaning to the browser than the other? How does accessibility play a role in it?
My usual method of implementation:
<form role="form" action="#" method="post" name="form" novalidate>
<label>
<span>Search</span>
<input role="search" type="search" placeholder="Search" name="s">
</label>
<button role="button" type="submit" name="s-btn">Search</button>
</form>
However, you can also use for="" and label an ID for the corresponding field. Which is obviously better served for type="radio" and type="checkbox" but does it hold any better semantic value than the above?
<form role="form" action="#" method="post" name="form" novalidate>
<label for="s">Search</label>
<input role="search" type="search" id="s" placeholder="Search" name="s">
<button role="button" type="submit" name="s-btn">Search</button>
</form>
And you can even use WAI-ARIA to label as well with ID's, should this be used in cohesion with for="" or is it a stand alone labelling method?
<form role="form" action="#" method="post" id="Form" novalidate>
<label id="s" for="sf">Search</label>
<input role="search" aria-labelledby="s form" id="sf" type="search" placeholder="Search" name="s">
<button role="button" aria-labelledby="form" type="submit" name="s-btn">Search</button>
</form>
I guess this question is brought on due to the never ending pursuit of balancing maintainability, optimizations, semantics, and accessibility.
the two methods, nesting controls into labels (implicit) and using id and for attributes (explicit) have different positives and negatives, however the current trend i've seen from professionals is to move away from implicit and more into explicit.
explicit allows more flexibility within your document(s), and html5 allows form controls to be placed anywhere within the document, so they go hand in hand in this case.
implicit can't be used for checkboxes and radios, as the label element is required to come after the input form control, so there is one limitation. implicit also had poor browser support a few years ago, and seems to still have trouble with screen readers. implicit does add to accessibility and usability, because the label's size adds to the form control's clickable surface area.
wai-aria still isn't finished, and also has problems with browser/screen reader support, but that certainly shouldn't stop you from implementing it when possible. ideally, if not supported, it will simply fail silently (like html5 inputs do with non-html5 supporting browsers), but i would be wary here and test vigilantly. different supports can also have one screen reader/browser/user agent reading both, instead of seeking wai-aria, and defaulting to imp/exp labeling.
semantics: meh. ask 10 devs, you'll get 10 answers. but the correct answer is are you using that form control properly? is it labeled correctly? properly and correctly meaning will it validate and pass accessibility testing? properly and correctly also meaning, in your personal context, in this use-case, are you using the correct control/label for the interaction you are providing the user? only you can answer the latter...if you're using posh principals, you shouldn't have any problem with either.
side note: about avoiding ids, in this case, ids are optimal and they are being used for functionality...i'm assuming the form controls are being processed on submit? i could be wrong about functionality in regards to your intended use, but they are still optimal here, if you are avoiding them for wpo: you can use ids, just don't target them in your style sheets.
I am currently writing a Java EE web-app using JSP's and I have a question regarding HTML tags.
I use fieldsets to properly structurate my forms on the main page and find myself perplexed and was wondering if the following was legal:
<fieldset id="FieldMain">
<form method="post" action="servletA">
<input name="a" type="text" />
<fieldset id="FieldA">
<input name="b" type="text" />
<input name="c" type="text" />
<input name="d" type="submit" value="Go for A" />
</fieldset>
</form>
<form method="post" action="servletB">
<fieldset id="FieldB">
<input name="e" type="text" />
<input name="f" type="text" />
<input name="g" type="submit" value="Go for B" />
</fieldset
</form>
</fieldset>
With the desired result being that when clicking the "Go for A" button it takes into account the field a, b and c (a being outside of the fieldset fieldA but inside the form A tag) while clicking go for B only takes fields e and f.
In other words, if I use field sets, can I have several forms in one single fieldset tag ? And can I have some fields outside of any fieldset tag as long as it is in the form tag ?
Thank you :-)
It's legal, but it's not entended to do this
The FIELDSET element allows authors to group thematically related
controls and labels. Grouping controls makes it easier for users to
understand their purpose while simultaneously facilitating tabbing
navigation for visual user agents and speech navigation for
speech-oriented user agents. The proper use of this element makes
documents more accessible.
Source: http://www.w3.org/TR/html4/interact/forms.html#h-17.10
As far as I remember form past discussions: it's legal according to
the letter of the standard and the DTD also makes it valid where a
block element is valid. Now as to intend, that's harder to determine,
it feels to me to be intended to be used in forms only. I don't know
why it got the far wider scope.
Also note that -despite the CSS standard not stating it should- a
fieldset creates a new stacking context (logical if you think about it
and the default way it's rendered, but not mentioned in the standard
AFAIK).
IMHO extensive use of it outside forms and/or reliance on the new
stacking context are dangerous if you want future proof code.
source: http://www.webmasterworld.com/html/3915579.htm
The title is pretty explanatory, basically I want to use a new input type in this case "search" while falling back to a type="text" if the browser doesn't support search.
I was guessing it could be like this:
<input type="text" type="search" name="s" placeholder="Search posts">
But I'm not sure.
How is this usually done?
That's the default behavior, and how HTML5 was designed. Non-supported types will fall back to type=text.
Source: Dive into HTML5
As with all the other new input types, browsers that don’t recognize type="search" will treat it like type="text", so there is absolutely no reason not to start using type="search" for all your search boxes today.
Edit
As pointed out in the comments, you don't need the two type attributes, just type=search:
<input type="search" name="s" placeholder="Search posts">
I'd like to take advantage of the improved semantics of html5. I'm creating a search area, and the search area should have a background and contain search related things, like autocomplete and search hints.
Is there some consensus around what type of element something like a search area should be wrapped in?
Should it be a NAV because searching is a method of navigation?
Should it be a SECTION because it's a discreet section of the page?
Should it be a DIV because the wrapping of search related elements has no clear semantics?
The markup is something like this:
<?whatElement?>
<input type="search" placeholder="Search for a name or ID..." required />
Search
</?whatElement?>
Thanks for your thoughts.
I am aware this question already has a chosen answer, but it ranked so high in my Google search for "semantic search form" that I feel the need to contribute what I believe to be a slightly better answer, semantically and from a standards standpoint.
<section role="search">
<form action="#" method="get">
<fieldset>
<legend>Search this website:</legend>
<label for="s">
<input type="search" name="s" id="s" placeholder="Search..." maxlength="200" />
</label>
<button type="submit" title="Search this website now">Submit</button>
</fieldset>
</form>
</section>
Of course, I made a series of assumptions and populated the HTML with some default values (action, get, the id and name of the input, etc) and with no classnames for the elements (which I always tend to use in favor of generic element names or, Heaven forbid, IDs) but you should adapt to your own needs.
For example, some additions on top of the excellent contributions above: the first child of any form should always be a <fieldset> tag and have a <legend> attached (visible or not - https://www.w3.org/TR/WCAG20-TECHS/H71.html ), and all <input> tags should have a connected <label> tag through the for and id properties (https://www.w3.org/TR/WCAG20-TECHS/H44.html - I find it easier to just wrap the input in the label so as not to forget connecting them). All call to action elements should have a title (for SEO and usability, to reinforce the action the user is about to make just before she makes it), etc.
The HTML5 specification says this about the section element:
Role must be either region, document,
application, contentinfo, main,
search, alert, dialog, alertdialog,
status, or log
so I would use that.
How about:
<form>
<input type="search" name="" value="" />
<input type="submit" value="Search" />
</form>
<section role="search">
The role attribute is an ARIA landmark:
A landmark region that contains a collection of items and objects that, as a whole, combine to create a search facility.