camden web accessibility guide v.1

7/30/2019 Camden Web Accessibility Guide v.1

1/86

Draft 5.0

Camden web accessibility guide

July 2011

Camden webteam 1


2/86

Draft 5.0

Table of Contents

Introduction................................................................................................................................................. 3IntroductiontoWCAG2.0 ............................................................................................................................ 4WhatsnewinWCAG2.0 ............................................................................................................................. 6

NewtermsinWCAG2.0 ....................................................................................................................................7MorepreciseSuccessCriteria............................................................................................................................8 Obsoletecheckpointsremoved......................................................................................................................... 8MoreflexibleSuccessCriteria............................................................................................................................8 Changesinpriority.............................................................................................................................................9 JavaScriptisallowedifaccessible ...................................................................................................................... 9SixnewPriority1requirements ......................................................................................................................10FournewPriorityAArequirements.................................................................................................................11

WCAG2.0LevelAandAAindetail ............................................................................................................. 13Principle1:Perceivable....................................................................................................................................13 Principle2:Operable .......................................................................................................................................472.4.6HeadingsandLabels(LevelAA)NEW Explanation.................................................................................65 Principle3:Understandable ............................................................................................................................693.2.4ConsistentIdentification (LevelAA)........................................................................................................76 Explanation ............................................................................................................................... ....................... 763.2.4Changeonrequest(LevelAAA) ..............................................................................................................77Explanation ............................................................................................................................... ....................... 77Principle4:Robust ............................................................................................................................... ............ 83

Camden webteam 2


3/86

Draft 5.0

Introduction

This document contains an:

Overview of WCAG 2.0: explaining the key principles of the new guidelines

and what is different from the first version of WCAG 1.0

WCAG 2.0 guidelines A and AA: explanation of all the guidelines that

Camden is committed to uphold along with recommendations for how they

should be implemented

Additional guidance for JavaScript, Ajax, Flash and PDFs

In addition there are separate accessibility documents that have in-depth coverage

of JavaScript, Ajax, Flash and PDF accessibility that Camden has produced.

Testing for accessibility

There is also a separate document on testing for accessibility that explains the key

tools for testing for accessibility and contains a checklist for testing all the success

criteria (checkpoints) that Camden supports.

Camden webteam 3


4/86

Draft 5.0

Introduction to WCAG 2.0

WCAG 2.0 builds upon the foundation of WCAG 1.0, but also introduces some

significant changes. The fundamentals are the same - forms still require labels, datatables still require headers, and images still require alternative text.

But there are significant changes - the guidelines are principle-centered rather than

technique-centered. This allows the guidelines to be relevant even as technology

changes. It is also easier to verify conformance in WCAG 2.0 compared to WCAG

1.0

The shift from technique-centered guidelines to principle-centered guidelines

resulted in a reduced number of top level ideas, or principles. WCAG 1.0 had

fourteen principles at the top level.WCAG 2.0 places only four principles at the top level under which there are 12 more

specific guidelines which are broken down further into testable success criteria.

A Success Criterion is the equivalent of a Checkpoint in WCAG 1.0.

These four principles can each be referred to by a single keyword:

Perceivable

Operable

Understandable

Robust

Camden webteam 4


5/86

Draft 5.0

Below is a bullet point summary of the four key principles that underpin WCAG 2.0

Perceivable

Provide text alternatives for non-text content.

Provide captions and alternatives for audio and video content. Make content adaptable; and make it available to assistive technologies.

Use sufficient contrast to make things easy to see and hear.

Operable

Make all functionality keyboard accessible.

Give users enough time to read and use content.

Do not use content that causes seizures.

Help users navigate and find content.

Understandable

Make text readable and understandable.

Make content appear and operate in predictable ways.

Help users avoid and correct mistakes.

Robust

Maximize compatibility with current and future technologies.

Camden webteam 5


6/86

Draft 5.0

Whats new in WCAG 2.0

WCAG 1.0 focused heavily on the techniquesfor accomplishing accessibility for

example HTML. Version 2.0 focuses more heavily on the principlesof accessibility,and presents techniques in separate documents.

1. Principles - At the top are four principles that provide the foundation for Web

accessibility: perceivable, operable, understandable, and robust.

2. Guidelines - Under the principles are guidelines. The 12 guidelines provide

the basic goals that you should work toward in order to make content more

accessible to users with different disabilities.

3. Success Criteria - For each guideline, testable success criteria are provided

to allow WCAG 2.0 to be used where requirements and conformance testingare necessary such as in design specification, purchasing, regulation and

contractual agreements.

In order to meet the needs of different groups and different situations, three

levels of conformance are defined: A (lowest), AA, and AAA (highest).

4. Sufficient and Advisory Techniques - For each of the guidelinesand

success criteriain the WCAG 2.0 document itself, the working group has also

documented a wide variety of techniques and failures. Figure 1 below gives

you a visual representation of how this works:

Figure 1 Structure of WCAG 2.0

Camden webteam 6


7/86

Draft 5.0

New terms in WCAG 2.0

Sufficient techniques: each Success Criterion (SC) has a list of core

techniques to meet the requirement.

Advisory techniques: may enhance accessibility but arent testable, dont

fully meet the SC or only work for some disabled users.

Web page: not just HTML but also applications, webcasts, downloads,

multimedia, Web 2.0.

Programmatically determined: information on a web page can be

understood by software such as a screen reader.

Accessibility supported: supported by users' assistive technologies as well

as the accessibility features in browsers and other user agents.

Web technologies: the technologies used to make a web page i.e. HTML,

CSS, programming languages, PDF, GIF, MPEG, Flash etc, use alone or in

combination to create end-user experiences ranging from static Web pages

to synchronized media presentations to dynamic Web applications.

Camden webteam 7


8/86

Draft 5.0

More precise Success Criteria

WCAG 2.0 is more precise and testable. For example colour:

WCAG 1.0 Checkpoint: 2.2 Ensure that foreground and background colorcombinations provide sufficient contrast when viewed by someone having

color deficits.

WCAG 2.0 Success Criteria 1.4.3. : Contrast (Minimum): The visual

presentation of text and images of text has a contrast ratio of at least 4.5:1,

except for large or decorative text.

Obsolete checkpoints removed

Some checkpoints from 1.0 are dropped in 2.0 such as:

WCAG 1.0, Checkpoint 10.4: Until user agents handle empty controls correctly,

include default, place-holding characters in edit boxes and text areas.

Note: Some of the removed checkpoints may still be beneficial and suggested as

advisory techniques, some are updated.

More flexible Success Criteria

For example flickering content:

WCAG 1.0 Checkpoint 7.1: Until user agents allow users to control flickering,

avoid causing the screen to flicker

WCAG 2.0 SC 2.3.1: Content does not contain anything that flashes more

than three times in any one second period, or the flash is below the general

flash and red flash thresholds.

Camden webteam 8
http://www.w3.org/TR/WCAG20/http://www.w3.org/TR/WCAG20/http://www.w3.org/TR/WCAG20/http://www.w3.org/TR/WCAG20/


9/86

Draft 5.0

Changes in priority

Some requirements have different priority levels in WCAG 2.0

1.3.1Info and Relationships - marking up headings and forms accessibly is

now level A rather than AA

2.1.1Keyboard: all functionality of the content is keyboard accessibly level

A requirement for event handlers to be keyboard accessible was AA in

WCAG 1.0

4.1.1Parsing (basic validation) - is now level A rather than AA

