boogdesign posts

Longer posts on standards based web design, portable web development and Linux, intermingled with some stuff on my other nerd interests.

Rob Crowther, London, UK based Blogger, Web Developer, Web Designer and System Administrator - read my Curriculum Vitae

Buy my book!

Book CoverHello! HTML5 and CSS3 available now

Buy my other book!

Book CoverEarly access to HTML5 in Action available now

Categories: Web Design, Information Architecure, Standards, HTML and CSS, Usability & Accessibility

29/05/08

11:59:28 pm Permalink WSG London Findability Meetup

Categories: Usability & Accessibility, Information Architecure, Front End Web Development, Standards, HTML and CSS, Semantic Web and Microformats

Review: Web Standards Group London Meetup at Westminster University, New Cavendish Street campus, London 19:00 to 21:00

Concepts of Findability (Cyril Doussin) - This was a whirlwind tour of the subject of findability, mostly based on Peter Morville's Ambient Findability, since you can probably just go and read the book I'm just going to mention a couple of things Cyril talked about that caught my ear, first - what's the difference between data, information and knowledge?
Data
An unevaluated set of symbols
Information
An evaluated, validated or parsed set of symbols
Knowledge
A set of symbols which have been understood

You can easily see this definition in the context of the Semantic Web project - moving the web from data/information into the realms of knowledge. Cyril then discussed several general strategies for making things findable: The "In Your Face" Discovery Principal (basically, traditional advertising); Hand Guided Navigation (web directories and drill-down hierarchical menu systems); Describe and Browse (search engines); Recommendations (forums, mailing lists, Digg and other interactive systems). Several websites combine two or more of these to improve findability, for example Yahoo now suggest categories for drill-down with your search results. Cyril then discussed how to measure the relevance of search results, by considering the precision (lack of false positives) and the recall (exhaustiveness) against the requirements for the type of search (for some searches recall is more important than precision and vice versa) before finishing off with a brief chat about content organisation.

Building Websites with Findability in mind (Stuart Colville) - This talk was mostly regular SEO type stuff, five basic requirements were covered:

  • Understand your potential audience - this almost goes without saying, but you everything in the design and structure of your website should be driven from who your visitors are and what they're after.
  • Have compelling content - with the wealth of content already available on the web, you've got to find a way to make your content stand out. Either be completely original, which is difficult, or aim at a niche market where there isn't so much competition. This could also come from presenting existing content in a new way to better serve the needs of your target audience. Also, try and keep your content focussed - pictures of your cat might be very cute, but unless they're relevant to the main topics of your website consider hosting them elsewhere.
  • Use quality markup - this was the meaty bit of the talk and ranged across a number of sections:
    • Follow web standards in your markup, while it won't turn poor content into compelling content, it will improve the ratio of content to code on your page
    • Pay attention to your meta tags, while keywords are ignored the description is often displayed in search engine results so should have something relevant to the current page
    • Titles and headings are important,. Titles always appear in search results and will also be the default link text for any of your content in social bookmarking services (ie. they're link juice keywords - check this out for an idea of how bad many people are at this - I got "1 - 10 of about 36,900,000"). Remember your h1 heading is the most important visible text on the page, for most pages on your site this will not be your company name and/or logo
    • Text content should use the semantically correct element, strong and em can be used to give particular phrases higher weight but use them sparingly, duplicate content is not the issue it used to be especially if it's 'natural' (eg. a blog where the same post will normally appear on several pages)
    • Images which are purely design elements should be CSS backgrounds, images which have some data should use CSS image replacement and inline images should always be given correct metadata (where 'correct' sometimes implies 'none')
    • Microformats can improve findability, particularly after Yahoo!s recent announcement
    • Javascript should always be unobtrusive and you should practice progressive enhancement
  • Always keep accessibility in mind - remember a search engine has a similar view of the web to someone using a screen reader, improving your accessibility will usually also improve your findability
  • Present no barriers to search engines
    • Website performance affects indexation - search engine spiders only spend a finite time crawling your site, so the quicker you deliver pages the more will get indexed
    • URLs are an important opportunity to add keywords, and remember "A cool URI is one which does not change." Learn to use mod_rewrite and remember to give correct HTTP responses - 301 for content which has moved, 404 for content which you need de-indexed
    • Be careful that you don't block off important parts of your site with the robots.txt file

Finding yourself with Fire Eagle (Steve Marshall) - Fire Eagle is a service which helps you manage your location. It sits between your location provider (GPS device, mobile phone etc.) and your location dependent services and presents a uniform interface to those services while also letting you control your privacy. The key point is that it breaks the tight coupling that usually exists between 'location getting device' and 'location using software' which should therefore facilitate an explosion in location driven websites when it goes online (Google are experimenting with a similar thing in Gears, so it's an idea who's time has come). One very nice feature was it's use of OAUTH to set privacy levels - you can determine for each service the amount of geographical detail it will get and the API returns to the service a hierarchical object which goes down to the level of accuracy you specify (eg. country -> city -> locality -> postcode -> geo). This talk and it's associated demos/examples was very interesting, but you probably need to see it in action to really grasp how cool it could be.

Overall I enjoyed this event, though I was already familiar with a lot of material in Stuart's talk it's always good to have a refresher/reminder, and I learned some new things in both the others so 4 out of 5

Technorati tags for this review:    

Tweet this!
2 feedbacks »PermalinkPermalink

21/01/08

11:41:55 pm Permalink Web Development for the Blackberry Pearl

Categories: Usability & Accessibility, Front End Web Development

We had a potential client which wanted to use our web application on their Blackberry Pearl devices. I figured "How hard can it be?", downloaded an emulator and got cracking :) I wanted to make the standard pages support the Pearl, I didn't want to write a whole new web app, without changing how they worked on desktop browser to avoid confusing existing customers.

