you are here: | |

register for updates | contact   

Added on Thursday 1 Jan 1970


Am Jerry Frances By name and am located in uk,am sending you enquiry for you service by building a website for me.
Please kindly get back to me to know your service and your cost.
I will be waiting to read from you as soon as possible.

Jerry Frances | Sat Mar 05 2005

Just skimmed the interesting diagram:

* What about semantics? Standard markup doesn't mean semantic markup (or does it, inevitably?), so the generation of, for example, a list of all document headlines can be by all means useless in an in other respects standards compliant document.

* What about "auxiliary techniques" like "skip navigation" links etc., are they located in "alternative content"? It might be useful to add them explicitly since they might be the icing on the cake.

* What about processes like user tests? A technically accessible site can be absolutely unusable (thus being inaccessible nonetheless). It might be useful to add this issue, too.

Just some thoughts, I like the idea of this diagram.

Jens Meiert | Mon Jan 03 2005

is very usufull diagram
but the way to do this (accessibility)
is still to much no clear
we need this also

bob | Sun Nov 14 2004

hmm...funky formatting...forgot. hope it makes some kind of sense nonetheless.

Patrick H. Lauke | Thu Aug 19 2004

worth adding: in case you are using PHP and sessions, PHP itself may add the session ID to links and form elements. to ensure that it uses & rather than & when attaching the session variable to a link that already has GET arguments:

if you have access to php.ini, make sure you change arg_separator.input and arg_separator.output to

arg_separator.input = '&'
arg_separator.output = '&'

You may be able to do this in an .htaccess file

php_value arg_separator.input '&'
php_value arg_separator.output '&'

As a last resort, you may be able to override it at the beginning of all your scripts in PHP itself


Patrick H. Lauke | Thu Aug 19 2004

Ah ha, I've found that article I mentioned: <a href=""

Certainly an interesting alternative.

Guy Carberry | Thu Jul 22 2004

Alternatively, dont use imagemaps. Use CSS as detailed on a recent A List Apart article (site seems to be down at the moment so cant provide a link unfortunately).

Guy Carberry | Wed Jul 21 2004

Good suggestion Jim. Another aspect of Checkpoint 10.5 is that the character between links needs to be audible to acocunt for different screen readers and speaking browsers. We've had experiences with designers using small simple graphics between links in horizontal menus with null alt text. While this can look nice and is fine in some screen readers, others (like Home Page Reader) just run the links together. So, another hint for Checkpoint 10.5 is to use "printable and audible" characters between links.

Andrew Arch | Tue May 18 2004

The BWDMA are already working on this issue - see <a href=""
target="_blank"></a>. Maybe the two groups should work together.

Andrew Arch | Wed Apr 28 2004

One other reason why we use the described technique is the inability of older Geckos to display floated label elements. We didn't want to use tables for the forms, but unfortunately the labels (positioned via floats) wouldn't show in Netscape 7.0 and older (7.1 doesn't show this behaviour) - so users would be left in the cold without a hint what too fill in where.

Tomas Caspers | Fri Feb 20 2004

Hi Jim,

Rather than specifying a string literal for the check, you could reuse the same event handler with:


I fail to see that the user agent(s) that had this problem are in popular use today, as they would be more or less useless on the Web. I agree with Patrick that this guideline should be considered obsolete, as it definitely creates more of a usability issue than the problem it was intended to solve. If JavaScript is switched off, which is a more likely scenario that someone with a user agent that is incapable of navigating to a form field with no placeholder text, the visitor has to manually delete the text.

Gez Lemon | Wed Feb 11 2004

p.s.: spoke personally to shawn lawton henry <a href=""
target="_blank"></a> yesterday at the best practices session in madrid <a href=""
target="_blank"></a> ... and i quizzed her about "can we now finally assume that this guideline is obsolete" ? well, she said yes - and if i'm not mistaken, WCAG 2.0 will not feature anything like this...
so, there we have it, from the horse's mouth (although i certainly wouldn't call the charming shawn a horse by any means)

Patrick H. Lauke | Wed Feb 11 2004

Thanks for the pointer to your example scripts - and your suggestion that this guideline is obsolete.

All the best,

Jim Byrne | Sun Feb 08 2004

Hi Patrick, your original comment is still on the page, in the tips section. I have yet to update the comments code in this site to the latest version, but I added in the url parsing in response to your request.

All the best,

Jim Byrne | Sun Feb 08 2004

oh...i now implemented automatic comment parsing...

Patrick H. Lauke | Sat Feb 07 2004

what happened to my comments ?
as i pointed out, i did something similar back in june, with a nice script that goes through your entire page for you, and uses title to prepopulate inputs...

see <a href="">this post at sitepoint</a> and <a href="">the thread to put it in context</a>

on a sidenote, though: i've asked a few times on the WCAG IG list, but nobody seems to know (or wants to aknowledge) the answer..."are there any user agents in circulation today that don't handle empty form elements correctly ?"
my experience is no, making this guideline obsolete in my eyes (and even something of a usability issue)

Patrick H. Lauke | Sat Feb 07 2004

we're using something very similar at and it helps us to work around some other issues. Older Browsers (and that unfortunately includes older Geckos as well) tend to choke on floated label- and form elements. The duplication guarantees that the info from the label isn't lost when it is not displayed.

Tomas Caspers | Fri Feb 06 2004

