Draft 5.

Camden web accessibility guide

July 2011

Camden webteam

Draft 5.0

Table of Contents
Introduction................................................................................................................................................. 3 IntroductiontoWCAG2.0 ............................................................................................................................ 4 WhatsnewinWCAG2.0 ............................................................................................................................. 6 NewtermsinWCAG2.0 .................................................................................................................................... 7 MorepreciseSuccessCriteria............................................................................................................................ 8 Obsoletecheckpointsremoved ......................................................................................................................... 8 MoreflexibleSuccessCriteria............................................................................................................................ 8 Changesinpriority ............................................................................................................................................. 9 JavaScriptisallowedifaccessible ...................................................................................................................... 9 SixnewPriority1requirements ...................................................................................................................... 10 FournewPriorityAArequirements ................................................................................................................. 11 WCAG2.0LevelAandAAindetail ............................................................................................................. 13 Principle1:Perceivable.................................................................................................................................... 13 Principle2:Operable ....................................................................................................................................... 47 2.4.6HeadingsandLabels(LevelAA)NEWExplanation................................................................................. 65 Principle3:Understandable ............................................................................................................................ 69 3.2.4ConsistentIdentification(LevelAA)........................................................................................................ 76 Explanation ...................................................................................................................................................... 76 3.2.4Changeonrequest(LevelAAA) .............................................................................................................. 77 Explanation ...................................................................................................................................................... 77 Principle4:Robust ........................................................................................................................................... 83

Camden webteam

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

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, data tables 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

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

Draft 5.0

Whats new in WCAG 2.0

WCAG 1.0 focused heavily on the techniques for accomplishing accessibility for example HTML. Version 2.0 focuses more heavily on the principles of 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 testing are 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 guidelines and success criteria in 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

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

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 color combinations 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

Draft 5.0

Changes in priority
Some requirements have different priority levels in WCAG 2.0 1.3.1 Info and Relationships - marking up headings and forms accessibly is now level A rather than AA 2.1.1 Keyboard: 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.1 Parsing (basic validation) - is now level A rather than AA 2.4.1 Bypass Blocks - skip links are now A rather than AAA 1.4.3 Contrast - 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 software and Voice Recognition technology under WCAG 2.0.

Camden webteam

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 and operating 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 that component 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

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 of operation 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

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

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 each Success Criterion with a link to the detailed sufficient 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 is inaccessible

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

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

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 of the link not a description of the image itself. b. Empty alt (alt=) text should only be put on images that do not convey any useful information to the content of the page such as spacer and decorative graphics or images wrapped in the same anchor tags as the equivalent text link so both screen readers and text readers ignore them making the page a more pleasant experience to read. Keep alt text concise and brief - avoid verbosity. c. Where possible, start the alt text with a keyword, for example simply use Broadband rather than Click here for BT Broadband. This benefits 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 the list that starts with B. d. For more complex images like pie charts or graph an alt text will not be sufficient to describe the image either provide a table of data with the chart, a link to a spreadsheet to download, or describe the graphic in words on the page or link to a longer description using the longdesc attribute - for example <p><img src="chart.gif" alt="a complex chart" longdesc="chartdesc.html"/></p>

Camden webteam

15

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

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

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 effective captioning. 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

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 most accessible 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

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 to indicate 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

Draft 5.0 For more detail see http://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

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 <strong> tags not the <b> tag. Coded this way a screen reader will hear the Display and Edit text read out more loudly for emphasis. <strong>Display and Edit</strong>

Camden webteam

22

Draft 5.0 Key techniques For bolding text use the <strong> tag rather than <b> tag or CSS Replace <font> 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 <font> and <u> have been used In addition you will need to check the code for instances of <b> tag where <strong> should be used. In the example below, the text with the deprecated tag (<font face="helvetica">Camden council</font>) is highlighted.

Camden webteam

23

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 semantic markup to mark emphasized or special text (HTML) H48: Using ol, ul and dl for lists (HTML)

Camden webteam

24

Draft 5.0

Headings WCAG 2.0 reference 1.3.1 Info and Relationships - Level A Explanation Screen reader users often listen to headings out of context from the main content of the 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 <H2> 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 <H1> 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

Draft 5.0 Do not use <H1> headings in the body of the page. As far as possible, below the main <H1> heading should come the secondary, or h2, headings. Subheadings of these sections should be level 3, or <H3>, headings, and so on as shown below:

Depending on the page structure it might not be possible to have an <H1> 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 to ensure they follow a logical sequence H1>H2>H3 and visually match the heading structure of the page.

Camden webteam

26

Draft 5.0

Further information WCAG 2.0 techniques H42: Using H1- H6 to identify headings (HTML)

Camden webteam

27

Draft 5.0

Data Tables WCAG 2.0 reference 1.3.1 Info and Relationships - Level A Explanation The 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 <th> tag with the scope attribute added. Also note the column rows are coded up correctly as well.

Camden webteam

28

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 ( <th scope=col> and <th scope=row>) 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 <th> 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

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.

<label for="query" class="hide">Search :</label> <input name="query" type="text" size="15" id="query" onfocus="this.value=''" value="-" />

Camden webteam

30

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. Example HTML for an Accessible Form
<form><label for="name">name:</label>

<input type="text" id="name" size="50"> <br> <br> <legend>sex</legend> <input type="radio" name="sex" id="male"> <label for="male">male</label> <input type="radio" name="sex" id="female"> <label for="female">female</label> <br><br> <label for=employ">employment type:</label> <select name=employ" id=employ"> <option>permanent</option> <option>part time</option> <option>temporary</option> </select> <br><br> <label for="com"> comments:</label><br> <textarea rows=10 cols=30 id="com"></textarea> <br> <input type="submit"> <input type="reset"></form>

Note: The value of the label "for" attribute must be the same as the value of the fields "id" attribute for the label attribute to work properly. The fields without labels do not have to have visible labels to make them accessible; you can use hidden labels using CSS to hide the code but still make it accessible to

Camden webteam

31

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 using CSS 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 left of the form field When using checkboxes and radio buttons, labels should be positioned to the right of the form field

Camden webteam

32

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

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 visually for 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

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

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

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 techniques For 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 uses colour 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

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

For detailed sufficient techniques see: How to Meet 1.4.1

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 For detailed sufficient techniques see: How to Meet 1.4.2

Camden webteam

38

Draft 5.0

1.4.3 Contrast (Minimum)(Level AA) Explanation Not all users can differentiate between similar colour combinations and tones. Even where 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

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/contrastanalyser.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

For detailed sufficient techniques see: How to Meet 1.4.3

Camden webteam

40

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

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

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

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 of text 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

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 contrast colour 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 For detailed sufficient techniques see: How to Meet 1.4.5

Camden webteam

45

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 help people 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 test Review the page manually and check for justified text Further information WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 1.4.8

Camden webteam

46

Draft 5.0

Principle 2: Operable
Not 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 to use 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

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 WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 2.1.1

Camden webteam

48

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 other controls. 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 held down. 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

Draft 5.0 Further information WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 2.1.2 Other resources Flash 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

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 given options to turn off, adjust, or extend that time limit. Some people who have disabilities will need more time to complete tasks than the majority of users: they may take longer to physically respond, they may take longer to 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 requires more 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

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 For detailed sufficient techniques see: How to Meet 2.2.1

Camden webteam

52

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 trouble reading 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 less than 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

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 For detailed sufficient techniques see: How to Meet 2.2.2

Camden webteam

54

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 any moving 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 For detailed sufficient techniques see: How to Meet 2.3.1

Camden webteam

55

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

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 sighted keyboard 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: <div id=skip> <a href=#mainContent>Skip to content</a> </div>

Camden webteam

57

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 For detailed sufficient techniques see: How to Meet 2.4.1

Camden webteam

58

Draft 5.0

2.4.2 Page Titled (Level A) NEW

Explanation Web 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 <title> 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 For detailed sufficient techniques see: How to Meet 2.4.2

Camden webteam

59

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 the text 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 For detailed sufficient techniques see: How to Meet 2.4.3

Camden webteam

60

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 a page as a 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 so it is not possible for a screen reader user to work out the context of the links they just 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: <img src="../assets/LicenseeImages/view.gif" alt=Open border="0" /></a>

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 not possible for a screen reader user to work out the context of the link it would just appear as click here and not offer any information on where the link takes you.

Camden webteam

61

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

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
WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 2.4.4

Camden webteam

63

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 manner that 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 For detailed sufficient techniques see: How to Meet 2.4.5

