rowid,title,contents,year,author,author_slug,published,url,topic
125,Accessible Dynamic Links,"Although hyperlinks are the soul of the World Wide Web, it’s worth using them in moderation. Too many links becomes a barrier for visitors navigating their way through a page. This difficulty is multiplied when the visitor is using assistive technology, or is using a keyboard; being able to skip over a block of links doesn’t make the task of finding a specific link any easier.

In an effort to make sites easier to use, various user interfaces based on the hiding and showing of links have been crafted. From drop-down menus to expose the deeper structure of a website, to a decluttering of skip links so as not to impact design considerations. Both are well intentioned with the aim of preserving a good usability experience for the majority of a website’s audience; hiding the real complexity of a page until the visitor interacts with the element.

When JavaScript is not available

The modern dynamic link techniques rely on JavaScript and CSS, but regardless of whether scripting and styles are enabled or not, we should consider the accessibility implications, particularly for screen-reader users, and people who rely on keyboard access.

In typical web standards-based drop-down navigation implementations, the rough consensus is that the navigation should be structured as nested lists so when JavaScript is not available the entire navigation map is available to the visitor. This creates a situation where a visitor is faced with potentially well over 50 links on every page of the website. Keyboard access to such structures is frustrating, there’s far too many options, and the method of serially tabbing through each link looking for a specific one is tedious.

Instead of offering the visitor an indigestible chunk of links when JavaScript is not available, consider instead having the minimum number of links on a page, and when JavaScript is available bringing in the extra links dynamically. Santa Chris Heilmann offers an excellent proof of concept in making Ajax navigation optional.

When JavaScript is enabled, we need to decide how to hide links. One technique offers a means of comprehensively hiding links from keyboard users and assistive technology users. Another technique allows keyboard and screen-reader users to access links while they are hidden, and making them visible when reached.

Hiding the links

In JavaScript enhanced pages whether a link displays on screen depends on a certain event happening first. For example, a visitor needs to click a top-level navigation link that makes a set of sub-navigation links appear. In these cases, we need to ensure that these links are not available to any user until that event has happened.

The typical way of hiding links is to style the anchor elements, or its parent nodes with display: none. This has the advantage of taking the links out of the tab order, so they are not focusable. It’s useful in reducing the number of links presented to a screen-reader or keyboard user to a minimum. Although the links are still in the document (they can be referenced and manipulated using DOM Scripting), they are not directly triggerable by a visitor.

Once the necessary event has happened, like our visitor has clicked on a top-level navigation link which shows our hidden set of links, then we can display the links to the visitor and make them triggerable. This is done simply by undoing the display: none, perhaps by setting the display back to block for block level elements, or inline for inline elements. For as long as this display style remains, the links are in the tab order, focusable by keyboard, and triggerable.

A common mistake in this situation is to use visibility: hidden, text-indent: -999em, or position: absolute with left: -999em to position these links off-screen. But all of these links remain accessible via keyboard tabbing even though the links remain hidden from screen view. In some ways this is a good idea, but for hiding sub-navigation links, it presents the screen-reader user and keyboard user with too many links to be of practical use.

Moving the links out of sight

If you want a set of text links accessible to screen-readers and keyboard users, but don’t want them cluttering up space on the screen, then style the links with position: absolute; left: -999em. Links styled this way remain in the tab order, and are accessible via keyboard. (The position: absolute is added as a style to the link, not to a parent node of the link – this will give us a useful hook to solve the next problem).

a.helper {
	position: absolute;
	left: -999em;
}

One important requirement when displaying links off-screen is that they are visible to a keyboard user when they receive focus. Tabbing on a link that is not visible is a usability mudpit, since the visitor has no visible cue as to what a focused link will do, or where it will go.

The simple answer is to restyle the link so that it appears on the screen when the hidden link receives focus. The anchor’s :focus pseudo-class is a logical hook to use, and with the following style repositions the link onscreen when it receives the focus:

a.helper:focus, a.helper.focus {
	top: 0;
	left: 0;
}

This technique is useful for hiding skip links, and options you want screen-reader and keyboard users to use, but don’t want cluttering up the page. Unfortunately Internet Explorer 6 and 7 don’t support the focus pseudo-class, which is why there’s a second CSS selector a.helper.focus so we can use some JavaScript to help out. When the page loads, we look for all links that have a class of helper and add in onfocus and onblur event handlers:

if (anchor.className == ""helper"") {
	anchor.onfocus = function() {
		this.className = 'helper focus';
	}
	anchor.onblur = function() {
		this.className = 'helper';
	}
}

Since we are using JavaScript to cover up for deficiencies in Internet Explorer, it makes sense to use JavaScript initially to place the links off-screen. That way an Internet Explorer user with JavaScript disabled can still use the skip link functionality.

