How can I create input type="text" with <select></select> option. In other words I would like to have one field where can I input text, but if I want I could choice option from dropdown list from all values just like with select tag. Is it possible?
If you want to allow free-text typing with suggestions/pre-defined choices then I would encourage you to look at the HTML5 datalist element (see https://developer.mozilla.org/en-US/docs/HTML/Element/datalist) which is designed for precisely this purpose.
As browser support for this is limited to more recent versions of browsers (and not available at all in Safari, iOS or Android) you'll probably want to Polyfill this with something like JQuery UI autocomplete (see http://jqueryui.com/autocomplete/).
Not as a built in html control, no. You would need to create one using an input field and another element (such as a div or list) which contains the dropdown values, with javascript gluing the component parts together. There are plenty of tutorials on how to do this dotted around Google.
Related
I am creating a search form that has two elements an input field and a button. The input field does not have an label associated with it.
To make the field more accessible I can add <label for="searchfield">Search</label> and visually hide it so it will e.g. be accessible for screenreaders.
I could also add aria-label="search" to the input field and leave the input field without an label.
I have tested with "Voice Over" on a Mac and I get the same result/output. My question is are these approaches equivalent? Or is one approach better than the other one?
Here is a pen.
In the absence of having any knowledge of the site (how are other form fields labeled?) or the audience (what is their skill level or tech profile?), I approach these questions with a couple parameters:
The rules of ARIA (the first rule may apply here)
Progressive enhancement
That being said, I often code a page without ARIA and without CSS (as that may get blocked, chunked, etc) and make sure it is accessible.
That means I code a <label>. Then I visually hide it. If the CSS breaks, all is still well. If the user's screen reader does not support ARIA, all is still well. As an aside, if you think all screen readers of your users support ARIA, I encourage you to do to a tech assessment of users (local blind associations are a good start in the absence of any real users). Many people still run older versions of browsers and SRs.
For sighted users, I make sure I lean on contextual clues, like a clear search icon (or the word) in the button (as Unor references). Or maybe a placeholder with appropriate contrast (though you could use the <label> as a visual placeholder with some CSS trickery to hide it on focus).
If your submit button uses SVG, then I would be folding ARIA into that given the inconsistent support around SVG alternative text methods.
FWIW, I am also not a fan of the title attribute, partly because of inconsistent accessible name calculation and partly because I think it looks meh.
So, to answer your questions:
My question is are these approaches equivalent?
No, but the distance between them is shrinking.
Or is one approach better than the other one?
That depends on context we do not have.
Using aria-label is preferable to relying on CSS to visually hide a label element.
(Related Technique: Using aria-label to provide an invisible label where a visible label cannot be used)
But note that you don’t have to provide a label for a search form that only consists of the search field and the submit button. Assuming that you use a button labeled with something like "Search", it already makes clear which purpose the text field has.
(Related Technique: Using an adjacent button to label the purpose of a field)
In that case, while it doesn’t need a label, it should still get a name. One way to provide a name is to use the title attribute on the input element. The Technique Using the title attribute to identify form controls when the label element cannot be used shows this (a search form without label, with title attribute on input) in example 3.
I believe that aria-label="search" is the correct approach, as it produces cleaner markup (i.e. no unnecessary label tag) and no need for CSS to set visibility of the label - like in this example.
I believe visually hiding a label using CSS is a somewhat 'hacky' way to approach the problem, whereas ARIA is the standard for accessible markup, so it should be the obvious choice for situations like this.
On the other hand, it would be worth ensuring all browsers you intend to support can use ARIA correctly, and if not, it may be worth using the label approach to ensure compatibility across all browsers. Although, I think the support these days is pretty good, so that should not be a common scenario.
I've been developing for some time now...every now and then I find out about more HTML tags, PHP functions etc that I never new I had at my disposal.
Today, I'm talking about the different HTML input types....well, only one and then some link->rel values...
Input type: search?
I have looked in several places and all I get is the obvious answer of what it's purpose is.
I can do fulltext queries just fine by making the field a text type...
so what's the technical difference between the text and search input types? and are there any benefits of using making the input field a search type?
And, I have similar misunderstandings with some of the rel values of the link tag:
Next, prev, search etc...
I can do the same things without using those rels...I can create a 'slideshow' of articles without using next/prev. search, i don't understand at all... I can only find the defeintion of it..'Links to a search tool for the document'...does this mean a tool like that which google provides so your users can search through a document?
I can do these things without using s altogether so I'm guessing the answer to my question is in the fact that I don't use for these tasks and maybe I should? Combine then with AJAX?
Thanks
At the moment, there are no differences between input type='search' and input type='text'. The reason these new HTML input types are put in place is so that functionality can be added later in the future. It's good practice to use type='search' when you are creating a search field, as it could become more useful in the future and it also makes your code more semantic.
There are really some differences are there between "search" and "text"
These two are rendered differently according to the browser. safari, Chrome like browsers adds a cross icon to clear the field more quickly than normal text field.
And in smartphones it changes the normal return button of the soft keyboard into magnifier or search button. which is more user friendly
some browsers will trigger certain applets while user is on a search field
HTML 5 defines a lot of new input types such as date, time, number, email, ... (you find a complete list here) which can be used by modern browsers to provide more functionality such as validation or support for input.
The browser can display a calendar for date inputs. On a touchscreen a different keyboard (containing #) is shown for an input field of type email or phone. For the search attribute an hourglass might be shown.
You should always use the new input types, as they provide more semantic information. An old browser will interpret them as <input type="text" />. A disadvantage is that different browsers display the same field differently and some browsers do not use the tags at all. For input type search a magnifier might be displayed.
Your second question is about link types. Again, this is semantic information mainly for search engines or user agents. The different link types might be displayed in a separate navigation bar.
On many websites, when typing in a username for example, a dropdown occurs where previous input shows up so the user can easily select something instead of typing. I know you can turn this off in browsers by having the form or input have an attribute of autocomplete="off". The problem is when I want it on, and the input has padding. The dropdown looks horribly off because it has no padding for each item.
Is there any way to style this with only css? I'm aware that you could potentially use a javascript/jQuery workaround to store previous entries in a cookie or something and make your own dropdown. But I don't want to rely on javascript for this.
Nope. Autocomplete is not a part of any standard, and is not part of the DOM. The only way to style is, as you've suggested yourself, by recreating that functionality using JavaScript.
Unfortunately there is no way to style the drop down box itself with CSS, because in this case (when not using javascript/jQuery/mootools/etc.) it is operating system dependent - i.e Windows/Linux/Mas OS visualize it according the visual user settings (i.e scheme).
I'm using some HTML5 form features to progressively enhance the user experience of my web project. One in particular is autofocus, I'm wanting to use this in a modal (lightbox) dialog that allows users to enter tags. Existing tags could be there.
The only browser I have installed that supports autofocus is Chrome 9, however when I test it there it does place the focus on the field, but also automatically selects all existing text in the field. I did not expect or want autoselect, I want autofocus.
Is my expectation wrong or is Chrome wrong?
Chrome decided they were wrong and changed this behaviour in Chrome 36.
I know this because I was wrongly relying on javascript .focus() and html autofocus for also selecting the text. Now it requires a .select() to select and focus in the text field. Good that we can now be specific of what we want :-)
So now Chrome behaves like e.g. Firefox.
Read more about autofocus and html5 here: http://php.quicoto.com/autofocus-in-html5/
If you have a snippet of code we could look at, we might be able to further be of help. It looks fairly simple and painless to implement and says the feature is supported in everything but Fx and IE.
From the HTML5 specification, the focusing steps do not prescribe whether or not text should be selected. User agents are neither required nor forbidden to select the text. Specifically, here is the relevant focusing step:
The user agent may apply relevant platform-specific conventions for focusing widgets.
Note: For example, some platforms select the contents of a text field when that field is focused.
It is supposed to select the text, as input.focus() does this too.
Is it possible to auto-select the text in a PRE tag without the use of Javascript?
No, you have to use scripting to achieve that. There might be some accessibility tools out there that does that for you on form elements (like autofocusing on the first input field in a form) but probably not for arbitrary elements and depending on your actual use-case this might not be an option for you (if it even exists).
And to my knowledge the whole range selection in JavaScript is still not standardized AND implemented by all relevant browser manufactures in that standardized way ;-) ( http://www.quirksmode.org/dom/range_intro.html )