Camden webteam

64

Draft 5.0

2.4.6 Headings and Labels (Level AA) NEW

Explanation Well written headings will trigger a users interest and draw them to a relevant section 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

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. Instead emphasise 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 For detailed sufficient techniques see: How to Meet 2.4.6

Camden webteam

66

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

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 WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 2.4.7

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

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

Further information WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 2.4.8

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

Draft 5.0 are specified in order to meet the requirements of XHTML and provide backward compatibility with HTML.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">

Key techniques Use the HTML lang attribute (<html lang="en">, for html, and xml:lang=en for xhtml to specify the language of the page. How to test View the page code and check the language has been specified, for example <html lang="en> for english in html and xml:lang=en for xhtml. Further information WCAG 2.0 techniques
For detailed sufficient techniques see: How to Meet 3.1.1

3.1.2 Language of Parts (Level AA) Explanation If you have more than one language on a page you need to ensure it is coded with the relevant language attribute so it can be understood by adaptive technology such as screen readers who can then load the right language drivers to pronounce the text properly. Example To code French in an html page with English specified as the default language you use the lang attribute as follows: <p><span lang=fr>En garde:</span> French for 'on guard' - the position that fencers take before a bout begins</p>

Key techniques
When appropriate, the language of sections of content that are a different language are identified, for example, by using the lang attribute (<blockquote lang="es")>

Camden webteam

70

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 language loaded it might not have drivers for other language unless they have been installed. Further information WCAG 2.0 techniques
For detailed sufficient techniques see: How to Meet 3.1.2

Camden webteam

71

Draft 5.0

Guideline 3.2 Predictable:

Make Web pages appear and operate in predictable ways 3.2.1 On Focus (Level A) Explanation This Success Criterion helps people with visual disabilities, cognitive limitations, and motor impairments by ensuring that functionality is predictable as they navigate their way through a web page reducing the chance that a change of context will occur unexpectedly and cause them confusion. Example An example of breaking this requirement is opening a new window as soon as a new page is loaded as shown in the screen shot below; where a life insurance page automatically pops up when the user goes to the homepage of an online newspaper.

Key techniques If significant changes occur such as new window popping up on screen when some element on screen is selected or has focus you need to warn users. Ensure when a page element receives focus, it does not result in a substantial change to the page such as: the spawning of a pop-up window such as adverts ensure a page pops up a new window only when the user clicks (or uses spacebar) on a button rather than using onfocus to pop up a new window. An unexpected change of keyboard focus for example tabbing to a submit button results in the form being submitted ensure the submit button needs to be activated to submit the form or any other change that could confuse or disorient the user. As a general approach use activate" rather than "focus" as a trigger for changes of context

Camden webteam

72

Draft 5.0 How to test Using a keyboard tab through all the selectable elements on screen and check no unexpected changes of context occur when any component receives focus. Further information WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 3.2.1

3.2.2 On Input (Level A)

Explanation This requirement is very similar to D11.1 Focus and content change - when a user inputs information or uses a control on the page it must not results in a significant changes unless you have warned the user beforehand. The intent of this Success Criterion is to ensure that entering data or selecting a form control is predictable. Example When inputting a phone number in a form with an area code and main number form fields the focus automatically shifts from the area code when it is input to the main number. If the user is warned this change in focus is going to happen it passes this guideline - if no warning is given it would break this guideline. Key techniques When a user inputs information or interacts with a control ensure it does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user unless the user is informed of the change ahead of time. How to test Check putting data / making selections for all controls on the page such as form fields does not result in an unexpected change of focus unless there is a clear warning on the page it is going to happen Further information WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 3.2.2

Camden webteam

73

Draft 5.0 3.2.3 Consistent Navigation (Level AA)

Explanation For many disabled users poor navigation can make websites frustrating or impossible to use. It is important that navigation elements that are repeated across pages have the same relative order to avoid confusion and disorientation. Examples: Always positioning a skip link as the first link on the page Place the search box on the top right of every page. A left navigation menu includes a list of seven main links. When one of the links is selected its related sub navigation links appear as a list below the relevant main link - so all the main links are still in the same relative order.

Below shows a screenshot of a website with inconsistent, confusing layout across four pages. Layout changes from page to page, the appearance of the main page heading varies from page to page, and the appearance and position of the main navigation feature also changes.

Camden webteam

74

Draft 5.0 Key techniques When designing pages ensure elements such as navigation bars and search boxes are positioned consistently across pages so they would be in the same relative position on every page. How to test Review pages designs and ensure elements are positioned in the same place (relatively) on the page. Note that homepages often have a different layout to subpages but as far as possible keep the same positioning. Further information WCAG 2.0 techniques For detailed sufficient techniques see How to Meet 3.2.3

Camden webteam

75

Draft 5.0

3.2.4 Consistent Identification (Level AA)

Explanation To avoid confusing customers, page features such as search that have the same functionality across multiple web pages should always be labelled the same way. People who use screen readers and those with cognitive impairments such as dyslexia rely heavily on their familiarity with functions that may appear on different web pages. If identical functions have different labels on different web pages, the site will be considerably more difficult to use. Examples If a search button is labelled go on one page and search on another it can cause confusion. Another example of inconsistency would be on a multi step transaction process to sign up for an account a next button is used on some pages and continue on others to go to the next step in the process. On our payments site we use this technique where appropriate, but on some pages it is clearer to have make a payment or proceed to give card details which give a clearer call to action than a next button would. Use common sense when applying this technique. Key techniques When designing the site ensure that labels are used consistently for the same features and functions such as search. How to test Review all the elements that are repeated across pages and check they have the same labels / descriptions. Further information WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 3.2.4

Camden webteam

76

Draft 5.0 3.2.4 Change on request (Level AAA)

Explanation People can be confused if a web link opens a new window and they have not realized this has happened they might try and click the back button but this will obviously no longer work or a screen reader user might be disorientated to where they are. Key techniques To avoid confusing customers, A hyperlink or pop-up that opens a new browser window on an external site must inform the user this is going to happen by adding to a title text of title=link opens in a new window or in the alt text if an image link - for example if a link to the NHS Camden website using their logo opens in a new window the alt text would be alt= NHS Camden link opens in a new window Editing the title attribute will involve editing the HTML code, if you dont have access to this, please add to the actual text of the link (link opens in a new window) How to test You can use the WAT toolbar to check for links that open in new windows go to Doc Info > JavaScript/New Window Links and review all the links highlighted to ensure they all have a clear description that they will open in a new window. Further information WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 3.2.5

Camden webteam

77

Draft 5.0

Guideline 3.3 Input Assistance:

Help users avoid and correct mistakes 3.3.1 Error Identification (Level A) NEW

Explanation The purpose of this Success Criterion is to ensure that users are aware that an error has occurred and can determine what is wrong. The error message should be as specific as possible. In the case of an unsuccessful form submission, re-displaying the form and indicating the fields in error is insufficient for some users to perceive that an error has occurred. Screen reader users, for example may abandon the form altogether, thinking that the page simply is not functional. Example Below is an example of unclear error feedback if you do not fill in the username or password or both fields you just see a red asterisk next to the fields indicating an error rather than any helpful text

Below is an example of clear error feedback in our payments area, this is in addition to a message at the top of the page alerting users to a problem with the form.

Key techniques When using form validation clearly alert users to errors in an accessible way for example put text highlighted in red before the form to indicate what the error is.

Camden webteam

78

Draft 5.0

Error Identification best practice: Set up a standard method for identifying required fields and errors and maintain it throughout the site, so it will become easily recognisable to all users. Include all vital information relating to a form field in the label tag, such as tips, and mandatory field identifiers, A span with a title="mandatory" or title=required on the asterisk would helpful Identify errors through text and structure. Visually, errors should be marked with strong red text (and ideally a hazard symbol); the same clarity should be provided for non-sighted users. Use <strong> to emphasize text, and prefix the error message at the top of the page with the word 'Error', so the user is immediately alerted to the fact their form has not been submitted. Adding the error message in the label field next to the form element in question also helps user identify which field is causing the problem There should be an error message at the top of the page or in a pop up event window, so a screen reader user does not have to navigate through a lot of page content, before finding out there has been a problem with the form If possible, include anchor links above the form down to the problem fields. Provide clear, succinct instructions on any necessary information for completing the form to prevent error.

How to test Systematically go through a form and check all error messages are clearly provided in an accessible way (ideally in red before the form) by trying to submit it by missing out or putting in the wrong data into fields. Further information WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 3.3.1

Camden webteam

79

Draft 5.0

3.3.2 Labels or Instructions (Level A) NEW

Explanation The purpose of this success criterion is to help users avoid making mistakes when inputting information by giving them enough guidance so they know what to do. This can come in the form of clear instructions, examples, properly positioned form labels, and/or fieldsets/legends Example For example in a date, field include the year format you need such as dd/mm/yy in the fields label or at least in the fields title attribute. The example below uses the right guidance but places the information outside the label tag so it is not as accessible as it could be.

Key techniques Provide clear labels, cues, and instructions for form fields, specifically:

Make sure each field has a descriptive label Place the label close to its related field to help magnification users Provide examples of data format for fields where appropriate such as date fields Give clear instructions on filling in the form especially if it spans more than one screen for example a sign up process to a service

You also need to ensure when you indicate mandatory fields for example with a red asterisk it is included within the field label tag not outside it as Screen readers usually utilise a "forms mode" when completing web forms. When in forms mode, only form elements and their associated labels are read as they read through the form. Therefore, any instructions and cues that are not part of a form label or a fieldset legend, could be ignored.

Camden webteam

80

Draft 5.0

Explanation As users with disabilities potentially find it harder to spot mistakes when inputting information this success criterion builds in an extra safeguard by allowing the user to change or delete legal, financial, or test data, the changes/deletions are reversible, verified, or confirmed. Example Below is an example on our online payments where you can review, the details of your payment amount and change or delete them if you wish before you enter your card details.

Key techniques When a user is buying a product or services build in a review stage so they can check all the details are correct and have the option to edit or delete any of them before they submit them. How to test Go through the steps of purchasing a product or service and before submission check there is a stage where you can change or delete all aspects of the order.

Camden webteam

81

Draft 5.0 Further information WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 3.3.4

Camden webteam

82

Draft 5.0

Principle 4: Robust
People use different operating systems, different browsers, and different versions of browsers. Despite the differences between users and the technologies they use, they all expect the web to work. As far as possible users should be allowed to choose their own technologies to access web content

Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies

4.1.1 Parsing (Level A) Adaptive technology makes the assumption that web pages have been created using specific rules and that they validate against those standards - if this is not the case it can cause quirky or unpredictable behaviour in adaptive technology software. Example The Amazon.co.uk homepage fails on a number of parsing requirements such as failing to close tags correctly.

Key techniques The key requirement is to create well formed code, for example: content is created according to the rules defined in the formal grammar for that technology for example xhtml or html elements have complete start and end tags 83

Camden webteam

Draft 5.0 elements are nested according to their specifications for example not putting a div tag inside a paragraph tag or using span across items in a list when it should only be used for one list item, Elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

Note: Validating to published formal grammars is a stronger requirement than what is required by this Success Criterion but validation is one of the sufficient techniques for this Success Criterion.

How to test You can use the following or similar tools to identify where the parsing code errors are in your pages and fix them. X/HTML validator at: http://validator.w3.org/ CSS validator at: http://jigsaw.w3.org/css-validator/ Further information WCAG 2.0 techniques For detailed sufficient techniques see: How to Meet 4.1.1

Camden webteam

84

Draft 5.0

4.1.2 Name, Role, Value (Level A)

Explanation For people that use adaptive technology such as screen readers interface elements of a page like Flash and multimedia movies as well as forms and menus need to have descriptions or labels associated with them that make sense so they can use them effectively being clear about their purpose and their current stare. Example The JW flash player has all its Flash buttons correctly labelled in the screenshot below in addition when the play button is selected the button state is changed to Pause. Note the Unlabelled1 Combo box Select Language html field is however missing a label which is before the video player in the html page code. Note that in Jaws Flash buttons are treated as Form buttons which is why they are listed under Form Fields.

Camden webteam

85

Draft 5.0

Key techniques For HTML follow the HTML /XHTML specifications for using forms, form labels, frame titles, etc. appropriately. For technology like Flash ensure you expose names and roles so they can be understood by adaptive technology. See the Flash best practice accessibility guide in this series or see www.adobe.com/accessibility How to test The only way to test this requirement is to use a screen reader to check all interface controls are accessible. Further information WCAG 2.0 techniques
For detailed sufficient techniques see: How to Meet 4.1.2

Camden webteam

86