2.4.1Bypass Blocks - skip links are now A rather than AAA

1.4.3Contrast - Text must have a contrast ratio of 4.5:1 - now level AA rather

than AAA

JavaScript is allowed if accessible

There has been a major shift in how JavaScript can be used between WCAG 1.0

and WCAG 2.0

JavaScript and WCAG 1.0

A non-JavaScript alternative should be provided for important functionality i.e.

searches, form validations and links. Unimportant uses of JavaScript include visual

effects and mouseovers, print and add to favourites functionality.

JavaScript and WCAG 2.0

Important functionality should be implemented in a way that is compatible with

assistive technology (Accessibility Support of Web Technologies). So if you use

JavaScript for core functionality like navigation, search or other interactions they

must work with screen readers and other technology such as Magnification softwareand Voice Recognition technology under WCAG 2.0.

Camden webteam 9


10/86

Draft 5.0

Six new Priority 1 requirements

There are six new level A success Criteria.

1.3.3 Sensory Characteristics: Instructions provided for understanding andoperating content do not rely solely on sensory characteristics of components

such as shape, size, visual location, orientation, or sound.

1.4.2 Audio Control: If any audio on a Web page plays automatically for

more than 3 seconds, either a mechanism is available to pause or stop the

audio, or a mechanism is available to control audio volume independently

from the overall system volume level. (Level A)

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of

the page using a keyboard interface, then focus can be moved away from thatcomponent using only a keyboard (example Flash embedded in the page)

2.4.2 Page Titled: Web pages have titles that describe topic or purpose.

3.3.1 Error Identification: If an input error is automatically detected, the item

that is in error is identified and the error is described to the user in text.

3.3.2 Labels or Instructions:Labels or instructions are provided when

content requires user input.

Camden webteam 10
http://www.w3.org/TR/2008/REC-WCAG20-20081211/http://www.w3.org/TR/WCAG20/http://www.w3.org/TR/2008/REC-WCAG20-20081211/http://www.w3.org/TR/2008/REC-WCAG20-20081211/http://www.w3.org/TR/2008/REC-WCAG20-20081211/http://www.w3.org/TR/2008/REC-WCAG20-20081211/http://www.w3.org/TR/WCAG20/http://www.w3.org/TR/2008/REC-WCAG20-20081211/


11/86

Draft 5.0

Four new Priority AA requirements

In addition there are important new level AA Success Criteria

2.4.7 Focus Visible: Any keyboard operable user interface has a mode ofoperation where the keyboard focus indicator is visible.

3.3.3 Error Suggestion: If an input error is automatically detected and

suggestions for correction are known, then the suggestions are provided to

the user, unless it would jeopardize the security or purpose of the content.

3.3.4 Error Prevention (Legal, Financial, Data): For Web pages that cause

legal commitments or financial transactions, at least one of the following is

true: (Level AA)

Reversible: Submissions are reversible.

Checked: Data entered by the user is checked for input errors and the

user is provided an opportunity to correct them.

Confirmed: A mechanism is available for reviewing, confirming, and

correcting information before finalizing the submission.

2.4.6 Headings and Labels: Headings and Labels describe topic or purpose.

There are also 11 new Priority AAA Success Criteria which are listed in Appendix A.

Camden webteam 11


12/86

Draft 5.0

Quick checklist

Any work commissioned should meet the following summary points set out in WCAG

2.0:

Provide text alternatives for non-text content.

Provide captions and alternatives for audio and video content.

Make content adaptable; and make it available to assistive technologies.

Use sufficient contrast to make things easy to see and hear.

Make all functionality keyboard accessible.

Give users enough time to read and use content.

Do not use content that causes seizures.

Help users navigate and find content.

Make text readable and understandable.

Make content appear and operate in predictable ways.

Help users avoid and correct mistakes.

Maximize compatibility with current and future technologies.

There is a detailed checklist in the Camden Testing guidelines document, where you

can also find details of free testing software.

Camden webteam 12


13/86

Draft 5.0

WCAG 2.0 Level A and AA in detail

In this section all the level A and AA Success Criterion are explained under each

principle and each guideline. Key guidance is given in how to meet eachSuccess

Criterion with a link to the detailedsufficient techniques for reference. Each new A

and AA Success Criterion is highlighted with NEW

Principle 1: Perceivable

Any discussion of web accessibility is based upon the assumption that people need

to be able to perceive web content. They need to be able to input the information into

their brain so that they can process it. If the information cannot get into the brain, it isinaccessible

Guideline 1.1 Provide text alternatives for non-text content.

Provide text alternatives for any non-text content so that it can be changed into other

forms people need, such as large print, braille, speech, symbols or simpler language.

1.1.1 Non-text Content (Level A)

Explanation

For accessibility all non-text elements on a page such as images and Flash movies

need alternative text often known as alt text, so that screen readers and other

adaptive technology can understand what is on the page. In addition CAPTUCHA

must have an alternative to just an image.

Example

Below is an example of alt text best practice from the Swiss Cottage Leisure Centre

page. The graphics alternative text contains all the information contained graphically

Camden webteam 13


14/86

Draft 5.0

in the image.

Below is an example where there is an image with missing alternative text it should

be alt=Babies being cute behind a fence

Camden webteam 14


15/86

Draft 5.0

Key techniques

Ensure all images have a relevant descriptive alt text, in addition:

a. If the image is a link, you must describe the destination or purpose ofthe link not a description of the image itself.

b. Empty alt (alt=) text should only be put on images that do not conveyany useful information to the content of the page such as spacer anddecorative graphics or images wrapped in the same anchor tags as theequivalent text link so both screen readers and text readers ignorethem making the page a more pleasant experience to read. Keep alttext concise and brief - avoid verbosity.

c. Where possible, start the alt text with a keyword, for example simplyuse Broadband rather than Click here for BT Broadband. Thisbenefits screen reader users who can bring up all the links on a Web

page into a links list - hitting B will jump them to the first item on thelist that starts with B.

d. For more complex images like pie charts or graph an alt text will not besufficient to describe the image either provide a table of data with thechart, a link to a spreadsheet to download, or describe the graphic inwords on the page or link to a longer description using the longdescattribute - for example

Camden webteam 15


16/86

Draft 5.0

How to test

Using the Firefox Web Developer Toolbar (see the Camden Accessibility testing

guide for more information), select the images option and check for images that

have, and are missing, alt text on images. For those images with an alt text check

they are relevant and descriptive as explained under key techniques.

Further information

WCAG 2.0 techniques

For detailed techniques see: How to Meet 1.1.1

Camden webteam 16
http://www.w3.org/WAI/WCAG20/quickref/#qr-text-equiv-allhttp://www.w3.org/WAI/WCAG20/quickref/#qr-text-equiv-allhttp://www.w3.org/WAI/WCAG20/quickref/#qr-text-equiv-all


17/86

Draft 5.0

Guideline 1.2

Time-based Media: Provide alternatives for time-based media

1.2.2 Captions (Prerecorded) (Level A)

Explanation

Captions provide for deaf or hard of hearing people information about the audio track

of a video. Captions should not only include dialogue, but identify who is speaking

and include non-speech information conveyed through sound, including meaningful

sound effects.

Note: While video that provides service or council information must be subtitled at

this time all other videos should include the option to request a transcript.

There are two types of captions Open and Closed.

Open captions

Open captioning is fixed into the picture; the formatting is set by the producer and

cant be changed the video will always display the captions so cannot be turned off.

