Develop Reference

How to make a Select element accessible if it has no label?

I'm learning about accessibility in HTML and I came across an example of a Select dropdown HTML element, this element doesn't have any text label next to it, just the context of a title higher up the page gives an idea to what this element contains e.g. for example a list of countries on a section about countries.
When running an accessibility tool on it, the tool complains that there is no accessible name, I was wondering if there is a way to give this a name for a screen reader without having to add a label if that is not wanted as part of the design?

Short Answer
It isn't about what you want as part of your design, it is about what makes the page usable for as many people as possible. You should make the design work with a visible and properly associated label.
Longer Answer
There are ways we can add a label that isn't visible, one way being aria-label:
<select aria-label="label for the select">
</select>
Or we could use a visually hidden class on a <label> element so that it is still reachable by Assistive Tech (screen readers etc.) but does not show visually:
.visually-hidden {
border: 0;
padding: 0;
margin: 0;
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
clip: rect(1px, 1px, 1px, 1px); /*maybe deprecated but we need to support legacy browsers */
clip-path: inset(50%); /*modern browsers, clip-path works inwards from each corner*/
white-space: nowrap; /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
}
<label for="select1" class="visually-hidden">Label Text</label>
<select id="select1">
<option>Option 1</option>
<option>Option 2</option>
</select>
But although that helps people using Assistive Tech (AT) such as a screen reader, it doesn't help everybody else.
What if someone has a learning difficulty and cannot associate the options in your select with the heading further up?
What if someone is using a screen magnifier and needs a label close to the control to know what it is for?
What if someone is using a custom style sheet that changes your layout and the association based on the layout doesn't work anymore?
So the answer is to add a <label> that is visible and properly associated to make it accessible and better for everybody.
The design should not suffer from a visible label (and if it does, your graphic designer / UI team need to up their game!) and it is likely to have the added bonus that people will feel like the form is easier to fill out, increasing conversions (as you reduce "friction").
So the best thing is to add a visible label:
<label for="select1">The label</label>
<select id="select1">
<option>Option 1</option>
<option>Option 2</option>
</select>
Note the use of an explicit label using for="IDofSelect", rather than an implicit label - where you wrap the <select> in a <label>, as implicit labels can cause problems with voice software such as Dragon Naturally Speaking

Chaining CSS classes in IE6 - Trying to find a jQuery solution?

