Playing Catchup

I seem to have got out of the blogging habit, so I'm hoping to catch up on a few posts now. I'll tweak the dates so they're relevent to the events roughly as they happened (chronology? what's that?!)

The first event I'd like to make a post about was the excellent -

Web Standards Group Meeting on Javascript

Some of us shy away from JavaScript (until recently, myself included) on the grounds that it's not accessible. But these days, if it's done right, it can be positively beneficial to accessibility.

Demystifying Screen Readers - Steve Faulkner
Steve is very knowledgable on screen readers and all their foibles, and is Director of the Web Accessibility Tools Consortium. This talk mainly centred around Jaws (65%) and Window Eyes (35%). The bracketed figures are from a US National Federation of the Blind market share survey - it's obvious these are the two big players.

The key issues revolve around:

• Dynamic updates - user initiated and independent
  Can the user access the updated content?
  Is the user aware that the content has been updated?
• Rich Internet Applications (RIA)
  Can the user understand the role of the control?
  Can the user successfully interact with the control?
  Is the user able to access information about the current state of the control?

He then explained the differences in screen reader modes:

• Browse Mode (virtual buffer) - the user can navigate page content via paragraphs, headings, links, lists etc. They can also activate links and some form controls. But text characters can't be input into form fields, or interact with select elements in this mode.
• Forms Mode (browse mode off) - the user may only navigate through a document to focusable elements via the TAB key. Text access is limited to "read all" functionality. Most of advanced content navigation is unavailable.

The crucial question we have to consider is, when and how does content become available to the user after it's been updated in the browser?

[Steve Faulkner and the Latency Issue]

Latency is a problem because the virtual buffer does not update and the user doesn't know anything has changed. However, JAWS v7.1 started "listening" for virtual buffer updates in response to things like:

• window.setInverval()
• object.innerText (for IE)
• object.textContent and object.appendChild (in Firefox)
• changes in form control values
• And other stuff like ALT or TITLE attribute value changes.
  

Jez Lemon has an excellent article on Improving Ajax Applications For JAWS Users on his webiste. Steve summed up with some recommendations:

• Do not code to accommodate the poor support shown by JAWS and Window Eyes.
• Use unobtrusive methods where available and appropriate, to help screen readers along.
• Don't use the excuse that JavaScript / Ajax is not accessible for screen readers to not bother to design for accessibility.
• Start developing interface elements that use WAI-ARIA specs, which will provide some benefits now and many more in the future.

Steve's thought-provoking presentation was followed by a turn from Christian Heilmann entitled Seven Reasons For Code Bloat