Open captions are less commonly used the Closed captions but they are an option

where video is played in a noisy environment such as airports, health clubs and bars.

Disadvantages of Open captions include as the captions are not text they cannot be

indexed and searched and if the video is compressed the clarity and legibility of the

caption text will be affected.

Closed captions

Closed captions appear only when the player being used supports them and the

user turns them on; so Closed captions places the responsibility on the user to

understand how to turn captions on in their media software. Closed captions work

by linking a text file with timing information with the related video and playing them in

synch.

All the main Media players (and Flash players) caption with the same principles but

use slightly different formats for example see an over view of Captioning for

Windows Media

http://www.webaim.org/techniques/captions/windows/

Example

The JW player is one of the most accessible Flash players available with the ability

to add captions and it includes a CC icon to indicate that Closed Captions are

available.

Camden webteam 17
http://www.webaim.org/techniques/captions/windows/http://www.webaim.org/techniques/captions/windows/http://www.webaim.org/techniques/captions/windows/


18/86

Draft 5.0

Key techniques

Most of our videos are hosted on our You Tube channel. Closed caption subtitles

can now be added to any video hosted on You Tube.

See our guide and tutorial on adding subtitles to videos hosted on You Tube.

There is a good overview of web captioning on the Webaim website

http://www.webaim.org/techniques/captions/

Also see the JW Player tutorial at

http://www.longtailvideo.com/support/tutorials/Making-Video-Accessible

Below are recommendations for what to consider when captioning your videos.

Caption best practice

The way you style and present your captioning is an important aspect of effectivecaptioning. Below are some key best practice recommendations.

Font

Use a sans serif typeface: such as Arial, Tahoma, Verdana avoid serf fonts

such as times or times new Roman

Use sentence case dont use lots of uppercase letters as this makes the text

hard to read particularity by people with Dyslexia

Use italics in moderation for emphasis use bold instead if possible

Camden webteam 18
http://www.webaim.org/techniques/captions/http://www.webaim.org/techniques/captions/http://www.longtailvideo.com/support/tutorials/Making-Video-Accessiblehttp://www.longtailvideo.com/support/tutorials/Making-Video-Accessiblehttp://www.longtailvideo.com/support/tutorials/Making-Video-Accessiblehttp://www.webaim.org/techniques/captions/


19/86

Draft 5.0

Text size

Use 12pt text or larger if possible anything below 12pt will be difficult to read

for many people with a visual impairment

Contrast

Use black background with high contrast light text this is the most common

colour scheme used with captions and the most accessible

Punctuation

Use punctuation marks to convey meaning within the caption text

Follows the conventional rules for punctuation and spelling as outlined in

standard English-language style manuals and dictionaries.

Speed

Strive for a reading speed that allows the viewer enough time to read the

captions yet still keep an eye on the video.

For further information on effective captioning see the free guide by the Described

and Captioned Media Program which explains in detail how to create the mostaccessible captions.

http://www.dcmp.org/captioningkey/captioning-key.pdf

How to test

To check if captions are present look for a CC option on the video player; if they are

present turn on the option and check that they are synchronized with what is

happening on screen.

Further information

WCAG 2.0 techniques

For detailed sufficient techniques see: How to Meet 1.2.2

1.2.3 Audio Description or Media Alternative (A)

Explanation

For people who are blind or visually impaired video content that contains more than

just dialog they need an alternative version to fully make sense of it. This can be

either a text transcript or an audio description. A text transcript is the minimum for

any video or multimedia to make it accessible.

Camden webteam 19
http://www.dcmp.org/captioningkey/captioning-key.pdfhttp://www.dcmp.org/captioningkey/captioning-key.pdfhttp://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-captionshttp://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-captionshttp://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-captionshttp://www.dcmp.org/captioningkey/captioning-key.pdf


20/86

Draft 5.0

Example

London2012 has provided transcripts for many of its videos such as 1000 days to the

Paralympic Games video where they clearly state who is talking as shown below.

Key techniques

A descriptive text transcript in addition to the dialog needs to include all relevant

visual and auditory information.

Specifically include in the transcript:

Speaker names.

All speech content. If there is speech that is not relevant, it is usually best toindicate that it has been excluded from the transcript, e.g.: "[participants

discuss the weather while the presenter reboots his computer]".

Relevant information about the speech, usually in brackets, e.g.: "Joe: I hate

this computer! [shouted]"

Relevant non-speech audio, e.g.: "[computer crashing into bits and parts

sliding across the floor]". Non-relevant background noise can usually be left

out of the transcript.

Camden webteam 20


21/86

Draft 5.0

For more detail seehttp://www.uiaccess.com/transcripts/transcripts_on_the_web.html

How to test

Check that a transcript is provided via a link either in the video player or adjacent to

it. Check the transcript is clear and indicates who is speaking and includes all the

speech content available in the audio of the video.

Further information

WCAG 2.0 techniques

For detailed sufficient techniques see:How to Meet 1.2.3

Camden webteam 21
http://www.uiaccess.com/transcripts/transcripts_on_the_web.htmlhttp://www.uiaccess.com/transcripts/transcripts_on_the_web.htmlhttp://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-audio-deschttp://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-audio-deschttp://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-audio-deschttp://www.uiaccess.com/transcripts/transcripts_on_the_web.html


22/86

Draft 5.0

Guideline 1.3 Adaptable:

Create content that can be presented in different ways (for example simpler

layout) without losing information or structure

1.3.1 Info and Relationships (Level A)

This success criterion is about ensuring you have coded up your web pages

semantically using heading, lists and paragraphs etc. In addition data tables are

correctly coded and the label element is used with form forms. This is core in

ensuring your pages are perceivable to people using adaptive technology such as

screen readers.

WCAG 2.0 reference 1.3.1 Info and Relationships -Level A

Markup

Explanation

This requirement is about ensuring you have coded up your web pages using tags

that convey semantic meaning rather than just visual formatting so adaptive

technology such as screen readers can gain information about text from the

formatting.

Example

In the example below CSS has been used to emphasis the Display and Edit option

on a page; which means a screen reader user would not notice any difference

between the bold text and normal surrounding text.

Standard HTML mark-up should be used in this case the tags not the tag. Coded this way a screen reader will hear the Display and Edit text read out

more loudly for emphasis.

Display and Edit

Camden webteam 22
http://www.w3.org/TR/2008/REC-WCAG20-20081211/#content-structure-separation-programmatichttp://www.w3.org/TR/2008/REC-WCAG20-20081211/#content-structure-separation-programmatic


23/86

Draft 5.0

Key techniques

For bolding text use the tag rather than tag or CSS

Replace tags with CSS formatting

Lists should be used for navigation menus as well as lists in body content

How to test

On the WAT accessibility toolbar use the Depreciated Elements options under the

Doc info tab to find out if tags such as and have been used In addition

you will need to check the code for instances of tag where should be

used.

In the example below, the text with the deprecated tag (Camden council) is highlighted.

Camden webteam 23


24/86

Draft 5.0

Additionally, use the Structure/Order tab on the WAVE Toolbar to check that

navigation elements are coded as lists

Further information

WCAG 2.0 techniques

G115: Using semantic elements to mark up structure AND H49: Using semanticmarkup to mark emphasized or special text (HTML)

H48: Using ol, ul and dl for lists (HTML)

Camden webteam 24
http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G115http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H49http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H49http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H48http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H48http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H49http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H49http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G115


25/86

