Chapter and Verse Blog

by Penny Everett, VerseOne Accessibility Specialist

As an Accessibility Consultant, much of my time is spent conducting accessibility and usability audits of websites—mainly in the UK public sector.

At VerseOne’s upcoming Accessibility Focus events in January, I have been asked to present on the most common accessibility and usability errors that I have encountered whilst conducting website audits in 2012.

For my first Accessibility Focus blogpost of 2013 I thought I would list the top 5 accessibility issues that I came across on websites from the NHS, local government and housing sectors in the UK.

I have to say that, before you read on, all these errors were made by designers and content authors who had no idea that they were creating a problem for the disabled visitors to their website. Whilst, they were all mortified when they realised how they could be affecting their users, they showed great diligence and enthusiasm to make the necessary changes for WCAG 2.0 compliance.

As well as listing the issues themselves, for  a bit of fun I have also accompanied the list with a quiz. You can submit you’re answers in the comments below, or book onto one of the free events in January. At the end of the month we’ll post the answers up on the blog.

So what are the 5 most common accessibility errors?

1. Not tell users in advance what would happen if they clicked on a link.
   Q. What 3 main instances could affect users adversely?
    
2. Use formatting for headings inappropriately.
   Q. Why would this be a significant problem and who would it affect?
    
3. Websites often have short videos that exclude both deaf and blind users.
   Q. What 2 things can be done to ensure that these disabled users are able to gain the same information as people who are not deaf or blind?
    
4. Images are often used to link to another web page or web site which give blind users a problem.
   Q. Apart from forgetting to add alternative text for the image there is another major mistake that content providers make in this respect – what could that be?
    
5. One of the most common motor impairments is found in office workers who have repetitive strain injury and can no longer use a mouse. They often end up just relying on the keyboard to navigate web pages. Unfortunately many websites make this very hard for these users.
   Q. What is the most common difficulty they might experience when doing this?

Penny Everett

Web Accessibility Consultant

If you would like to see Penny's presentation in January 2013 click here to book onto an Accessibility Focus event near you, or share your thoughts on the answers to any of the questions in the comments box below.

John Sexton ( john@developer.plus.com) is a visually impaired user and he will be presenting a talk on the issue of Web Accessibility as well as demonstrating the use of assitive technology at VerseOne's upcoming Accessibility Focus events in January 2013 that are free to attend for organisations in the public or private sector.

John Sexton discusses Web Accessibility

John has 11 years experience of working in the NHS as a web developer, specialising in accessibility, user experience and web application build and design.

In this time John has had personal experience of the evolution of text to speach (TTS) and the ongoing development of specialist assistive technology for people with special requirements.

A recent Braille student and advocate of the use of Braille in digital media, member of UKAAF and many online groups for accessibility in technology.

Reflecting on his experience and knowledge in this area John has put together a set of questions that he will be covering at January's Accessibility Focus Sessions:

"These ten key questions are based on both my personal and professional experience in my 11 year web development career as a visual impared person.

1  Why does the web have the potential to be the most accessible communication medium?

2  What benefits are there in web accessibility?

3  How does learning from experience help future projects?

4  What is progressive enhancement and how does it help?

5  What is AJAX and can it be made accessible?

6  What are captcha's and do they work?

7  Do separate text only versions of websites help?

8  What is assistive technology and how does it help people?

9  What new technologies are being used and how do they improve people's lives?

10 What social impact does the web have on communities and how is it breaking barriers and prejudices?

Attend this upcoming event to hear and discuss these key questions and much more. 

Or you can contact me at john@developer.plus.com"

If you would like to hear John's presentation click here to book onto an Accessibility Focus event near you, or share your thoughts on the answer to any of the questions in the comments box below.

Guest post by Chris Mounsey, Product Manager

Some of our readers may have heard of the exciting possibilities offered by HTML5, particularly in the area of native audio and video playback.

The idea is that we will no longer have to rely on plugins—such as Adobe Flash (currently the most widespread), Windows Media Player or Apple Quicktime—to be immersed in the wonderful world of online multimedia.

The problem is that, like many great ideas, the devil is in the details—or, in this case, the war between a number of different codecs.

Despite the fact that it is necessary for me to get a little technical in places, I hope that by the end of this (admittedly slightly lengthy) post, you will have a decent understanding of the problems facing HTML5 media playback.

Not only will this impress your friends (possibly), but it will also enable you to appreciate the good news nestling at the end of this small essay...

Background

Without trying to be too techie, playing video on the web depends on two main elements:

1. the codec under which the video file was compressed (or encoded), and
2. the container used to bring all of the elements (e.g. video and audio) together.

The benefits of the latter very much depend on the format of the former.

Benefits

The HTML5 <video> tag provides a standardised container for playing video codecs, and for providing various controls, e.g. play, pause, etc. And, of course, the audio tag does the same for sounds.

Up until now, publishers have had to use Flash containers—which, of course, require Adobe’s Flash plugin. Flash is near ubiquitous on modern computers but the inaccessibility of many Flash players—combined with some rather serious security bugs and the plugin’s large appetite for memory—has made it a less than ideal solution.

Not only this, but the code for embedding an HTML5 video is very simple, e.g. <video src="someclip.mp4" controls /> embeds your video and delivers standard controls.

