"I saw that building 20 minutes ago," I thought to myself as my bus drove past the Blackheath Social Club for the second time this journey. It was a Sunday morning and that meant replacement bus services and continual disruption to what would on any other day have been considered a fairly simple journey. Quarter of an hour after my train had departed, my bus dropped me at Smethwick Galton Bridge station. Despite these problems and Trev's directions, I still managed to arrive at Leamington Spa and locate the correct geeks at the correct time in the correct park.
The weather held, and then improved, meaning we pretty much got a full day of sunshine. There was even a need for sunglasses. A good thing considering the picnic element of the event, and it meant that all sandwiches remained dry, which is more than can be said for Stu, who went for a paddle to retrieve the official Geek In The Park football. We quickly decided that wetting the attendees was a bad idea, and the task of rescuing future water-bound footballs was contracted out to rowers on the river. The 5-a-side tournament was a great success, so much so that it soon evolved into into a 6-a-side match. I was able to comprehensively display my lack of talent and fitness, yet we still won, hurrah.
There were approximately 35 'picniceers', not including kids (of which there were a good number), and a similar figure of developers who turned up for the evening event. Those who braved out the entire day ate dinner at the nearby Scream pub and afterwards headed over to the Jug and Jester for a dose of discussion before I finally had to call it a day and head home.
Patrick and Bruce took the subject of pragmatic accessibility as the core focus for the talk; chain-smoking their way through a passionate discussion about where the responsibilities of the web developers and the user agents meet. The speakers made some important observations about the expectation of designers to provide solutions to browser shortcomings. The podcast will be available for download soon from the Geek In The Park web site, but in the meanwhile thought I would summarise my feelings and conclusions whilst they are still fresh in my mind.
Patrick highlighted the real need for the browsers to take a greater interest in their interface development and not just the compliance to web-based standards (quoting the poor browser subscription to W3C User Agent Guidelines). My personal feeling on this is, as developers, we do already have a way of addressing these gaps in the software. Mozilla and Microsoft have already allow additional function can be mapped into the interface, and there is no reason why we should not be creating solutions that can be plugged into the browsers. The current plethora of extensions are tailored specifically for the developer market (who doesn't have the developer toolbar installed?), but there is hardly anything created specifically for the end users.
The sort of extension I envisage is a toolbar of solutions to standard access problems which are currently routinely patched by developers. The sort of problems I mean are that of font resizing, the 'aesthetic' problem of skip links and the issues of colour contrast. Some of these settings can already be changed in the UA, but mostly are hidden away so that your standard user hasn't got a clue about it. Others simply have not been implemented.
An 'access toolbar' could be combined into a single extension and act as showcase to both web and UA developers. This prototype would have little impact on the standard user (as they still don't know what an extension is); the real benefit would be the ability to demonstrate to the UA developers what the web developers would like, and why it would help us. It would also help to channel the heated discussions onto how to implement the good access features into the browser interface, rather than carry on the superficial arguments over how we should spend our time working around problems that should be being addressed by another group of people. I don't think the extension would ever need to be shown to the public, it should simply be an example of an interface, showcasing features that should be considered for inclusion in a final release product.
I believe that enough pressure could levy change. It's an optimistic view I know, but if you look at the current rates of innovation within the industry, there are two very different speeds. On the one hand, the W3C et al take years to formulate their specifications, then the browsers then take years to implement them. The content of CSS 3 and XHTML 2 are still being debated, but by the time they are widely adopted we will have known exactly what was coming in them for half a decade - no novel advancements, no innovation, just what we already know and expect, and similarly the browsers seem to fail to provide spectacular never-seen-before advancements.
On the other side of the divide is the developers. We have a vested interest in improving our working methods, and innovations in projects/applications are commonplace. The level of creativity and drive is unbridled; we are seeing rapid advances in our design techniques, but all this energy is being channelled into the formulation of CSS hacks and browser workarounds, which is a reactive approach to the problems. This is confusing considering the proactive and innovative nature of the rest of the work that we are involved in (our sites).
If we look at what happens when developers' energy is applied to a generic web problem we can see the results can be very effective. I refer you to Microformats. Within a short period we have a set of specifications that I am confident will eventually become a grassroots web standard and become woven into the fabric of everyday, semantic mark-up. By it's wide scale adoption, Microformats would provide a precedent for developer-led change. Not by W3C committees and not by browser makers, but by developers. If Yahoo! or Google were to start to incorporate these formats in their normal web results, it would be a coup d'etat, and demonstrate that we can make an effective impact on wider web policy.
The point I am trying to illustrate is that there is often a lot of talking about the way we can improve our design/accessibility techniques. It's a by-product of our creativity and online innovation. What is lacking is actions. As has been shown on many occasions, the industry giants are prepared to take on board good ideas. They are willing to pay good money for it. Take Writely, Flickr, del.icio.us... all bought up and adapted by the Big Guns. Why? The technology existed and was proved to work. There would be no point of turning up on Dragon's Den without a prototype. If you want a browser to adopt a feature, you need to mock it up, shout about it, build up a fan base and get the idea adopted. We can talk about what other people should be doing for us as much as we like, but unless we spend some time illustrating what we mean, it's never going to be. What makes this easier is that the tools for the job are already available.
I would like to thank both Bruce and Patrick for getting me psyched
starting me thinking. With a bit of enthusiasm and some help, I am sure us developers could bolt together
some kind of useful little demo bar that might help the UA makers see where
we are coming from and open a discussion on what we want need from them. Bruce and
Patrick are already compiling a list of things we need to see addressed in UAs, so this could be a very useful
stepping stone.
On other topics I have less to say (mostly because I've spilt my heart already), but I would like to agree with their idea of a pragmatic approach to access. The key is to assess the project scope (time & money) and work out if you can adopt a fully accessible schema given the resources available. If you can't, draw up contingencies. If you've made a site that doesn't provide an alternative stylesheet because the project wasn't long enough to allow it, don't feel guilty. Acknowledge you had to make the sacrifice and be prepared to make the change if and when you need it. You are not likely to be immediately sued for not having a high-vis stylesheet if you quickly and cheerfully react to any request or complaint. You will appear in a better light for meeting the needs of your visitors, whilst improving the access level generally on a per-se basis.
Of course it is desirable to have the stylesheet there in the first place, but we all know there are times where a compromise has to be reached for one reason or another. I must stress I am not advocating cutting of corners just because you want your tea a bit earlier; the responsibility that lies with the developer here requires a very pragmatic and realistic approach. You don't want to discriminate and you don't want to leave you or your client vulnerable to criticism. Remember, in law everything is judged in relation to a 'reasonable person', and by my estimation, as long as you could demonstrate you were reasoned in your decisions, you are likely to be within your rights (as a designer only; your client might be liable for not making the resources available)*. Make your code valid, prioritise you access features, then be prepared to act immediately if the audience requests something you couldn't deliver first time around. Crucially, only compromise on access when there is no alternative.
Lastly, Bruce and Patrick were keen to talk about the advantage of baselines in terms of legal positioning of firms. I am still not convinced this is a good way forward. As Nicky Danino put it, "it gives people a get out clause," and I agree. Just because we want to make it easier to define the lowest boundaries, doesn't mean we should do it by providing ways that allows the relaxing of standards. I think it is fairly clear from the years of discussion already under our belts is that the WCAG AAA spec is a holy grail of accessibility, no one can really claim to have achieved it. What is important is that people demonstrate that they have striven to achieve it. Oddly, they don't have to succeed to be successful. It is more important to see people have made a serious attempt at accessibility and standards than to let them pick their own marker and sit on it as low as possible because their in-house access policy says they can. As the classifications are all subjective I predict it won't help the legal position anyway; I think the courts are more likely to weigh a decision based on the level of commitment shown to meeting the godly targets rather than whether they managed to meet a self-set lowly minimum.
Opinions over. I had a great day, it was really good to meet all you folks I'd not met before, and to catch up with those of you I already knew. Thankfully there were no Geek In The Pond fatalities despite the precautions the police took, and hopefully I'll get a chance to see some of you again at the Multipack meet in two weeks time.
*Disclaimer: I am not a legal expert, or anything even similar and this is simply my interpretation and opinion. Please do not use my ramblings as a basis for any access policy without consultation with a legal professional, as without precedent, all this advice is purely speculation and should be treated as such. I won't not hold any responsibility for anyone acting on my advice as I cannot confirm it's value.