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.
Related
I have been seeing the aria attribute all over while working with Angular Material. Can someone explain to me, what the aria prefix means? but most importantly what I'm trying to understand is the difference between aria-hidden and hidden attribute.
ARIA (Accessible Rich Internet Applications) defines a way to make Web content and Web applications more accessible to people with disabilities.
The hidden attribute is new in HTML5 and tells browsers not to display the element. The aria-hidden property tells screen-readers if they should ignore the element. Have a look at the w3 docs for more details:
https://www.w3.org/WAI/PF/aria/states_and_properties#aria-hidden
Using these standards can make it easier for disabled people to use the web.
A hidden attribute is a boolean attribute (True/False). When this attribute is used on an element, it removes all relevance to that element. When a user views the html page, elements with the hidden attribute should not be visible.
Example:
<p hidden>You can't see this</p>
Aria-hidden attributes indicate that the element and ALL of its descendants are still visible in the browser, but will be invisible to accessibility tools, such as screen readers.
Example:
<p aria-hidden="true">You can't see this</p>
Take a look at this. It should answer all your questions.
Note: ARIA stands for Accessible Rich Internet Applications
Sources: Paciello Group
Semantic Difference
According to HTML 5.2:
When specified on an element, [the hidden attribute] indicates that the element is not yet, or is no longer, directly relevant to the page’s current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user.
Examples include a tab list where some panels are not exposed, or a log-in screen that goes away after a user logs in. I like to call these things “temporally relevant” i.e. they are relevant based on timing.
On the other hand, ARIA 1.1 says:
[The aria-hidden state] indicates whether an element is exposed to the accessibility API.
In other words, elements with aria-hidden="true" are removed from the accessibility tree, which most assistive technology honors, and elements with aria-hidden="false" will definitely be exposed to the tree. Elements without the aria-hidden attribute are in the "undefined (default)" state, which means user agents should expose it to the tree based on its rendering. E.g. a user agent may decide to remove it if its text color matches its background color.
Now let’s compare semantics. It’s appropriate to use hidden, but not aria-hidden, for an element that is not yet “temporally relevant”, but that might become relevant in the future (in which case you would use dynamic scripts to remove the hidden attribute). Conversely, it’s appropriate to use aria-hidden, but not hidden, on an element that is always relevant, but with which you don’t want to clutter the accessibility API; such elements might include “visual flair”, like icons and/or imagery that are not essential for the user to consume.
Effective Difference
The semantics have predictable effects in browsers/user agents. The reason I make a distinction is that user agent behavior is recommended, but not required by the specifications.
The hidden attribute should hide an element from all presentations, including printers and screen readers (assuming these devices honor the HTML specs). If you want to remove an element from the accessibility tree as well as visual media, hidden would do the trick. However, do not use hidden just because you want this effect. Ask yourself if hidden is semantically correct first (see above). If hidden is not semantically correct, but you still want to visually hide the element, you can use other techniques such as CSS.
Elements with aria-hidden="true" are not exposed to the accessibility tree, so for example, screen readers won’t announce them. This technique should be used carefully, as it will provide different experiences to different users: accessible user agents won’t announce/render them, but they are still rendered on visual agents. This can be a good thing when done correctly, but it has the potential to be abused.
Syntactic Difference
Lastly, there is a difference in syntax between the two attributes.
hidden is a boolean attribute, meaning if the attribute is present it is true—regardless of whatever value it might have—and if the attribute is absent it is false. For the true case, the best practice is to either use no value at all (<div hidden>...</div>), or the empty string value (<div hidden="">...</div>). I would not recommend hidden="true" because someone reading/updating your code might infer that hidden="false" would have the opposite effect, which is simply incorrect.
aria-hidden, by contrast, is an enumerated attribute, allowing one of a finite list of values. If the aria-hidden attribute is present, its value must be either "true" or "false". If you want the "undefined (default)" state, remove the attribute altogether.
Further reading:
https://github.com/chharvey/chharvey.github.io/wiki/Hidden-Content
setting aria-hidden to false and toggling it on element.show() worked for me.
e.g
<span aria-hidden="true">aria text</span>
$(span).attr('aria-hidden', 'false');
$(span).show();
and when hiding back
$(span).attr('aria-hidden', 'true');
$(span).hide();
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.
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).
I was hoping to use HTML5's input control (with range type) to allow our users to click up/down and increment/decrement a value represented inside of the control.
After taking a look at supported browsers: http://www.w3schools.com/html5/html5_form_input_types.asp, I found that this control was not supported in all the browsers I need it to be supported in.
I did a bit of Googling, but am not sure what keywords I should be using to dig up a more friendly version of this control. It seems all references to the words 'input' and 'range' immediately point me to the HTML5 version.
Does anyone know how I could emulate this functionality while still supporting IE8 and all modern browsers?
HTML5 Input range polyfill could be used.
Details are in this URL :
http://www.frequency-decoder.com/2010/11/18/unobtrusive-slider-control-html5-input-range-polyfill/
Also, www.HTML5Please.com is an excellent site when stuck with fall back or polyfill doubts.
One of our web applications just went through 508 compliance testing. We use TinyMCE version 3 for content development and I understand it generally has good accessibility. However, one of our pages contains 3 or more TinyMCE instances each preceded by a label indicating what the TinyMCE instance is for but we are being told that these are "implicit" labels when they should be "explicit" labels (i.e. with the for attribute). Problem is, TinyMCE instances are just iframes with a complex assortment of custom html "controls", whereas as far as I know the label/for technique only works with traditional form elements. What's the best strategy for achieving an "explicit" label for a TinyMCE instance?
Thanks!
Edit
Solutions explored using label + for which don't work: pointing the label at the initial textarea, pointing the label at the generated iframe.
One possible solution I am exploring is encompassing each TinyMCE instance with a ledgend + fieldset but testing this out with JAWS 9.0 it doesn't seem to make any difference unless the fieldset contains form elements (e.g. input, type=text) and JAWS is in forms mode.
There is an emerging standard for exactly this kind of problem: ARIA (Accessible Rich Internet Applications). It's still a working draft, but support is beginning to show up in recent screen readers (JAWS 9, recent versions of NVDA) when used with recent browsers (IE 9, Firefox 3.6 (partial) and 4.0, Chrome).
In this particular case, take a look at aria-label and aria-labelledby. These are attributes which would be added to the BODY element in TinyMCE's widget -- or to the IFRAME, whichever of the two actually takes focus when the user is entering data. Thus:
<body aria-label="Edit document">
The aria-label attribute just specifies a string that serves as the label. The aria-labelledby (note the two L's, as per British spelling) works like the traditional LABEL element in reverse. That is, you feed it an ID:
<body aria-labelledby="edit-label">
And then you would have this someplace else in the code:
<label id="edit-label">Edit document</label>
It doesn't necessarily have to be a LABEL element, you could use a SPAN or whatever, but LABEL seems semantically appropriate.
ARIA attributes will not validate under HTML 4, or XHTML DTD's. However, they WILL validate under HTML 5 (itself still in development). If validation is important to you under an older DTD, you can add the attributes programmatically using JavaScript when the page has loaded.
Ideally, if you have a visible label for the widget already, then you should be using aria-labelledby to prevent redundancy. However, I have no idea if it'll work across document boundaries. That is, if the BODY is in an IFRAME, and the visible label is defined in the IFRAME's parent document, I don't know if it'll work. The browser/screen reader may treat the two as separate documents which don't talk to one another. You'll have to experiment to find out. But if it turns out they don't work, try http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden. Thus, in the parent document:
<label aria-hidden="true">Edit document</label>
And in the TinyMCE document:
<body aria-label="Edit document">
The aria-hidden attribute will prevent the label in the parent document from being read, and the aria-label attribute in the child document (which is not visible) will take its place. Voila, a widget labeled both visibly and audibly with no redundant reading.
If you use aria-hidden this way, be very careful that the bit you're hiding (or an equivalent) is always made available for reading someplace else.
This solution will only work for people using web browsers and screen readers that support ARIA. People with older screen readers or browsers will be out of luck, which is discussed at length in the recent article on A List Apart, The Accessibility of WAI ARIA. The author makes a good case for preferring traditional semantic HTML solutions whenever possible; but in your case I don't think you have any other option. At the very least, adding ARIA attributes will let you reasonably claim that you've done your due diligence and made a good faith effort to make it as accessible as possible.
Good luck!
Note to far future readers: The links to the ARIA specification given here refer to the September 2010 working draft. If it's been more than a few months since then, check for more recent specs.
Using the information Will Martin provided regarding the aria-label attribut, I wrote the following line of code which works for TinyCME 4:
tinymce.init({
…
init_instance_callback: function(editor) {
jQuery(editor.getBody()).attr('aria-label', jQuery('label[for="' + editor.id + '"]').text())
}
});
It uses the callback function triggered after initialisation of the editor.
There has to be a label targeted at the original element on which TinyMCE is call upon, in my case a textarea. e.g.:
<label for="id_of_textarea">Shiny wysiwyg editor"</label><textarea id="id_of_textarea"></textarea>
The content of the label (text only) is added as aria-label attribute to the body tag inside the TinyMCE-iframe.
OSX screenreader is propperly returing the label when selecting the TinyMCE
Some inspiration from TinyMCE: How bind on event after its initialized
If I read the specs right, the for property must indeed point to another control on the same page, as you already say.
Therefore, I think the only valid option is to point the for attribute to the <textarea> element that TinyMCE replaces. It makes the most sense, seeing as that element gets sent to the server when editing is finished.