Blog accessibility

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.

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!

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)?

Have those lovely people at Texthelp Systems really entered into the spirit of accessibility with their Browsealoud product?

Browsealoud is a piece of free software that you can download to enable you to hear the text content of a website. It works on a PC or a Mac, and you can download a variety of voice packs.

Sounds great, but here's the thing: Browsealoud won't work for just any website, in fact only a limited number out of the millions available are supported.

But that doesn't sound right. Surely a piece of software should be able to read the content of any web page: we already know that search engines can do it, so why not text-to-speech software?

The simple answer is that Texthelp Systems could if they wanted develop their system to work on any site, and use the site's CSS to better read the page, but they probably make far too much money from encouraging web developers to make their sites Browsealoud-enabled.

There are plenty of free browser add-ins that will give you the same (and possibly better) results than Browsealoud can give you, and as long as the page you're reading is developed properly, you'll have no problems.

Browsealoud is just one of many proprietary formats that fragment the web and make things more difficult for end-users.