Whereas embedding a Flash video requires something more like this:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0" width="400" height="300" id="movie" align=""><param name="movie" value="movie.swf""><embed src="movie.swf" quality="high" width="400" height="300" name="movie" align="" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer"></object>

Ugh.

Anyway, the HTML5 video tag is supported in all modern browsers—Safari, Firefox, Chrome, and IE9+—but, unfortunately, we have been largely unable to take advantage of this.

Why?

Because of a fight between browser vendors over the codecs.

Codecs

Over time, a number of video codecs have been developed for use on the web.

1. Ogg Theora is generally acknowledged to deliver pretty poor quality video, but it is open-source.
2. H.264 (or MP4) was developed by the MPEG LA organisation (which includes a number of hardware and software corporations, and which also developed MP3) and delivers very high-quality video with decent compression.
3. WebM is a Google-sponsored open source codec, the quality of which is rather better than Ogg.

Browsers

Broadly speaking, what has happened is this...

The Mozilla Foundation—which develops Firefox—is immensely committed to open source codebases and, as such, refused to adopt H.264; instead, they relied on Ogg Theora (in the early days) but their browsers will now also play WebM.

Apple enthusiastically embraced H.264—believing (rightly, in my opinion) that it delivered the best experience for its customers. Any videos you buy or rent from iTunes are delivered in H.264 format (as are most DVD movies for that matter). Further, since iOS devices (i.e. iPhones and iPads) do not have Flash, H.264 embedded in the <video> tag is the way of delivering web video to these devices.

Google Chrome supported both Ogg and H.264; however, a couple of years ago, the company stated that they would, in future, only support Ogg and WebM.

Until IE9, Microsoft's browsers simply did not support the <video> tag at all: IE9, however, supports all of the above formats.

In other words, in order to be able to deliver HTML5 video to all compatible browsers, you would have to encode your video at least twice—once as H.264 and once as WebM (or, possibly, Ogg)—upload both versions to your website, and link to both versions when embedding it in your page.

And you would still have to provide a Flash fallback to cater for older browsers.

HTML5 video and VerseOne CMS

That was the state of play at the time that the VerseOne Development team decided to develop the standard media player in VerseOne CMS (back around June 2011).

Believing that our customers—not usually technical—would not want to encode, upload and embed two video formats, we decided on the following course of action.

1. The media player would support embedded Flash videos (as before).
2. Users could also upload H.264 (or MP4) format files too. When these were embedded into the page, the system would detect what browser viewers were using.
   • Those using IE9, Chrome or Safari (on Mac or Windows) will be served the HTML5 <video> version. And, critically, those using iPhones and iPads are able to view the videos using the HTML5 <video> tag.
   • All other browsers would be provided with a Flash container.

This last catered (in theory) for mobile phones running Android or Windows since Adobe were working on—and had (sort of) delivered—a Flash plugin for mobile devices.

Unfortunately, this always ran pretty poorly on low-power mobiles and Adobe cancelled that project in January 2012.

(As a result, we will be revisiting our policy for these devices.)

The Good News

So, we currently have two browsers that support HTML5 video: IE9 and Safari (including Mobile Safari).

And, despite their announcement a couple of years ago, Google have not dropped support for H.264 in Chrome—nor do they show any sign of actually doing so.

So that leaves Firefox and the Mozilla Foundation. It's just one browser, but Firefox now is used by about 25% of web users—a significant number of people to leave out in the cold. (By comparison, IE now has around 35%, Chrome 20% and Safari of all flavours 12%.)

So, we welcome the news that the Mozilla Foundation is finally debating enabling support for H.264. Provided that Mozilla push ahead,  all of the major browsers will shortly support the H.264 codec.

We can then provide a reliable, standards-based recommendation to our customers as regards their video options, i.e. that they should encode their video as H.264 MP4 files (as they should currently do if they wish to deliver to iOS devices).

We can modify our media player to serve video via the HTML5 <video> tag, and support more platforms and more systems (whilst still providing the Flash fallback for less capable browsers).

Conclusion

This will remove a thoroughly thorny problem for us (and for our users) and allow the industry to move forward in providing an excellent, standardised and flexible delivery method for video on the web.

by Penny Everett, VerseOne Accessibility Specialist

Following on from last week's blog, I am now looking at the next Success Criteria listed in the Web Content Accessibility Guidelines.

1.2.1: Audio-only and video-only (Pre-recorded)
The rule of thumb is that Content Authors/Editors need to ensure they are offering an equivalent experience for deaf/blind users to that of other users.

So how can you do that?

Well, the simple answer is to start with a verbatim transcript for the audio on the same web page or a link to it on another page. This will enable a deaf person to read it.

That’s all well and good for the audio only, but what about video only, i.e. video with no sound?

This is much more complex and totally depends on the topic of the video. So you will have to make a judgement—is it reasonable to expect you to explain in writing to a blind person what the video is showing?

For instance, imagine a video with no sound showing how to make a cake...obviously everyone would benefit from written instructions. But what about a video which shows you a cuckoo disposing of its adopted siblings? In order to give a blind person an equivalent experience, the explanation could be quite lengthy. Perhaps it would be easier in this case to consider adding a voice-over. Here again, everyone would benefit and you could transcribe the voice-over.