tl;dr = "Anyone know how to apply chained classes for IE6 using jQuery or similar?"
Right,
perhaps I ask the impossible? I consider myself fairly new to Javscript and jQuery, but that being said, I have written some fairly complex code recently so I am definitely getting there... however I am now possed with a rather interesting issue at my current freelance contract.
The previous web coder has taken a Grid-960 approach to the HTML and as a result has used chained classes to style many of the elements. The example below is typical of what can be found in the code:
<div class='blocks four-col-1 orange highlight'>Some content</div>
And in the css there will be different declarations for: (not actual css... but close enough)
.blocks {margin-right:10px;}
.orange {background-image:url(someimage.jpg);}
.highlight {font-weight:bold;}
.four-col-1 {width:300px;}
and to make matters worse... this is in the CSS:
.blocks.orange.highlight {background-colour:#dd00ff;}
Anyone not familiar with this particular bug can read more on it here: http://www.ryanbrill.com/archives/multiple-classes-in-ie/ it is very real and very annoying.
Without wanting to go into the merrits of not chaining classes (I told them this, but it is no longer feasible to change their approach... 100 hand coded pages into a 150 page website, no CMS... sigh) and without the luxury of being able to change the way these blocks are styled... can anyone advise me on the complexity and benefits between any of my below proposed approaches or possible other options that would adequately solve this problem.
Potential Solution 1
Using conditional comments I am considering loading a jquery script only for IE6 that:
Reads the class of all divs in a certain section of the page and pushes to an array
creates empty boxes off screen with only one of the classes applied at a time
Reads the applied CSS values for each box
Re-applies these styles to the individual box, somehow bearing in mind the order in which they are called and overwriting conflicting instructions as required
Potential Solution 2
read the class of all divs in a certain section of the page and push to an array
Scan the document for links to style sheets
Ajax grab the stylesheets and traverse looking for matching names to those in class array
Apply styles as needed
Potential Solution 3
Create an IE6 only stylesheet containing the exact style to be applied as a unique name (ie: class='blocks orange highlight' becomes class='blocks-orange-highlight')
Traverse the document in IE6 and convert all spaces in class declarations to hyphens and reapply classes based on new style name
Summary:
Solution 1 allows the people at this company to apply any styles in the future and the script will adjust as needed. However it does not allow for the chained style to be added, only the individual style... it is also processor intensive and time consuming, but also the most likely to be converted into a plugin that could be used the world over
Solution 2 is a potential nightmare to code. But again will allow for an endless number of updates without breaking
Solution 3 will require someone at the companty to hardcode the new styles every time they make a change, and if they don't, IE6 will break.
Ironically the site, whilst needing to conform to IE6 in a limited manner, does not need to run wihtout javascript (they've made the call... have JS or go away), so consider all jQuery and JS solutions to be 'game on'.
Did I mention how much i hate IE6?
Anyway... any thoughts or comments would be appreciated.
I will continue to develop my own solution and if I discover one that can be turned into a jQuery plugin I will post it here in the comments.
Regards,
Mike.
edit: added tl;dr to the top.

Here's a combination solution: http://code.google.com/p/ie7-js/
Fixes the multiple class bug and some other selector issues you may encounter.

I believe that if you look closely at how IE6 handles class chaining, and if the order of the class names are consistent, then you can avoid some of the IE6 issues with careful class coding.
First have a look at your provided HTML example:
<div class='blocks four-col-1 orange highlight'>Some content</div>
IE6 will apply the CSS in the order of the class names, starting with 'blocks' and continue through to 'highlight'.
Now look at your initial group of classes:
.blocks {margin-right:10px;}
.orange {background-image:url(someimage.jpg);}
.highlight {font-weight:bold;}
.four-col-1 {width:300px;}
These would be applied without any problems as each applies different properties. However, if you should, say, apply a different background with 'highlight' you should see that it will override the one set with 'orange'.
Using this same logic approach, let's have a look at the last class you defined:
.blocks.orange.highlight {background-colour:#dd00ff;}
This class should only apply to objects that have all three class names applied. What happens in IE6 is the first two class names are ignored and only the last class name is used to apply the styling. This means that any object that has the class 'highlight' will receive the new background property. (PS: the CSS property should be background-color, no 'u')
However, if you use other selector methods you can possibly avoid the limitations by applying nested ids/classes [#section .blocks] and/or object associations [form input.highlight]. This complicates the process I know, but at some point we simply need to stop trying to fully support out dated software.
Note: IE6 has not received any updates for two years and the browser itself is nine years old. The browser has two successors and a third is already in development. There should be some cutoff where an acceptable loss of presentation is allowed.

OK... as there is some confusion about what I am asking:
I have been called in to work on a project that is almost completed.
There are no templates.
There are 100+ pages, hand coded and a looming deadline. Here is some actual code from the HTML/CSS all written by the last guy (not abreviated like above):
<div class="block four-col-1 gold black-bg">
<h1>Self Managed Super</h1>
<a class="highlight" href="#"><span class="left bottom">
<strong><span class="text-white">Bolster your<br />
portfolio</span><br /></strong>
with unique<br />
investment<br />
options</span>
<img src="/AU/individuals/_images/superannuation-2.png" alt="" /></a>
</div>
<div class="block four-col-1 grey-light black-bg">
<h1>Self Managed Super</h1>
<a class="highlight" href="#"><span class="left bottom">
<strong><span class="text-white">Financial <br />
flexibility,</span></strong> <br />
into and <br />
throughout <br />
retirement
</span>
<img src="/AU/individuals/_images/superannuation-3.png" alt="" /></a>
</div>
and here is some of the relevant CSS:
.block .highlight {display:block;position:relative;height:auto;min-height:110px;-webkit-border-radius: 4px;-moz-border-radius: 4px;border-radius: 4px;}
.block .highlight:hover {border:1px solid #ddd;}
.block .bottom {position:absolute;font-size:11px;line-height:12px; bottom:10px;letter-spacing:-0.2px; }
.block .left {float:left;font-size:11px;margin-left:8px;width:75%;}
.block.black-bg p, .block.black-bg p * {color:#828282;}
.block.black-bg p * span.text-white {color:#fff;}
.block img {position:absolute;bottom:0;right:1px;z-index:0}
.block .highlight img {position:absolute;bottom:0;right:0px;z-index:0}
.highlight:hover {opacity: .75; filter: alpha(opacity=75); -ms-filter: "alpha(opacity=75)";-khtml-opacity: .75;-moz-opacity: .75; overflow:visible;}
.content .block.black-light.highlight, .block.black-light .highlight, .block.black-light
.block-inner {background:url(/AU/_images/system/block-black-light.gif) no-repeat top left;}
.content .block.grey-light.highlight, .block.grey-light .highlight, .block.grey-light
.block-inner {background:url(/AU/_images/system/block-grey-light.gif) no-repeat top left;}
.content .block.orange.highlight, .block.orange .highlight, .block.orange .block-inner {background:url(/AU/_images/system/block-orange.gif) no-repeat top left;}
.content .block.gold.highlight, .block.gold .highlight, .block.gold .block-inner {background:url(/AU/_images/system/block-gold.gif) no-repeat top left;}
.content .block.blue-light.highlight, .block.blue-light .highlight, .block.blue-light .block-inner {background:url(/AU/_images/system/block-blue-light.gif) no-repeat top left;}
.content .block.blue-dark.highlight, .block.blue-dark .highlight, .block.blue-dark .block-inner {background:url(/AU/_images/system/block-blue-dark.gif) no-repeat top left;}
.content .block.black-light.black-bg.highlight, .block.black-light.black-bg .highlight, .block.black-light.black-bg .block-inner {background:url(/AU/_images/system/black-block-black-light.gif) no-repeat top left;}
.content .block.grey-light.black-bg.highlight, .block.grey-light.black-bg .highlight, .block.grey-light.black-bg .block-inner {background:url(/AU/_images/system/black-block-grey-light.gif) no-repeat top left;}
.content .block.orange.black-bg.highlight.block.orange.black-bg .highlight, .block.orange.black-bg .block-inner {background:url(/AU/_images/system/black-block-orange.gif) no-repeat top left;}
.content .block.gold.black-bg.highlight, .block.gold.black-bg .highlight, .block.gold.black-bg .block-inner {background:url(/AU/_images/system/black-block-gold.gif) no-repeat top left;}
.content .block.blue-light.black-bg.highlight, .block.blue-light.black-bg .highlight, .block.blue-light.black-bg .block-inner {background:url(/AU/_images/system/black-block-blue-light.gif) no-repeat top left;}
.content .block.blue-dark.black-bg.highlight, .block.blue-dark.black-bg .highlight, .block.blue-dark.black-bg .block-inner {background:url(/AU/_images/system/black-block-blue-dark.gif) no-repeat top left;}
(Code is essentially exactly as he wrote it, in all it's unformatted, hideous beauty.)
If you can be bothered to read all that (and most of you probably can't - hence my abbreviations above) you would see that whilst some classes are unique and do not conflict, some do. The result is that some blocks which are expected to be balck, in EI6 are blue, and the margins in EI6 are often wrong, and the absolutely positioned images also break particularly when combined with an IE PNGFix to make them appear transparent as expected.
Also, due to the nature of the deadlines, assume that going over each and every of the 100+ pages and editing the HTML is no longer an option. This was my recommendation from day one and whislt the client accepts that what they have is well and truly less than ideal, they are also working to a tight deadline.
This leaves only two options for edits. Change the CSS so it works across all browsers (as this is called on each page), or generate some Javascript (again, this can be called onto each page using an include) to do something with the HTML on every page on the site, or something else tricky. Changing code in the included pages is easy, changing the HTML in each of the blocks in question is out.
I completely understand what everyone is commenting on so far and thanks for those... they were my initial solutions in both cases, and I wouldn't be on here if they were an option.
Thanks to everyone who has read this, but I really am trying to find some super tricky solution to the entire problem of non-chaining classes in IE6. potentially for broader use than this project. However I now only have 5 working days to find the answer before my contract ends, so if we don't we will just hack an IE6 style sheet that makes all the blocks appear in one way on that browser and leave it at that. I would prefer to find a universal solution, but... meh. Hopefully 18 months from now the user base of IE6 will be so low that it's no longer an issue.
Thanks everyone.
Cheers,
Mike.

I think you may have missed the point of my earlier comment. I was not confused about your request but was trying to explain how you might approach the task should the coding of the site be consistent.
For a more detailed example, lets take a line from your last CSS example, minus the actual styling properties:
.content .block.orange.highlight, .block.orange .highlight, .block.orange .block-inner { }
Following the behavior of Internet Explorer 6 in regards to chained CSS classes, that line of code would be seen by IE6 as:
.content .highlight, .orange .highlight, .orange .block-inner { }
Notice that the chained class names are ignored for all except the last name in the chain. Since you had already rejected the JavaScript solutions that were proposed by others, the only solution I can see is to design your CSS class definitions with this IE6 limitation in mind as you code.
This does not make the task simple as the whole reason for chaining the classes is to be able to apply special conditional styling without increasing the DOM nodes of the document. However, in order to continue to support enhanced feature programming in IE6, without the help of some JavaScript solutions, you will simply have to put in more effort to find older conventional methods for the same result. I know this comment is likely a bit late for your project but I hope it helps with the planning process when dealing with IE6 styling.

Styling HTML FORM elements with padding, with width 100%

I'm styling a form by using a table with fixed-width columns and I want the input elements inside the <td> to fill the container. I know the CSS box model and I know the elements would bleed through with width: 100%, but the problem is with its consistency.
<input> elements bleed through as expected but <select> elements don’t. This results in making my fields not line up properly. I've tried all properties like overflow, display, whitespace... it doesn’t make any difference. What’s with the <select> element? I can see in Firebug that they have the same box model properties with the input element, but they don’t render the same.
I’m using HTML 5 doctype and this happens both in Firefox and Chrome.
Right now, I’m fixing this using a JS function which selects all elements with class stretch and computes and sets the static width to make it fit inside the container. This perfectly lines up the elements of the form. (I had to exclude <select> elements because their widths were already okay... weird quirk.)
Is there a pure CSS solution to this? I wouldn’t want to run this function everytime a part of the page is updated, like on AJAX calls...

You could use box-sizing: border-box; on textfields and textarea's.
It solves te difference with the selectbox.

The best way is to fake the borders of the elements with a div.
<div class="formholder>
<textarea></textarea>
</div>
With this CSS:
.formholder {padding:10px;background:white;border:1px solid #ccc}
.formholder textarea {width:100%;padding:0;margin:0;background:white;border:0}
Of course, you can expand that for other fields. Some browsers might give you issues. Chrome and webkit allow you to resize textareas but if you add resize: none; to your CSS, it should disable it but YMMV.

It may help you to know the following results from various usability studies.
1) For most forms, people prefer to see the label just above the form element:
2) People find it useful if the form elements are sized appropriately to help suggest how much information is expected.
<ul>
<li><label for="firstname">First Name</label><br>
<input type="text" id="firstname" name="firstname" size="15"></li>
<li><label for="age">Age</label><br>
<input type="text" id="age" name="age" size="3"></li>
<!-- ... more list items -->
</ul>
Note: the list in this example would be styled so that it doesn't appear as a bullet-point list. Using lists in this way helps with accessibility as screen readers will tell the user how many items are contained in the list.
I thought this might be useful as it suggests that your efforts may be a bit wasted trying to layout the form in a table and stretch all inputs to the same length.
http://dev.w3.org/html5/markup/input.html#input

Not the most helpful answer, but CSS styling of form elements is pretty unreliable between browsers. A JavaScript solution like yours is the best bet.
Two reasons for the unreliability:
Some features of form elements can’t be described by CSS. The <select> element is a good example: there aren’t any CSS properties that can describe the different ways a <select> element looks on different operating systems.
Trying to work out which CSS properties should affect form elements, and how, is a rat’s nest for browser makers, so they’ve mostly left it alone. Safari is a notable exception; see e.g. http://webkit.org/blog/17/the-new-form-controls-checkbox-2/
You can argue that form elements should look the same between sites regardless of the site owners’ intentions, so that users know what they’re clicking on.
See http://meyerweb.com/eric/thoughts/2007/05/15/formal-weirdness/ for a deeper examination.

Say your html looks somewhat like this:
<form><table><tr>
<td><input type="text" /></td>
<td><select><option /><option /></select></td>
</tr></table></form>
How about just using the input and select for setting the width?
td { width: auto; }
input[type=text] { width: 100px; }
select { width: 100px; }
Or did I get your problem wrong?

The following CSS works for Moz Firefox, for html input elements (submit, button, text), textarea elements, and even select elements. The select elements are nearly equal length in the browser I'm trying.
table {width:100%;}
form input { width: 100%; }
form textarea { width: 100%; overflow-y: scroll; resize: vertical; }
form select { width: 100%; }

How do I make an area unclickable with CSS?

Let's say if I have wrapper div which includes some links and images,
is there any way I can deactivate it at once with CSS only?
After review of answers:
I dropped the idea that can make it with CSS only.
jQuery blockUI plug in works like charm.

There is a CSS rule for that, but it's not widely used because of old browsers support
pointer-events: none;

These days you can just position a pseudo-element over the content.
.blocked
{
position:relative;
}
.blocked:after
{
content: '';
position: absolute;
left:0;
right:0;
top:0;
bottom:0;
z-index:1;
background: transparent;
}
http://jsfiddle.net/HE5wR/27/

I think this one works too:
CSS
pointer-events: none;

if you are going to use jQuery, you can easily accomplish this with the blockUI plugin. ...or to answer your question with CSS, you'll have to absolutely position the div over the content you wish to block. just make sure the absolutely positioned div comes after the content to be blocked for z-indexing purposes.
<div style="position:relative;width: 200px;height: 200px;background-color:green">
<div>
Content to be blocked.
</div>
<div style="position: absolute;top:0;left:0;width: 200px;height:200px;background-color: blue;z-index:2;opacity:0.4;filter: alpha(opacity = 50)"></div>
</div>
sorry for all the inline css. you'll have to make some nice classes. Also, this has only been tested in firefox and IE7.

Cover it up with another un-clickable element. You may need to use JavaScript to toggle this "cover" on and off. You can do something clever like make it semi-transparent or something as well.
<style>
#cover {position:absolute;background-color:#000;opacity:0.4;}
</style>
<div id="clickable-stuff">
...
</div>
<div id="cover">
</div>
<script type="text/javascript">
function coverUp() {
var cover = document.getElementById('cover');
var areaToCover = document.getElementById('clickable-stuff');
cover.style.display = 'block';
cover.style.width = //get areaToCover's width
cover.style.height = //get areaToCover's height
cover.style.left = //get areaToCover's absolute left position
cover.style.top = //get areaToCover's absolute top position
}
/*
Check out jQuery or another library which makes
it quick and easy to get things like absolute position
of an element
*/
</script>

You should consider to apply the event.preventDefault function of jQuery.
Here you can find an example:
http://api.jquery.com/event.preventDefault/
TL;DR-version:
$("#element-to-block").click( function(event) {
event.preventDefault();
}
BAM!

If you mean unclickable so that the users can't copy and paste it or save the data somehow. No this has never really been possible.
You can use the jQuery BlockUI plugin or the CSS rule pointer-events: none; but that doesn't really prevent people from copying your text or images.
At worst I can always wget your content, and at best both css and js methods are easily circumvented using plugins like:
"Allow right click" on firefox or chrome
"Absolute enable right click and copy" on firefox or chrome
"Don't fuck with paste" on firefox or chrome
Further to the point, unless you have a really good and legitimate excuse for breaking basic browser behavior, usability, accessibility, translation functionality, password managers, screenshot tools, container tools, or any number of various browser plugins functionality in the users right click context menu, please, just, stop, doing, this.

Firefox page "moves" when hiding/showing divs

We have a web page with this general structure:
<div id="container">
<div id="basicSearch">...</div>
<div id="advancedSearch" style="display: none">...</div>
<div>
With this CSS:
#container { MARGIN: 0px auto; WIDTH: 970px }
#basicSearch { width:100% }
#advancedSearch{ width:100%;}
We have a link on the page that lets the user toggle between using the "basic" search and the "advanced" search. The toggle link calls this Javascript:
var basic = document.getElementById('basicSearch');
var advanced = document.getElementById('advancedSearch');
if (showAdvanced) {
advanced.style.display = '';
basic.style.display = 'none';
} else {
basic.style.display = '';
advanced.style.display = 'none';
}
This all works great in IE.
It works in Firefox too - except - when we toggle (ie: show/hide) from one div to the other, the page "moves" in Firefox. All the text in the "container" moves about 5px to the left/right when you toggle back and forth. Anyone know why?

Is it causing a scrollbar to appear / disappear?

Toggling content can make the page content taller. Check whether this makes a scrollbar appear, as this will affect the page width slightly.

What I ended up doing was this: HTML { OVERFLOW-Y:SCROLL; OVERFLOW-X:HIDDEN; }
Here's a good related SO post.

Check your XHTML is well formed, sounds like a dangling DIV (firebug will help with this).
On a side note jquery has some really nice animations that make this switch much nicer on the eyes.

I don't know why, but if you install Firebug a Firefox plug in you can use it to debug your problem.
Firebug has saved my hours of debugging time when it comes to CSS and showing and hiding divs.
With firebug you can view what may be different between the two divs.
From firefox, just choose the Tools Menu, then click Ad-Ons, then click Get Ad-Ons and search for firebug.
One thing that you could try is to hide before you show, this may have less flicker. If you are causing the page to get taller, this could be the source of your trouble.
I hope this helps.