The tips below are things I specifically ran into on the Pearl, I imagine they'll apply pretty well to any low end mobile browsing device.

Tables make layout inflexible - the Blackberry has a fairly narrow screen when compared to a desktop. If your form laid out is in a table which is several hundred pixels wide the chances are it's not going to fit in the width. Since your page is most likely already too long for the display this is going to leave users having to scroll in two axes to complete the form. To avoid this I changed all the forms I expected to get used on the Pearl into a tableless layout which then used CSS to achieve the same display on the desktop, and then add a mobile stylesheet to override this:

<link rel="stylesheet" href="style/handheld.css" media="handheld" type="text/css">

This meant they lay out in a grid on a desktop browser but in a linear column on mobile devices

No javascript by default - the web app I was working with has been in production for more than five years, so it has it's share of hairy code particularly in the javascript department - a mixture of inline and external. One of the main issues for me was that so much of the supporting functionality depended on JS - for instance the search form could be filled out and submitted, but the functionality for scrolling through the results depended on onclick events on buttons. I re-wrote the forward and back buttons to be wrapped in little forms of their own which submitted to the correct URLs to solve that fairly easily (and that worked just as well for full desktop browsers too).

The more difficult situation was the input form, which, although it allows free text input, also allows you to select from a list of available options. Unfortunately the way this has always worked is for users to click on a button which launches a pop-up window, then double click on the item they want out of the resulting select list. The value is then inserted into the main form and the window closed, and the whole process is driven by javascript.

So, obviously it's not going to work at all without any javascript. I should point out this represents a bad design decision, I should have started with a form which worked without javascript and layered the enhanced behaviours on top (a technique known as progressive enhancement, but way back when the decisions were made I didn't know any better and neither did anyone I worked with. So I was re-writing the page in my ASP era web app, but I wanted to keep visually identical (close enough, at least) to the previous version. Here's an example of what the form components looked like before I started (names have been changed to protect the innocent):

<tr>
<td>
  <input class="standardWidth" value="Service Group" onclick="openPopup('Default.asp?WCI=listItems','PopUp','300','680');" type="button">
</td>
<td>
  <input autocomplete="off" name="txtITEM" id="txtITEM" size="25" maxlength="20" title="Click button to display list" value="" type="text">
<div style="display: none;" class="auto_complete" id="txtITEM_complete">
</div>
<script type="text/javascript">
new Ajax.Autocompleter('txtITEM', 'txtITEM_complete', 'Default.asp?WCI=listItemUL', {minChars: 2});
</script>
</td>
</tr>

A quick note here so you don't get lost - I'm using scriptaculous for the auto complete, openPopup is a fairly standard popup function, all the server side functionality is encapsulated in a WebClass, basically a VB6 DLL embedded in an ASP page, so different pages are called up by varying the WCI= parameter.

