Blog Web standards

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.

There’s a fair bit of discussion around at the moment on the topic of HTML 5, and I’m led to wonder why. According to an article on A List Apart, we shouldn’t prepare for any practical use of HTML 5 until between 2017 and 2022!

“Why” I wondered, “when it took fourteen years to move from a working alpha to the HTML 4.01 standard we know today (and its XML-based cousin) does it take between ten and fifteen years to move up one major version?”

And I think the answer is this: there are far more players in the Web game than there were in the early ’90s, and everybody wants their say. Apple have recently weighed in to the discussion with the request that they drop support for the Ogg Vorbis audio format from the new spec along with Nokia, a company that has no business deciding such matters. Apple are obviously protecting their proprietary DRM-protected format, but why should it worry a mobile phone manufacturer who have never really embraced portable audio in the way others have?

Recently I’ve got back to using Winamp. I’ve always loved this software, but I found that since Microsoft bucked their ideas up with Media Library 9 and above, other (admittedly, non-bundled) players haven’t had a look in. However, with their full support of WMA and a myriad of other formats, and their near hassle-free Media Library - more than I can say about Microsoft’s over-engineered system - Nullsoft have really hit the nail on the head.

But looking through the various tweakable options the player contains, I couldn’t help thinking that here was an example of community thinking done right. They’d looked through the forum and its Wishlist section and discovered, then made the changes that would make this product so immensely versatile. Forget the large number of plugins, skins and visualisations available: most (if not all) of the functionality the player needs are right there in the initial download. Some have been written by others, some have been “inspired” by other plugins, and some are just great ideas that Nullsoft could never have thought of because they were too close to the project.

So why then can a media player as popular as Winamp is be designed by committee but still get put together pretty quickly? And the answer is simple: they’re a dictatorship! They decide which ideas to approve and reject (the ones that go into the player’s make-up, that is), and they are the ones that implement them. They rely on a body of loyal users for their feedback and a tight community of developers for that expert touch. What they don’t do is include every amendment, contribution or request for functionality (or lack thereof) from every Tom, Dick and Harry who signs up to be a member of their “working group”. They know what they want, and they know that their users trust them.

So my point is...oh yes, there is one...we can pretty much forget about HTML 5, as none of us are going to see it in our careers: not in any practical sense anyway; not unless somebody decides to stand up and say “no more”. Working groups are useless in my opinion; democracy is a great system but it relies on strong leadership to make difficult choices. OK we can appoint the leadership, but we then have to trust in their judgement. The reason no-one’s doing that now is because the Internet was always designed to be a community affair, and although there are numerous bodies from the W3C to the WHATWG to InterNIC and beyond, none of these is a governing body: none of these can make a choice that affects how the Web works in reality. After all, none of the big players conform to the W3C’s standards, so why should anyone else?

So there.

WebCredible bill themselves as "the usability and accessibility specialists" and quite frankly run an excellent site, with a lot of good content and a decent portfolio of work.

But I was interested to note that the facility allowing users to change the size of text is not available for those without Javascript enabled on their browsers; those people have to go to the About page to find out how to do so in their browsers, and still don't get the same effect.

Why would a company that knows so much about web usability force people to use Javascript in order to change the appearance of a page, when this can be done very simply with server-side code (ala this site)?

Mobile web browsing is by no means perfect, but there is currently a solution. When a browser (on a computer, a mobile device or anything else with access to the Web) accesses a web page, it sends a piece of data called a user-agent string. This bit of text tells the computer hosting the website what piece of software is being used to access it. For example, Internet Explorer sends a string like “MSIE 7.0” to identify itself, Firefox sends a string like “Mozilla/4.0”, and mobile browsers have a similar string.

This can be a boon for web developers, because it means they can tailor their content based on the technology reading it: because web browsing is much slower than browsing on a computer, large HTML files can mean longer waiting times, so web developers can send a cut-down version of the page to the mobile user, and keep the larger version for the computer user.

That is unless you’re on Vodafone. Their new Internet service strips out heavyweight HTML and replaces it with something more lightweight before sending it to your phone, so the page loads more quickly. Nice eh? Apart from the fact that it the service does not send a user-agent string, meaning it will be up to Vodafone - not the site developer - to decide how a site should render on a mobile.

Can’t we all just get along? Can’t we just pick a standard and stick to it? Evidentially not.

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.