You are currently browsing the Christian Heilmann blog archives for May, 2007.
Here are the slides from my talk at the Webstandards Group meetup earlier. A massive Thanks to Stuart Colville for organizing the event, Steve Faulkner for his presentation on screen readers and accessibility and everyone who attended and bought me drinks afterwards.
Slideshare.net version:
One of my biggest annoyances when talking about accessibility and web development is the argument of some developers that what they develop are web applications and not web sites which is why they don’t need to care about accessibility. The arrogance of that statement aside it also does not make any sense whatsoever. If anything, web applications should be even more accessible than web sites. A blind or a keyboard user not being able to learn about the new sports range of a certain brand is less problematic than the same user not being able to do a money transfer or apply for council benefits.
I have suffered for years trying to fill in overly complicated timesheet and room billing systems, and frankly I didn’t see anything to be proud of and consider yourself above the rules of normal web development. If anything, the logic that the system will be used in a closed environment with fixed parameters lead to many solutions that age terribly bad. Most of the time this happens because of time constraints or limitations of the systems used to create these applications. It is stunning how companies get stingy when it comes to spending another 2 weeks on development but don’t mind their employees wasting 30 minutes each time they enter their timesheets instead of 2. Maybe some accountant department should do an audit what makes more sense financially.
The solution to accessible web applications came to me when I gave a talk at the Braillenet conference in Paris and someone in the audience was asking why Yahoo! doesn’t store the information that a user has a screen reader in his profile.
The main difference between a web application and a web site is that you need to sign up for it, and this is where we can get all the information we need to create an accessible web site – by asking the user if they use assistive technology.
Alastair Campbell proposes a full-fledged profile covering lots of disability options and settings which might be a bit too much to ask, but it is going in the right direction. Instead of trying to find out programatically (for example via Flashaid) if a user has assistive technology we just flat out ask them for it, store this information and change the interface accordingly.
If your framework or development tools does not plan for these situations then this is no excuse, but a chance to contact the developers of these and ask for these options. After all, professional web developers got rid of the idea of WYSIWYG long time ago as well and asked developers to turn the “paint your web site” tools into development IDEs.
One of the biggest issues with disability is that not everybody wants to be known to be disabled. therefore the information harvested this way should not be on the profile but only used behind the scenes in your application.
In the first part of this I wrote about three aspects of a professional web developer: not to overrate your knowledge, for it is fixed in time, making sure you share what you know and never ever consider yourself indispensable.
In terms of delivery of work you can show your professionalism first and foremost by delivering on time and budget (which happens not very often, but it keeps the people happy who spend money on us). This can mean that you cannot deliver the all-singing all-dancing solution you have in your head or spend 2 hours pondering what the best semantic markup for a certain bit of content is. However, it is no excuse for delivering bad quality. Bad quality means shortcuts or stopgap solutions that don’t make sense (as they will never be replaced with the real thing) or simply code that only you understand. The main quality criteria of code in a development team is that it does the job, that it does it in a clean manner and that anyone in the team can maintain it. Best practices are what it says on the tin: best practices. You can only make them a standard by sharing the idea with other developers, verify it as a good one and implement it in bulk. We all have different ideas what is best, and if we all implement it on the sly we don’t end up with a standard, but with lots of good ideas that all together don’t paint a consistent image.
As a web developer we have to communicate in all directions – much like project managers do.
That’s a lot of points of contact, which is why larger companies have lead web developers who take on the bulk of this so that other developers have time to deliver the work that has to done.
What it also means is that you should be aware that all of these people around you know and like their job – the oft mentioned incompetent idiot is not as common as you think. The same way we expect people to trust our judgment when it comes to what makes sense on the web we should show respect and trust PMs to know about delivery schedules and material gathering and designers to know what works for end users and is engaging. The smoother your interplay with all the other people involved in a project is the less stressful your job will be.
It is amazing how quickly people forget the perks we have as web developers.
The amount of time we spent uploading photos to flickr, commenting on blogs, twittering, sending personal email or reading our RSS subscriptions is not as easy to get out of other jobs. Don’t get me wrong, I’d personally never work for an employer that does not grant me internet access, but technically they don’t need to – you could work on internal projects and servers.
From a legal point of view, everything personal we write or create using software or hardware belonging to our employers also belongs to that company as we used company assets to create it (can someone back that up with a legal example in the comments?). And now be honest: how often have you fixed something on a personal web site or blog in the office as the connection is faster than the one at home?
All the companies I worked in so far as a web developer had no smart dress code (to me, wearing a tie sitting in front of a heat-emitting box is everything but smart anyways) which also means we don’t have to buy clothes for work but can wear whatever we do in our free time instead. This is a lot of money saved when you also consider dry-cleaning, pressing of shirts and other stuff we wouldn’t be able to do ourselves as we are too busy on top of the initial buying of suits, ties and uncomfortable shoes.
If your employer is a good one you’d also not have to worry about software you need to use. As a freelancer, you’d need to buy your applications (CS3 anyone) and upgrade whenever a client cannot deliver raw material in a format you can use. Sure, you could use pirated copies, but don’t forget that a lot of software does keep your name and computer identity hidden in the binary files it creates. Furthermore, using non-licensed software makes you a hypocrite – after all you don’t want people to re-sell what you have done as theirs and for their own profit either.
All of these are something to consider when you compare what we earn to stock brokers, investment bankers or other, higher-paid jobs.
One of the guys I keep dragging into the limelight of the web (the last time with an A List Apart article on font resize monitoring) is my colleague Lawrence Carvalho. This time he has an amazingly versatile tab interface based on the YUI on offer.
There are many tabs solutions out there, including my DOMtab but Lawrence’s beat mine hands-down:
Check out the example page to see the different implemenations.
I will fly to San Francisco on Monday to work in Santa Clara and stay in Sunnyvale for the next 2-3 weeks. So far my stops beside working are:
Anything else I should be doing while I am there? I got a rental car and a cheap hotel room :)