After I'd switched to a tableless layout (see above), my first step was to comment out all the javascript, this broke everything &amp;#58;&amp;#41; Next, I changed the input element to be a submit. Every button on the form would submit it and I planned to then detect which button had been clicked on the server side. This is relatively straightforward, just give all your submit buttons a common name (but a unique id so you can reference them individually in script):

<div>
    <span class="colLeft">
        <input type="submit" name="butLogForm" id="subITEM" class="standardWidth" value="ITEM">
    </span>
    <span class="colRight">
        <input type="text" name="txtITEM" id="txtITEM" size="25" maxlength="25" value="" title="Click button to display list">
    </span>
</div>

Then, on the form target page you check the value of butLogForm, so in VB6/ASP it's Request( "butLogForm" ), and its value will be the whatever you assigned to the button which was clicked (ITEM in the above example). So if a button other than the 'main' submit button has been pressed it's easy to detect this and redirect to the appropriate selection page for the field (which would be the same page as was originally appeared in the popup window summoned by clicking the button). I then added some plumbing to direct the popup page to either submit the value as a form or populate with javascript into opener depending on how it was called and to capture all the values behind the scenes once the user had selected them.

So now the form worked fine with javascript disabled, the only task left was to make it work as it did before in a desktop browser, popup windows and auto-completes, when javascript was enabled. This was slightly complicated by the need for the javascript to know the URLs for all the pages, and these could be changed at runtime, so I decided to pass them all in as parameters to the onload function (there is a URLFor) utility function available within the webclass which calculates them). To reduce the number of URLs to be passed in I used a naming convention so that the URL for the auto-complete function could be easily generated from the popup URL by appending 'UL' to it:

if ($('subITEM')) {
    $('subITEM').onclick = function () {openPopup(urlITEM + '&IsForPage=Log','PopUp',width,height); return false;};
    if (!$('txtITEM').readOnly) {
        var elTxtITEM = $('txtITEM');
        acDiv = document.createElement('div');
        acDiv.className = "auto_complete";
        acDiv.id = "txtITEM_complete";
        elTxtITEM.parentNode.appendChild(acDiv);
        new Ajax.Autocompleter('txtITEM', 'txtITEM_complete', urlITEM + 'UL', {minChars: 2});
    }
}

The code is fairly simple. First I check to see if the relevant submit button actually exists (there are configuration settings in the app to turn each field on and off) and, if it does, adds the old popup code to the button. Next I check to see if the text field is editable (another configurable option) and add both the div required by the Ajax.Autocompleter and then initialise the control itself.

The <button> element is useless - well it might not be completely useless, I didn't try too hard, but I decided I was only using it in the first place to show off my l33t HTML skills so I just switched them back to regular input elements.

No CSS by default - the browser on the Blackberry Pearl will not use CSS by default, though you can change the configuration to enable it and it will then respect the mobile stylesheet. The main problem this posed for me was that, in a lot of places, I was relying on padding and borders to provide spacing between text elements, eg:

<div><span><strong>Status:</strong></span><span>Active</span></div>

So when CSS is turned off you end up with tall the text running together with no spaces in between, making it hard to read. Since in this situation it's impossible to control the presentation with CSS I resorted to using markup for it and added &nbsp; glyphs inside the spans in every place where the text needed a space.

Turning on javascript leads to memory errors (slowly) - just like CSS, the browser on the Blackberry Pearl will not use javascript by default. This leads to the issues I already covered above, but a more amusing issue occurs if the user happens to enable javascript. The Pearl is a low memory device, even compared to other smart phones, and if your web app has several hundred kilobytes of javascript for it to download it will use up all of that memory in a vain attempt to parse the file. Since all the javascript gets downloaded in a standard header this led to a long wait and then an error message when you even tried to access the login page on my app. I made an extremely cut down javascript file, basically the standard field validation and date formatting functions, the openPopup function and some empty function stubs for all the onload functions (to avoid error messages). Since I didn't have the time or resources to implement WURFL or DeviceAtlas and this is only ever likely to be used in controlled corporate environments, I made a user configuration setting in order to send the cut down version to the Blackberry instead of the regular JS .

