Don't Be Lazy, Use HTML Labels Correctly
blog.goodsense.io
blog.goodsense.io
Maybe it's because I didn't fill in any other boxes?
The thing I hate is the warning that tells me that I'm about to view pages over a secure connection
Rightly so, because it "is a bad thing" and websites shouldn't be putting users in that position.
is easier.
You can combine nesting with for="id" to make sure you get complete compatibility.
<i>Some <b>text</i> here</b>
Part of the problem is that when assistive technology breaks, it's user is completely SOL. Another is that replacing it is often expensive (both financially and operationally). This makes it a lot harder than simply upgrading to the latest version of $browser.
edit: a comment below suggests that both of our comments are based on wrong info, and that screen readers and such actually prefer nested labels over id/for attributes. I don't have evidence either way, but I think both developers of websites and of AT are doing the handicapped a disservice as fellow humans.
That's a good reason to use the format the author suggested instead of nesting.
> In the following code examples, the names associated with the text input controls are not properly determined by assistive technology.
Which assistive technology? Why doesn't the assistive technology simply implement HTML properly? Associating a label with an element by nesting has been standardized since HTML 4.01 at least (I haven't bothered to check further back), and I'm pretty sure all of the browsers implement it properly.
Now, instead of simply writing a bunch of guidelines that say vaguely "not properly determined by assistive technology", they could show the results of testing, in a format similar to http://caniuse.com/. That would actually be useful; you could determine if the problem still exists or not, based on how many people are using some old buggy version of assistive technology.
But, rather, the WCAG are simply a bunch of prescriptive rules with vague justifications, and then various people on standards list try to argue that because there are laws that have been written that specify that certain things must comply with accessibility standards, these kinds of guidelines have the force of law and thus trump all other interests in standardization.
I am not arguing that you should ignore accessibility, or that it's not a good thing. What I'm saying is that there's a certain group of people in web standards who put accessibility over everything else, and refuse to adopt newer, better technologies for providing accessibility because some older, broken technology was already standardized on years ago.
For instance, there's the whole fight over longdesc in HTML5. longdesc has been standardized for a while, and lots of accessibility standards require or recommend it. It's supposed to contain a link to a page containing a textual description of the image; it is intended for cases in which you can't fit a full description into the "alt" attribute. But so many authors use it incorrectly; some just put the long description right in the longdesc attribute, some had broken links, and so on, that most screen reader users either ignored it or didn't even know it existed in the first place. One reason it's so badly broken is that normal user agents don't provide any way to access a longdesc attribute, so you never see that it's broken unless you try to use a screenreader and specifically test the longdesc.
So the HTML5 authors decided to deprecate longdesc in favor of newer solutions that were more likely to provide working description, like aria-describedby, which refers to another element on the page. That element is much more likely to work as it's already there on the page, visible to people using ordinary visual user agents, unless it's explicitly hidden. If you still want to provide a link to another page, you can just point aria-describedby at a link.
But many of the accessibility crowd complained loudly at deprecating the severely broken longdesc attribute, merely because it had already been included in so many accessibility guidelines like this, not because it was actually technically the best solution.
http://www.html5accessibility.com/tests/form-labels.html
Note that according to this document the use of ARIA, the new hotness in accessibility, actually confuses some combinations of accessibility tool and browser. Should we not use that?
I have to say, as someone with an interest in accessability, the tendency for the accesability "scene" to opt for changing the behaviour of millions of web devs by writing obscure documents that the vast majority of HTML coders will never be aware of, much less read, with fewer still understanding or following the complicated advice within, rather than working on fixing the handful of relevant software is baffling to me.
Maybe it's a holdover from when a stagnant IE6 ruled over the internet with no changes in sight. Now I'd rather see them apply market pressure by recommending anyone with accessability issues uses a browser/OS/accessability tool that actually works and put their effort into the various viable open source efforts.
Once a website reaches a certain scale (especially with rich web apps), global DOM id's become an almost impossible headache to deal with (because of multiple views which duplicate id's, coordination of global names across hundreds of files, etc.).
Global id's are basically an antipattern, whereas labels with nested controls have always seemed pretty workable.
The most effective way I've found to deal with them in those circumstances is to have them generated automatically at runtime when they are absolutely required. It's still a terribly backwards way of doing things, but at least you can ensure their uniqueness that way.
Since input elements already have unique names/values, otherwise the backend wouldn't know what you've posted. You can use a (scrambled) version of this, plus a sequence number if required in case of multiple inputs with same name.
Remembering to manually insert the label for every radio input is just bound to fail.
Instead, you identify your input elements with classes, use something like jQuery to read the values from elements with certain classes from inside a specific DOM element only (not globally), and then POST to the server using AJAX. Nowadays, user interface elements have no need to be tightly coupled with HTTP parameters.
ID's worked in the era of non-JavaScript. But for large dynamic sites where JavaScript is required (webapps, etc.), I haven't used ID's anywhere for years, thank God (like I said, an antipattern).
For example, <label id="R_../../checkbox1+_label"> would be renamed to the id of the first checkbox on the parent's parent with _label appended to it. The library could be smart enough to only recognize the R_ prefix as needing to be renamed.
Not saying that you should do that, just that you could.
The label element may contain at most one descendant input element,
button element, select element, or textarea element.
1. http://www.velocityreviews.com/forums/t155840-nesting-inside...
I would argue that when you're creating dynamic content, dealing with IDs is inelegant. If I already have a reference to a DOM node, I shouldn't have to assign it a unique ID just so I can tell another node about it.
I think "normal" checkbox label behavior is very much ingrained in the web development community, thats why I suppose the developers at LinkedIn know about it as well.
I'm really not. My experience with LinkedIn in terms of production quality code has been quite bad - not being able to unsubscribe from emails because of bugs that crash the website among the most annoying one.
<%= label_tag :is_premium, 'Toll free? (e.g. 1-888--*)' %> <%= check_box_tag :is_premium, true, params[:is_premium] %>
Am I doing it right?
Another neat thing it does is optionally render dropdowns with fewer than 3 choices as radios -- 1 click to select vs 2.