Draft 5.0

Headings


Explanation

Screen reader users often listen to headings out of context from the main content ofthe web page through use of a headings list. This enables quick access into areas of

content the user is interested in, rather than having to listen to the entire web page.

Also, if headings are used but do not follow a logical sequence (H1 to H6) the

structure of the page can be ambiguous.

Examples

Missing H2 heading

In the example below there is no level 2 heading and no clear indication of

structure from the headings that have been used.

Key techniques

The most important thing to get right with headings is to use them consistently

across pages.

In addition where you have used more than one heading on page you need to nest

the headings in sequence correctly. On the Camden website, the heading is

created by the page title in the CMS and is shown above in the coloured strip at the

top of the content.

Camden webteam 25


26/86

Draft 5.0

Do not use headings in the body of the page. As far as possible, below the

main heading should come the secondary, or h2, headings. Subheadings of

these sections should be level 3, or , headings, and so on as shown below:

Depending on the page structure it might not be possible to have an level

heading first this is acceptable but not ideal.

Remember also that you are not stuck with the default HTML styling for headings;

use CSS to amend the heading text size, and other attributes, as necessary, to

match the look and feel of your site.

You can wrap graphics in headings tags but these should be kept to a minimum.

How to test

In the WAVE Toolbar, click the Structure/order button and check the headings toensure they follow a logical sequence H1>H2>H3 and visually match the heading

structure of the page.

Camden webteam 26


27/86

Draft 5.0

Further information

WCAG 2.0 techniques

H42: Using H1- H6 to identify headings (HTML)

Camden webteam 27
http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H42http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H42


28/86

Draft 5.0

Data Tables


ExplanationThe main reason to code tables of information or data tables correctly is to enable

blind web users who use screen reader technology to make sense of the information,

it enables them to go through a table item by item and at a key stroke check the

name of the row or column they are in.

Example

The data table below is coded up correctly with the column headers e.g. ISA

Product, Initial Charge etc wrapped in tag with the scope attribute added. Also

note the column rows are coded up correctly as well.

Camden webteam 28


29/86

Draft 5.0

Key techniques

Ensure all column headings and column rows in data tables are coded using the

table header (th) tags rather than the table data (td) tags.

In addition you can also add the scope attribute to column headers and rows ( and ) as shown in the example above for improved

accessibility.

Note for more complex data tables (such as financial accounts) with more than one

level of column headings or rows a different technique is recommended - see HTML

4.01 header information with data cells

How to test

In the WAVE Toolbar use the Structure/order button to highlight all the table cells on

the page. Check if column headings and rows (if present) are labelled correctly with

the tag and the scope attribute and caption tag has been used.

Further information

WCAG 2.0 techniques

H51: Using table markup to present tabular information (HTML)

H63: Using the scope attribute to associate header cells and data cells in data tables

(HTML)

H43: Using id and headers attributes to associate data cells with header cells in data

tables (HTML)

Camden webteam 29
http://www.w3.org/TR/html4/struct/tables.html#h-11.4.1http://www.w3.org/TR/html4/struct/tables.html#h-11.4.1http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H51http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H63http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H43http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H43http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H43http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H43http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H63http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H51http://www.w3.org/TR/html4/struct/tables.html#h-11.4.1


30/86

Draft 5.0

Forms

WCAG 2.0 reference 1.3.1 Info and Relationships Level A

Explanation

Coding forms fields such as search boxes correctly is important for accessibility

because blind web users using a screen reader need to know what input boxes are

for - if they are not labelled properly it is often confusing and often hard to identify

what text to enter. Also form labels do not need to be visible they can be hidden with

CSS.

Example

The AbilityNet search box is coded up correctly with a label element - as you can see

from the screen shot there is no visible label because of the use of a hidden class

but note the Select a Form Field box for the Jaws screen reader has the label

Search showing.

Search :

Camden webteam 30


31/86

Draft 5.0

Key techniques

All input boxes and other form controls need to be explicitly associated with their

labels using the label (tag) element.

The example simple form below illustrates this by giving you general guidance on

how different elements of a form should be coded with the label tag note the

difference in the way radio buttons (checkboxes are also coded the same way) are

coded. Checkboxes and radio buttons must always be on the left of the label text

otherwise a screen reader can misinterpret which label goes with which checkbox or

radio button.

name:

sex

male

female


32/86

Draft 5.0

screen readers you can use this technique for the pension combo boxes for

example.

For more information on this technique see the article:

Hiding Content from View http://www.abilitynet.org.uk/webarticle67

Forms best practice

All form fields should have a text label, with corresponding for and id

attributes. Each id has to be unique to the page.

If the text label cannot be fitted into the design, it can be hidden using CSS.

For dates fields such as credit card details split over day, month and year

combo boxes put a visible label on the first box and hidden labels usingCSS on the second and third

If it is not possible to include a label, use a title attribute in the form field

explaining the required information.

When there are several associated form elements, they can be grouped

together by a fieldset. Each fieldset should have a legend. A screen reader

will read out the legend before each form field within it

Important information should be included in the label or legend tag.

When using textboxes and select fields, labels should be positioned to the leftof the form field

When using checkboxes and radio buttons, labels should be positioned to the

right of the form field

Camden webteam 32
http://www.abilitynet.org.uk/webarticle67http://www.abilitynet.org.uk/webarticle67http://www.abilitynet.org.uk/webarticle67


33/86

Draft 5.0

How to test

In the WAVE toolbar, click on the Errors, Features and Alerts tab. Green icons

indicate correctly marked-up labels. Red icons indicate missing, or incorrectly

marked-up, labels.

You can also use a screen reader such as Jaws to test form fields are correctly

labelled to do this load Jaws and make sure the web page has focus and while

holding the Insert (Ins) key press F5 to bring up the Select a Form Field dialog box

and check each field listed has a descriptive label.

Further information

WCAG 2.0 techniques

H44: Using label elements to associate text labels with form controls (HTML)

H65: Using the title attribute to identify form controls when the label element cannot

be used (HTML)

H71: Providing a description for groups of form controls using fieldset and legend

elements (HTML)

H85: Using OPTGROUP to group OPTION elements inside a SELECT (HTML)

Camden webteam 33
http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H44http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H65http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H65http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H71http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H71http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H85http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H85http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H71http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H71http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H65http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H65http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H44


34/86

Draft 5.0

1.3.2 Meaningful Sequence (Level A)

Explanation

It is important that the sequence of information on a page makes sense non visuallyfor screen reader users otherwise they can become confused and disorientated. In

addition keyboard only users do not expect to have to tab backwards after

completing a form to select a next or continue button.

Example

The screen shot below shows a form with the action buttons (top right) such as

Continue (right arrow) placed before the fields in a form to make logical sense to a

screen reader they should be after the form.

Key techniques

Ensure the reading and navigation order of the page is logical and intuitive

How to test

In the Firefox Developers Toolbar click on the Miscellaneous tab and select

Linearize Page to make the page into one column then review the content to check

it makes sense.

Camden webteam 34


35/86

Draft 5.0

Further information

Main WCAG 2.0 techniques

G57: Ordering the content in a meaningful sequence for all the content in the Web

page

C6: Positioning content based on structural markup (CSS)

C27: Making the DOM order match the visual order (CSS)

Camden webteam 35
http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G57http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C6http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C27http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C27http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C6http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G57


36/86

Draft 5.0

1.3.3 Sensory Characteristics (Level A) NEW

Explanation

