• News archive
• Sign up for our eNewsletter

Home > News

Robin Christopherson 'Beyond a Code Audit' - @media 2006 speaker notes.

24/07/2006

Speaker notes - Robin Christopherson

@media 2006 presentation – 16 June 2006

I want to start by reiterating what I said last year about the importance of testing – it’s the only way to not only mop up those 45% of issues not highlighted by a code audit (DRC research April 2004) but also to ensure that how you have interpreted the WCAG checkpoints is optimal or even sensible.

Amazon Update

Firstly let’s quickly revisit Amazon which we featured last year and see how it’s doing… I’ve been keeping an eye on it for you.

Amazon – www.amazon.co.uk

Not very well. For most of the year the main navigation tabs remained unlabelled.

But then a couple of months ago they were labelled! But all with the same alt tag of alt=“amazon.co.uk”

Then a couple of weeks ago they changed – but hardly for the better. They went to all having a null alt tag (alt=””)!

So if it’s so difficult for a site to successfully comply with checkpoint 1.1 of the guidelines, it’s with some trepidation that I now embark on illustrating a range of points that fall outside the WCAG guidelines but which are nevertheless very important to the real life accessibility of a website.

Flash issues

Let’s start with a fun area – Flash.

There are two checkpoints (8.1 which is a P1 checkpoint) and 6.5 (which is P2) which refer to ensuring that dynamic content and other objects are accessible, but that’s where the guidelines stop.

If you want to use a technology such as Flash, for example, you have to go to the developers of that technology for guidance.

So let’s do that. Let’s look at a Flash presentation on Adobe/Macromedia’s site which has been provided as a tutorial on designing accessible Flash.

Accessibility of Flash - http://adobe.breezecentral.com/p16268622/

Here are a number of Flash movies and we will look at the movie entitled 'Flash Accessibility , Part 3 – Key Concepts' by Bob Regan, Sr. Product Manager, Macromedia.

We don't actually need to go any further than the first slide in this Flash movie to see a number of issues:

• No text alternative to audio track for hearing impaired users
• Next and Previous Slide buttons not obvious (they could equally be Fast Forward and Rewind) - no tool tips on them.
• Similarly the Change View button not obvious what it is - no tool tip.
• When click the Change View button Jaws (screen reading software) and Home Page Reader (HPR) (specialist text browser) cannot see the text that has appeared as a result.
• When using Jaws the Pause button does not appear to change to Play when pressed. - although it does in HPR
• Insufficient colour contrast with white text on the orange background as it gets lighter towards the bottom of the slide
• Also insufficient colour contrast with the Slide title and Duration headings (which come up when you have clicked on the change View button - bottom right) which are grey on a slightly darker grey background

And all on the first slide!

More general issues which apply to all Flash movies -

• Cannot change text colours or style - may be vital for many users
• Can increase text size by zooming in on the content - but this crops the movie (no text wrapping as is possible in HTML)
• Cannot control Flash using voice recognition - we'll se this later)
• Flash also cannot be accessed by many using other specialist browsers not as sophisticated as HPR, or screen readers not as sophisticated as Jaws

Some of the issues Flash can present are similar to the functionality of dynamic web applications in Web2.0

Web2.0 Issues

When websites become more like applications using new technologies such as AJAX (more dynamic content, heavier use of scripting and more complex functionality) we may see a downturn in accessibility for a range of users – these may include keyboard users, magnification users, screen reader users and users with a cognitive impairment.

Though not a web application we can illustrate this sort of dynamic functionality with the Disney website.

Disney website – www.disney.com

This site has a lot of mouse-triggered movement which will be very disorientating for magnification users, confusing/distracting for users with a cognitive impairment and is often not keyboard accessible.

Avoid too much movement. If you want to have lots of onmouseover-triggered functionality offer the ability for this behaviour to be turned off.

Other issues highlighted in this video -

• Magnification users see so little of your page that page objects should be thoughtfully and consistently placed (e.g. isolated form fields over to the right-hand side and out of the vertical 'flow' of the form are often missed by magnification users)
• Images of text should be avoided - as images pixelate at higher levels of magnification
• Avoid unnecessary audio clutter which can be distracting for users with a cognitive impairment.

Don’t assume that people using access technologies aren’t running JavaScript

Web2.0 will rely more heavily on JavaScript – but you can’t assume that disabled people will automatically and magically be accessing the noscript content you have lovingly provided.

The vast majority of access technologies run in parallel to a standard browser such as IE and endeavour to give the user as much access to content such as JavaScript as possible.

South Cheshire College – www.s-cheshire.ac.uk

Here’s an example of a site that uses some JavaScript which has undesirable consequences when accessed by a screen reader. When viewed with HPR we see some messy code, and when read with Jaws a ghostly voice tells us that their motto ‘To Strive and Achieve’ isn’t true…

Also the continual regular page auto-refresh makes it impossible for an HPR user to read more than the first few items.

Again – testing with a range of access technologies is the only way to avoid any such issues.

There are the same accessibility issues with the use of AJAX as any other site that uses JavaScript, just more so. Usually a page using AJAX is completely reliant on JavaScript for its functionality. Turn JavaScript off and the page doesn’t work. So redundancy needs to be built in.

As Ajax manipulates part of the page without needing to rely on reloading the full page, a fallback would be to have the whole page reloading when AJAX fails. Users with AJAX get the bells and whistles; users without still get the content, just in a slightly clunkier format.

And if you know your dynamic content isn’t going to be accessible you need to offer a well sign-posted link to the JavaScript-free content as you can’t assume that users will be taken there automatically.

Test your sites/web-applications with the keyboard and tools such as HPR.

Resizing text

