This question already has answers here:
Is it OK to have an empty anchor tag?
(5 answers)
Closed 8 years ago.
Is this valid HTML?
Home
I'm using the ID to call a jQuery function with an id of "whatever." I can't find anything that says whether this is valid. I'm having a debate as to whether it is.
Also, is it valid HTML to have a radio button group without one selected?
It's valid, and necessary to have something in the href attribute in most browsers to activate the link behaviour of the <a> element. (although href="" would cause the browser to open the index page of the current 'folder'.)
IF the link represents some change of state, then it's better to put more (e.g. '#home') so if the user presses back/forward/refresh, you can restore the state on page load - this is a boon during development too if you tend to refresh the pages a lot whilst developing them.
--
Unselected radio groups are trickier, HTML 4 validators will let it pass, but the HTML 4 specification says one must always be checked (Since user agent behavior differs, authors should ensure that in each set of radio buttons that one is initially "on".). HTML 5 has relaxed this as far as I know since I cannot find any equivalent wording in the HTML 5 specification.
However, such a group of radio buttons is in an invalid state, so it should not be used for capturing optional input (if the user checks one, they cannot uncheck it).
It's better for the user if a default value was selected (usually the most frequent choice), or if it is optional, to have an explicit option for null (e.g. 'None of the above')
Your HTML is completely valid.
Just as a suggestion, your jQuery function should prevent the default behavior of your anchor tag:
jQuery("#whatever").click(function(evt) {
evt.preventDefault(); // Prevent the default anchor tag behavior
// Do what you need here
});
This way you will prevent the common "scroll-to-top" behavior when using href="#".
The HTML markup is valid and conforms to HTML specifications, which cite URI specifications regarding the values of the href attribute. The current authoritative specification is RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, also known as Internet-standard STD 66. According to it, as well as older URI specifications, # is a same-document reference. The relevant clauses in the spec are 3.5 and 4.4.
Following a link with href="#" thus means staying in the current document, with no reload, but positioning the document at its start (“jump to the start”). Thus, it is not a no-op as such, even though href="#" has been used to make the element a fake link, more or less.
On the other hand, an a element without any href attribute is valid, too. It will then not be regarded as a link in visual renderings, scripting, link analysis, etc. If it’s not meant to be a link, don’t make it a link.
Related
This question already has answers here:
Can HTML checkboxes be set to readonly?
(48 answers)
Closed 8 years ago.
In HTML, only text controls like text-box, text-area, password-box have read-only property. Why didn't they support check-box/radio-button?
I know I can achieve this feature using script by putting onclick="return false;". (I don't want any workaround, I want to know only the reason for not providing native support to achieve this)
But my question is there any specific reason for not supporting read-only in check-box/ radio button even-though it accepts input from user.
EDIT 1:
I found this but it doesn't answer my question - Why there is no native way to restrict the user to change the state without disabling it?
It's important to understand that READONLY merely prevents the user
from changing the value of the field, not from interacting with the
field. For many types of fields, READONLY is irrelevent because you
don't normally change the value. In checkboxes, for example, you can
check them on or off (thus setting the CHECKED state) but you don't
change the value of the field. DISABLED, however, actually prevents
you from using the field.
Notice in these examples that you can set the checkboxes even though
they are "read only":
SOURCE
EXAMPLE from faqs.org
HTML 4.01 allows readonly for input in general without restrictions by type. However, it seems that it was generally not implemented in browsers, possibly because the implementors did not see much need for it. In HTML5 CR, readonly is explicitly disallowed for input type=checkbox, and HTML5 CR (or some other “HTML5 spec” such as HTML 5.1 Nightly or WHATWG Living HTML) is generally what implementors use as the guideline these days.
There have been proposals to allow it in HTML5, e.g. a discussion in May 2011 at the whatwg list, as well as browser bug reports (rejected on the basis of what HTML5 says), but apparently without sufficiently good use cases. Although real use cases exist, they are probably too marginal, and reasonable alternatives can be presented, such as the use of a checkbox image (checked or unchecked as desired) with suitable associated text and, if the pseudo-checkbox is set to checked, a hidden field carrying the desired information.
Use jquery to make it disable(readonly) or enable. Only text fields are possible to make them readable at the time of rendering.
<input type="checkbox" id="chk1"/>
then by using Jquery
$(document).ready(function(){
$("#chk1").prop('disabled',true);
});
First, you shouldn't intersect the onclick event of a checkbox for the mere purpose of checking whether it is checked or not. You should use the onchange event instead. Why? Because the onclick event triggers before the onchange event, so if you intersect the onclick event you will not be able to get the actual state of the checkbox unless you do some ugly javascript acrobatics with setTimeout
If you want to make the checkbox "read-only" you have to use the disabled attribute. Like below...
<input type="checkbox" disabled/>
To answer your question, I think it's better explained by the HTML Specs in W3.Org
The difference between disabled and readonly is that read-only controls are still focusable, so the user can still select the text and interact with it, whereas disabled controls are entirely non-interactive. (For this reason, only text controls can be made read-only: it wouldn't make sense for checkboxes or buttons, for instances.)
I just noticed that, in soundcloud, the "action" buttons on a track (like, repost, etc...) are all html button tags. Moreover, they are neither inside a form nor they bind to a form a la html5 nor submit a form (they apparently are being handled through javascript). Is this valid HTML? Can a button exist without a form? Or does that just make these buttons plain clickable divs? And how valid/unvalid would that be for screenreaders?
A button element is valid anywhere in the document body where text-level markup may appear. Such an element need not have any relationship to a form element. The currently authoritative reference is the HTML 4.01 specification, and the formal rules are in the DTD, but you can take a shortcut and use the W3C Markup Validator to check whether a document is valid.
When not associated with a form, a button element is not very different from a span element (rather than div, which is block-level by default), but button has special default rendering. Browsers and assistive software may treat button as otherwise special too, and it is safest to use button only for elements that are supposed to trigger some action when clicked on. Conversely, such elements are often best represented using button markup, though you can create visually button-like elements in other ways too (images or CSS, mostly).
Outside a form, a button element has type=button as default (and that’s normally the only sensible type for it then). This means that it can only have an effect via JavaScript. This does not make it invalid in any way. However, you may consider generating such buttons via JavaScript instead of having them as static HTML content, so that when scripting is disabled, there won’t be a (valid, but) confusing button that does nothing.
To address clarifying questions in the comment below:
A button type=button element is similar to input type=button; the difference is that the latter has no content but takes the text shown in the button from the value attribute, whereas button has content that can be “rich” (with markup).
For either element, if using them causes a server action (typically, via an Ajax call), then we can indeed ask how the page works with JavaScript disabled. But this question might be irrelevant (perhaps the page is an application that is supposed to run with JavaScript anyway), and in any case there is nothing formally wrong with the idea.
Why do they exist? For author convenience and for legacy reasons, I would say. Similarly, one might ask why HTML has event attributes at all, when they cannot possibly work without client-side scripting and you can assign event handlers to elements in JavaScript. But in the early days, that was not possible, and even at present, it might be more convenient to use the button element or the onclick attribute than to do things in JavaScript (and, for making an element look like a button, CSS). There is also the point that button and input type=button create browser-dependent appearance for elements, and it might be argued that for most users, anything that has the style of his browser’s default style for buttons is perceived as a button.
Yes. Since a very long time.
From whatwg.org :
Contexts in which this element can be used:
Where phrasing content is expected.
In the era of ajax, most inputs aren't just send by submitting a form. And most buttons are just used to execute an action on click while using a recognizable widget.
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.
What is the "correct" way to deactivate tooltips on a given page so that the title attribute of a tag does not get shown?
There is no specific "correct" way.
If you don't want a title on an element, don't put one there.
If they must exist, you can use JavaScript to remove the title from any element you need to.
The issue here is that how the attribute is displayed is browser dependent - the spec says so:
Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object).
The fact that they display as a tooltip in most visual browsers does not mean they have to be. And there is no specific standard mechanism to "disable" this behavior.
In the Web Content Accessibility Guidelines is states that you should supply a "skip" link that jumps you (for example) over a navigation block and straight into the content. This is particularly useful for impaired users who use a screen-reader to describe a page audibly.
6.2 Grouping and bypassing links WCAG Guidelines
However, this technique relies on using the name attribute on an anchor tag:
<h2><a name="content">Content</a></h2>
Along with the skip-to link:
Skip to content
The problem is, the "name" attribute of the anchor tag is obsolete in HTML5. HTML Obsolete Features
Is there any other way to achieve this "skip to" functionality without using the name attribute?
Footnote: The status of the HTML5 specification in still in draft and it is possible that the name attribute will actually continue to be allowed in this scenario - although it will probably still generate a "warning". It has currently been marked as "obsolete but conforming", which means you COULD still use it - however, I would like to know of other ways to perform the "skip to" to see if there is a way to do it that doesn't rely on an obsolete attribute.
Instead of using <a> tags, you can use any element with the id attribute:
<h2 id="content">Content</h2>
Skip to content
EDIT, found you a source (albeit it's Wikipedia ;-)):
Alternatively (and sometimes concurrently), with the name or id attributes set, the element becomes a target. A Uniform Resource Locator can link to this target via a fragment identifier. Any element can now be made into an anchor by using the id attribute,[2] so using <a name="foo"> is not necessary.
http://en.wikipedia.org/wiki/HTML_element#Anchor