Blog w3c

The first interesting and well conceived Vitanim article in a long while caught my eye today, arriving as it did at just the right time. “How do you get your line manager to buy into accessibility?” is basically the question it answers.

The problem I’ve recently faced as a Web developer who reports directly to a line manager or director (as apposed to working for an agency and dealing only with your project manager) is figuring out how I can take the ideals I built on as part of my agency experience and apply them to working for a company directly.

As a Web developer working for an agency, and especially one with a project manager you’re able to make judgements based on your own skills and experience, because the marketing professional who has hired your company affords that company a certain level of trust: they don’t need to know the nuts and bolts, just that it works for them.

These judgements are largely invisible to the client and are often to do with a perceived level of quality: of code, logic, markup or data structure. An agency developer may choose to sacrifice certain “flashy” functionality for the sake of accessibility or use CSS and XHTML for layout rather than dropping images in place of text, sacrificing time but gaining flexibility in the long run.

Contrast that with working directly for an organisation that doesn’t necessarily have a marketing department and that level of trust changes. It doesn’t lessen, but rather tightens. Although your manager will trust you to develop pages with your own judgement in play, because you’re working for them (whether as a contractor or a permanent employee) you’re expected to whistle to their tune. And that’s fine: they’re paying your wages after all.

But what do you do when your manager doesn’t care about accessibility? It can be costly (under the time = money rule if nothing else) and the benefits are mostly to do with gaining kudos amongst a community that will probably never buy the product or service your employers are selling. So do you tell him he’s wrong? Do you ignore him and carry on, choosing to justify yourself if and when the time comes, or do you try and work accessibility into your practice without throwing it his face?

Although it could possibly go a bit further into providing provable key points that professionals can understand, the Vitamin article on accessibility shares some great starting-point links, one of which being Google’s easy-to-follow Webmaster Guidelines page.

If you’re planning to march into your manager’s office any time soon, preaching the gospel according to Tim, stop, breathe and read Accessibility In Suit and Tie.

Best practises are methods and techniques for achieving a certain goal. By their very nature they set the standard for us to follow, and form a mechanism by which developers can be judged.

ASP.NET is my platform of choice when developing applications, but it gets a bum rap from developers on both sides of the open source debate, for its creators’ inherently arrogant approach to Web standards.

While working on a new project I thought I’d have to bite my tongue when I saw some of the .NET markup that was being used, but after a while it dawned on me that what was being written wasn’t incorrect, it was simply following Microsoft’s best practises rather than, for example the W3C.

Under ASP.NET, the tools that allow developers to change the styling for Webpage elements (font faces, sizes, colours, etc) are very close to hand. When adding a text box control to a form, the user can specify its border style, font size and colour aswell as the usual stuff like maximum length and validation functionality. Now as part of the XHTML and CSS methodology, which encourages the separation of content and styling, this type of customisation is abhorrent: it’s simply not the done thing. However, when developing the .NET Framework (and specifically ASP.NET), Microsoft were simply following a pattern.

Some people actually don’t realise, but the .NET Framework in and of itself has nothing to do with Web development: it is simply a software framework. Programmers can build desktop and console applications, libraries and games with it. Now in desktop application development it is very common for developers to be given the option to change how a form looks by hard-coding the window styles directly into the application. There is no CSS technology for desktop applications, and so programmers pick colours from a specific palette (which include system colours) and fonts from a dropdown list, to suit their needs.

Not only can you build both desktop and Web applications with the .NET Framework, you can also use the same software (Visual Studio) to build both types of application, so developers could make the transition from building Windows Forms apps to producing Websites. Microsoft even took care to give the Web versions of their controls (like textboxes and labels) the same or similar name as their Windows Forms counterparts, with the same abilities to change styling that programmers had grown used to.

So I think it’s unfair to rail at Microsoft for not embracing W3C, when this isn’t actually the case. As a standards-conscious developer I’m not forced to use the hard-coded styling method that I would use with Windows apps: I can apply CSS classes to my controls just like I could in HTML.

So hard-coding your “look and feel” doesn’t make you a bad Web developer: just one that’s following one set of practises. Problems only arise when developers pick and choose elements from different methodologies to create their own which makes picking up someone else’s project that bit more difficult.

This realisation has made me a more forgiving programmer: now I just have to learn to resist the urge to force my ideals onto others.