Ok – everyone knows you have to make all the text on your site resizable (including headings and navigation please), so you define all your text sizes in scalable ‘em’s – but do you then test to make sure all is well when the text is resized? The checkpoint doesn’t say “and make sure your site works when the Largest text size in a browser is used”.

Learndirect - http://catalogue.learndirect.co.uk/courses/

An example of cropping/overlapping when text is enlarged. Make sure you don’t hard-code the size of table cells, for example, so that text crops at ‘Largest’.
This site is also a good illustration of how text can disappear black on black when a user has chosen high contrast white on black for his Windows colour scheme (common choice).

There is no checkpoint that covers the importance of defining both background and text colours to avoid this behaviour.

Define both background and text colours (or do not define any colours at all) and ideally offer a styleswitcher (such as at www.bbc.co.uk/accessibility)

Colour choice

Poor colour contrast/danger colour combos is never more crippling than when it affects text. Yes it’s in the guidelines - but good text contrast is a P3 issue and gets ignored all the time so I make no apologies for including it here. (Image contrast is a P2 issue – which would you say was more important?).

Colour combos are really vital for many visitors.

(Shows video illustrating how the London Underground map appears to people with different colour deficit conditions)

Without careful checking it is easy to use a combination of colours that will appear radically different for many users.

We all know we have to pick our colours carefully – but test, test, test. Use the filters at www.juicystudio.com and www.vischeck.com

Keyboard and mouse issues

Let’s move on to Some Keyboard and Mouse Difficulties…

Many people have difficulties using (or are unable to use) a standard keyboard or mouse. Others are unable to use their hands at all. We know we must make website functionality device independent – but there’s more…

Clickable areas

Many mouse users find it difficult to control a mouse accurately.

Lastminute.com - www.lastminute.com

Clickable areas must be a decent size and not too close together (Under the Travel link on the LHS there is a list of links that are very close together)

Google - www.google.co.uk

A good example of well spaced out links is Google's links to further pages of search results. Who knows – this alone may be the reason why Google has reached its position of world domination!

A clear highlight to the active link

We know that we need to make the tabbing order sensible (not like the official site of the Vatican - www.vatican.va/phome_en.htm) but there’s no point having a sensible tabbing order if you can’t see which link is active.

RNLI – www.rnli.org.uk

It is very difficult to see where you are when tabbing through the main nav links on this website. The highlight around the active link should be clear.

Skip to content link

We know that offering a skip to content link is good, but that doesn’t mean that offering five is better! Some sites offer several such as ‘Skip to content’, ‘Skip to section navigation’, ‘Skip to search’ and ‘Skip to footer navigation’ which in themselves double the navigation on the page.

Also, why not make your skip to content link visible so that keyboard users can use it as well as screen reader users, and so they won’t be confused by the initial Tab press on the page seemingly doing nothing. If you don’t want it to be visible all the time why not use styles to make it visible when it receives focus? (e.g. www.abilitynet.org.uk)

Flash games

The guidelines say that we should make all content device independent, but most of us think of this in terms of making sure the content is able to be used by a keyboard-only user.

Let’s hear from someone who, when it comes to time-critical functionality, is in effect a mouse only user.

(Shows video of Darren who uses a head operated mouse and on-screen keyboard)

So this illustrates the importance of true device independence – not just keyboard access. So Flash games, for example, should be operable from both keyboard and mouse wherever possible.

Voice recognition software issues

Darren could use voice recognition software if he chose to. For those who have difficulty using a keyboard or mouse it’s a really powerful way of operating a computer – allowing you to easily move around web pages by issuing voice commands, and to simply say any item you want to have clicked.

Amazon – www.amazon.co.uk

This demo uses Amazon (sorry to use you again Amazon) to show that pictures of text (such as ‘Wishlist’ above the navigation tabs) isn’t able to be clicked by voice as its alt tag is different from its screen text.

Also the user is unable to click the tabs by voice as they are null alt tagged.

Stimorol – www.stimorol.com

Flash breaks this 'say what you see' ability of voice recognition software as we see here on Stimorol’s website. You have to use a series of verbal commands to manually drive the mouse pointer to the desired area and click ('mousegrid')

Let’s hear from Rachel who is a voice recognition user…

(Shows video of Rachel who has RSI and uses Dragon Naturally Speaking)

Going that extra mile

Many people see the priority level 3 checkpoints as going that extra mile to further enhance access for many groups – and in a way they are right. Certainly by the WAI’s own definition it’s only at AA that we stop hindering access for certain groups.

But there are other ways you could consider adding that extra bit of help for certain users that fall outside the guidelines and we’ll look at a few.

There isn’t much in the guidelines specifically to benefit users with a learning disability. Let’s meet Lorraine…

(Shows video of Lorraine who has a moderate learning disability)

Lorraine would benefit from some of the following which aren’t covered in the guidelines.

Text considerations

Segment text blocks with enough white space.

Ensure that your text isn’t too small under common viewing conditions - such as on a 12” laptop running 1024x768.

A slightly larger sans serif font will assist those with a vision impairment or dyslexia, and don’t fully justify the text.

Let’s see an illustration of some of the effects people with dyslexia experience…

(A video of text effects seen by someone with dyslexia was shown)

Spatial-literacy.org - www.spatial-literacy.org

This site could show a little more spatial literacy as it includes fully justified text. See the large spaces between words making rivers of white through the text.

Text to speech

You could also offer a text to speech option for these groups such as BrowseAloud (www.browsealoud.com) or ReadSpeaker (www.readspeaker.com).

Signing

You could even offer signing on your site to assist those who find it difficult to read English.

Sign Community - www.signcommunity.org.uk

This shows a BSL signed version of content using videos or automated avatars.

The above is not a comprehensive review of issues to be considered over and above a code audit. Please ask us for more details or to commission an audit or disabled end user testing.

Go to Top.