This is all very time-consuming, but bear in mind the word "reasonable". Has your organisation got the resources for this, or do you feel justified in stating "If you are having any difficulty with viewing the video, please contact our..."? Just remember that barrister—the one you could meet in a Court of Law.

by Penny Everett, VerseOne Accessibility Specialist

The Equality Act 2010 makes it quite clear that any service provider must by law make sure the service is accessible (which includes web products). Although the Web Content Accessibility Guidelines are not law, they have been put in place to help organisations to comply with the law and make their web products accessible.

So I thought it would be a good idea to start looking at some of the success criteria that the Guidelines have set for organisations to follow. We'll start with the very first one—set at Level A compliance—which comes under "Perceivable" (one of the four main guidelines):

Text alternatives—SC 1.1.1: Non-text content
This covers informative/decorative images, controls, media, CAPTCHAs, and sensory experience.

For example...

When it comes to decorative images, web service providers should ensure that any item that is purely decorative (such as non-informative images, formatting, or invisible elements) can be ignored by assistive technology.

In the case of decorative images, they should either be "called" from the CSS, or the HTML alternative text attribute should be set to "null", e.g. (no space between the quotes). I mention this in more detail because so many people either ignore the alternative text, which means the blind user hears the file name, or they put a space between the quotes, which means the blind user knows there is an image there, but doesn't know what it is.

A good content management system, like VerseOne CMS, will make sure a content author gives an image alternative text. But it can't actually help them to make sure the wording is adequate, or determine whether or not an image is decorative. That part is down to the human; provided they have had sufficient training.

To sum up, we need to bear in mind at all times that the aim is to give the impaired user as near an equal experience as possible to that of other users.

by Penny Everett, VerseOne Accessibility Specialist

Did you know that if the source document isn't accessible then the PDF document won't be either?

Organisations are often compelled by law to publish documentation to their target audiences. Many of these documents are very long and were originally prepared in Microsoft Word. Content authors given this task often simply convert the original file to PDF, upload it to the server, and link to it from a web page. Job done!

But not so fast... This is good practice only as long as the resulting PDF is accessible and can be read by assistive technology. Impaired users, such as the blind who use screen-reading software, must also be able to access these documents.

This means that not only must content authors ensure that the content on their website is accessible, but that the linked PDF documents are too.

The process for making a PDF accessible is known as "tagging" and is very similar to the coding process for a web page. Just as the headings, tables, forms, and links on a web page require semantic coding, so do the same elements in a PDF.

This is made much easier if the originating document has been made accessible in the first place. For instance, the 2010 version of Microsoft Word has a built-in accessibility checker.

So organisations who are still using Word 2003/2007 would do well to heed this fact. They should ensure that content authors who are converting Word documents to PDF have access to this latest version of Word, be it on a spare laptop or a single dedicated PC. They can then run the accessibility checker on any source document prior to converting it to a PDF.

Then, provided they use software such as Adobe Acrobat Pro's PDF Maker to convert to PDF, they will be going a long way towards meeting the WCAG 2.0 Guidelines.

by Penny Everett, VerseOne Accessibility Specialist

I spend most of my day auditing websites for their level of accessibility and, to be honest, sometimes I find myself groaning out loud. Some of the issues really impact on disabled users, and others are just frustrating.

Here's an example of something that's both. It is an image of text on the home page of a website (names etc changed to avoid blushes).

Impacting on the disabled: Whoever uploaded it added the alternative text for a blind screenreader user explaining what the image portrays—but withheld from them the actual telephone number and email address!

Frustrating: The title attribute (information displayed on screen in the form of a "tooltip") tells a sighted user that the image is displaying an email address!

Well, folks, how many marks would you give them out of 10 for being inclusive? And how many for going to the trouble of adding a superfluous title attribute?

by Penny Everett, VerseOne Accessibility Specialist

Will this be the case that makes lax web service providers take notice of their legal responsibilities?

The RNIB have been trying to work with a low cost airline (BMIBaby) since 2010 and, despite RNIB's giving them both a full audit report and recommendations, BMIBaby has still not made any significant progress in making their web services more accessible.

So, finally, the RNIB has now served BMIBaby with legal proceedings as the website remains inaccessible to those using screen readers, or those who cannot use a mouse.

Hugh Huddy, the RNIB Campaigns Officer for Inclusive Society, said: "Blind and partially sighted customers deserve to have access to the best online prices and flight information, just as any customer of BMIBaby does. Why should those with sight loss risk missing out on a web-only deal, or be forced to ring a call centre simply because companies are failing to take accessibility standards seriously?"

Even if this case is settled out of court, it has gone public and therefore will be quoted for many years to come! So for those web service providers who don't worry about making sure their website is inclusive: "Be afraid, be very afraid."

Read the RNIB press release here.

by Penny Everett, VerseOne Accessibility Specialist

Last week the free email newsletter (E-Access Bulletin) on access to digital technologies by people with disabilities* published the following:

"The UK's largest supermarket chain has said it is taking seriously the concerns raised about the inaccessibility of its new smartphone app, and is to work with the RNIB to improve the situation."

A visually impaired user found that when she went to order her shopping using Tesco's new app, the screen reader on her iPhone said the same thing for every item. This meant that the new app was totally inaccessible for her.