Only onchange on inputs, no onblur or onfocus - the final thing that caught me out was to do with my validation and formatting helpers on text inputs, these were all hanging off onblur and were not getting fired on the Pearl. The quick solution was to change everything to onchange instead, though the reason I'd used onblur in the first place was because I'd experienced some unreliability in the desktop browsers so this was not ideal. Unfortunately I had to wrap up this project before I had chance to get into it in more detail.


Tweet this!
Send feedback »PermalinkPermalink

16/10/07

03:02:19 pm Permalink My First Website for Mobiles

Categories: Web Design, Front End Web Development, Server Side Web Development

At work we decided to purchase a few .mobi domains, not because we have any particularly compelling mobile content, but to boost the web presence of our mobile product and, mostly, to make sure no-one else snapped up the domain names we wanted. However this did give me the opportunity to build my first website explicitly for mobile devices.

I'd checked our main website on ready.mobi, because I have written a mobile stylesheet for it, but it got a pretty crappy score mostly because of the sheer size of the content. So my main goals for this first site were to:

  • Produce a website which validated
  • Get a 'Good' score on the ready.mobi evaluator

My first task was some background reading, I had a look through the DotMobi Mobile Web Developer's Guide and Luca Passani's Global Authoring Practices for the Mobile Web. Following that, I grabbed a page off the main website and broke the content up into three XHTML-MP pages. This was easy enough to do after reading the guides, not much different from creating regular XHTML pages. The only bit I wasn't too familiar with was sorting out the navigation and access keys. It was easy on the home page (actual links changed for brevity):

<ol>
<li><a href="page1.php" accesskey="1">One</a></li>
<li><a href="page2.php" accesskey="2">Two</a></li>
<li><a href="page3.php" accesskey="3">Three</a></li>
<li><a href="page4.php" accesskey="4">Four</a></li>
</ol>

But on the other pages I wanted to avoid having a link to the current page, but keep a consistent numbering scheme, from 'page3.php':

<ol>
<li><a href="page1.php" accesskey="1">One</a></li>
<li><a href="page2.php" accesskey="2">Two</a></li>
<li value="4"><a href="page4.php" accesskey="4">Four</a></li>
</ol>

So that was the actual content sorted out, most of the issues I was seeing in the ready.mobi validator were to do with server side configuration. Some mobile browsers require a application/vnd.wap.xhtml+xml MIME type, which Apache isn't going to do by default, but is easy enough to configure. However, I wanted the website to display on my boss's desktop browser too and IE will have some difficulties with that, so I decided to use PHP to do some lightweight browser detection:

<?php
header("Cache-Control: no-transform, max-age=86400");
header("Vary: User-Agent, Accept");
if (strpos(strtolower($_SERVER['HTTP_ACCEPT']),'application/vnd.wap.xhtml+xml')>0) {
header("Content-type: application/vnd.wap.xhtml+xml");
} elseif (strpos(strtolower($_SERVER['HTTP_ACCEPT']),'application/xhtml+xml')>0) {
header("Content-type: application/xhtml+xml");
} else {
header("Content-type: text/html");
}
echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n";
?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

This works by looking to see what MIME types the browser says it can accept, then giving it the best one it can handle. Note that I'm also advising transcoding proxies not to transform this content.

The final setup step was to set appropriate cache headers on all the static content. This is easy to do in .htaccess:

<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 1 day"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType text/html "access plus 1 week"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
ExpiresActive Off
</FilesMatch>
</IfModule>

Note that I'm ignoring PHP files in this directive, as I'm already handling the headers in the PHP files.

