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.

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

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

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

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

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?

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.