[Christain's been on the beanz again]

His notes are available for download from his blog, so I won't repeat them verbatim. Needless to say, it was a fun presentation and contained the obligatory photo of a kitten ;-). Meanwhile, he's thinking of this as the title of his next book:

[Christian's Next Book?]

PubStandards XVIII
Of course, the next item on the social agenda was the PubStandards gathering. Lots of fun and revelry as usual, here's one photo, but you can see more on Flickr.

[Patrick & Ashe go head-to-head, while Ross butts in the middle]

Patronage And Other Musings

You may have noticed the "i'm patronising" badge on the side of this blog. What's it all about? Well, Joe Clark has a big plan and he needs small donations towards keeping him fed, while he spends four months trying to raise $7 million (canadian) to undertake the research he wants to carry out. He's targeting four major strands of accessibility, and has set up the Open & Closed Project in order to do so. By donating a modest sum, folks like you and me can make a small contribution, which in turn will allow Joe to make a big one. Good luck Joe!

Two more recent posts concerning accessibility have caught my eye:

• Frances Berriman raises some good questions in her Developing for Others post, and also encourages some useful feedback. I'm hoping to be able to attend one of the Screen Reader demonstrations on offer in the near future. Whilst I do have access to a copy of JAWS for testing the sites I work on, I've no doubt that a non-sighted user would actually use the software in a completely different way to me - so observing some real-world users first hand will be a great learning experience.
  
• Meanwhile, Chris Heilmann makes us question the way we approach design, by asking, if the Needs of the disabled spark inventions, why not in web design?

Further Reading

There was a dangerously-tempting bookstall at d.Construct the other week, and I found myself buying two books which have been on my To Be Read list for a while:

Beginning JavaScript with DOM Scripting and AJAX - Christian Heilmann, Apress
I think it will be an excellent companion for the DOM Scripting book I've already read by Jeremy Keith. Will do a proper review when I've read this in more depth.

Blog Design Solutions - Andy Budd et al, Friends of ED
Great advice for customising your blog. Not just in terms of look and feel, but also advice on hosting your own blog, setting up testing environments, databases etc. I hope to give this blog a "lick of paint" in the near future!

I've also recently finished Dan Cederholm's excellent book:
Bulletproof Web Design - Dan Cederholm, New Riders
This one is a must-read for anybody seriously contemplating standards-based web design. Dan takes common table-based solutions (which can still be seen in the wild), explains why they are not bulletproof, and then reworks the solution in a standards-based way. I was very impressed with the session he did for @media in June, and this takes things even further. A great reference for bulletproof techniques.

D Is For DOM and d.Construct

Inspired by Christian Heilmann's presentation on DOM Scripting last week (he made JavaScript sound fun, for heavens' sake!), I thought I would try and get my head round the concept. I'm much more familiar with CSS and tend to cower in the corner at the thought of writing any Javascript. So I thought I would buy a book. Well, I actually went into Borders looking for a newbie's guide to PHP but came out with Jeremy Keith''s DOM Scripting: Web Design with JavaScript and the Document Object Model (Friends of ED). How did that happen?

Talking of Jeremy and his friends at Clear:left, I have bought my ticket for the 2006 d.Construct meeting in Brighton on 8th September. It promises to be a good event, and I thought I might make a weekend of it and see a bit of Brighton while I'm at it (or is that just so I can recover from the post-con hangover??).

WSG London #1

The first London meeting of the Web Standards Group took place last night in North London, and was well very well attended with 190 people turning up to hear speakers Andy Budd on Who Cares About Standards? and Christian Heilmann speaking about Maintainable JavaScript.

Christian was very animated and went quite quickly, and since JavaScript is not really my forte, unfortunately I found it was easier to just listen than trying to scribble notes as well. His slides are available via his blog. But I was able to take notes during Andy's talk, a precis of which appears below.

Who Cares About Web Standards?
This was the rather controversial opening salvo from Andy! He began by giving us a brief history of standards - not just web, but standards in general. From one of the earliest in 1120 when King Henry I defined the L unit of measure (the length of his arm!) through the inventions of the wooden screw by the Romans, and the subsequent standardisation of screws and other machined parts by Sir Joseph Whitworth in 1841, when the Industrial Revolution was in full flow.

Whitworth was in charge of Babbage's Works where the first mechanical computer, the Difference Engine, was made. By 1860, Whitworth's screws had become the de faco standard, certainly in the UK. Meanwhile in the US, William Sellers proposed a different standard (sounds familiar?!) to help build the railroads. This was all fine until towards the end of the second World War, when the US was supplying England with a lot of spares for machinery and the war effort - and they were having to make two version of everything. Eventually the UK capitulated and the US standard became the very first official standard for anything. Now there are over 800,000.

Why bother?
When implemented, standards should:

• Ease communications and inter-operability. Buy a new DVD player and plug it into your TV and it should work.
• Make life easier. You can buy a toaster safe in the knowledge that its plug will fit the sockets in your walls.
• Be a measure of quality, or level of expertise, a mark of professionalism.
• Ensure safety and durability.

There are different types of "standard" - Official, de facto, (non regulated but ubiquitous), open, proprietory. When standards work well, you tend not to think about them.

What's this got to do with the web?
During the Browser Wars, the languages such as HTML and CSS were produced and expanded by the browser manufacturers. By pushing their own "standards" they set out to monopolise. When the W3C came together and put together language recommendations (they are still not standards!), and developers put pressure on the browser manufacturers to support them coherently. All modern browsers support the W3C recommendations - some just do it better than others! The term "web standards" was coined by Jeffrey Zeldman and the WaSP project.

The Philosophy Behind "Web Standards"
The aim is to separate content from presentation and behaviour, using (X)HTML, CSS and JavaScript in the appropriate fashion to produce quality code and semantically correct documents.

Benefits

• Communication - easier to hand over to other developers (or come back to yourself in six months' time)
• Inter-operability - more accessible, forwards-compatible, multiple device support for phones, PDAs, text readers, microformats etc
• Make life easier - code can be more easily maintained
• Safety & durability - code less likely to "break" and should last longer
• Guarantees a level of expertise - proves you are resonably proficient as a developer and should help eradicate the FrontPage Cowboys ;-)
• Mark of professionalism - you will stand out from the crowd
  

Things Aren't Perfect
Standards-complient pages not necessarily load up faster - the number of packet (file) requests can slow things up, so if you have 2 or 3 CSS files associated with a page, there can be a bigger "up front" hit on speed when a visitor first comes to your site, although subsequent pages may well be quicker to load. There is the benefit of less code bloat without all those <table> and <font> tags though.

Huge CSS files can be very difficult to maintain, especially when the full consequences of the cascade are taken into account. Presentation is still tied to content (to a much lesser extent) as the CSS/layout you choose is often influenced by the code order of the document itself. It's much better than it was.

Full CSS Layout is less than ideal at times. Floats are really a buggy hack, but it's the best we've got. Browser implementations for things like <fieldset> and <legend> are still inconsistant (handles padding and margin differently). Advances in XHTML and CSS are beginning to stall. When is CSS3 due? XHTML isn't great for marking up applications as opposed to static documents, or for microformats.

Are standards becoming irrelevent?
Almost reached a tipping point where "everyone" is doing it - so why should we keep going on about it? Development using the standards should be a no-brainer - why do it any other way? Besides, most clients don't care as long as the job gets done, so just do it that way and don't go overboard in advertising the fact. A couple of lines in your proposal documentation (to the effect that "we will use the appropriate web standards" is sufficient).

What now?
The focus needs to change more towards:

• Accessibility/Useability
• User Experience
• Design
• Branding
• Client and user goals

Andy's slides can be downloaded from his website.

Geeky Prize Comeptition!
To tie in with Andy's fixation with screws, here's a little bit of fun...
Despite the US standard for screws taking off after WWII, you can still find a ¼-Whitworth screw/thread in common usage today. I will award a pack of 4 hand-made greeting cards of your choice to the first person who can tell me where.

Oh lord, I've just spotted myself in the audience shots which Christian uploaded to Flickr.