It is vital that the number of links rendered in this way is kept to a minimum. Every link you offer needs to be tabbed through, and gets read out in a screen reader. Offer these off-screen links that directly benefit these types of visitor.

Andy Clarke and Kimberly Blessing use a similar technique in the Web Standards Project‘s latest design, but their technique involves hiding the skip link in plain sight and making it visible when it receives focus. Navigate the page using just the tab key to see the accessibility-related links appear when they receive focus.

This technique is also a good way of hiding image replaced text. That way the screen-readers still get the actual text, and the website still gets its designed look.

Which way?

If the links are not meant to be reachable until a certain event has occurred, then the display: none technique is the preferred approach. If you want the links accessible but out of the way until they receive focus, then the off-screen positioning (or Andy’s hiding in plain sight technique) is the way to go.",2006,Mike Davies,mikedavies,2006-12-05T00:00:00+00:00,https://24ways.org/2006/accessible-dynamic-links/,ux
127,Showing Good Form,"Earlier this year, I forget exactly when (it’s been a good year), I was building a client site that needed widgets which look like this (designed, incidentally, by my erstwhile writing partner, Cameron Adams):



Building this was a challenge not just in CSS, but in choosing the proper markup – how should such a widget be constructed?

Mmm … markup

It seemed to me there were two key issues to deal with:


	The function of the interface is to input information, so semantically this is a form, therefore we have to find a way of building it using form elements: fieldset, legend, label and input
	We can’t use a table for layout, even though that would clearly be the easiest solution!


Abusing tables for layout is never good – physical layout is not what table semantics mean. But even if this data can be described as a table, we shouldn’t mix forms markup with non-forms markup, because of the behavioral impact this can have on a screen reader:

To take a prominent example, the screen reader JAWS has a mode specifically for interacting with forms (cunningly known as “forms mode”). When running in this mode its output only includes relevant elements – legends, labels and form controls themselves. Any other kind of markup – like text in a previous table cell, a paragraph or list in between – is simply ignored. The user in this situation would have to switch continually in and out of forms mode to hear all the content. (For more about this issue and some test examples, there’s a  thread at accessify forum which wanders in that direction.)

One further issue for screen reader users is implied by the design: the input fields are associated together in rows and columns, and a sighted user can visually scan across and down to make those associations; but a blind user can’t do that. For such a user the row and column header data will need to be there at every axis; in other words, the layout should be more like this:



And constructed with appropriate semantic markup to convey those relationships. By this point the selection of elements seems pretty clear: each row is a fieldset, the row header is a legend, and each column header is a label, associated with an input.

Here’s what that form looks like with no CSS:



And here’s some markup for the first row (with most of the attributes removed just to keep this example succinct):

<fieldset>
	<legend>
		<span>Match points</span>
	</legend>
	<label>
		<span>Win</span>
		<input value=""3"" />
	</label>
	<label>
		<span>Draw</span>
		<input value=""1"" />
	</label>
	<label>
		<span>Lose</span>
		<input value=""0"" />
	</label>
	<label>
		<span>Played</span>
		<input value=""0"" />
	</label>
</fieldset>

The span inside each legend is because legend elements are highly resistant to styling! Indeed they’re one of the most stubborn elements in the browsers’ vocabulary. Oh man … how I wrestled with the buggers … until this obvious alternative occurred to me! So the legend element itself is just a container, while all the styling is on the inner span.

Oh yeah, there was some CSS too

I’m not gonna dwell too much on the CSS it took to make this work – this is a short article, and it’s all there in the demo [demo page, style sheet]

But I do want to touch on the most interesting bit – where we get from a layout with headers on every row, to one where only the top row has headers – or at least, so it appears to graphical browsers. For screen readers, as we noted, we need those headers on every row, so we should employ some cunning CSS to partly negate their visual presence, without removing them from the output.

The core styling for each label span is like this:

label span
{
	display:block;
	padding:5px;
	line-height:1em;
	background:#423221;
	color:#fff;
	font-weight:bold;
}

But in the rows below the header they have these additional rules:

fieldset.body label span
{
	padding:0 5px;
	line-height:0;
	position:relative;
	top:-10000em;
}

The rendered width of the element is preserved, ensuring that the surrounding label is still the same width as the one in the header row above, and hence a unified column width is preserved all the way down. But the element effectively has no height, and so it’s effectively invisible. The styling is done this way, rather than just setting the height to zero and using overflow:hidden, because to do that would expose an unrelated quirk with another popular screen reader! (It would hide the output from Window Eyes, as shown in this  test example at access matters.)

The finished widget

It’s an intricate beast allright! But after all that we do indeed get the widget we want:


	Demo page
	Style sheet