Not using any sensory specific language that relies on shape, size or visual location

is relevant to people who cannot perceive shape or size or use information about

spatial location or orientation, specifically people with vision impairments.

Instructions on a website should not rely upon shape, size, or visual location.

Example

In the screen shot below instructions are using location specific language You can

download a copy of the new charges using the links on the right hand side - which is

unclear for anyone who cannot see the screen. It would be clearer to reword it to say

something like - You can download a copy of the new charges on this page

Key techniques

Ensure any information on the page / instructions do not rely upon shape, size, or

visual location for example:

Click the square icon to continue"

or

"Instructions are in the right-hand column"

Also instructions should do not rely upon sound. For example an instruction such as

A beeping sound indicates you may continue" is inaccessible.

Camden webteam 36


37/86

Draft 5.0

How to test

Read the web page and check if any language uses any sensory specific language

Further information

WCAG 2.0 techniquesFor detailed sufficient techniques see: How to Meet 1.3.3

Guideline 1.4 Distinguishable:

Make it easier for users to see and hear content including separating

foreground from background

1.4.1 Use of Color (Level A)

Explanation

Issues with using colour cut across all the accessibility levels. The most important

issue is not using colour alone to convey information. For example click on the

green button to start or click on the red button to stop.

The reason for this is that people with colour blindness and other vision problems

cannot easily distinguish between certain colour combinations. This is most

commonly an issue for graph, charts or diagrams.

Example

An example of bad practice would be a pie chart as shown below which only usescolour to convey the breakdown of benefits.

To fix this the simplest solution would be to add the percentage figures next to each

benefit using a table next to the pie chart with three columns for colour, benefit and

percentage to make it as accessible as possible.

Key techniques

When designing graphs, charts or diagrams ensure you dont only use colour as a

way to convey information build in another way that the information can be

understood as explained in the example.

Camden webteam 37
http://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-understandinghttp://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-understandinghttp://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-understanding


38/86

Draft 5.0

How to test

Scan the page and check all images and text don't just use colour to be

understandable. The Web Accessibility toolbar has a greyscale option under the

colour menu but it does not work reliably with pages that use complex CSS

Further information

WCAG 2.0 techniques


1.4.2 Audio Control (Level A) NEW

Explanation

Screen reader users can find it hard to hear the speech output of their software if a

webpage they visit is playing audio at the same time, so it is important that they have

a way they can turn off or pause any audio or turn down the volume of the page

audio.

Examples

An audio file begins playing automatically when a page is opened. However,

the audio can be stopped by the user by selecting a "silent" link at the top of

the page.

A Flash splash page with sound that plays and then stops in less than 3

seconds.

A Flash splash page with sound that plays automatically includes a control at

the top that allows users to turn the sound off.

Key techniques

Ensure when a page loads with automatically playing audio, either the sound stops

after three seconds or you provide a mechanism to turn off or pause the sound on

the page.

How to test

If a page has audio that automatically starts when it has loaded and the audio lasts

longer than three seconds check to see if there is an option to turn off the audio

this should also be keyboard accessible.

Further information

WCAG 2.0 techniques


Camden webteam 38
http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-without-colorhttp://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-without-colorhttp://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-dis-audiohttp://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-dis-audiohttp://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-dis-audiohttp://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-without-color


39/86

Draft 5.0

1.4.3 Contrast (Minimum)(Level AA)

Explanation

Not all users can differentiate between similar colour combinations and tones. Evenwhere colours are different, they may still create issues for users who suffer from

colour-blindness, those whose eyesight have deteriorated, e.g. older users and

users who use a black and white screen.

Example

Below is an example where the white text Business on the green background is low

contrast 2.4:1.

Assuming the text is at least 14pt bold (large text) if a darker green is used such as

#589E21 the contrast would be sufficient 3.3:1.

Camden webteam 39


40/86

Draft 5.0

Key techniques

Ensure there is sufficient contrast between text and background colours you use on

your web pages.

The recommend minimum contrast ratio is 4.5 to 1 for standard text up to the

equivalent size of 14pt

For large text (equivalent of 14pt bold+ or 18pt+) a ratio of 3:1 is the minimum

required

Note however that logos / brand names are exempt from this requirement under the

WCAG 2.0 guidelines

How to test

Use a tool such as the free Contrast Analyser, Version 2 from the Paciello Group

which can be downloaded form http://www.paciellogroup.com/resources/contrast-analyser.html to check for colour contrast.

For people with colour blindness ensure you check your website colours with either

the Vischeck on-line page checker or Photoshop plug-in available at:

http://www.vischeck.com/

Further information

WCAG 2.0 techniques


Camden webteam 40
http://www.paciellogroup.com/resources/contrast-analyser.htmlhttp://www.paciellogroup.com/resources/contrast-analyser.htmlhttp://www.vischeck.com/http://www.vischeck.com/http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-contrasthttp://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-contrasthttp://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-contrasthttp://www.vischeck.com/http://www.paciellogroup.com/resources/contrast-analyser.htmlhttp://www.paciellogroup.com/resources/contrast-analyser.html


41/86

Draft 5.0

1.4.4 Resize text (Level AA)

Explanation

Many people with mild to moderate vision impairments just need to read web pages

with a bigger test size that they typically select from browser options you need to

ensure when the text size is increased for example in Internet Explorer View > Text

Size > Largest the text size increasing and there is no cropping or overlapping of

text.

Example

Below the text on the Express newspaper website does not resize when you select

View > Text Size > Largest in Internet Explorer

Key techniques

Use a relative size unit for font sizes (and their container elements) such as EMs or

%s.

It is important to ensure that container elements can resize to accommodate the text

contained within; otherwise text can spill out of elements, overlap, or become

unreadable.

A useful calculator to convert px to EM \ % can be found at http://pxtoem.com/

Camden webteam 41
http://pxtoem.com/http://pxtoem.com/


42/86

Draft 5.0

An alternate way of accomplishing this is to provide several stylesheets, each with a

slightly increased text size. A widget could provide a mechanism for switching

between these stylesheets as was used on the previous Camden website.

How to test

Select the view menu in Internet Explorer or Firefox and view the page in large text

sizes. Also look at any dropdown menus and combo boxes that contain options.

Camden webteam 42


43/86

Draft 5.0

Further information

WCAG 2.0 techniques

G142: Using a technology that has commonly-available user agents that support

zoom

Ensuring that text containers resize when the text resizes AND using measurements

that are relative to other measurements in the content by using one or more of the

following techniques:

C28: Specifying the size of text containers using em units (CSS)

Techniques for relative measurements

C12: Using percent for font sizes (CSS)

C13: Using named font sizes (CSS)

C14: Using em units for font sizes (CSS)

Techniques for text container resizing

SCR34: Calculating size and position in a way that scales with text size (Scripting)

G146: Using liquid layout

G178: Providing controls on the Web page that allow users to incrementally change

the size of all text on the page up to 200 percent

G179: Ensuring that there is no loss of content or functionality when the text resizes

and text containers do not resize

Camden webteam 43
http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G142http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G142http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C28http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C12http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C13http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C14http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/SCR34http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G146http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G178http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G178http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G178http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G179http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G179http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G179http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G179http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G179http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G178http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G178http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G146http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/SCR34http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C14http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C13http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C12http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C28http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G142http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G142


44/86

Draft 5.0

1.4.5 Images of Text (Level AA)

Explanation

As far as possible you should use formatted text (using CSS) rather than images oftext as text is more accessible to people with vision impairments as they can more