I realize that this is an old post, but thought I would drop in my $.02.
Whether we use table-based layout or CSS, I think it is also important that if we place the content first, it can be helpful to offer a 'skip to navigation' link. Or, if the navigation is first, offer the more traditional 'skip to content.'

Christopher Phillips | Fri Dec 12 2003

Hello Jim,

I have been involved with and organisation with several hundred legacy pdf’s most of which were pretty inaccessible. The perceived wisdom at the time was to provide an accessible equivalent, such as a ‘word’ document because, as was explained to me, ‘word’ is accessible. Now in the event I soon discovered that many of the ‘word’ documents (from which the pdf’s were derived) were just about as inaccessible as the pdf’s themselves. I have been struggling to find an ‘idiots guide’ to writing accessible ‘word’ documents, either to be used on their own or to be subsequently converted to pdf’s. Either I am way off beam or this must be a common occurrence. Could I have your view and do you know of any web resource that might help me?



Fraser Syme | Tue Nov 18 2003

Hi Patrick, Thanks for the suggestion; splitting style sheets up by font, size and colour - I'll need to have a think about how that would work in practice.

We were aware of the cache issue - but at the moment I can't think of a way around it.

All the best,

Jim Byrne | Mon Nov 03 2003

the only downside i can think of here is that the stylesheet won't be cached on the user's machine, as it's generated afresh each time, and on sites with enormously high traffic the additional processing necessary to create the stylesheet might become noticeable.
a different approach could be to split up the stylesheets into sections: one for the actual font sizes, one for the colour, and one for anything else. this would then limit the number of stylesheet that theoretically need to be created from being (number of font sizes * number of colours) to (number of font sizes + number of colours)...
but yes, for all intents and purposes, the impact of dynamically generating the css each time should be negligible for all but the most heavily visited sites.

patrick h. lauke | Fri Oct 31 2003

Site gets better and better Jim. Really useful.

David Donald | Sun Oct 26 2003

Thanks for the link Gez - I'll check it out.

All the best,

Jim Byrne | Wed Oct 22 2003

The following link is quite useful for an introduction to colours:

Gez Lemon | Wed Oct 22 2003

Hi Anette, I am not sure what you mean - or what you are referring to - can you give me more information?

All the best,

Jim Byrne | Wed Oct 01 2003

this doesn` work - nothing changed ??

anette merker | Tue Sep 30 2003

Adding to the list of resources: a discussion of <a href="">Optimal Web Typography</a> at Typographica.

Stephen Coles | Fri Sep 05 2003

Adding to the list of resources: discussion of <a href="">Optimal Web Typography</a> at <cite>Typographica.</cite>

Stephen Coles | Fri Sep 05 2003

<p>OK, so it looks like some of my HTML was processed by the comments system. Let's hope that this works. The big heading should be marked up HTML like this:</p>

<blockquote>&lt;h1&gt;This is the heading&lt;/h1&gt;</blockquote>

<p>And let's make the links clickable:</p>

<li><a href="">stopdesign's Douglas Bowman's article on the technique</a></li>
<li><a href="">Stuart Langridge comes up with an alternative</a></li>
<li><a href="">Dave Shea discusses the technique at Digital Web</a></li>
<li><a href="">Mike at phark adds a more accessible version</a></li>

<p>Of course, there's nothing wrong with putting an image directly in the markup either.</p>

Owen | Sun Aug 17 2003

There's been an awful lot of discussion in the Web design community recently about using CSS to replace text in an <hx> element with a background image. The idea is to have a heading as text in the markup:

<h1 id="foo">This is the heading</h1>

while replacing it with an image via the background-image property in CSS. Several techniques are now in place, some more accessible than others.

See the following for more info:

Owen | Sun Aug 17 2003

Sell the benefits of accessible web design to web designers, and people who are responsible for commissioning websites.

Jim Byrne | Thu Jun 12 2003

Good point; if there is adequate 'context' to the link, then I can see that ther should be no confusion. However, there will be cases when links are extracted from the page presented as a summary list (some screen readers can do this), and then, the context is lost.

There is another less relevant point, and that is: because I have a site that is about accessible web design, I get people checking my site because they would love to e-mail me to tell that 'isn't it ironic that your site doesn't pass Bobby'. Rather than have to waste time replying to such e-mails I'd rather sort out even the 'daftest' of errors Bobby throws up.

Jim Byrne | Thu Jun 12 2003

Let's see if they actually OBEY ATAG or not.


Kynn Bartlett | Thu Jun 12 2003

In my opinion, as long as it's within a legitimately structured page, there's nothing wrong with having two links that both read "permalink" but which go to different locations.

Joe Clark made a good argument for this recently on the WCAG working group, and he's right.


Kynn Bartlett | Thu Jun 12 2003

Okay, I'll bite -- sell to whom?


Kynn Bartlett | Thu Jun 12 2003

I agree that CSS is the right approach; I've spent the last two days running an accessible web design training course saying exactly that. But there are still a lot of people using tables for layout, and they will be doing it for a while yet. So they might as well learn a few tricks to make their tables more accessible while they are at it - no?

Jim Byrne | Fri May 30 2003

I dunno, I think it's time we stop coddling people with layout tables and urged them to use CSS. These days, CSS is pretty darn well supported for layout, in truth, and there's only a few cases in which you'd actually need to resort to layout tables.


Kynn Bartlett | Fri May 30 2003

Add your comment
Tick the box if you used markup in you comment.