It’s not perfect, most notably because the legends have to have a fixed width; this can be in em to allow for text scaling, but it still doesn’t allow the content to break into multiple lines. It also doesn’t look quite right in Safari; and some CSS hacking was needed to make it look right in IE6 and IE7.

Still it worked well enough for the purpose, and satisfied the client completely. And most of all it re-assured me in my faith – that there’s never any need to abuse tables for layout. (Unless of course you think this content is a table anyway, but that’s another story!)",2006,James Edwards,jamesedwards,2006-12-11T00:00:00+00:00,https://24ways.org/2006/showing-good-form/,ux
142,Revealing Relationships Can Be Good Form,"A few days ago, a colleague of mine – someone I have known for several years, who has been doing web design for several years and harks back from the early days of ZDNet – was running through a prototype I had put together for some user testing. As with a lot of prototypes, there was an element of ‘smoke and mirrors’ to make things look like they were working. 

One part of the form included a yes/no radio button, and selecting the Yes option would, in the real and final version of the form, reveal some extra content. Rather than put too much JavaScript in the prototype, I took a preverbial shortcut and created a link which I wrapped around the text next to the radio button – clicking on that link would cause the form to mimic a change event on the radio button. But it wasn’t working for him. 

Why was that? Because whereas I created the form using a <label> tag for each <input> and naturally went to click on the text rather than the form control itself, he was going straight for the control (and missing the sneaky little <a href> I’d placed around the text). Bah! There goes my time-saver.

So, what did I learn? That a web professional who has used the Internet for years had neither heard of the <label> tag, nor had he ever tried clicking on the text. It just goes to show that despite its obvious uses, the label element is not as well known as it rightfully deserves to be. So, what’s a web-standards-loving guy to do? Make a bit more bleedin’ obvious, that’s what! 

The Mouse Pointer Trick

OK, this is the kind of thing that causes some people outrage. A dead simple way of indicating that the label does something is to use a snippet of CSS to change the default mouse cursor to a hand. It’s derided because the hand icon is usually used for links, and some would argue that using this technique is misleading:

label {
	cursor: pointer;
}

This is not a new idea, though, and you didn’t come here for this. The point is that with something very simple, you’ve made the label element discoverable. But there are other ways that you can do this that are web standards friendly and won’t upset the purists quite so much as the hand/pointer trick. Time to wheel in the JavaScript trolley jack …

Our Old Friend AddEvent

First things, first, you’ll need to use the addEvent function (or your favourite variation thereof) that Scott Andrew devised and make that available to the document containing the form:

function addEvent(elm, evType, fn, useCapture)
{
	if(elm.addEventListener)
	{
		elm.addEventListener(evType, fn, useCapture);
		return true;
	}
	else if (elm.attachEvent)
	{
		var r = elm.attachEvent('on' + evType, fn);
		return r;
	}
	else
	{
		elm['on' + evType] = fn;
	}
}

Finding All Your Labels

Once you’ve linked to the addEvent function (or embedded it on the page), you can start to get your JavaScripting fingers a-flexing. Now, what I’m suggesting you do here is:


	Identify all the label elements on the page by working your way through the DOM
	Find out the value of the for attribute for each label that you uncover
	Attach a behaviour or two to each of those label elements – and to the input that the label relates to (identified with the for attribute)


Here’s the technobabble version of the steps above:

function findLabels()
{
	var el = document.getElementsByTagName(""label"");
	for (i=0;i<el.length;i++)
	{
		var thisId = el[i].getAttribute(""for"");
		if ((thisId)==null)
		{
			thisId = el[i].htmlFor;
		}
		if(thisId!="""")
		{
			//apply these behaviours to the label
			el[i].onmouseover = highlightRelationship;
			el[i].onmouseout = hideRelationship;
		}
	}
}
function highlightRelationship()
{
	var thisId = this.getAttribute(""for"");
	if ((thisId)==null)
	{
		thisId = this.htmlFor;
	}	
	this.className=""showRel"";
	document.getElementById(thisId).className=""showRel"";
	//if (document.getElementById(thisId).type==""text"") document.getElementById(thisId).select();
}
function hideRelationship()
{
	var thisId = this.getAttribute(""for"");
	if ((thisId)==null)
	{
		thisId = this.htmlFor;
	}	
	this.className="""";
	document.getElementById(thisId).className="""";
}
addEvent(window, 'load', findLabels, false);

Using the above script, you can apply a CSS class (I’ve called it showRel) to the elements when you hover over them. How you want it to look is up to you, of course. Here are a few examples of the idea. Note: the design is not exactly what you’d call ‘fancy’, and in the examples there is one input that looks broken but it is deliberately moved away from the label it relates to, just to demonstrate that you can show the relationship even from afar. 



	Background colour changes on hover
	Background colour change + mouse pointer trick
	Background colour change + mouse pointer trick + text selection


Hopefully you’ll agree that using an unobtrusive piece of JavaScript you can make otherwise ‘shy’ elements like the label reveal their true colours. Although you might want to tone down the colours from the ones I’ve used in this demo!",2006,Ian Lloyd,ianlloyd,2006-12-13T00:00:00+00:00,https://24ways.org/2006/revealing-relationships-can-be-good-form/,ux
144,"The Mobile Web, Simplified","A note from the editors:  although eye-opening in 2006, this article is no longer relevant to today’s mobile web.
                
                
                      
                Considering a foray into mobile web development? Following are four things you need to know before making the leap.

1. 4 billion mobile subscribers expected by 2010

Fancy that. Coupled with the UN prediction of 6.8 billion humans by 2010, 4 billion mobile subscribers (source) is an astounding 59% of the planet. Just how many of those subscribers will have data plans and web-enabled phones is still in question, but inevitably this all means one thing for you and me: A ton of potential eyes to view our web content on a mobile device.

2. Context is king

Your content is of little value to users if it ignores the context in which it is viewed. Consider how you access data on your mobile device.  You might be holding a bottle of water or gripping a handle on the subway/tube. You’re probably seeking specific data such as directions or show times, rather than the plethora of data at your disposal via a desktop PC.

The mobile web, a phrase often used to indicate “accessing the web on a mobile device”,  is very much a context-, content-, and component-specific environment. Expressed in terms of your potential target audience, access to web content on a mobile device is largely influenced by surrounding circumstances and conditions, information relevant to being mobile, and the feature set of the device being used. Ask yourself, What is relevant to my users and the tasks, problems, and needs they may encounter while being mobile? Answer that question and you’ll be off to a great start.

3. WAP 2.0 is an XHTML environment

In a nutshell, here are a few fundamental tenets of mobile internet technology:


	Wireless Application Protocol (WAP) is the protocol for enabling mobile access to internet content.
	Wireless Markup Language (WML) was the language of choice for WAP 1.0.
	Nearly all devices sold today are WAP 2.0 devices.
	With the introduction of WAP 2.0, XHTML Mobile Profile (XHTML-MP) became the preferred markup language.
	XHTML-MP will be familiar to anyone experienced with XHTML Transitional or Strict.


Summary? The mobile web is rapidly becoming an XHTML environment, and thus you and I can apply our existing “desktop web” skills to understand how to develop content for it. With WML on the decline, the learning curve is much smaller today than it was several years ago. I’m generalizing things gratuitously, but the point remains: Get off yo’ lazy butt and begin to take mobile seriously.

I’ll even pass you a few tips for getting started. First, the DOCTYPE for XHTML-MP is as follows:

<!DOCTYPE html PUBLIC ""-//WAPFORUM//DTD XHTML Mobile 1.0//EN""
""http://www.openmobilealliance.org/tech/DTD/xhtml-mobile10.dtd"">

As for MIME type, Open Mobile Alliance (OMA) specifies using the MIME type application/vnd.wap.xhtml+xml, but ultimately you need to ensure the server delivering your mobile content is configured properly for the MIME type you choose to use, as there are other options (see Setting up WAP Servers).

Once you’ve made it to the body, the XHTML-MP markup is not unlike what you’re already used to. A few resources worth skimming:


	Developers Home XHTML-MP Tutorial – An impressively replete resource for all things XHTML-MP
	XHTML-MP Tags List – A complete list of XHTML-MP elements and accompanying attributes


And last but certainly not least, CSS. There exists WAP CSS, which is essentially a subset of CSS2 with WAP-specific extensions. For all intents and purposes, much of the CSS you’re already comfortable using will be transferrable to mobile. As for including CSS in your pages, your options are the same as for desktop sites: external, embedded, and inline. Some experts will argue embedded or inline over external in favor of reducing the number of HTTP connections per page request, yet many popular mobilized sites and apps employ external linking without issue.

Stocking stuffers: Flickr Mobile, Fandango Mobile, and Popurls Mobile. A few sites with whom you can do the View Source song and dance for further study.

4. “Cell phone” is so DynaTAC

If you’re a U.S. resident, listen up: You must rid your vocabulary of the term “cell phone”. We’re one of the few economies on the planet to refer to a mobile phone accordingly. If you care to find yourself in any of the worthwhile mobile development circles, begin using terms more widely accepted: “mobile” or “mobile phone” or “handset” or “handy”. If you’re not sure which, go for “mobile”. Such as, “Yo dog, check out my new mobile.”

More importantly, however, is overcoming the mentality that access to the mobile web can be done only with a phone. Instead, “device” encourages us to think phone, handheld computer, watch, Nintendo DS, car, you name it.

Simple enough?",2006,Cameron Moll,cameronmoll,2006-12-19T00:00:00+00:00,https://24ways.org/2006/the-mobile-web-simplified/,ux