Yes I know, both Molly and Derek have reported on it already, but after pointing out in my 10 reasons why clients don’t care about accessibility article that one reason is that nobody has been sued properly yet, it seems we are one step in that direction.

Target is being sued for inaccessibility. From the webaim list:

This is to bring to your attention that a web accessibility lawsuit has been filed against the retail store Target. For further information, please see the disability rights advocates site . There are two links about NFB v. Target at the bottom of the page – one is a factsheet and the other is the actual complaint filed February 7, 2006. The International Center on Disability has also posted the information on their homepage at http://www.icdri.org. Filed in California State court, the complaint alleges violations of the California Unruh Civil Rights Act and the California Disabled Persons Act. Relief requested includes statutory damages which may include treble damages under the Unruh Civil Rights Act. California law incorporates the Americans with Disabilities Act provisions in the Unruh Civil Rights Act and provides for relief beyond that available at the federal level.

The very interesting part is that target seem to be only a whitelabeled site using the Amazon API, once again proof that the backend can be good but you still can make a pig’s ear out of it.

A client asked for a proof of concept how you could create large clickable boxes as a navigation. They wanted the whole box clickable, and if the link is a section link with child elements they wanted an indicator that there is more. The links without children should simply send the user to the site, the parent links should not follow the main link, but expand the children.

Check out the demo page: large boxes as links and feel free to get inspired. If wanted, I can write a quick explanation on how it is done and you could send sexier styles.

I just decided to celebrate the sale of a commercial license for my tree menu script pureDOMexplorer by creating a new version, which fulfils the change requests I had in the past. The new version of pde now

• turns a nested list with the class “pde” into a tree menu – which means you can use it more than once on a page
• uses fully unobtrusive JavaScript, including addEvent and encapsulation of all functionality in one pde object.
• creates collapse and expand links and allows the section links to link to a landing page
• allows for both keyboard and mouse to expand the sections (I still have to fix the tabbing issue over hidden elements)
• keeps all the look and feel in the CSS - you don’t need to know JavaScript to change the look and feel
• does not collapse lists that contain a STRONG element – to allow for a “you are here” state in your trees.

You can check and see the new version at the new pureDOMExplorer demo page

Now, it all works fine in MSIE/Opera/Firefox on PC, but on Safari I cannot make the hiding and showing to work without resorting to the inaccessible display block/none solution.

Currently my demo CSS uses the “Off Left” technique, as recommended to be most accessible :


/* The class to hide nested ULs */
.hide{
position:absolute;
top:0;
left:-4000px;
width:1px;
}

/* The class to show nested ULs */
.show{
position:relative;
top:0;
left:0;
width:auto;
}

Update
Ingo Chao took on the challenge and fixed the Safari issue. All working fine now.

Update
Following the requests in the comments to make the parent link also collapse and expand the nested list, I changed the script and added a new parameter called linkParent. If the parameter is false the parent link will point to the document it links to, if it is true, it will collapse and expand the same way the arrows do.

Jeff Han is doing some research on Bi-manual, multi-point, and multi-user interactions on a graphical interaction surface and watching the 17MB demo reel got me hooked on the idea. The accessibility of it of course is not mentionable, but how cool would it be to sort your digital pictures by dragging them with your finger or even use this interface for card sorting exercises resulting in an XML sitemap?

It is bad practice to rely on the maxlength attribute of form fields to ensure the real length of entered data. That much I knew, as playing with curl made me aware how vulnerable forms are on the wild wild web.

However, I was a bit agog when I realised that it is possible to change the value of a field to a word longer than maxlength on MSIE and Opera.

I set up a demo that shows how to override maxlength with JavaScript .

So, don’t trust maxlength, make sure to also check the real length on the server side.

[tags]security, HTML, maxlength, webdevtrick[/tags]