One final note, as I discovered a few times while working on this, you need make sure your error pages also handle all the MIME type stuff and are valid XHTML-MP, otherwise the experience could be confusing for mobile users. This applies to 404 pages (I just made it a PHP page) and your formmail.php script (if you're using one).

And there you have it, my first real, live, mobile website!


Tweet this!
Send feedback »PermalinkPermalink

16/06/07

09:18:21 pm Permalink GDD07UK: Building a Mobile Website

Categories: Web Design

Review: Building an Interoperable Mobile Website at GDD07UK, The Brewery in London, 52 Chiswell Street, London 16:45 to 17:30

My final talk of the day was title on the signup page 'Developing for the mobile', which led me to believe it would be a discussion of web applications for mobile devices, but the title of the talk on the day was as above, and focussed mostly on web content rather than application type interactivity. Despite not fully meeting my expectations, this was perhaps the talk where I learned the most new stuff.

Gummi started with a discussion of why mobile website development has been so much more difficult than standard web development. Mainly this comes down to standards - although 'desktop' web developers complain about inconsistencies between popular browsers, this is nothing compared to the great variety of mobile browsers and devices and also the different standards that have been implemented. He recommended that these days it was best to concentrate on for the Japanese market and for the rest of the world.

Mr Hafsteinsson's golden rule for mobile websites - KISS. Generally that cunning feature you've thought of which would be 'neat' rather than useful to users is a feature you don't need on your mobile site. There were then a sequence of slides with more specific tips:

  • Use well formed markup - use the correct XML preamble and DOCTYPE declaration, validate your markup and specify character encoding. While it is feasible for a desktop browser to do a lot of processing to correct your markup mishaps, most mobile devices don't have enough spare processing power to deal effectively with invalid input
  • Send Google a Mobile Sitemap - on the mobile web people don't (generally) type in URLs, because typing options are usually fairly restricted and/or awkward on mobile devices, there is a much greater reliance on search engines so you need to do everything in your power to help the search engines out
  • Understand best practice - two sites specifically mentioned were the W3C's Mobile Best Practices and the dotMobi portal
  • Test in emulators - it's not feasible for you to obtain every mobile device on the planet, so testing in emulators is a good shortcut. Some of the specific emulators mentioned were the NTT DoCoMo i-mode HTML Simulator, the wmlbrowser extension for Firefox, the OpenWave emulator and the NetFront emulator (which has a Linux version) and, of course, Opera which can emulate the phone browser in the desktop version.
  • But don't just test in emulators - sites should be usable on entry level phones and provide an effective experience on mid-range devices. Be aware that these devices have far more limited physical features than your desktop development machine, things that work fine in the emulator on your desktop with 2Gb of RAM and a broadband connection might not work well, or at all, on a GSM phone with 64K of RAM. Again, don't overload your websites with features that overload more basic phones.

That was the bulk of the talk (actually relatively short), but there was a long question and answer session which covered the use of XHTML Mobile profile (and not Basic, as shown on the slide at the beginning) on .mobi websites and quite a lot of discussion on the merits and pitfalls of user agent sniffing (using, for instance, the WURFL device database). Gummi's advice was not to blindly adopt a sniffing approach, use standards for the most part and use sniffing to get round incompatibilities where appropriate for your users - generally think about your users rather than about the devices. Hopefully increasing use of standards in mobile websites will lead to better support of standards in mobile devices. The questions went on with some discussion of the Google mobile search and content transcoding (where Google automatically converts a website to mobile compatible format when you click on the link rather than sending the page directly), how this would become less necessary as more sites provided mobile versions of their content, and also a meta tag you could put in your head element to direct Google to the mobile version of a particular page (though I can find no mention of this elsewhere on the web, so if anyone locates it please leave a comment).

Overall an excellent talk despite being short, a bit high level and lacking code examples (which I know I've criticised other talks for, but in this case the high level information was very useful to me). Also the question and answer session covered a lot of extra ground, so 5 out of 5. If you are planning to get involved in the development of mobile websites I would recommend spending 45 minutes viewing this talk.

Technorati tags for this review:      

Tweet this!
1 feedback »PermalinkPermalink

05/06/07

07:24:29 pm Permalink Scriptaculous Draggable and Z-index

Categories: Web Design

I was building a prototype today using the Scriptaculous Draggable object. It was a fairly simple idea, a set of 'items' along the top of the page which could be dragged onto a selection of timeslots below, the idea being that by dragging the item to the timeslot you are 'booking' the item for that timeslot. Obviously in the real application this would have to link back to a database and do all sorts of complex stuff, but for now I just wanted to mockup how the UI would work.

I started off aiming to get the basic functionality working and not worrying too much about design. The Scriptaculous stuff is easy to use, I set up my items and timeslots as div elements and gave them a class name, then in my initialisation function used getElementsByClassName to get an array of elements to which I could apply the behaviour:

var els = $('available').getElementsByClassName('cat');
for (var i=0; i<els.length; i++) {
    new Draggable(els[i],{revert: true});
}

The droppable bit was a bit more complicated as I added event handler functions for onHover and onDrop:

var els = $('times').getElementsByClassName('slot');
for (var i=0; i<els.length; i++) {
    Droppables.add(els[i],{accept: 'cat', onDrop: catchDrop, onHover: showCatch } );
}

My catchDrop handler inserts an item into the booking slot, or increments the number of that item if one or more is already booked, though initially I just popped up an alert to confirm everything worked as expected. The showCatch handler changes the background colour of the element when a draggable is moved over it. I tried using Effect.Highlight initially, but it didn't interact well with the drag and drop stuff - if you tried to add an item to the bottom booking slot, all of the slots above became highlighted as well. So I settled for changing the background colour and used a brute force approach of removing the background colour from all the other elements before applying to the current one. Here is what I'd got so far.

With the basic functionality working I set about styling the page with CSS. I envisaged a 'toolbar' of items across the top with an 'Outlook style' collection of timeslots below. Since, in the actual application, there could be any number of items, I made the toolbar a fixed height and width and set it to scroll along the x axis:

#available {
    width: 100%;
    height: 64px;
    overflow-x: scroll;
    overflow-y: hidden;
}

This had an unfortunate side effect, however. Now when I dragged my items down onto the booking slots they were hidden behind the slots, and this looked a bit stupid. I did some experimenting with z-index for the various elements involved, but didn't have much joy - I got it sort of working in IE but that 'solution' hid all the booking slots in Firefox, so I resorted to Google. The first thing I learned was that Scriptaculous sets the z-index of the draggable element to 1000 - so clearly that shouldn't be the problem. Next, I wondered if the float: left I'd applied to the draggable elements somehow interfered with the the z-index, which led me to an article, with an excellent example, on the Mozilla developer site. This was useful information, and clearly floating does have some effect but it looked like it wasn't what was causing my problem. Finally I came across a CSS-d wiki article on z-index stacking context. Although I'm sure I haven't fully understood the article yet, this seemed to be the problem - the draggable elements were now in a different stacking context to the droppable elements, and this is why my z-index experiments weren't working. This got me to the root of the problem - if it worked fine before any CSS was involved, then something in my CSS was messing with the stacking context. Commenting the rules out one by one soon revealed the culprit - overflow-x creates a new stacking context (or at least, has an equivalent effect) in Firefox, whereas it seems IE's broken z-index handling was what allowed me to end up with something which worked there.

Rather than delve even deeper into the mysteries of z-index I chickened out and did the page without the overflow, it's only a mockup after all (which is also why it's only been tested in Firefox and IE7, before anyone starts complaining &amp;#58;&amp;#41; )


Tweet this!
11 feedbacks »PermalinkPermalink

30/04/07

11:53:55 pm Permalink Is your markup POSH?

Categories: Web Develop, Front End Web Development, Standards, HTML and CSS, Semantic Web and Microformats

Much like the cool name AJAX made DHTML seem sexy again, the standardista blogosphere has recently started pushing POSH as a new umbrella term for semantic markup good practice. I'm here to do my part to add what little weight I can to the meme.

Not surprisingly, the idea has come the the Microformats community - an IRC chat led to a dinner discussion IRL and that led to a wiki page. A blog post from Tantek and similar posts from others who were there added to the momentum and pretty soon there was also a Wikipedia page.

So how do you make your markup POSH? There is a handy checklist on the wiki page:

Before you right click, view source and get all critical, I know my blog skin could do with some work in this regard, and I'll be getting to that real soon now &amp;#59;&amp;#41; I also have a terrible habit of creating class names like 'red_text' which I'm working to get out of. In the meantime, do as I say, not as I do!


Tweet this!
Send feedback »PermalinkPermalink

17/02/07

12:48:49 am Permalink What is our legal exposure because of web accessibility laws?

Categories: Web Design, Web Develop, Usability & Accessibility

I spent just over an hour and a half writing an email after one of the directors where I work asked this question. It occurs to me that most of what I said in the email had some general applicability and there may be other people out there getting asked similar questions. It may be useful for all of us to compare notes, so I've edited all the company specific information out and you'll find the bulk of my response below. I'm interested in opinions on what I've said, what I could have said differently (or what I've got wrong!), other things I could have said and answers you may have given to the same question. Context: I work for a software company which provides a web interface as a secondary interface to a desktop application.

This entire response should be prefaced with the fact that I am not a lawyer and am therefore not qualified to determine legal risk. For definitive answers of our legal exposure we should consult a lawyer.

In my opinion we are unlikely to get sued directly unless we've explicitly promised in a contract or tender that we meet accessibility requirements. That's not to say that, should one of our clients get sued, we wouldn't find the costs passed on to us, but we are somewhat shielded as we are not offering a public service directly.

A number of our clients would be in a position to get sued, basically anything which:

  • provides a service to an employee through a website; or
  • provides a service to the public on a website; or
  • has anything to do with the government

is a viable target for legislation that currently exists in the UK. Note that ignorance of the law is not usually considered an excuse in this area.

In practical terms, it seems legal action is unlikely. Even since the government introduced the new guidelines in 2004, new websites commissioned by the government have not met those requirements - there was something of a fuss about at least one major project (see Blether: The DTI Responds for some info, and the resulting petition). For ultimate irony, consider that many of the legal accessibility documents provided by governments that I linked to in the email below are themselves in contravention of the web accessibility guidelines because they're only available in PDF or Word format... It seems that, even though the government has decided to make accessibility a legal requirement of any government web project they don't have anyone with the technical skills to asses whether or not the requirement has been met. In addition, comments I've read from representatives of major disability organisations in the UK indicate that, currently, those organisations would rather work with web site producers to improve accessibility rather than initiate confrontational legal action. However, it may be a case of waiting for the floodgates to open, the clients themselves are relatively unlikely to complain unless they face outside pressure. Any major UK government related projects or probably any project involving web in Australia, where we would either have agreed to supply a web application meeting accessibility requirements or it would have been an implied requirement, we may have some exposure.

From a technical standpoint, I only really started paying serious attention to this in the last six months. It is something of a technical minefield because, unlike other web standards, there aren't so many hard and fast rules and a lot of it comes down to the practicalities of popular screen reading software. Although there are standards, screen readers have to deal with the web as it is rather than as it ought to be. There are also a lot of folk on the web who are just parroting what they've heard before without actually having any practical understanding of the issues facing disabled users, these people often fall into the trap of assuming "standards compliance = accessibility" (myself included). It's also important to remember that disability does not equal blindness, there is a tendency to focus on blind users but there are also other vision related issues (eg colour blindness, partially sighted) as well as the wider world of disability (people with motor control issues clicking on small buttons).

One of the main problems from the point of view of our development process is that we are often trying to achieve a level of interactivity and presentation similar to desktop software under severe time pressure, and none of the people involved have much understanding of accessibility issues, so we usually take the easy way out. The lack of knowledge hurts us across the board, because at no point is there anyone who can assess the issues: client facing staff are in no position to evaluate the accessibility of client proposals and can land us with requirements which are always going to be problematic; sales staff focus on stuff which 'looks impressive' and that stuff often ends up in the product; developers are unable to meet accessibility requirements either because they're not aware of them or because there is time pressure to have an item produced; testers cannot test accessibility because they have no knowledge or experience in this area. Anyway, the result is that we have some issues with checkpoint 6.3 and checkpoint 6.4 of the WCAG (Web Content Accessibility Guidelines, which are the basis of most current legislation).

Here is a potted tour of our current web offerings and their level of accessibility: [Summary of our web products and how much effort it would take to get them up to full compliance went here]

So what can we do?

This was from an earlier email I sent which led to the question, I refer to it above so I include it for context:

Some further references in relation to the Accessibility stuff:

  1. Australia was the first country in the world where a legal case was brought and won against an inaccessible website (the Sydney Olympics site)
  2. Here are some guidelines to the Australian law, the key thing to note here is that, unlike some other countries, the focus is on all web sites rather than just government information
  3. Guidelines from an Australian government website
  4. This article discusses UK legislation which came into effect in 2004
  5. Here are the UK Government guidelines (ie. for government websites)
  6. The US Americans with Disability Act
  7. Some discussion of the US ADA
  8. US Section 508 summary
  9. Irish Disability Act
  10. Discussion of the recent Dutch Web Accessibility Laws, likely to be taken as a model for future European legislation

Tweet this!
Send feedback »PermalinkPermalink