easily modify its size and colour to meet their needs

However:

Graphical text is ok to use in moderation but make sure it has good

contrast

(Sighted) disabled users enjoy good design and variety

Previously, accessible developers have been overcautious and avoided

graphical text

Use sIFR (or Scalable Inman Flash Replacement) with care; while Flash

can have good accessibility it needs to be coded well and not overused.

Example

On the Amazon.com homepage homepage the main Kindle graphic and Internet

Explorer 8 adverts include text that could be rendered with stylesheets. When

viewed with a high contrast colour scheme often used by people with a vision

impairment you can see it does not reflect the inverted colour scheme as the rest of

the page does.

Camden webteam 44


45/86

Draft 5.0

Key techniques

Use graphic text for headlines (14pt +) rather than blocks of text

Use a clear typeface preferably a sans-serif font

Ensure high contrast

Make sure alt text is accurate and contains the equivalent of all the

graphical text in the image

Avoid cluttered background images especially if you have text over them

as it impacts on legibility

Avoid for navigation use CSS styled text as much as possible

Avoid for body text below the equivalent of 12pt

How to test

In addition to following the key techniques above use the Windows high contrastcolour scheme to view your pages to ensure you have not overused graphic text In

Windows XP Go to Control Panel in Windows (XP) and select Accessibility options

under the Display tab select use High Contrast as shown below.

For Windows Visa and System 7 you will find the option under in the Ease of Access

Center.

Further information

WCAG 2.0 techniques


Camden webteam 45
http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentationhttp://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentationhttp://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentation


46/86

Draft 5.0

1.4.8 Visual presentation (Level AAA) - recommended

Explanation

The purpose of this Success Criterion is to ensure text is presented on screen as

clearly as possible its layout does not interfering with its readability. This will helppeople with a range of impairment such as people with low vision, Dyslexia cognitive,

language and learning disabilities.

Key techniques

Text is not justified (aligned to both the left and the right margins)

Example

As standard on the Camden website, all text is justified to the left margin

How to testReview the page manually and check for justified text

Further information

WCAG 2.0 techniques


Camden webteam 46
http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-visual-presentationhttp://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-visual-presentationhttp://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-visual-presentation


47/86

Draft 5.0

Principle 2: OperableNot everyone uses a standard keyboard and mouse to access the web. Keyboard

accessibility is one of the most important principles of Web accessibility because it

cuts across disability types and technologies

Guideline 2.1 Keyboard Accessible:

Make all functionality available from a keyboard

2.1.1 Keyboard (Level A)

Explanation

People with mobility problems often use only a keyboard and not a mouse to

navigate a web page. As do screen reader users as they cannot see the screen touse the mouse. Also a lot of adaptive technology uses the keyboard interface as the

way it interacts with a computer. Therefore if parts of your website cannot be used

without a mouse it means a significant number of people will be affected.

Example

Drop down menus as the one shown in the screen shot below are not keyboard

accessible you need to use a mouse to click and then select a link. To make this

accessible you either need to add a Go button or program so that you can tab into it

and then use the arrow keys to move up and down the list and then press enter to

select.

Key techniques

When developing a page ensure you build in keyboard accessibility for all the page

elements such as links and form fields. For scripting ensure you use keyboard

accessible JavaScript. Also ensure any rich media content such as Flash or

Silverlight is fully keyboard accessible.

Camden webteam 47


48/86

Draft 5.0

Also ensure any page-specified shortcut keys and accesskeys (accesskey should

typically be avoided) do not conflict with existing browser and screen reader

shortcuts.

How to test

Using the keyboard tab through a webpage and test you can select and interact with

all links, form elements and all other interface controls such as buttons in a Flash

player without having to resort to using a mouse.

Note with radio buttons in a form you use the up and down arrows to make a

selection and then press tab to move to the next form control. To select checkboxes

you use the spacebar key.

Further information


Camden webteam 48
http://www.w3.org/WAI/WCAG20/quickref/#qr-keyboard-operation-keyboard-operablehttp://www.w3.org/WAI/WCAG20/quickref/#qr-keyboard-operation-keyboard-operablehttp://www.w3.org/WAI/WCAG20/quickref/#qr-keyboard-operation-keyboard-operable


49/86

Draft 5.0

2.1.2 No Keyboard Trap (Level A) NEW

Explanation

Keyboard users typically tab through a webpage to interact with links and othercontrols. If they became stuck in any part of the page and cannot go backwards or

forwards they have to close the browser window and start again which is obviously

frustrating and also means they cannot use that page. Historically this has primarily

been related to Flash content on a webpage such as a media player.

Example

Not only the flash players controls below cannot be accessed with the keyboard but

when you tab into it you become trapped and cannot go back of access the hypertext

links after the video

Key techniques

You must ensure Keyboard focus is never locked or trapped in any page elements

particularly check this for Flash players.

How to test

On the page you want to check hold down the tab key and watch the focus run

through the page. It should keep on cycling back round while the tab key is helddown. If, however, it stops at a particular element such as a Flash movie, this

indicates a keyboard trap, which means you should not be able tab back or forwards

anymore.

Camden webteam 49


50/86

Draft 5.0

Further information

WCAG 2.0 techniques


Other resourcesFlash and keyboard access across browsers

http://www.iheni.com/flash-and-keyboard-access-across-browsers/

Firefox Focus and Actual Links (Flash)

http://blogs.adobe.com/accessibility/2009/04/firefox_focus_and_actual_links_1.html

Camden webteam 50
http://www.w3.org/WAI/WCAG20/quickref/#qr-keyboard-operation-trappinghttp://www.w3.org/WAI/WCAG20/quickref/#qr-keyboard-operation-trappinghttp://www.iheni.com/flash-and-keyboard-access-across-browsers/http://www.iheni.com/flash-and-keyboard-access-across-browsers/http://blogs.adobe.com/accessibility/2009/04/firefox_focus_and_actual_links_1.htmlhttp://blogs.adobe.com/accessibility/2009/04/firefox_focus_and_actual_links_1.htmlhttp://blogs.adobe.com/accessibility/2009/04/firefox_focus_and_actual_links_1.htmlhttp://www.iheni.com/flash-and-keyboard-access-across-browsers/http://www.w3.org/WAI/WCAG20/quickref/#qr-keyboard-operation-trapping


51/86

Draft 5.0

Guideline 2.2 Enough Time:

Provide users enough time to read and use content

2.2.1 Timing Adjustable (Level A)

Explanation

Under this requirement if a page or application has a time limit, the customer is givenoptions to turn off, adjust, or extend that time limit.

Some people who have disabilities will need more time to complete tasks than themajority of users: they may take longer to physically respond, they may take longerto read things, they may have low vision and take longer to find things or to read

them, or they may be accessing content through an access technology that requiresmore time.

Example

Below is a screenshot from our site giving details of the timeout feature and offering

users an option to overcome this. This approach does not fully meet the requirement

of this guideline but it at least warning customers about the timeout and offering a

way to respond to it.

Camden webteam 51


52/86

Draft 5.0

Key techniques

The minimum in the spirit of this guideline is to at least warn users that there is a

timeout and how long it will be for example 10minutes.

Ideally you should offer a mechanism that allows customers to extend the timeout an

additional 100 percent. So if the standard time is 10minutes you should offer

customers the option to extend the timeout to 20minutes.

Also if possible offer the option to turn off page refresh on logout as well which would