Did you know a Google search for the phrase "click here" returns some 2,210,000,000 results? Probably not, as I imagine searching for such phrases is not the way you like to spend your free time, but it’s true nonetheless!

What this means is that on over 2 billion pages, Web authors are using the words “click here” to link to other pages.

That may sound like useless knowledge, but when you consider the fact that something like 22,000 Brits use screen reading software to browse the Web, that’s quite shocking.

A screen reader is a piece of software that, as the name suggests, reads the contents of a Web page, usually for the blind or partially sighted. Popular commercial products include JAWS, Microsoft Narrator and the proprietary system Browsealoud.

When a fully-sighted person browses the Web, they can read the whole of a paragraph that contains a link, and choose whether or not to click that link based on its context, so if we see a sentence that reads “click here for information on properties in Spain”, we know that clicking that link shown in bold will take us to a page about Spanish properties.

Users of screen readers don’t have that luxury. If they want to “click” a link, they first have to tab through the entire list of links on that page, listen to the text of each link, then either “click” it or move to the next one.

So a blind user’s audio experience of our fictional property page might work something like this: “home”, tab, “about”, tab, “contact us”, tab, “click here”, tab, “privacy statement” etc (where “tab” indicates the user moving to the next link).

The problem is compounded when you have more than one “click here” link on a page: for example a list of news headlines and summaries.

Unfortunately many Web developers have a strange knack of following rules exactly to the letter when it comes to W3C guidelines, so rather than using the phrase “click here” they use the phrase “find out more” or something similar, but that’s just as problematic because it means nothing when out of context.

For more information, see the W3C’s guidelines on link text.

The venerable BBC are trialling a new design for their gargantuan website. At the moment it’s confined strictly to the homepage, but it looks as though this is to be the new preferred layout for the entire site.

Aswell as ditching the 750 pixel wide, left-aligned layout that has come to be known as the ‘BBC style’, they are also making a strong push towards valid HTML, something that is surprisingly not a feature of the current site. The new design now has the site centred on-screen and stretching to 960 pixels in width with a 10 pixel gutter, thereby reflecting the majority resolution of 1024x768 (the display setting that is most common, especially for PCs).

It also makes use of some fancy new AJAX, with each block of content being customisable: allowing the user to move blocks around, expand or collapse them or add in extra blocks. What’s great to see is that this has all been achieved in full compliance with the W3C’s HTML standards. Also most of the functionality (bar the movement of blocks) is available to users who don’t have Javascript enabled on their browsers. The page is fully CSS-driven and should work well in text-only browsers.

I’m quite looking forward to seeing this new, non-stuffy layout go live across the entire site, but I think we could be waiting a considerable time for that to happen. Good work so far though!

Last year saw the battle between HD-DVD and Blu-ray, crushed partly by a bit of ingenuity on the part of manufacturers who are building in support for both formats into their latest models.

But times they are still a-changin’, and the next few years could see interesting times for the Web as HTML 5 and XHTML 2 do battle.

In the red corner, WHATWG’s offering: HTML 5. Before XHTML took hold, HTML 4 was pretty much the standard, and some would argue the only one needed (some suggesting that XHTML 1.0 offers no advantages). Because it builds on the code base of its predecessor, HTML 5 is fully backwards-compatible with 4, and offers some useful new features. It’s supported by the major browser developers, except (of course) for Microsoft.

In the blue corner wearing the W3C shorts, XHTML 2. This offers some very interesting improvements, and a real change in the way developers think about content online. XHTML and CSS have become big buzzwords, and this standard is seen as the “cleanest” and most sensible. The major problem with XHTML 2 is that it is not backwards-compatible with its predecessor, and that because it offers many new features, these cannot be used in good conscience until all major browser platforms are able to support them...so almost never.

As I’ve already mentioned, Microsoft’s complete absence from this debate raises serious questions. The simple fact is, unless Microsoft gets behind one (or both) of these standards, this argument is purely academic. The Microsoft and Mozilla code bases are the only two that matter, and let’s face it, the Internet won’t collapse if Firefox is unable to accurately reproduce newer web pages, whereas if developers get behind a standard that is unsupported by Microsoft, over 80% of web users could be stuck in 2007. This eventuality is unlikely of course, but the simple fact is that the Web can’t move forward before the Microsoft troll hiding under the bridge gives it the nod.