I am trying to come up with a good way of displaying Access Key shortcuts on my html5 page.
Some places recommend using the first letter of a link/tab/heading/whatever as the access key, so as to be intuitive. Those places generally recommend that you "subtly" hint to the user that it is an access key by styling it differently to the rest of the heading--that is, to make it underlined, or italic, or bold. This sounds like it would be very ugly, and make people think that it is a bug!
Other places recommend using numbers as access keys, so as not to conflict with browser or device built-in access keys. Those places generally recommend showing access keys after the heading in brackets. This sounds even uglier, and less clear!
Is there a better way of choosing access keys, and how to display them?
Edit:
I really liked #Luke2012's recommendation of using both a letter and a number like:
<input type="search" name="q" accesskey="s 0">
BUT while this works beautifully in IE, it disables ALL of the access keys for the element in firefox or chrome.
You can use both letters and numbers as access keys which make it easier over a range of devices. For example:
<form action="/search">
<label>Search: <input type="search" name="q" accesskey="s 0"></label>
<input type="submit">
</form>
Both s and 0 will trigger the shortcut key.
As far as displaying the shortcuts to a user, what about an information icon that can be hovered (like a tooltip) to explain the shortcut keys. Or a subtle dotted line under the element that will trigger a tooltip when hovered.
There are two options that came to my mind:
A) Some programs, for example the CMS Plone, provide short, automated overviews with a list of the used shortcuts. You could display a link to your users to some "help" page where those are explained.
B) It is very common that accesskeys are underlined when pressing the Alt key. You could mimic such a behavior using JavaScript. You could even read the given accesskey from the the HTML attribute and enclose the first matching character with a span.accesskey or something alike to automate the task of highlighting the the accesskey characters.
If you choose a letter, it seems to me they can be memorized more easily.
How to show them: Use the kbd element.
Where to show them: This depends on your site. Typically, access keys are useful for regular visitors, not for new users. So it might not be necessary to show the keys on every page, as regular users will likely memorize them anyway. Instead, document this feature on a separate page (or as part of a relevant existing page).
If you should use them at all, and in which way you should communicate existing access keys to your users, is probably best discussed at https://ux.stackexchange.com/.
Related
I have a simple html form, i am using "google autofill" on a field that autofill data on two fields.
The issue is that the browser address autofill is overlapping the google autofill.
How to disable the browser autofill on fields on every browser ?
Feel free to share thoughts on this.
Thankyou.
Here's the universal solution that will work in all browsers as of May 2021!
TL;DR
Rename your input field names and field ids to something non-related like 'data_input_field_1'. Then add the character into the middle of your labels. This is a non-printing character, so you won't see it, but it tricks the browser into not recognizing the field as one needing auto-completing, thus no built-in auto-complete widget is shown!
The Details
Almost all browsers use a combination of the field's name, id, placeholder, and label to determine if the field belongs to a group of address fields that could benefit from auto-completion. So if you have a field like <input type="text" id="address" name="street_address"> pretty much all browsers will interpret the field as being an address field. As such the browser will display its built-in auto-completion widget. The dream would be that using the attribute autocomplete="off" would work, unfortunately, most browsers nowadays don't obey the request.
So we need to use some trickery to get the browsers to not display the built-in autocomplete widget. The way we will do that is by fooling the browser into believing that the field is not an address field at all.
Start by renaming the id and the name attributes to something that won't give away that you're dealing with address-related data. So rather than using <input type="text" id="city-input" name="city">, use something like this instead <input type="text" id="input-field-3" name="data_input_field_3">. The browser doesn't know what data_input_field_3 represents. But you do.
If possible, don't use placeholder text as most browsers will also take that into account. If you have to use placeholder text, then you'll have to get creative and make sure you're not using any words relating to the address parameter itself (like City). Using something like Enter location can do the trick.
The final parameter is the label attached to the field. However, if you're like me, you probably want to keep the label intact and display recognizable fields to your users like "Address", "City", "State", "Country". Well, great news: YOU CAN! The best way to achieve that is to insert a Zero-Width Non-Joiner Character as the second character in the label. So replacing <label>City</label> with <label>City</label>. This is a non-printing character, so your users will see City, but the browser will be tricked into seeing C ity and not recognize the field!
Mission accomplished! If all went well, the browser should not display the built-in address auto-completion widget on those fields anymore!
Hope this helps you in your endeavors!
This is not so easy to implement cross-browser.
Many browsers, in particular Google Chrome has pushed very hard on having a tool that helps users auto-fill their forms, but for developers this has been just been painful.
I could list tons of different ways that could or could not work depending on different factors, but I will post this one solution that finally does the trick. So if you have been looking for this answer all over the internet, leave me a comment below and tell me if it worked.
First of all, due to browser compatibility, we need to add these attributes as eventually things will work properly:
autocorrect="off" spellcheck="false" autocomplete="off"
This is supposed to be enough, BUT IT IS NOT! and we all know that. so the next thing to do is to add a little bit of JS in case the browser managed to ignore these attributes. For this example I will just use jQuery and assume that we are dealing here with inputs, but you can chose any selector you want.
$('form').attr('autocomplete', 'off');
$('input').attr('autocomplete', 'off');
Finally, this will work 50% of the times, but if the browser has previously detected that this form was filled up in the past it might judt ignore it, so let's add a final step.
There is another popular trick that involves adding a dummy password field, but I don't like adding dummy content, and I don't find this solution elegant so I will just skip it, besides it doesn't work.
To be honest this final step is the one that makes everything work, but as I said it is better if our attributes are ready for future compatibility. Keep in mind that the browser will never attempt to autocomplete a readonly input, so for this last step we need to make it readonly and on focus bring it back to normal, so add the following JS in the onfocus attribute:
readonly onfocus="this.removeAttribute('readonly');"
BINGO! it should work now.
So the final input looks like this:
<input type="text" name="email" required autocorrect="off" spellcheck="false" autocomplete="off" readonly onfocus="this.removeAttribute('readonly');" />
<script>
$('input').attr('autocomplete', 'off');
</script>
It seems like a lot, but this works 100% of the times. as I said probably with readonly onfocus="this.removeAttribute('readonly'); is enough, but browser compatibility is changing and eventually things will work properly, so it is good to have it there.
If this worked (or did not work) leave a comment!
Thanks
So I read a lot of articles that say that HTML 5 form validation is accessible (things required attribute which will prevent the form from being submitted is a field is left blank), yet when I tested my form on NVDA on Chrome and BackTalk on Android, if I hadn't filled in the input, it focuses back to the input field (which is good!) but both screen readers announce "Please fill in this field" which is useless to the user, since they don't announce the label of the field.
So HTML5 validation alone isn't accessible? Also, can you combine HTML5 validation and custom JS?
Do you have to write custom client site validation in order to make forms accessible?
Short Answer
Yes the standard HTML5 validation is accessible and will pass WCAG2.1 AA, but you can do a lot better with some JavaScript.
Long Answer
If you need to support Internet Explorer 9 or below then you will need to use JavaScript (which according to WebAim survey - section "Browsers" still covers around 3.6% of screen reader users).
Native HTML5 validation is a very good starting point, but there are limitations (you gave one in a comment, some screen readers (NVDA) do not announce the label again, meaning a user has to physically ask for the label to be read via controls).
The other thing is that once you leave a field it doesn't normally tell you you have made a mistake until you have submitted the form (it is meant to but this is not always the case depending on your announce speed, settings and browser).
For example updating aria-invalid is useful for immediate feedback (and provides support for older browsers, while being more robust with 'unusual' screen readers).
Using an aria-live region to provide immediate feedback onblur (or throttled / debounced) is also useful and a better solution.
One other thing is that the native validation is not actually very effective. For example fff#fff shows as a valid email and will allow a form to submit on a type="email" field, same with type="url" it will allow https://fff to be submitted (in Chrome at least).
I could go on with other things such as providing better instructions on how to fix errors (especially for things like phone numbers) but you get the idea.
Basically, use as many native HTML5 features as possible to give a solid grounding and a good fallback for JavaScript errors / people not using JavaScript. Then use CSS and JS to improve the experience for everyone.
Also, can you combine HTML5 validation and custom JS?
You can and you should but be aware that you end up doubling up validation (which isn't a bad thing as I stated for fallback).
The beauty is you can use pseudo selectors in your JavaScript to target fields by type, saving the need for adding unnecessary classes etc.
e.g. document.querySelectorAll('input[type=email]') could be used to select any email input for validation or document.querySelectorAll('input[required]') to find all required fields.
You can also use things like max="100" on slider / numeric inputs to set your validation ranges 'on the fly' and still have a fallback for no JavaScript.
As you can imagine this let's you write a library if you can't find an off the shelf one that is reusable on nearly any form.
Basically I have a text box with a modifier dropdown. I would like an icon of the current choice to display when chosen. The problem with the current set-up (using UNICODE) is that the icons do not always display, such as on google chrome (unless the specific fonts have been installed).
For example see the Fiddle:
https://jsfiddle.net/q5eLLu2h/
<select class="squareDropdown" id="da" name="da">
<option value="AND">➕ AND</option>
<option value="EXCEPT">➖ EXCEPT</option>
<option value="OR"><b>O</b> OR</option></select>
<input class="textArea" id="d" name="d" placeholder="d" type="text" />
<br>
<br>
<br>
<select class="squareDropdown" id="ca" name="ca">
<option value="OR"><b>O</b> OR</option>
<option value="AND">➕ AND</option>
<option value="EXCEPT">➖ EXCEPT</option>
</select>
<input class="textArea" id="c" name="c" placeholder="c" type="text" />
Does anyone have any advice on what I could do? Either a way to get the unicode icons to display (like through forcing the person to download them?) or a simple way to get pictures or images into a select box, or anything really. Jquery UI is installed, is there anything I can do with it?
Thank you
Options are hard to style.
The basic reason is that they are reaching into the operating system for generation rather than being generated solely by the browser like most other website HTML elements.
This is why file upload form field 'submit' buttons don't follow the same rules as any other submit buttons on a form.
Here is some more detail about limited and inconsistent possibilities and a question that proves <option> can't have any children (this in turn stops the psuedo-elements from working, unfortunately, as psuedo elements are rendered like DOM nodes).
All this means that using an icon font won't work either as you'd need to target just the bit with icon in, which you could only do with extra child elements.
Using JQuery
There are many ways of mimicking select option form fields with various javascript plugins that will give you more control, however, they come with an important caveat. Standard select elements bring with them all the extra usability and accessibility features (such as keyboard focus and operation) javascript plugin writers don't necessarily think about, so use with care.
It's also worth remembering that when you are replacing complex functionality with JQuery you've got quite a lot of overhead in testing / development - select elements do just work in all browsers, without their actual functionality needing testing. This is more considerable if you do pay attention to all the accessibility points.
The MDN article does however judge that this is the best way and lists some good plugins for a solution, which I would use as MDN can be trusted to have considered all the important stuff I mention above.
For the sake of link rot, here are the two of the three they recommend that link to a product still:
UniForm
FormalizeMe
(please note, I haven't tried these, I'm just trusting Mozilla!)
Unicode
You are trying to use unicode in your option tags. This should work, and without forcing a download on the user if you:
Use a font that has the unicode characters you want to use defined.
Ensure that you have the charset in your docs set to utf-8
However, you'll only ever get characters, never styleable icons and you might be stuck with websafe or proprietary fonts.
This jsfiddle here demonstrates with the web-safe font-family: sans-serif and also characters taken from this link with a big list of those that are commonly supported
And finally
For small option sets radio buttons are probably better. The user can immediately see the available options rather than having to open them each time (better learnability, faster cognition); plus, they can make their desired selection, or change their desired selection with just one click each time. The guys over at UX.SE discuss what to use further, raising other points.
All your problems might just disappear if you think about whether <select> is the best option.
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.
This is a "best practices" question. I was perusing the Code Review StackExchage site, and I saw this thread. In it, Joseph Silber makes the suggestion of using bracket notation and eschewing IDs entirely for a form with multiple identically-structured rows of form inputs.
In the books I've read on web design/development, I've never seen this strategy used. Is using bracket notation and wrapping input elements within label tags, as well as not using id tags in form inputs a good idea? Perhaps there something about Javascript/JQuery that makes this approach advantageous?
I wanted to ask Joseph about it directly, but I don't have any reputation on the site yet so I couldn't even comment. However, I'm interested in seeing the community-wide perspective on this, because searching for things like "HTML5 bracket notation" and "HTML5 arraylike notation" isn't turning up anything definitive for me so far.
Here's a summary of the above question with some example code borrowed from the linked question:
Why use this:
<label>Comment:
<input type="text" name="comment[]" width="50" />
</label>
instead of this:
<label for="comment-0">Comment: </label>
<input type="text" id="comment-0" name="comment-0" width="50" />
in a form with multiple rows of the same inputs?
Sticking [] on the end of an input name will cause some server side form processing libraries to present the data as an array. Some other form processors don't need the special syntax. Your choice will largely depend on your desire to be compatible with the former kind vs having more complicated names and not being able to access the elements via dot-notation in JS.
Using child elements instead of for attributes will:
Save you from having to generate unique ids (especially useful if similar forms can appear on a single page)
Limit your styling choices
Be compatible with fewer browsers (I think the only loss is old versions of IE, which is no big loss).
So there are pros and cons there and you have to decide what it right for you.