be helpful to screen reader users as explained in the example above.

For security reasons it is not realistic to offer customers the option to turn off a

timeout feature.

Note this is not a requirement for real-time events (e.g., an auction), where the time

limit is absolutely required, or if the time limit is longer than 20 hours.

How to test

Login to the site and check if any information is provided about timeouts - at a

minimum there should be information about how long the timeout is and ideally a

mechanism to either extend it once logged in or an option to extend when a warning

is given that you are about to be logged out from the site.

Further information

WCAG 2.0 techniques


Camden webteam 52
http://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-required-behaviorshttp://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-required-behaviorshttp://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-required-behaviors


53/86

Draft 5.0

2.2.2 Pause, Stop, Hide (Level A)

Explanation

Content that moves or auto-updates can be a barrier to anyone who has troublereading stationary text quickly as well as anyone who has trouble tracking moving

objects. It can also cause problems for screen readers.

For certain groups, including people with low literacy, reading and intellectual

disabilities, and people with attention deficit disorders, content that blinks may make

it difficult or even impossible to interact with the rest of the Web page

Example

The moving BT Flash carousel on the BT Group homepage has controls to

play/pause, fast forward and rewind that are also keyboard accessible.

Key techniques

Automatically moving, blinking, or scrolling content that lasts longer than five

seconds can be paused, stopped, or hidden by the user. Moving, blinking, or

scrolling can be used to draw attention to or highlight content as long as it lasts lessthan five seconds.

Automatically updating content (e.g., automatically redirecting or refreshing a page, a

news ticker, AJAX updated field, a notification alert, etc.) can be paused, stopped, or

hidden by the user or the user can manually control the timing of the updates.

Camden webteam 53


54/86

Draft 5.0

How to test

For any element that moves on screen if it lasts longer than 5 seconds check there is

a way to turn off or pause the movement

If any content is automatically updating on the page options are provided to pause,

stop or hide the action or they are offered a way to manually control the timing of the

updates.

Further information

WCAG 2.0 techniques


Camden webteam 54
http://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-pausehttp://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-pausehttp://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-pause


55/86

Draft 5.0

Guideline 2.3 Seizures:

Do not design content in a way that is known to cause seizures

2.3.1 Three Flashes or Below Threshold (Level A)

Explanation

People who have photosensitive seizure disorders can have a seizure triggered by

content that flashes at certain frequencies for more than a few flashes. People are

even more sensitive to red flashing than to other colours

Example

The Photosensitive Epilepsy Analysis Tool (PEAT) can be used to check if anymoving content has the potential to cause seizures. Web: http://trace.wisc.edu/peat/

Key techniques

No page content flashes more than 3 times per second unless that flashing content

is sufficiently small and the flashes are of low contrast and do not contain too much

red.

How to test

Use the PEAT tool to test any moving content as referenced above.

Further information

WCAG 2.0 techniques


Camden webteam 55
http://trace.wisc.edu/peat/http://trace.wisc.edu/peat/http://www.w3.org/WAI/WCAG20/quickref/#qr-seizure-does-not-violatehttp://www.w3.org/WAI/WCAG20/quickref/#qr-seizure-does-not-violatehttp://trace.wisc.edu/peat/


56/86

Draft 5.0

Guideline 2.4 Navigable:

Provide ways to help users navigate, find content, and determine where they are

2.4.1 Bypass Blocks (Level A)

Explanation

Skipping the navigation allows people a choice about how they navigate through a

page and enabled them to skip over repeated content on pages which can be

laborious to navigate every time. For example for screen reader users who visit

several pages on the same site can avoid having to hear all heading graphics and

dozens of navigation links on every page before the main content is spoken.

Also for people who use only the keyboard or a keyboard interface can reach content

with fewer keystrokes making navigation faster and less likely to cause pain.

Example

The AbilityNet website www.abiltiynet.org.uk uses a skip to content link(top left) that

is visible (given focus) when the tab key is used to navigate the page so both screen

reader users and keyboard users have access to the skip link.

Camden webteam 56
http://www.abiltiynet.org.uk/http://www.abiltiynet.org.uk/


57/86

Draft 5.0

The Camden Council site uses a skip link that becomes visible as it receives the

focus, as shown below

Key techniques

Provide askip navigation on all pages and ensure that the functionality is available to

screen reading software and keyboard only users.

The best approach for skip links is to make it visible only when the keyboard user

tabs to it and the skip link receives focus via CSS; as has been done on the

www.camden.gov.uk website.

The screen reader user will still hear the link with this approach, and sightedkeyboard users can also make use of the link, however mouse users, who do not

use skip links, will not see it.

A typical example for coding a skip link would be:

Skip to content

Camden webteam 57
http://www.camden.gov.uk/http://www.camden.gov.uk/


58/86

Draft 5.0

With the following style declarations in the CSS:

#skip a, #skip a:hover, #skip a:visited{position: absolute;left:0px;

top:-1000px;width: 1px;height: 1px;overflow: hidden;}

#skip a:active, #skip a:focus {position:static;width:auto;height: auto;}

In the above example, two styles are created. The first style hides the skip to content

link from view whilst the second active style moves the skip to content link to the

visible area when it receives focus from the tab key. More information on this

technique can be found at http://www.abilitynet.org.uk/webarticle67

Note1: If a page has a proper heading structure, this may be considered a sufficient

technique instead of a "Skip to main content" link. Note that navigating by headings

is not yet supported in all browsers.

Note2: If a page uses frames and the frames are appropriately titled, this is a

sufficient technique for bypassing individual frames.

How to test

If you cannot visually see a skip to content link - tab through the page and see if a

skip link appears. If not, view the html code and look for a skip link option. Also test

that the skip link works on all pages.

Further information

WCAG 2.0 techniques


Camden webteam 58
http://www.abilitynet.org.uk/webarticle67http://www.abilitynet.org.uk/webarticle67http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-skiphttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-skiphttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-skiphttp://www.abilitynet.org.uk/webarticle67


59/86

Draft 5.0

2.4.2 Page Titled (Level A) NEW

ExplanationWeb pages should have html titles that describe their topic or purpose. This helps

users to find content and orient themselves within the site.

Example

Below is an example of a clear html page title on our website (Apply for housing and

council tax benefit online)

Key techniques

Ensure each webpage has a descriptive and informative page title using the html

element that reflects the pages content.

How to test

Review the page title and check it clearly relates to the page content and is not left

blank or just duplicates the homepage page title.

Further information

WCAG 2.0 techniques


Camden webteam 59
http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-titlehttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-titlehttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-title


60/86

Draft 5.0

2.4.3 Focus Order (Level A)

Explanation

For keyboard users who tab through the page the focus order of links should be

logical or intuitive

Example

An example of illogical tabbing using the screenshot below would be after starting at

the logo the tabbing went backwards through the 4 colour schemes from far right to

left

(2 to 5) then the text size in reverse (6 to 8) order then the search box (9) and thetext sizes going before going to the search box.

Key techniques

When creating the web page ensure that the logical flow of how you would tab

through the page matches the visual sequence. For instance, when tabbing through

a form, you expect the fields to be selected in the order they appear on the page e.g.

firstname, lastname, email address etc

If you are inserting dynamic content into the page such as a hide / show feature

ensure it immediately follows its trigger element in the Document Object Model

How to test

Tab through the page and check the sequence makes sense

Further information

WCAG 2.0 techniques


