This tends to leave us with a swathe of bug reports every time something slightly out of the ordinary crops up, which it's my job to fix. Recently a client reported a problem where they were unable to book any rooms in 2008. I isolated the problem to a single function, run in the onload event, which takes a date in dd/mm/yy format delivered from a Java applet, transforms it into the standard format for the server side app and then sticks it in a hidden field. Everything in '07' worked just fine, but anything in '08' ended up producing a date in 2000. The culprit was the
parseInt function, and the thing I didn't know was that numbers with a leading zero are interpreted as octal, and, of course, '08' is not a valid octal number so the
parseInt returned zero (and then had 2000 added to it, hence the final date). A change to
parseInt(strYear, 10) fixed the problem immediately.
As I scrolled through the code to look for other issues this may be causing I came across evidence that others (possibly even myself, it's hard to remember) had covered this ground before - a function called
removeLeadingZeroes featured fairly commonly inside
Every so often it's good to remind yourself how much you don't know...
It ought to have been a relatively straightforward task, and really it was if I'd been thinking clearly. The problem I encountered was that, after I'd separated everything into three files my neat pause/continue content cycling stuff went haywire in Opera. Everything still worked identically in IE6/7 and Firefox, but in Opera the pause button didn't pause, the panel disappeared for ten seconds at a time and my neat fade in/out effect for the skip link stopped working. I tried lots of weird and (in retrospect) wildly improbable fixes but nothing seemed to work, in desperation I tried putting it all back into the one file but still had the same problem. In the end I gave up and went home, had some tea, then fiddled with it for another hour, but still no joy.
A night's sleep turned out to be the cure for my stupidity, here's what was causing the problem: when everything was in the same file I'd been using the
onload attribute on the
init function programmatically, using a variant of Simon Willison's addLoadEvent function; while doing this I'd forgotten to remove the
onload from the
The interesting thing is that this only affects Opera. In IE and Firefox the
onload on the
body element replaces anything which
window.onload has been set to in script, in Opera it doesn't - both will get called, first the
onload on the
body element and then the
window.onload. If you're using global variables to, for instance, keep track of the current state of your little animation, and you're not checking the state of those variables when running your initialisation code, this will really mess things up...
My laptop is running SuSE 10.1, for which there are no official RPMs available. Celso Pinto has built some SuSE RPMs, but they're now several versions out of date, so I tried to build the latest version (1.1.37-1) using his spec file.
There were a number of bumps along the way (needed to install
mozilla-xulrunner180-devel, needed to pass the correct gecko-sdk paths to configure, needed to install
gnutls-devel and then wasted a couple of hours using an older version of the spec file so
rpmbuild kept falling over with
File must begin with "/" errors), but in the end - triumph!
Here's a SuSE i586 Mugsgot RPM (right click and save as, can't seem to get the mime type for x-redhat-package-manager working I'm afraid) and my modified spec file. Enjoy
Update: a newer version is available
With my increasing interest in accessibility issues I signed up for the WSG London Accessibility Meetup as soon as I heard about it. I can't remember anything else I've tried to learn where I've had my preconceptions (misconceptions really) shattered on such a regular basis. There were a couple of those moments in the evening's talks for me.
Three talks, so I'm having another crack at the hReview thing, this time three reviews in one post so I'm trying the include pattern (though I think I've got it a bit wrong, and I had to do a bit of hacking in b2evo to get the internal anchors to work...).
Accessible Flash from Niqui Merret, 19:00 to 19:30
Niqui started off with some justification. many web developers believe that Flash can never be accessible, and this is not true. Flash has a lot of built in support for accessibility such as access keys, labels and captions, and in addition can be used to detect the presence of a screen reader (if you're using IE on Windows...). It is also a misconception that a block of HTML content is necessarily more accessible than a Flash movie - the phrase 'a picture is worth a thousand words' can be applied here, some disabled users will have far more trouble reading a large block of text than they would assimilating an animation.
No technology is 100% accessible, but the process of making Flash as accessible as possible is the same as with any other technology - identify the barriers stopping people accessing your content and work out how to get around them. Flash has a number of built in mechanisms to help the developer overcome barriers - as previously mentioned it can communicate with screen readers and notify it of content updates, it can be keyboard driven and labels can be added which will be read out. Niqui then showed us a demo of a simple accessible Flash game she'd built, using it with a screen reader and keyboard, and showed us some other useful tricks which were possible - dynamically adjusting/inverting colours and contrast in the movie, and a simple script which allowed the movie to scale as the browser font size was changed. She also had some interesting points about the relationship between Flash and standards - there aren't going to be any standards for accessible Flash content until the 'standards people' accept Flash.
Niqui was enthusiastic about her subject matter and had excellent presentation skills, the talk was a definite eye opener in some respects, but Flash was unfortunately the thing I was least interested in so . out of 5
Accessibility, what not to do by Anne McMeekin, 19:30 to 20:00
Anne's talk covered some common pitfalls in building an accessible website, I noted down some highlights:
- Don't assume - not all disabilities are the same, some groups don't even class themselves as disabled even though they have accessibility requirements, so you can't predict how accessible your site will be to all of them. Also don't assume that disabled people won't be interested in what you have to offer.
- Don't ignore - if people complain about the accessibility of your site then that needs to be treated as an opportunity to improve, feedback is valuable.
- Don't forget the background - not everyone browses with a default background colour of white, if your site design depends on having black text on a white background it can look pretty horrible (and be hard to read) if a user is browsing on Windows using the high contrast theme if you don't explicitly set those colours in your stylesheet.
- Don't waffle - cut out unnecessary text like 'click here for', don't duplicate content across alt and title attributes and the link text as it could end up getting read out three times (and don't put crucial content only in the title attribute, as it may end up not getting read at all). Also remember that the popup boxes for alt and title attributes can often obscure important content for screen magnifier users, who need to keep the mouse pointer near to what they're reading. Don't make your pages unnecessarily long as vast swathes of text will fill up the screen reader's buffer and slow everything down.
- Don't be shy - biggest users of skip links are people with motor disabilities, not blind users, so hiding skip links and keeping them only for blind users is counter productive. Don't forget the :focus and :active pseudo classes as these are the ones which will be activated by keyboard only users.
- Don't leave it to chance - put unique information first on the page, don't take the chance that disabled users will leave before getting to the interesting content. Put instructions before the form to which they apply. If you have help info for items on your form then put the links to that help inside the labels otherwise they may be ignored by screen readers in 'forms' mode. Put the labels in the expected places (before inputs and selects, after checkboxes and options) so that users using screen magnifiers will see them. Also remember that, when using legends with fieldsets, many screen readers will read out the legend before the label for each form field - so keep the legend short and sweet (Anne mentioned one example she'd seen which had a 38 word legend!).
The subject matter of this talk was far better aligned with my interests, but Anne was a bit soft spoken which made it difficult to hear at points, and there weren't too many practical examples, so . out of 5
Web Accessibility by Mike Davies, 20:00 to 20:30
Mike's talk focussed on the business case for accessibility, and mostly related to his work in transforming the Legal and General website. His opening slide was quite impressive, he asked "What if a web agency walked into your office and promised the following things for your website re-design?":
- 40% increase in traffic
- Double the number of successful conversions
- Double the revenue generated by the site
- Get a return on investment for the re-design in five months
Although none of these were the explicit goals of the re-design, but they happened as a result of accessibility improvements.
Mike discussed some of the things which were required to get the whole project pushed through:
- Clear responsibility and vision - the goal of accessibility was driven from the top
- Define a role and career path for 'web Developers', don't let web pages be the thing trainees do before they move on to 'proper' development
- Have a consistent vision for the whole website, educate the content developers to understand accessibility requirements
- Choose a design agency which demonstrates an understanding of accessibility (assess the accessibility of websites in their portfolio, assess the accessibility of their own website, ask them to explain any shortcomings when they come in for an interview) - they chose Fortune Cookie
He also discussed the role of web standards with an anecdote from the early part of the project. One of Legal and General's web applications worked in IE but didn't work at all in Firefox, an attempt at validating the page showed several thousand errors but it turned out the main issue was a missing double quote on a single attribute. The point here is, if the page had been designed to validate from the start then an error like that would have stuck out like a sore thumb instead of being lost in a sea of other validation errors - Mike estimated this particular error cost the company approximately £20000 in lost business. One other thing Mike mentioned which stuck in my mind was that the biggest single asset in producing and accessible website was the imagination of the developer - they need to be able to imagine how differently abled people will interact with the site.
Overall this was probably the best talk of the night, there was a lot of information on the slides over and above what I discuss above including some detailed statistics, but, as the focus was on business issues, there was again a lack of practical examples, . out of 5
After the three talks there was a question and answer session which was very useful, touching on some of the legal requirements (British law requires a 'best effort' from the web developer so they should attempt to work around technological deficiencies; the RNIB and other similar organisations cannot sue you for having an inaccessible website, only individuals can sue; several legal actions have already been settled out of court) as well as some specific techniques and issues which hadn't be covered in the talks - Anne was particularly good.
Overall this was an excellent evening and I learned a lot, I'll be looking out for the next WSG meetup.
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?
- We need to raise general levels of awareness as far as accessibility is concerned. This can take a number of forms:
- Books: Web Accessibility: Web Standards & Regulatory Compliance, of course we need to figure out how to get people to read them
- Training for managers/HR/designers
- Training for developers
- Training for testers/designers
- Other: This company offer free demonstrations of screen reading software in use
- We should attempt to set up some sort of accessibility review process for UI changes, but will mean the people involved will all need to have some training.
- Testers need to be in a position to test accessibility, this means giving at least one person training and the tools required (ie. buy some copies of the common screen reading software, JAWS)
- We could hire or contract with a disabled person (or people) and use him as an expert
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:
- Australia was the first country in the world where a legal case was brought and won against an inaccessible website (the Sydney Olympics site)
- 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
- Guidelines from an Australian government website
- This article discusses UK legislation which came into effect in 2004
- Here are the UK Government guidelines (ie. for government websites)
- The US Americans with Disability Act
- Some discussion of the US ADA
- US Section 508 summary
- Irish Disability Act
- Discussion of the recent Dutch Web Accessibility Laws, likely to be taken as a model for future European legislation
Categories: Web Develop, Usability & Accessibility, Front End Web Development
This was the final talk of the day and I was flagging a bit, I'd originally planned to go to Scott Guthrie's WPFe talk, but that was packed out and, following Dave's stellar performance in the previous talk I was interested to see what he had to say on a subject I was a bit more familiar with.
- no target="_blank" - this assumes your user is browsing in a windowed environment
- Do we really need it?
- Will my links still work?
- Does this break the back button?
Another great talk from Dave with much useful advice, . I must admit to doing a lot of the href="#" stuff in my daily work as a sort of reflex action, it's a habit I should get out of! out of 5
Categories: Web Develop, Server Side Web Development
Review: Ruby On Rails for .NET Developers at WebDD Conference 07 14:30 to 15:30
After a brief spell writing a Ruby on Rails app last summer I always meant to do more stuff with it, but somehow I never got around to it. I was hoping this talk would re-ignite my enthusiasm and give me some good pointers.
Dave started off with some general background for the benefit of the .Net crowd, positioning C#/VB as comparable with Ruby and ASP.Net as Rails equivalent in the Microsoft world. He then moved on to an overview of Ruby:
- Ruby is Object Oriented - a lot of languages claim to be, but not many are as aggressively object oriented as Ruby, even null is an object
- Ruby is Readable - there were some good examples:
2.weeks.from_now.utcfor the date two weeks from today; punctuation for tests as in
x.null?; punctuation for destructive and non-destructive methods as in
- Ruby is Dynamic - and this is taken full advantage of in Rails, there were some more examples using
method_missingand the Linguistics add on, which extends built in objects
Next we moved on to Rails, and after some general discussion of convention over configuration the bulk of the presentation was a live demonstration of building a web application. The eye opening part of this for me was that Dave approached this in a completely different way to how I'd previously done it (in my admittedly limited experience). He started by defining his model and then adding fields using Rake migrations. I'd never paid any attention to Rake before but it looks very useful once you know what to do with it, basically you define your database upgrades and downgrades in Ruby so then it's easy to roll databases backwards and forwards.
The talk finished up with some references to how Microsoft is 'borrowing' some of the ideas in Rails, LINQ being quite similar to ActiveRecord and BLINQ performing similar tasks to the Rails scaffolding.
I really enjoyed this talk, what's not really coming across in my dry description of the talk above is what engaging presenter Dave Verwer really is, if you have a chance to go see him present I can highly recommend it. Overall this was my favourite talk of the day, . out of 5
Categories: Web Design, Web Develop, Usability & Accessibility, Server Side Web Development
Review: Quick and dirty Usability tests - one week, no budget, and no usability facility at WebDD Conference 07 12:00 to 13:00
I got "Don't make me think" for Xmas and so I've become quite interested in the concept of cheap usability testing, I was looking for this talk to give me a fresh perspective on what I'd read.
Zhivko started off with a short introduction on what usability is (ease of use, user efficiency, user satisfaction) and why it's important. Increased user satisfaction leads to:
- Increased sales
- Decreased development costs (more testing means less fire fighting)
- Improved brand image
- Improved user productivity (ie. when using internal applications)
The talk then moved to comparing remote testing (screen sharing over the internet) with 'traditional' testing methods (with usability labs and all the paraphernalia). Remote testing gives you:
- A realistic context of use - you're testing users in a 'real life' environment, where they're more comfortable
- Better geographic representation - with traditional methods it's very expensive to test outside the area where your office is located
- Access to professionals - if you're selling to a certain market, such as software developers, you might not be able to persuade them to travel to your lab
- Lack of non-verbal signals - this is a disadvantage, you don't see the non-verbal cues that indicate users are getting frustrated and so have to depend on what they're telling you
Zhivko discussed some research which demonstrated that, despite being much cheaper than traditional usability testing the results gained with remote testing is at least as effective.
The final part of the talk walked through the process for running usability tests at Telerik, here's a summary:
- Define Objectives & Target Audience
- Set up Test Scenario
- Recruit Test Users
- Carry out Tests
- Analyze Findings
- Design Report & Brief Stakeholders
This was littered with practical advice, such as good software to use (GoToMeeting, Camtasia), what sort of compensation to offer to ensure enough respondents (a little bit more than your target group's average hourly rate), how often to use the same testers (no more than twice a year) and even how to avoid putting testers under unnecessary time pressure (don't tell them in advance how many tasks there are).
An excellent talk, just the sort of thing I was looking for with all sorts of useful tips. The only problem I had was reading the slides off the TV screen (I was unfortunately right at the back) and sometimes hearing what Zhivko was saying (probably the being at the back thing again), . out of 5
I've recently re-installed the file server at home with Fedora Core 6, it all went fairly well apart from some intermittent hardware issues not related to the OS. A few days later, after a
yum update, I started getting an error after logging in to Gnome:
GConf schema installer error, battery_low_percentage cannot be zero
Since this machine is going to spend most of it's life not even plugged into a monitor I didn't consider it a big deal, but as the hardware issues have persisted, and as it therefore continued to use the monitor, power and network connection which are normally plugged in to my main desktop, it's become a bit more of an issue. So this morning I finally got round to researching the solution.
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
gconftool-2 --makefile-install-rule /etc/gconf/schemas/gnome-power-manager.schemas
killall -HUP gconfd-2
The difference to the steps described on the mailing list is the second step, it seems the default schemas are in a non-standard place in FC6. That got rid of the error message, but there were still some odd visual effects so I installed the
metacity.schemas. Looks like some sort of upgrade error stopped the default schemas being installed, so I'm guessing any similar errors can be resolved by choosing the relevant file from
/etc/gconf/schemas/ and using the above commands.
Review: Doing it in style: creating beautiful sites, the web standards way at WebDD Conference 07 10:40 to 11:40
Patrick started with an explanation of web standards, what they are and why they're good for you. The list of benefits he gave were fairly standard, but it's always worth reminding yourself:
- Lighter code - your HTML content is more lightweight as it doesn't contain repeated copies of your presentation code
- Ease of maintenance - when HTML is structured semantically it's much easier to make updates without breaking things than in pages built with five levels of table nesting
- Easier to change look and feel - because your look and feel is defined seperately from your content
- Multiple output media - handheld, print etc. from the same content
- Accessibility - reduce the number of potential customers who can't use your site
- SEO - increase the traffic to your site
The second section of the talk covered common pitfalls that CSS noobs fall into (been there, done that was my reaction to most of them, though I'm probably still guilty of some of them on occasion):
- New technology, old habits - the font tags have all gone, but they've been replaced by spans with inline styles
- Meaningless content - the font tags have all gone, but everything (including the headings) is a paragraph with an inline style
- Non-semantic class and id names - people often assume that class and id attributes are just there to hang CSS rules off of, but in fact they are an independent part of the HTML spec, they are a way of adding semantic value to your markup so don't use class names like 'red' when you mean 'important'
- Classitis and Divitis - adding unnecessary classes and ids to every element in your document when you could just use CSS selectors
The third section of the talk was the 'advanced' part where Patrick moved on to some specific CSS techniques. First up he covered tables, pointing out that the goal of standards based developers isn't to eradicate all tables from their markup but to use tables properly. A rule of thumb: if your data is the sort of thing you would lay out in an Excel spreadsheet, then you should probably mark it up as a table. Tables are an excellent way of showing data relationships and screen readers have built in functions for navigating across rows and columns, when designers build 'fake tables' out of
spans then you lose these good properties. These are good points, but I think the whole thing hinges on what your definition of 'tabular data' (or 'Excel-like data') is - my excuse for building 'fake tables' is when I want to lay things out differently on different devices (ie. on a web screen 7 columns and 4 rows, on a handheld device 4 columns and 7 rows, or even just a single column). This section also had some useful examples of the
scope attribute as well as
th in relation to
tbody and how it can styled, stuff which I'd not really appreciated before.
Next up were a number of techniques for 'fluff images' - using CSS background images instead of cluttering up the content with images which are purely presentational followed by a quick demonstration of the sliding doors technique. The talk was already running pretty late by this point so the section on image replacement was rushed through and I had to leave for the next talk I wanted to attend as Patrick moved onto forms, so I missed that, the layout portion and the conclusion.
The presentation was given in an engaging manner, and Patrick clearly has a very deep understanding of his subject, but the main problem was that he was trying to fit enough material for two talks into one hour of presentation. This spoiled a lot of the more advanced stuff, which was my primary interest, because it had to be rushed through. I still learned several useful things, and was given a few timely reminders of stuff I ought to know already, but overall this was the most disappointing talk of the day - . out of 5
Categories: Web Develop, Information Architecure, Front End Web Development, Server Side Web Development
Review: Microformats HTML to API at WebDD Conference 07 9:30 to 10:30
This was the first talk of the day, it was in the smallest room but it was packed to overflowing (people were sitting on the floor!) which is surely a good sign for the future of Microformats. The first part of the talk was a whirlwind tour of Microformats - what they are, how they're used and some examples. I was already familiar with this material so I didn't make any notes. The most interesting bit (for me) was the slide with a quote from Dan Cedarholm which referred to Microformats as 'oblivious development' - by adding semantic value to your markup you allow other to build value on top of it while you remain oblivious. A quick search today reveals I've been a bit oblivious myself, as this term seems to be in quite common use in the community, but at the time I thought it was nice.
In the second half of the talk Glen went on to the API part. His basic premise was that you should just add Microformats randomly to your web app and hope that the seeds would grow, you should think about how developers might want to use the information in your site and organise it in a consistent manner. He listed his REST-like principals for Microformats as API:
- Design URLs for maximum clarity and discoverability
- Design URLs into a schema to act as an API (his term here was 'faceted structures'
- Remember URLs have semantic importance
- Remember URLs can look and act like method calls (ie. composability of URL values, like searching by multiple tags in del.icio.us)
- Use HTTP verbs that work (a la REST, though Glen felt PUT and DELETE were not practical currently and POST should be used for updates)
His final advice for APIs was borrowed from the Microformat ethos: keep it simple. Simplicity gives you a lower barrier to entry which in turn increase the chance of take up. There was quite a long question and answer session after the talk which demonstrated Glen's in depth knowledge of the subject (in fact he appeared, to me, a lot more comfortable and knowledgeable in this interactive role than he had in the first part of the talk).
Overall pretty good, . I think, given the popularity of this talk, there was scope for having an introductory session and one or more advanced sessions rather than having to rush through the first half of it, but I learned a few things and enjoyed it. out of 5
Buy my book!Hello! HTML5 and CSS3 available now
Buy my other book!Early access to HTML5 in Action available now
- Semantic Web and Microformats
- Web Design
- Web Develop
This work is licensed under a Creative Commons Attribution-Share Alike 2.5 License.