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.

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

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

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

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?