The initial response of Tesco's customer service was to admit that they knew the app was inaccessible, and they were unable to refer the visually impaired user to anyone else within the organisation.

Eventually, after E-Access Bulletin contacted them, Tesco said they were taking the concerns seriously and would need to build and test and amendments to the application, which would take time to complete.

The visually impaired user pointed out that a large organisation couldn't defend themselves by saying they did not have enough resources. She went on to say:

"Ultimately it is a question of leadership. The bottom line is I feel as if I've been treated less favourably for reasons of my disability. It doesn't feel like it's been taken seriously from the top down—it doesn't feel like the decision-maker has taken an inclusive approach, so why should customer service?"

Could the same be said in your organisation? Are the decision-makers aware of the implications of the Equality Act 2010 in relation to services such as websites or mobile phone applications?

*Read the full article by E-access Bulletin, which is published by Headstar: http://www.headstar.com/eablive/?p=672.

by Penny Everett, VerseOne Accessibility Specialist

Indirect discrimination is against the law—even if it isn't intentional!

So, I can hear you say, what exactly is "indirect discrimination"?

It is best explained by giving an example:

A legal services provider places a large number of legal documents in portable document format (PDF) on its website. None of the PDFs are able to be read by a screen reader because the text has been saved in graphic format.

Now, let's face it, this company probably isn't aware that they had done anything wrong. However, they have left themselves open should a visually impaired user decide to take action because they cannot access important legal information.

If the legal services company were to be taken to court, they would have to justify why they had committed this offence. Unfortunately for them, a court of law will not accept the argument that the organisation doesn't have sufficient staff to undertake the conversion of these documents.

The moral of this story is that you need to ensure that all your PDFs are accessible. If you realise that some of your legacy documents are not, then you need to take action immediately and at the very least:

• add a statement on your website to ask users to contact you if they experience difficulty accessing any document on your website.

The next thing to do would be to look into training a member of staff to ensure that all your PDFs are accessible. Simply converting a document to PDF does not necessarily make it accessible, as the above example demonstrates.

Act Statutory Code of Practice on services, public functions and associations (PDF 908KB)

by Penny Everett, VerseOne Accessibility Specialist