Camden webteam 60
http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-focus-orderhttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-focus-orderhttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-focus-order


61/86

Draft 5.0

2.4.4 Link Purpose (In Context) (Level A)

Explanation

Screen reader users often have problems with links that do not make sense on apage asa minimum it should be possible to work out from the context of the link

where it will take you

Example

The Open link images shown in the screenshot below have no descriptive alt text soit is not possible for a screen reader user to work out the context of the links theyjust come up as LicenseeImages/view.gif

Fig 20 Images links do not make sense in context

The solution is simply to add an alt text (as discussed in the images section) to the

Open links as a minimum you can use alt=open as shown in the code snippet

below:

But it would be more helpful (but optional) to add in a more descriptive alt text such

as alt=Open Pension benefit details for the link to each benefit.

Another example

The Click here link shown in the screenshot below is not descriptive so it is notpossible for a screen reader user to work out the context of the link it would justappear as click here and not offer any information on where the link takes you.

Camden webteam 61


62/86

Draft 5.0

The solution is simply make the link a description of what you will find after clicking

on it as shown in the image below.

You can use text links such as Find out more or More information as long as the

link relates directly to the previous heading so it makes sense in context.

The surrounding text (heading, paragraph, list item, table cell) can be used to add

context to a link as shown in the image above.

Camden webteam 62


63/86

Draft 5.0

Key techniques

Ensure the purpose of each link (or form image button or image map hotspot) can be

determined from the link text alone, or from the link text and it's context (e.g.,

surrounding paragraph, list item, table cell, or table headers).

Links (or form image buttons) with the same text that go to different locations are

readily distinguishable by the surrounding text.

How to test

Review the page and check all links make sense in the context of the page,

especially make sure that any links with the same text that go to different pages such

as More information are clearly differentiated by their surrounding text.

Further information


Camden webteam 63
http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-refshttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-refshttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-refs


64/86

Draft 5.0

2.4.5 Multiple Ways (Level AA)

Explanation

Even small sites should provide users with some means of orientation. The purpose

of this success criterion is to make it possible for users to locate content in a mannerthat best meets their needs. Users may find one technique easier or more

comprehensible to use than another

Example

Our website has a global site search, site map and an A-Z

Key techniques

Multiple ways are available to find other web pages on the site - at least two of the

following:

a list of related pages

table of contents

site map

site search

list of all available web pages.

For simplicity the key technique is to offer both a site search and a sitemap.

How to test

Review the page and ensure that both a site search and a sitemap link are available

Further information

WCAG 2.0 techniques


Camden webteam 64
http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-mult-lochttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-mult-lochttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-mult-loc


65/86

Draft 5.0

2.4.6 Headings and Labels (Level AA) NEW

ExplanationWell written headings will trigger a users interest and draw them to a relevantsection of the page. They should also be descriptive and unique on the page to help

people know where they are within the page specifically an issue for screen reader

users. Labels should also be unique and descriptive to avoid confusion.

Example

On the 2 level homepages on our site, we use clear descriptive headings which

summarise what you can find in the area

Camden webteam 65


66/86

Draft 5.0

Key techniques

Provide descriptive headings that are descriptive and ideally unique - avoid

duplicating heading (e.g., "More details") unless the structure provides adequate

differentiation between them.

Ensure all labels for form fields and any interactive elements are clearly labeled for

example for an online map where users can zoom in" to view part of the map in

greater detail, and can zoom out" to make the show a larger part of the city.

The controls can be operated using either a mouse or a keyboard. The controls are

labelled Zoom in (Ctrl + Shift + L)" And Zoom out (Ctrl + Shift + R)."

An additional recommendation is to avoid all CAPS headings as they are more

difficult to read than Sentence case particularly for people with Dyslexia. Insteademphasise headings via bold fonts, bigger font size or different colour, using CSS

style sheets rather than writing them in all caps.

How to test

Scan the headings and labels on the page and ensure they are descriptive and

ideally unique

Further information

WCAG 2.0 techniques


Camden webteam 66
http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-descriptivehttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-descriptivehttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-descriptive


67/86

Draft 5.0

2.4.7 Focus Visible (Level AA) NEW

Explanation

Keyboard users need to know where they are when they tab through links on a page.

Providing a keyboard focus highlight via CSS or scripting gives them a clear visual

indicator so they dont become disoriented or lost.

Example

Below is a screenshot from the AbilityNet website that shows when the Link BT

Community Connections is tabbed to it is not only highlighted with a dotted outline

but the link and background colours are also changed.

Key techniques

At a minimum ensure each link has a standard dotted line around it when it is tabbed

to (receives focus) and ideally use CSS to enhance this by changing the colour of

the link or the link and background colour.

A browser like Mozilla Firefox supports the CSS pseudo class: focus, but Internet

Explorer has for some unknown reason instead implemented the: active pseudo

class as if it was ":focus". Web pages using a:focus degrades gracefully in browsers

that do not support the :focus pseudo class: they show the usual dotted rectangle

around the link having focus.

Camden webteam 67


68/86

Draft 5.0

For images such as the print icon shown below you can use CSS to swap the

images over to show when it is selected when you tab onto it. A slightly different

image, such as a different colour should be provided for the print icon when it has

focus.

The CSS code for the print images would be similar to:

#print {

background-image:url(print);}

#print:hover, #print:focus, #print:active {

background-image:url(print-hover.jpg);}

How to test

Check it is visually apparent which page element has the current keyboard focus

(i.e., as you tab through the page, you can see where you are?

Further information


2.4.8 Location (Level AAA) recommended

Explanation

When a web user is going through a process with a series of steps such as paying

their council tax it is helpful to indicate which step they are on and how many steps in

the sequence so they are clear about progress and know where they are.

Key techniques

In a sequence of pages that are steps in a process ensure you add in details of

which step they are in such as step 2 of 5 - address details and step 4 of 5

confirm order and pay.

Camden webteam 68
http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-focus-visiblehttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-focus-visiblehttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-focus-visible


69/86

Draft 5.0

Examples

Two different examples used on the Camden website are shown below.

Further information

WCAG 2.0 techniques


Principle 3: Understandable

Understandability can be just as big a barrier to accessibility as any of the

more technical issues. Talking about understandability moves the discussion

into the broader realm of usability.

Guideline 3.1 Readable:

Make text content readable and understandable

3.1.1 Language of Page (Level A)

Explanation

The language of each page needs to be specified. This is so browsers and assistive

technologies (such as screen readers) can identify the language of a given page and

use the right speech engine.

Example

This example below defines the content of an XHTML 1.0 document with content

type of text/html to be in the English language. Both the lang and xml:lang attributes

Camden webteam 69
http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-locationhttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-locationhttp://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-location


70/86

Draft 5.0

are specified in order to meet the requirements of XHTML and provide backward

compatibility with HTML.

Key techniques

Use the HTML lang attribute (, for html, and xml:lang=en for xhtmlto specify the language of the page.

How to test

View the page code and check the language has been specified, for example


71/86

Draft 5.0

How to test

Review the page for any non English words and then review the code to check the

right language attribute has been used for the text. Alternatively use a screen reader

like Jaws to read through the page and listen for whether the non English text is read

out correctly note by default Jaws will have a number of European languageloaded it might not have drivers for other language unless they have been

installed.

Further information

WCAG 2.0 techniques


Camden webteam 71
http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-other-lang-idhttp://www.w3.org/WAI/W

camden web accessibility guide v.1

Documents