I'm experimenting with placeholder attribute, but I have noticed that if I focus the field on Chrome the placeholder disappears, in Firefox it disappears only after the first keydown.
I like Firefox behaviour: how can I force Chrome to act the same way?
Thanks a lot
The specification states (emphasis mine)-
User agents should present this hint to the user, after having
stripped line breaks from it, when the element's value is the empty
string or the control is not focused (or both), e.g. by displaying it
inside a blank unfocused control and hiding it otherwise.
This means that browsers may implement either approach you described above. To deviate from the browser default behaviour you would probably have to write a custom JavaScript solution which would have an on keyup event handler and compare the input value with an empty string.
I would personally implement this using a data-placeholder attribute on the input to hold the value.
As it happens though, it would appear that Chrome has changed its default behaviour as with Chrome Canary and Chrome 31 (which is current), the placeholder value remained visible until the user started typing in the JS Fiddle I linked.
This behaviour was only tested on the "desktop" version of the browser, and only on the Windows operating system. It is possible there may be some variation on other platforms, even with the same browser.
Chrome auto-updates, it is in fact relatively hard to prevent this from happening, so it is highly unlikely that many of your users will be using a version as old as Chrome 14 (released September 2011). Generally it is my experience that statistics will show Chrome versions in use being divided between the last three versions, usually mostly the current and previous version (with ratio dependent on the time since the last release).
As a result, it would appear your issue is unlikely to affect many (if any) users.
Please note the following from the specification though-
Note: Use of the placeholder attribute as a replacement for a label
can reduce the accessibility and usability of the control for a range
of users including older users and users with cognitive, mobility,
fine motor skill or vision impairments. While the hint given by the
control's label is shown at all times, the short hint given in the
placeholder attribute is only shown before the user enters a value.
Furthermore, placeholder text may be mistaken for a pre-filled value,
and as commonly implemented the default color of the placeholder text
provides insufficient contrast and the lack of a separate visible
label reduces the size of the hit region available for setting focus
on the control.
Please don't use the placeholder as a replacement for labels, or at the very least have a hidden label for accessibility purposes (as in the Google example you cited).
Related
I am working on creating accessible help text for my form controls. I am planning to use aria-describedby to attach a accessible description to a field. This approach is discussed here
Although in my testing with ChromeVox extension and Windows 10 screen reader I have found out that aria-describedby is not announced, but it is rather well supported across browsers and screenreaders, so i am planning to use this approach.
Also this suggests that in some cases aria-describedby would be ignored or not work as expected but these cases are quite specific and i am generally ok with it.
aria-describedby content may not always be announced to users,
depending on their screen reader and navigation method. The attribute
is well supported, but that doesn’t mean there aren’t some things to
be aware of: aria-describedby content may not be announced by all
screen readers if navigating to a button, link, or form control with
the virtual cursor. JAWS specifically may not announce an element’s
description when using hot keys to navigate to certain elements. When
navigating by visited links, the description will not be announced.
However JAWS should announce descriptions when navigating by form
controls. JAWS 17 + IE won’t announce aria-describedby content when
tabbing to a link (newer version of JAWS have fixed this). IE11 won’t
announce the accessible name or description of a form control if the
title attribute is used in tandem with aria-describedby, and the
user is navigating by virtual cursor or form control hot key (F). Both
will be announced if using the Tab key. (IE11 had much bigger problems
with aria-describedby in the past.) TalkBack + Android Chrome won’t
announce any aria-describedby content of a modal dialog when
auto-focusing an element within that dialog. If a user has
descriptions or hint text turned off, any associated content won’t be
announced. Because of this, it’s vital that any content that is
necessary to the understanding of a UI be available by means other
than just aria-describedby.
I would like to understand if there are times when aria-describedby would not be announced automatically? The previous link phrasing seems to suggest that it is only going to be announced on request :
By using aria-describedby to reference the format of the field, this
information is made available to the users on request. That is, it is
not automatically displayed or read aloud. This makes sense if the
user has been informed of the format before, or when there are lots of
input fields with the same format, for example.
I don't get what it means by "on request". I believe that the default behavior is to announce the aria-describedby text after announcing the label and the input type.
The behavior of aria-describedby (like aria-label and aria-labeledby) is profoundly influenced by the role of the element where they appear.
As you may know screenreaders generally have two 'modes', and this is mostly determined by the role (or default semantics) of the content.
I have certainly had problems getting non-interactive elements announced, if they appear within interactive ("forms mode") content.
I have had good results using aria-describedby with modal content. (Put the attribute on the modal, and point at the text elements inside which you want announced when the modal opens.) But I suppose this is because there is an obvious moment where the screenreader is supposed to make those announcements: the moment when the modal opens.
In the case that the form (or other "forms mode" container) is always present on the page, you can usually read the non-interactive content using browse-mode key combinations such as "next heading" ("H" on NVDA and JAWS) or "next paragraph" ("P"). Check to see if these 'requests' are enough of a solution.
You might also experiment with the standard HTML elements fieldset and legend, whose purpose is providing a text description for groups of interactive elements.
Also consider treating the 'form' (or toolbar or whatever) as a single tab stop, and use arrow keys to navigate the components within. This way, when you give focus to the container, you should get an announcement of whatever is aria-describedby (or indeed aria-labeledby/aria-label)
If this isn't working for you, there are a couple of hacks you might try as a last resort:
Put tabindex="-1" on the element surrounding the text you want
announced, and then call focus() on that element at the appropriate
moment.
Copy the text into the textContent of an aria-live region
with javaScript at the appropriate moment.
Neither of these hacks are pretty, and might not suit you, if there is no 'appropriate moment'. (There's no equivalent of onfocus for browse mode). But with a little care, they can be made to work.
I'm starting some work on some input fields.
I have a decision to make whether to carry out an action on the input:focus itself, or on a larger parent area focus.
In order to make the parent focusable, I intend to add a tabindex -1.
I've looked around and know that this stuff has been around a long time, but before I set off on a particular route, it would be good to know whether this works cross browser.
In terms of browsers I need to support, IE10 up, Chrome, Firefox, and the new "IE6", Android (3.0 upwards).
I'd appreciate any feedback as this is not something I can find out on caniuse and not something I can test widely at this stage.
Yes and no.
The HTML5 specification's notes on tabindex state:
If the value is a negative integer
The user agent must set the element's tabindex focus flag, but should not allow the element to be reached using sequential focus navigation.
However the HTML401 specification's notes on tabindex state:
This attribute specifies the position of the current element in the tabbing order for the current document. This value must be a number between 0 and 32767. User agents should ignore leading zeros.
If the browser supports HTML5 or ignores the HTML401 specification's implementation notes you're good to go. I have no idea what you mean by the new "IE6", but the other browsers you mention all implement HTML5.
Yes. It's been supported for years.
I want to use the autocomplete attribute on a form on a webpage. Specifically, autocomplete="tel-local" and such (i.e. autocompletes that specify what goes in a field)
I'd like to know how widely supported it is, and, if possible, what browsers support it. My attempts to google it have failed...
Also, as far as I can think, even in browsers that fail to support it, using the attribute should not cause problems. Is there any problem that I can cause by using it?
The spec that I intend to use is https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill (which, as far as I know, is the current spec).
The autocomplete attribute as such is well supported, see MDN info on input. However, this only applies to its original design, formally described in the W3C HTML5 Recommendation. Various drafts contained lists of other values, but they were dropped from the Rec due to lack of implementations. Such ideas are retained in the HTML 5.1 draft (work in progress) and in what the WHATWG group calls “Living HTML Standard” (a mutable document that expresses a person’s view of what is “standard HTML” today).
Support to values other than on and off in browsers is obscure. The current version of Firefox surely lacks support, since other values aren’t even reflected in the DOM, i.e. the autocomplete property of an element node cannot have other values (so e.g. autocomplete=tel-local is ignored, which normally means defaulting to autocomplete=on). Chrome and IE let you set the attribute to any value, in the sense of setting the property, but its effect appears to be undocumented. In Chrome, autocomplete=tel-local seems to have some effect, but to me it suggests just some text strings as values (perhaps due to some tests I have made previously).
The problem in support is that it may exist. It is then somewhat unpredictable how a browser implements the attribute.
On Chrome and Firefox, a form is submitted if the return key is pressed inside any text input inside the form.
Is this behaviour part of the standard?
Yes, this is default behavior.
[edit] I should qualify, this is for pretty much everything IE7 and up. I do know that some older browsers (Netscape) may not have done this. But for today's browser landscape, yes this is standard.
No, this behavior is not required. I’m afraid it isn’t even mentioned in the HTML 4.01 specification, though this is probably just an oversight.
But it is very common behavior and needs to be taken into account: users may well accidentally submit form data by pressing Enter, when they still intended to continue filling it out.
There are some browser differences, e.g. IE 9 does not do anything when Enter is pressed in a field provided that a) there are more than one text input fields there and b) there is no submit button. On older versions, condition a) was sufficient, and this was more or less the original idea (the feature was meant to make it easy to use very simple search forms without causing confusion).
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.