Some well-known companies (I don't feel it would be etiquette to name them) are stating that they will check the accessibility of websites they design against old legislation. Here's an example of wording I came across only this week:

"We'll audit against legislation specific to the countries you operate in. For example, The Disability Discrimination Act (DDA) 1995 in the UK..."

Unfortunately the DDA has now been replaced by the Equality Act 2010 (EqA) which came into force in October 2010—except in Northern Ireland. So these companies are telling the world that their services are not up-to-date!

This new Act of Parliament, however, is still undergoing changes, and organisations will need to ensure that they are fully aware of this. For example, one of the major updates which was added to the EqA in April 2011 and which affects websites is the Equality Act Statutory Code of Practice on services, public functions and associations (PDF 908KB) and can be found on the Equality and Human Rights Commission (EHRC) Equality Act section of their site.

Another addition to the EqA is aimed at the public sector and is the Public Sector Equality Duty (PSED). This section of the EqA replaced the Disability Equality Duty (DED) in April 2011 and guidance for the PSED is also available on the EHRC website.

As this demonstrates, new legislation started to come into force well over a year ago and old legislation such as the DDA and the DED have now been replaced.

We, at VerseOne, pride ourselves on keeping up-to-date in every sense—not just with technology, and we are happy to pass on our knowledge of this new legislation.

by Penny Everett, VerseOne Accessibility Specialist

This week's topic is more of a usability issue, although it also affects disabled users.

Whilst many users will be accessing your website from their laptop, mobile, android device or tablet, there are still a lot of users who use a mouse.

The majority of these users will use the middle wheel to scroll through pages and options within dropdown lists, which unfortunately can cause problems.

Have you ever wondered why you can't scroll down on the times when you go to www.thetrainline.com (that is, of course, if you use that website to look up train times)?

Imagine if it was possible to use the scroll button to select a train time...you would immediately run the risk of changing your selected time if you scrolled further down the page in order to click on the [Get times & tickets] button. Now wouldn't that be annoying?

Has this ever happened to you? Have you completed a form on a website and continued to scroll, and then found that the data you selected had changed when you went to submit the form? I frequently come across this when I input my credit card details on e-commerce sites.

Well, having established that allowing a user to scroll through options can cause problems, you need to check that this doesn't happen to your users when they access options on your website. Web designers can design option lists so that selecting an option doesn't adversely affect the user if they continue to scroll.

by Penny Everett, VerseOne Accessibility Specialist

Some years ago, I used to tell everyone that if you are sending the user to an external website then you should always make the new page open in a new window. Then I started to study accessibility and established that what I used to insist upon was wrong!

The reason for this is that if a blind person (a screen-reader user) clicks on a link that takes them to a new window, they cannot press the Backspace button to return to their previous window. And furthermore, if they close the new window down, they will not be focussed at the point they left the original window. This is why I state that opening links in new browser windows disorientates these users. It can also confuse the cognitively impaired.

In addition to the above, any link that opens in a new window should say so—in other words, the Content Author should not let the user experience any surprises.

The latest Web Content Accessibility Guidelines (WCAG 2.0) published by W3C WAI state:

3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component. (Level A)

Specific Benefits of Success Criterion 3.2.2:

• This Success Criterion helps users with disabilities by making interactive content more predictable. Unexpected changes of context can be so disorienting for users with visual disabilities or cognitive limitations that they are unable to use the content.
• Individuals who are unable to detect changes of context are less likely to become disoriented while navigating a site. For example:
• Individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected.
• Some individuals with low vision, with reading and intellectual disabilities, and others who have difficulty interpreting visual cues may benefit from additional cues in order to detect changes of context.

Do you feel you can now argue strongly with anyone that your links should not open in a new window?

by Penny Everett, VerseOne Accessibility Specialist

VerseOne regularly runs free seminars on web accessibility all over the country, and during those sessions we cover a wide variety of topics. The presentations are always a huge success, but the feedback from attendees nearly always expresses concern at how little they know about accessibility and how much they have been doing wrong. Much as we'd like to, we can never dwell too long on any one particular subject because of the time constraint. We see our role at these sessions as one of creating awareness. So in this week's blog, I thought I'd go into a little bit more detail about one of the topics we cover briefly in the seminars: captioning.

Captioning, or perhaps I should say "accessible captioning," is not just a case of typing up word-for-word (verbatim) what was said. It is a lot more complicated than that.

Take the simple statement: "You should endeavour to offer as near an equal experience as possible to all your users." Well, let's look at your deaf users viewing your videos. The requirement at single-A conformance for WCAG 2.0 is to add sub-titles (aka captions). However, as the title of this blog suggests, this is an art in itself. For instance, do you know the answer to the following?

• How you describe relevant sound and its source—for example, a phone ringing, a motorbike revving up.
• That a combination of description and onomatopoeia* was the preference of over 56% of surveyed users.
• The recommended speed your users should be expected to read (the presentation rate) to be able to follow the captions. It will generally range from 120-160 words per minute, depending on the target audience and whether the content is theatrical or not.
• That editing of conversations should only be carried out when a caption exceeds a specified presentation rate limit. And that it should maintain both the original meaning, content, and essential vocabulary.
• How you write numbers such as fractions, dates, weights and measurements.
• How you make it clear who is speaking at a given moment.
• What words could confuse non-British audiences.
• That you shouldn't duplicate any words appearing in the video itself in the captions, although you should do so in the transcript.
• That no caption should be on screen for under 2 seconds.

*words that imitate sounds, such as cuckoo, pop, sizzle, and hiss.

If you can't answer the above questions, you might not be offering an equal experience to your deaf users despite going to the effort of adding captions to your videos.

Penny Everett will be giving more practical advice on Accessibility at the upcoming Housing and NHS Hot Topics events that will take place in London and Manchester in October and November.

To view the dates and agendas for these sessions and to reserve your organisation a free place click here.

by Penny Everett, VerseOne Accessibility Specialist

There are almost 9 million Britons who have some kind of hearing loss and, of these, 650,000 are profoundly or severely deaf.

If you can spare 30 minutes to watch Evelyn's commentary and demonstrations in her video, it will give you an extremely uplifting experience. She became profoundly deaf at the age of 12 and despite this went on to become a famous musician.

The fact that failing to add captions to your videos will cause you to fail WCAG 2.0 at Single-A conformance means this video is worth looking at to view the captioning alone. It offers captioning in 27 languages (the English version is 100% accurate).

Do you find that people have a very limited view of deafness? Most people have some hearing loss after the age of 60, but don't like to admit it to anyone as they fear there is stigma attached to it.

Have you added any sound to your website in the way of audio or video? How have you catered for your deaf users? Has it caused any problems for you or your website visitors? Did you know you still have responsibility for adding captioning to your videos even if you place them on YouTube?

by Penny Everett, VerseOne Accessibility Specialist

Adding synchronised sub-titles (captions) to videos is a requirement of WCAG 2.0 at Single-A compliance, so when Google's speech-recognition technology—which automates sub-titling—was announced, we all gave a sigh of relief. At last, some of us thought, we had an easy way of doing this that would save us loads of time.

Unfortunately, the optimistic few were premature in their celebrations. The following is the result of relying on this technology:

"...and thus podcasts which the contaminate few watch listened to those red faces and the speed at which the put actions form have to be really well teen from about a bus because people don't want to invest anytime you see it."

The video can be seen at http://www.youtube.com/watch?v=u4gcf72iGAs and is about the Mobile Oxford University Project. The speaker is Tim Fernando, the Technical Project Manager, and there is nothing wrong with his diction.

Have you had a similar experience?

UPDATE: The owners of this video have now fixed the captioning for it. However, you can still see the results of Google's application in the screen grab and transcription above.

by Penny Everett, VerseOne Accessibility Specialist

Unlike alternative text, which is added to images for screen-reader users, title text is for sighted users and can be added to both an image and a text link, as well as other web page elements. Provided that you are using one of the main browsers, you will see any title attributes on the web page as tool tips when you roll your mouse over the page element. For example, if you roll your mouse over the following link: The title text attribute you should see the words "also known as a tool tip".

The title text attribute is typically used with the following elements: an image, a button, a text link, and a form control. Its purpose is to provide essential information. It is not generally used if it is felt that the element is self-explanatory and any additional information is unnecessary.

Title text can be read by some of the more modern screen-reading software but is not generally a default setting. Many blind users are unaware that they are able to listen to the title text. Some software will only let the blind user listen to either the title text or the alternative text, but not both. Blind users aren't the only ones who will miss out when it comes to title text—the keyboard-only user will not see a tool tip either. Users who choose to view web pages in text format only will also be unaware whether or not a tool tip has been added to any of the images.

The above creates a problem, in that we should give all users an equal experience. All I can advise is that if you feel it is necessary to add additional information to an element for sighted users, then go ahead. But you must make sure that users who will not see the tool tip are informed of this essential information through other means than via the title text attribute.

One of the worst things you can do with title text is to repeat the alternative text or link text. This means that the blind users who use fully functional screen-reading software, which reads both these attributes to the user, would have to endure listening to both sets of text. I often see websites with elements clearly labelled and the tool tip repeating the same text. This practice is absolutely pointless, as only sighted users can see the tool tip. I recently viewed a web site where all 50 menu item links had repeated the link text in the title attribute.

Are you aware of a website that has done this?

by Penny Everett, VerseOne Accessibility Specialist

An article published not long ago in the Evening Standard talked about Jasmine Gardner's experience using Dragon Naturally Speaking. Jasmine is a journalist, and she had decided to sit back and dictate her articles using this speech-to-text software and was positively expounding the virtues of using such a program.

But before you rush out and buy this type of software, bear in mind that you have to train it to understand your voice. Unfortunately, this may take some time before you can happily sit back like Jasmine and look totally relaxed about the whole thing.

However, I have to say, if you can get past the training hurdle you’ll never look back. But as Jasmine herself says, it's quite an accomplished art to dictate straight to the screen. Somehow hands paused and hovering over a keyboard seems to give you time to think about the next sentence or two, whereas dictating straight from your original thoughts is surprisingly hard to do.

Which brings me back to the fact that this software is also for disabled users. Yes, these programs are becoming easier and easier to use, but like most assistive technology, it takes hard work and patience to become fully conversant with using them. Still, with the way Jasmine is singing its praises, she will probably get more able-bodied people to have a go too.

Do you know anyone who is adept at using Dragon Naturally Speaking?

by Penny Everett, VerseOne Accessibility Specialist

At Christmas this year we will be hitting the third anniversary of the publication of version 2.0 of the Web Content Accessibility Guidelines (WCAG).

Let’s face it, three years is a very long time in the IT world. So why are some organisations still referring to version 1.0 of these guidelines?

These guidelines are published by the Web Accessibility Initiative (WAI), which is part of the World Wide Web Consortium (W3C). They are there to help organisations to make their websites accessible to as many users as possible. The version 1.0 was originally published in May 1999, which means it was in use for nearly 10 years.

Although it is possible to conform either to WCAG 1.0 or to WCAG 2.0 (or both), the W3C recommends that new and updated content use WCAG 2.0. They also recommend that Web accessibility policies refer to WCAG 2.0.

Following these recommendations through—do we assume that any website still referring to version 1.0 hasn’t updated their website for 3 years?

Is your organisation guilty of this complacency?

by Penny Everett, VerseOne Accessibility Specialist

A CAPTCHA is that funny graphic with squiggly distorted letters which has an accompanying text box where you key-in the letters that you think you can see. You generally see a CAPTCHA before you can continue with a task such as accessing a particular document on a website, or going ahead with a log-in.

The CAPTCHA is produced in such a way that robots which trawl the internet cannot decipher the text and therefore can't infiltrate a website with "spam".

CAPTCHAs are discriminatory in relation to people with a visual or cognitive impairment (particularly dyslexics), as these users find it virtually impossible to interpret the letters presented by the CAPTCHA. Unless the service provider of the website provides an alternative method of accessing this data, other than using a CAPTCHA, the organisation may be guilty of "indirect discrimination".

A CAPTCHA would, however, be acceptable if another accessible method of continuing with the task was offered to the disabled user. Webmasters who include CAPTCHAs on their website often presume they are accessible if they offer an alternative such as "click here for an audio version". This, of course, discriminates against another set of users – particularly the older user who may have a hearing impairment as well as problems with visually deciphering the distorted text.

Have you had problems interpreting the characters in a CAPTCHA?

Have you ever tried to listen to an audio version of a CAPTCHA and given up?

by Penny Everett, VerseOne Accessibility Specialist

Did you know that if you are creating a PDF from a Microsoft Word document that the original document needs to be made accessible?

I can’t tell you how many times I have come across PDFs that aren’t accessible and which originally started out as Word documents. The trouble is, making documents accessible relies on busy people knowing some of the slightly more advanced functionality within Word.

For instance, the first step you will need to know is how to use Styles in Word. Then there are ways of writing inclusively for the cognitively impaired (such as those with dyslexia), where use of images to illustrate points is useful. Plus you need to consider use of white space, Plain English, headings, tabs, and so it goes on.

Finally, when the document is finished, you will need to know how to create a TOC (table of contents) if the document is four or more pages in length.

At VerseOne, we have a document which our clients can download that helps them to produce an accessible document. What does your organisation do?

Are you aware of what to do in order to make your Word documents accessible? Or are you one of those very busy people who just haven’t been able to find the time yet? How do you think the “Word” could be spread?

by Penny Everett, VerseOne Accessiblity Specialist

The five senses of sight, smell, touch, taste, and hearing should be joined by balance, pain, temperature, and body position, to name just a few.

Fortunately, when it comes to making a website accessible, we need to concentrate on just three of those senses at the moment: sight, hearing and touch. One day, maybe in the not too distant future, we will be able to download a smell—who knows? In the meantime, we’ll stick with the three senses.

But I can hear you all saying—"What’s touch got to do with it?". Well, in this sense, we are talking about blind people being able to read content using a Braille reader, or feel the outline of a map or image, through a tactile mouse: http://www.economist.com/node/14955359.

How can a web developer, or content author, consider the sense of touch?

Simple: you need to remember that Braille readers output one line at a time. The blind Braille user cannot "hop" to another area of the screen as they need a marker of some sort to do so. So they cannot react to instructions such as: "you will see from the box on the left…" and, in any case, there could be more than one box on the web page. What you should do is give them as much help as possible to locate it, i.e. "As you will observe from the Survey Results box on this page…" and preferably give the box a heading with the same wording.

Do you have any more tips to offer content authors with regard to the sense of touch? Or do you know anyone who uses a Braille reader and has found something really difficult to "read"? Are you aware of any technology related to this sense that has been developed?

by Penny Everett, VerseOne Accessibility Specialist

When I first started working as a Disability Officer at a London university, I hadn’t realised the high proportion of staff who could no longer use a mouse.

In virtually all cases, it was because of repetitive strain injury (aka upper limb disorder or RSI) caused by using a mouse in the first place!

Many of these users had tried to use joy sticks and other alternative pointing devices, but they often reverted back to just using the keyboard to navigate the screen. I used to teach them many of the shortcut keys for commonly-used software, but when it came to navigating web pages, it was a whole new ball game.

Web developers and designers often don’t take into account keyboard-only users, and many content authors and editors are totally unaware of this disability, which falls under the categorisation of "motor impairment".

It really is quite simple to check whether a web page is accessible to keyboard-only users (which also includes blind screen-reader users). All you have to do is to emulate them: just try using only the keyboard yourself.

One of the WCAG 2.0 Success Criteria at Single A Compliance is “No keyboard trap”. This means that the keyboard-only user should not be led into a situation where they can no longer continue to navigate the contents of the page.

If you’re really serious about Web Accessibility, go to your own website, or web page, and try it out! Then try solving any problems you encounter.

by Penny Everett, VerseOne Accessibility Specialist

Two weeks ago on her Twitter page, Sara Cox (BBC radio DJ) showed how ignorant she was of the needs of the deaf when she moaned about a film that was sub-titled.

I don't think we should totally condemn her. As an Accessibility Web Auditor, I come across people who are totally ignorant of the need to make their web content Accessible. They are normal, caring people. The sort of people who, if they saw a blind person in difficulty, wouldn't hesitate to help them. Yet they have no awareness of the implications of what they are doing when they upload content on the web. They would be mortified if they witnessed first hand how inAccessible their content is to disabled users.

If anyone's to blame, it's society in general who should be taking on board that one in 7 of us has some form of disability. Content Authors and Editors need to be made aware of the Equality Act 2010 and the fact that they should be meeting the requirements of their disabled users. We're not just talking about the deaf or hearing impaired needing sub-titles (or transcripts) for online videos, but also those users who have low vision or are blind, who cannot use a mouse, and the 10% of people who are dyslexic.

More and more administrators are having responsibility for web content added to their job roles. So it follows that more and more organisations should be providing Accessible web content training for their staff.

What do you think? Has the message reached your organisation? Is it top down or bottom up?

Have you ever wondered why counterfeiters expend so much time and energy in creating fake money, when it would be easier and less risky to earn the money legitimately?

I often wonder something similar about search engine optimisation (SEO). 'Black hat' SEOs employ complex tricks and underhand work-arounds to make sure their clients' websites appear high in a list of relevant search results—and, like counterfeiting, these techniques are time-consuming, expensive, and heavily frowned-upon. Websites that use 'black hat' SEO techniques can end up being banned from the very search engines they're trying to utilise. Why go to such trouble when the legitimate way is easier and more effective?

And it turns out that the best way for a site to achieve search engine optimisation is for it to be Accessible. A List Apart (a highly valued resource here at VerseOne!) addresses this very point:

After reading for weeks and painstakingly editing my personal website to comply with most W3C Web Content Accessibility Guidelines, I have come to a startling revelation: high accessibility overlaps heavily with effective white hat SEO.

On further reflection, this overlap makes sense. The goal of accessibility is to make web content accessible to as many people as possible, including those who experience that content under technical, physical, or other constraints. It may be useful to think of search engines as users with substantial constraints: they can’t read text in images, can’t interpret JavaScript or applets, and can’t “view” many other kinds of multimedia content. These are the types of problems that accessibility is supposed to solve in the first place.

The author, Andy Hagans, goes on to describe some of the WAI Guidelines' Priority 1 Checkpoints and how each one also enhances search engine friendliness—all of which is well worth reading. He points out in his conclusion:

Of course, to most web designers, the goal of accessibility is (and should be) to make sites accessible to all people, independent of their platform or any disabilities they have. But if accessibility gets a website more traffic from Google, even better!

The good news is that a web designer who follows best practices for accessibility is already practicing solid white hat SEO. Search engines need not scare anyone. When in doubt, design your site to be accessible to blind and deaf users as well as those who view websites via text-only browsers, and SEO will fall into place.

VerseOne prioritises Accessibility, providing seminars and training courses on its different aspects, but we also know that websites have to be visited to be effective. It is good to read that other web experts agree: legitimate search engine optimisation and Accessibility techniques work hand in hand, and ensuring a website is Accessible brings extra rewards. Optimising your website via Accessibility truly <i>is</i> easier and achieves the best results.

Copywriting is one of the most often overlooked aspects of website building, and yet it is also one of the most crucial aspects of it. After all, most of the information that you want to deliver to your clients is encapsulated in the text of your website—if they don't read it, then your website is not going to be of much use.

In our free Building An Effective Website seminars, we concentrate heavily on the quality of copy—all too often, clients forget about it until the last minute (it's easy to do amongst the hurly-burly of organising staff, approving designs and harrying IT companies!)—and the text on the website is quickly ripped from policy documents, official communications and other unsuitable places.

Not only can this lead to your site breaching Accessibility rules—the guidelines surrounding which I shall deal with in another post—but it can lead to the utterly fatal trait of your copy being incredibly boring to read.

This tendency to write meaningless stuff (often for managers rather than the website audience) is addressed by online magazine A List Apart, in an article titled Attack Of The Zombie Copy.

You’ve seen them around the web, these zombie sentences. They’re not hard to recognize: syntax slack and drooling, clauses empty of everything but a terrible hunger for human brains:

Leveraging world class infrastructure strengths, mature quality processes and industry benchmarked people management practices…

Findings are recorded in a carefully architected summary that crystallizes the intent of the nation to increase its innovation capacity in a variety of modern economic scenarios…

Indigenous and proven career management tools coupled with a comprehensive series of integrated initiatives have been evolved, to ensure that employees continue to sustain a high performance culture, while recruitment and selection is based on necessary competencies…

It’s a partnering-with-partners strategy…

We've all seen writing much like the above example, haven't we? Does anyone really read it? Of course, for many of us, there are certain buzz- words and phrases that need to be mentioned in order to be taken seriously, but these should be as rare as hen's teeth and, if possible, embedded within a welter of more interesting, lively copy.

Is your website like this? If so, Attack Of The Zombie Copy does have a formula for dealing with it.

Prominent undead expert Dr. Herbert West, of Miskatonic University, suggests the following course of action if you’re attacked by zombie content:

1. Kill the modifiers. This is machete work, so wrap a bandanna around your face and grab some shop goggles. No reader is going to believe that your process is innovative or your product is world-class just because you say so, so kill those adjectives. Don’t feel sorry for them. They have no feelings.
2. Determine what manner of monster you’re dealing with. Once you’ve cleared the modifiers away, you’ll be able to get a better idea of the real shape of what’s underneath. If you can paraphrase the revealed sentence in a simpler way, the paraphrase can guide you to a new, clearer version.
3. Hit ’em in the head, right between the eyes. Once the sentences’ underlying form has been revealed, you’ll be able to start looking at the overall health of paragraphs and pages. You may find that whacking the modifiers and simplifying the sentences will reveal a mushy glop of circular logic and nonsense; if so, it’s time to deliver a merciful death. If, on the other hand, your copy is only mostly dead, you can revive it by excising meaningless or redundant passages and then patching up the remainder with transitions and clarifications.

It's worth reading the rest of the article, as the author demonstrates how much better and—yes—more meaningful the amended text is. So, take out your chainsaw and start lopping the loose limbs from those zombie sentences—everyone will benefit!

For those of us who design websites with Accessibility in mind, the question of fluidity—that is, the resizing of the site to accommodate differing screen resolutions—is a vexing question.

Should we design for a fixed width? Or should we design for flexible widths, or a totally fluid width? And if we do a fluid with, how do we ensure that the site maintains its look and feel at different screen resolutions and, indeed, at different text sizes?

This article at A List Apart describes how it might be done: by making the elements proportional to each other, rather than fixed.

Instead of exploring the benefits of flexible web design, we rely on a little white lie: “minimum screen resolution.” These three words contain a powerful magic, under the cover of which we churn out fixed-width layout after fixed-width layout, perhaps revisiting a design every few years to “bump up” the width once it’s judged safe enough to do so. “Minimum screen resolution” lets us design for a contrived subset of users who see our design as god and Photoshop intended. These users always browse with a maximized 1024×768 window, and are never running, say, an OLPC laptop, or looking at the web with a monitor that’s more than four years old. If a user doesn’t meet the requirements of “minimum screen resolution,” well, then, it’s the scrollbar for them, isn’t it?

Of course, when I was coding the site, I didn’t have the luxury of writing a diatribe on the evils of fixed-width design. Instead, I was left with a sobering fact: while we’d designed a rather complex grid to serve the client’s content needs, the client—and by extension, the client’s users—was asking for a fluid layout. As almost all of the grid-based designs I could list off at that time were rigidly fixed-width, I was left with a prickly question: how do you create a fluid grid?

As it turns out, it’s simply a matter of context.

I do suggest reading the whole article—it lays out, in the form of a sample tutorial, precisely the best way to ensure the maintenance of form and look in a fluid world.