Study on

“Web accessibility in European countries: level of compliance with latest international

accessibility specifications, notably WCAG 2.0, and approaches or plans to implement those

specifications”

Annex I

Methodological details and on the examination of a sample of web sites against WCAG 1.0 and WCAG 2.0

2

Table of Contents

1 Detailed Methodology Used for Website Evaluation – WGAG 1.0 Testing 3

1.1 Assessment Process................................................................................................. 3 1.1.1 Site Section .......................................................................................................................3 1.1.2 Automated Assessment ....................................................................................................4 1.1.3 Definition of Pass and Failure at Level A – WCAG 1.0.....................................................4 1.1.4 Results of WCAG 1.0 Testing ...........................................................................................5

2 WCAG 2.0 – Manual Assessment 6

2.1 Results of web sites that passed WCAG 1.0 automatic testing .................................... 6 2.2 Review of WCAG 2.0 checkpoint failure of web sites that did pass WCAG 1.0 automatic

testing .................................................................................................................. 10 2.2.1 Principle 1 – Perceivable.................................................................................................10 2.2.2 Principle 2 – Operable.....................................................................................................21 2.2.3 Principle 3 – Understandable ..........................................................................................29 2.2.4 Principle 4 – Robust ........................................................................................................31

2.3 Results of the Websites that did not pass WCAG1.0 automated testing ..................... 32 2.4 Review of WCAG 2.0 checkpoint failure for the Websites that did not Pass WCAG 1.0

Automated Testing ................................................................................................ 37 2.4.1 Principle 1 – Perceivable.................................................................................................37 2.4.2 Principle 2 – Operable.....................................................................................................42 2.4.3 Principle 3 – Understandable ..........................................................................................46

3 Detailed Success Criteria for Level A – WCAG 2.0 51 4 Benefits of an Accessible Website 62

3

1 Detailed Methodology Used for Website Evaluation – WGAG 1.0 Testing

1.1 Assessment Process

1.1.1 Site Section

The URLS used in the MEAC Study were reassessed in 2009 and were submitted for automated assessment. This assessment addressed seven themes each of which includes a number of distinct WCAG 1.0 Priority 1 Checkpoints. These checkpoints are reflected in the following table.

Table 1: WCAG 1.0 Priority Checkpoints

General Checkpoints

No. Details

1.1 Provide a text equivalent for all non-text elements.

2.1 Ensure that all information conveyed with color is also available without color, for example from

context or markup.

4.1 Clearly identify changes in the natural language of a document's text and any text equivalents

(e.g., captions).

6.1

Organize documents so they may be read without style sheets. For example, when an HTML

document is rendered without associated style sheets, it must still be possible to read the

document.

6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes.

7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.

Checkpoints for if you use images and image maps:

No. Details

1.2 Provide redundant text links for each active region of a server-side image map.

9.1 Provide client-side image maps instead of server-side image maps [except where the regions cannot

be defined with an available geometric shape].

Checkpoints for if you use tables:

No. Details

5.1 For data tables, identify row and column headers.

5.2 For data tables that have two or more logical levels of row or column headers, use markup to

associate data cells and header cells.

4

Checkpoints for if you use frames:

No. Details

12.1 Title each frame to facilitate frame identification and navigation

Checkpoints for if you use applets and scripts:

No. Details

6.3

Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or

not supported. If this is not possible, provide equivalent information on an alternative accessible

page.

Checkpoints for if you use multimedia:

No. Details

1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an

auditory description of the important information of the visual track of a multimedia presentation.

1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent

alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.

If all else fails:

No. Details

11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that

uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated

as often as the inaccessible (original) page.

Each of the submitted 120 URLS was processed by retrieving a number of pages, commencing with the home page and progressively following the hyperlinks to a predetermined depth within each domain. Wherever possible the domain depth selected was 5 and the number of pages analysed was 25. The results of the assessment were then consolidated for each site and stored in a spreadsheet for analysis.

During this process a number of sites could not be analysed since technical problems with the sites were encountered whereas in some cases duplicate URL were provided. At the conclusion of the process, usable data was obtained from 102 sites.

1.1.2 Automated Assessment

The automated assessment was undertaken using the software tool Test Accessibilidad Web (TAW) which has been developed by the Spanish Fondacion CTIC http://www.tawdis.net/taw3/cms/en. This tool has been widely used within Europe and the Danish office for Public Information On-line 1(OIO), provides TAW as the accessibility-assessment tool of choice.

1.1.3 Definition of Pass and Failure at Level A – WCAG 1.0

Fail – Websites with failure in Level A conformance. Site fails distinct automatic priority 1 checks.

1 The Danish office for Public Information On-line is a section under the Agency for IT and Telecommunications (http://www.itst.dk/), which is itself a department under the Ministry for Science, Technology and Development (www.vtu.dk).

5

Marginal Fail - Websites that fail automatic testing, but only in relation to check point 1.1 (Atlttext) at a level below specific quantitative thresholds2

Pass (Automatic only) – Websites that fully passed automatic testing, but fail subsequent manual testing Pass (Automatic and Manual) – Webs that pass automatic testing and all checkpoints that were manually as

1.1.4 Results of WCAG 1.0 Testing Table 2: Results of Automatic Checking of WCAG 1.0 Testing

Total Sites Submitted for

Testing

Total Sites Tested

Total Sites Passed

Automatic & Manual Testing

Total Sites Passed

Automatic Testing

Total Sites that Marginally

Failed Automatic

Testing

Total No. of Sites that Failed non-marginally

120 102* N= 0

0.0%

N=23

22.55%

N=15

14.70%

N=64

62.74%

* 10 Duplicates, 7=Technical Problems 1= NA

2 A ‘marginal fail’ was assigned where the website only failed the automatic test in relation to checkpoint 1.1 (which relates to provision of text ALT Attributes for images and image map hotspot areas) and where the number of images lacking the ALT Attribute is less than or equal to 10 or (including image map hotspots) is less than or equal to 5% of all the images found; if a site failed any other checkpoint it was classified as ‘failed’.

2 WCAG 2.0 – Manual Assessment Given that there does not exist an automatic testing tool for WCAG 2.0 assessment, it was decided that a manual assessment of WCAG 2.0 Level A Conformance would be undertaken. This assessment consisted of selecting 3 pages within a given site: the Home Page, the Contact Page and the Search. Each of these pages was subjected to a Manual Assessment which was guided by a compiled worksheet3 which detailed the Success Criterion and defined the Pass and Failure Criteria at Level A. This worksheet is reflected below. The Manual Assessment was undertaken for ALL 103 Websites which are part of this study. The following section 2.1. reflect the results of the 23 websites that passed WCAG 1.0 Automatic Testing and were submitted for WCAG 2.0 Manual Assessment. The results of the remaining 80 websites are presented in section 2.2.

2.1 Results of web sites that passed WCAG 1.0 automatic testing

None the 23 websites that were that passed WCAG 1.0 Automatic Assessment and were submitted for WCAG2.0 Manual Assessment – successfully passed the WCAG2.0 Success Criteria for Level A Conformance.

Please Note: The following table and figures only reflect those websites that successfully passed the Automatic Testing associated with WCAG1.0 (23 Websites).

WCAG 2.0 Success Criteria Failures

0

2

4

6

8

10

12

14

16

18

Websites Automatically Passing WCAG 1.0 Success Criteria

Tota

l Num

bero

f W

CA

G 2

.0 F

ailu

re

Figure 1: Total Number of Failures per Website.

Website failures ranged from between 2–16 failures. Table 3 reflects the percentage of websites that Passed, Failed or Marginally Failed to comply with each of the Success Criteria for Level A WCAG 2.0 Guidelines.

3 The Worksheet was built based on the WCAG 2.0 Checklist http://www.usability.com.au/resources/wcag2-aaa-worksheet.doc, the http://webaim.org/standards/wcag/checklist, the approach developed by the eAccessibility of Public Sector Services in the European Union available at www.cabinetoffice.gov.uk/e-government/eaccessibility and the MEAC Study.

6

7

Table 3: Percentage of Website Compliancy with WCAG 2.0 Success Criteria Level A - N=23

Success Criteria* for Level A compliance of WCAG 2.0

% of Websites

which Failed

% of Websites

which Passed

% of Websites

Marginally Failing

% of Websites where the

Criteria was NA

PERCEIVABLE: 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose

13.53% 43.48% 1.93% 41.06%

PERCEIVABLE: 1.2.1 Audio-only and Video-only (Pre-recorded): An alternative is provided for pre-recorded audio-only and video-only media.

0.00% 2.17% 0.00% 97.83%

PERCEIVABLE: 1.2.2 Captions (prerecorded): Captions are provided for all prerecorded audio content in synchronized media, except when media is a media alternative for text and is clearly labelled as such.

4.35% 0.00% 0.00% 95.65%

PERCEIVABLE: 1.2.3 Audio Description or Media Alternative (Prerecorded): An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when media is a media alternative for text and is clearly labelled as such.

4.35% 4.35% 0.00% 91.30%

PERCEIVABLE: 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

27.54% 34.78% 0.00% 37.68%

PERCEIVABLE: 1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

8.70% 91.30% 0.00% 0.00%

PERCEIVABLE: 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.

0.00% 71.74% 0.00% 28.26%

PERCEIVABLE: 1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

6.52% 93.48% 0.00% 0.00%

PERCEEIVABLE: 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

0.00% 4.35% 0.00% 95.65%

OPERABLE: 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints

4.35% 54.35% 4.35% 36.96%

OPERABLE: 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 interface, and, if it requires more than unmodified arrow or tab keys, the user is advised of the method for moving focus away.

0.00% 100.00% 0.00% 0.00%

8

Success Criteria* for Level A compliance of WCAG 2.0

% of Websites

which Failed

% of Websites

which Passed

% of Websites

Marginally Failing

% of Websites where the

Criteria was NA

OPERABLE: 2.2.1 Timing Adjustable: Give users control over time limiting functions.

0.00% 0.00% 0.00% 100.00%

OPERABLE: 2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true:

2.17% 0.00% 2.17% 95.65%

OPERABLE: 2.3.1 Three Flashes or Below Threshold: Web pages do 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.

0.00% 21.74% 0.00% 78.26%

OPERABLE: 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

34.78% 11.59% 0.00% 53.62%

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

17.39% 82.61% 0.00% 0.00%

OPERABLE: 2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

13.04% 82.61% 4.35% 0.00%

OPERABLE: 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

8.70% 63.04% 2.17% 26.09%

UNDERSTANDABLE: 3.1.1 Language of page: The default human language of each Web page can be programmatically determined.

26.09% 73.91% 0.00% 0.00%

UNDERSTANDABLE: 3.2.1 On Focus: When any component receives focus, it does not initiate a change of context.

0.00% 100.00% 0.00% 0.00%

UNDERSTANDABLE: 3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

4.35% 91.30% 4.35% 0.00%

UNDERSTANDABLE: 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.

13.04% 47.83% 0.00% 39.13%

UNDERSTANDABLE: 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input.

0.00% 60.87% 0.00% 39.13%

ROBUST: 4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

73.91% 26.09% 0.00% 0.00%

ROBUST: 4.1.2 Name, Role, Value: For all user user-interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification

0.00% 100.00% 0.00% 0.00%

9

Success Criteria* for Level A compliance of WCAG 2.0

% of Websites

which Failed

% of Websites

which Passed

% of Websites

Marginally Failing

% of Websites where the

Criteria was NA

of changes to these items is available to user agents, including assistive technologies.

Table 4 reflects the total number of Failures and Marginal Failures according to each Test Indicator used to determine Success Criteria Compliancy. In order to determine if a website failed Success Criterion 1.1.1 Non-text Content 9 distinct tests were conducted. Please Refer to Section 2.1 for a Description of the Success Criteria and their associated test indicators.

Table 4: Failures and Marginal Failures According to each Test Indicator used to determine Success Criteria Compliancy

Success Criteria* for Level A compliance of WCAG

2.0

Number of

Failures %

Number of

Marginal

Failures

%

PERCEIVABLE: 1.1.1 Non-text Content* 28 13.53% 04 1.93%

PERCEIVABLE: 1.2.2 Captions (Pre-recorded) 01 4.35% 00 0.00%

PERCEIVABLE: 1.2.3 Audio Description or Media

Alternative (Pre-recorded) 01 4.35% 00 0.00%

PERCEIVABLE: 1.3.1 Info and Relationships 38 27.54% 00 0.00%

PERCEIVABLE: 1.3.2 Meaningful Sequence 02 8.70% 00 0.00%

PERCEIVABLE: 1.4.1 Use of Color 03 6.52% 00 0.00%

OPERABLE: 2.1.1 Keyboard: 02 4.35% 02 4.35%

OPERABLE: 2.2.2 Pause, Stop, Hide 01 2.17% 01 2.17%

OPERABLE: 2.4.1 Bypass Blocks 24 34.78% 00 0.00%

OPERABLE: 2.4.2 Page Titled 04 17.39% 00 0.00%

OPERABLE: 2.4.3 Focus Order 03 13.04% 01 4.35%

OPERABLE: 2.4.4 Link Purpose (In Context) 04 8.70% 01 2.17%

UNDERSTANDABLE: 3.1.1 Language of page 06 26.09% 00 0.00%

UNDERSTANDABLE: 3.2.2 On Input 01 4.35% 01 4.35%

UNDERSTANDABLE: 3.3.1 Error Identification 06 13.04% 00 0.00%

ROBUST: 4.1.1 Parsing 17 73.91% 00 0.00%

TOTAL 141 10

10

Table 5: Summary of all Failures, Passes and Marginal Fails according to each Test Indicator used to Determine Success Criteria Compliancy

Failed Passed Marginal Failure

NA TOTAL

13.04%

N=141

45.51%

N=492

0.93%

N=10

40.52%

N=438

100.00%

N=1081

Once all the website failures were identified they were then categorised into three distinct types of repairs according to complexity.

Please Note: This estimate is based on an experienced staff employed at EWORX (web designers/developers) familiar with WCAG2.0 Success Criteria and how they can be resolved.

Table 6: Repair Type and Average Repair Estimate

Repair Type Average Time Required to Repair

Minor Fix An hour or up to a day or so

Considerable Fix Considerably more effort likely to be needed,

possibly 3-5 Days

Major Fix A lot more effort likely to be needed, may be more than 5 days and could be considerably

more in some cases

In view of the failures identified in Table 6 the Repair Type attributed to Failure is reflected in the following table.

Table 7: Complexity of Repairs Required to Meet WCAG 2.0 Success Criteria Level A for Websites where a Criteria Failed or Marginally Failed

Website where Types of Repair Totals %

Minor Fix 124 82.12%

Considerable Fix 13 8.61%

FAILED or MARGINALLY FAILED a TEST CRITERIA*

Major Fix 14 9.27%

TOTAL 151 100.00%

* Please Note – the Marginal Fails at this Level should not be confused with a Website Overall Marginally Failing. Here we are discussing Test Criteria.

2.2 Review of WCAG 2.0 checkpoint failure of web sites that did pass WCAG 1.0 automatic testing

The following section presents a brief discussion regarding the results from the Manual Assessment of WCAG 2.0 Success Criteria. Each checkpoint and its associated success criteria are discussed as are the best practice examples. Where possible challenges are highlighted and indications how these can be resolved are indicated.

2.2.1 Principle 1 – Perceivable

Principle 1: Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

This first principle refers to the way in which information and user interface components are presented to users. They should be presented in such a way so that users missing one or more human senses will be able to perceive it.

Guidelines relating to the Perceivable Principle concern the following:

11

Guideline 1.1 Text Alternatives: 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.

Guideline 1.2 Time-based Media: Provide alternatives for time-based media.

Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example

simpler layout) without losing information or structure.

Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including

separating foreground from background.

Of the nine success criteria which were assessed to test the above guidelines, six proved to be most

problematic. These are described below.

2.2.1.1 Non Text Context

PERCEIVABLE: 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose

The purpose of this Success Criterion is to ensure that information presented by non-text content is accessible through the use of a text alternative.

Of the 23 websites manually reviewed 10 websites passed this Success Criteria, 12 websites Failed and 1 Website Marginally Failed

The above is an interesting result given that during automatic testing these websites passed the WCAG 1.0 Success Criterion. This discrepancy is attributed to the fact that more in-depth evaluation was undertaken for ALT Text which included the following checks:

Table 8: Checks Undertaken in Order to Determine Compliancy with Success Criterion 1.1.1 Non-Text Content & Associated Results

Test Criterion 1.1.1 Indicators Passed Failed Marginal

Fail NA Total

Do all images, form image buttons, and image map hot spots have appropriate, equivalent alternative text.

12 09 02 00 23

Are all decorative images implemented as CSS backgrounds.

17 02 00 04 23

In cases where there is a null alt text (alt="") is the meaning conveyed by a text description within the content.

002 08 00 13 23

Do all linked images have descriptive alternative text. 16 04 02 01 23

Are Equivalent alternatives to complex images provided in context or on a separate (linked and/or referenced via longdesc) page.

01 00 00 22 23

Do all form buttons have a descriptive value. 20 01 00 02 23

Form inputs have associated text labels or, if labels cannot be used, a descriptive title attribute.

19 04 00 00 23

Is embedded multimedia identified via accessible text. 02 00 00 21 23

Are frames appropriately titled. 01 00 00 22 23

TOTAL 90 28 04 85 207

Of these failings (both Fails and Marginal Fail) 100% of repairs for achieving this Success Criteria were deemed Minor Fixes. (87.50% (N=28) Fails 12.50% (N=4) Marginal Fail)

A number of examples of websites that both passed and failed this Success Criteria are presented below.

One of the criterion which websites failed to comply with was the provision of appropriate Alt Text for Images. This failing is clearing reflected in the following example (Figure 2) where the logos associated with the Spanish Ministry of Education website (http://www.mepsyd.es/portada.html) have the same alt text , Abre en ventana nueva meaning opens in a new window associated with them which incorrectly reflects the names of the images/logos.

Figure 2: The Spanish Ministry of Justice Website and the associated HTML code for one of the Website Logos. Inappropriate „alt or „longdesc tag has been provided.

Since the code does not include attributes used to provide alternative text (such as alt and longdesc), text browsers and screen readers cannot provide users with any meaningful information about the image in question.

Another failing concerned the use of null alt text (alt="") without the meaning being conveyed by a text description within the content. This failure is reflected in the following example taken from the UK Ministry of Justice website (http://www.justice.gov.uk/). The image reflected in Figure 3 does no offer an associated alternative description as reflected in the HTML code.

12

Figure 3: The UK Ministry of Justice Website and the associated HTML code for one of the Website

Images. Null alt text (alt="") has been Inappropriately Used

In contrast to these failings the UK Department of Health website (http://www.dh.gov.uk) successfully provides text alternatives and thus fulfils this success criteria. The website offers equivalent alternative text to each relevant image on the website as reflected in the following example.

Figure 4: Example of Alt Text used by the UK Department of Heath Website

2.2.1.2 Captions (Pre-Recorded)

Perceivable 1.2.2 Captions (Pre-Recorded): Captions are provided for all prerecorded audio content

in synchronized media, except when the media is a media alternative for text and is clearly labelled as

such. (Level A)

The purpose of this Success Criterion is to enable users who are deaf or hard of hearing to view the audio

content of synchronised media presentations through the use of captions.

Common web accessibility guidelines indicate that captions should be4:

Synchronized - the text content should appear at approximately the same time that audio would be available

Equivalent - content provided in captions should be equivalent to that of the spoken word

Accessible - caption content should be readily accessible and available to those who need it

Given the onset of multimedia and its rapid growth, this Success Criteria is relevant to all synchronised media presentations played through multimedia players such as Quicktime, RealPlayer, or Windows Media

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

13

Player, but is also relevant to such technologies as Flash, Shockwave, or Java when audio content is a part of the multimedia presentation

Of the 23 websites manually reviewed 22 did not use video whereas in the 1 case where video was provided it did not comply with this Success Criteria i.e. Captions were not

provided.

Of the websites that Failed 100% (N=1) of Repair Types were considered Considerable Fixes.

Many techniques are available to add captions to media presentations with several websites (youtube, google video and others) providing this facility as an online service. Youtube (http://www.youtube.com/) for example offers a straight forward process for adding closed captions to a video, by simply uploading the captions from the edit video menu – see Figure 5. This facility (it supports two formats SubViewer *.sub and SubRip *.srt.

Figure 5: Youtubes Upload Caption Edit Video Menu

Once uploaded captions can be easily turned on and off. Additionally, options for multiple captions are also provided, making each video accessible to a broader audience.

There also exist non-commercial stand alone tools for captioning videos such as MAGpie (http://ncam.wgbh.org/webaccess/magpie/magpie2_download.html), which supports the most common video protocols like Real Media and Quicktime.

The following example presents an illustration of how multi-lingual captioning is utilised by the BBC (http://www.bbc.co.uk/)

Figure 6: BBC Example of Multi-Lingual Captioning

In contract the German Federal Government website (www.bundesregierung.de) does not use any of

14

these methods and includes videos without captions and therefore it failed this criteria.

Figure 7: German Federal Government Portal does not Provide Users with any Video Captioning

Options.

2.2.1.3 Audio Description or Media Alternative

Perceivable 1.2.3 Audio Description or Media Alternative (Pre-Recorded): An alternative for time-based media or audio description of the pre-recorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labelled as such. (Level A)

The purpose of this Success Criterion is to enable users who are blind or visually impaired to access visual information in a synchronized media presentation. Web designers can choose 1 of two approaches to implement this success criterion.

The first approach is to provide audio description of the video content. The audio description augments the audio portion of the presentation with the information needed when the video portion is not available. During existing pauses in dialogue, audio description provides information about actions, characters, scene changes, and on-screen text that are important and are not described or spoken in the main sound track.

The second approach involves providing all of the information in the synchronized media (both visual and auditory) in text form. An alternative for time-based media provides a running description of all that is going on in the synchronized media content. The alternative for time-based media reads something like a screenplay or book. Unlike audio description, the description of the video portion is not constrained to just the pauses in the existing dialogue. Full descriptions are provided of all visual information, including visual context, actions and expressions of actors, and any other visual material. In addition, non-speech sounds (laughter, off-screen voices, etc.) are described, and transcripts of all dialogue are included. The sequence of description and dialogue transcripts are the same as the sequence in the synchronized media itself. As a result, the alternative for time-based media can provide a much more complete representation of the synchronized media content than audio description alone.5

Of the 23 websites manually reviewed 22 did not use video whereas in the 1 case where video was provided it did not comply with this Success Criteria.

Of the websites that Failed 100% (N=1) of Repair Types were considered Considerable Fixes.

5 http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-audio-desc.html

15

The British Museum website (www.britishmuseum.org) presents an excellent example of the use of alternative media for pre-recorded video, by having a text transcript and audio file of the video available for the user. (Please Note: The British Museum was not among the websites sampled within this study. It is purely used for illustrative purposes given that no example could be derived from the websites tested).

Figure 8: Example of the British Museums use of Audio Description.

2.2.1.4 Information and Relationships

Perceivable 1.3.1 Information and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

The purpose of this Success Criterion is to ensure that visual and auditory formatting are preserved when the presentation format changes. Presentation formats for instance a likely to change when content is read by a screen reader or alternatively when a style sheet is substituted for the style sheet provided by the user. In order to preserve formatting this must be coded within the web page appropriately in order to indicate the structure of the page and the relationship between its different elements such as headings, paragraphs, list forms, tables etc. For instance within HTML the appropriate attributes and elements must be included within the code in order to describe the role of all page items.

Of the 23 websites manually reviewed 9 websites passed all 6 test indicators and therefore fully complied with this Success Criteria. The remaining websites, -14 Failed the test

indicators.

The extent to which these Failures associated with this text criterion could be repaired ranged from Minor Fixes to Major Fix Required. More specifically, 78.95% (N=30) of Repair Types were considered Minor Fixes. 2.63% (N=1) Considerable Fixes, 18.42% (N=7) Major Fix.

Table 9 indicates the results of the test results whereas the Figures 9 and Figure 10 indicate the types of repairs required in order to ensure compliance with this Success Criterion.

16

Table 9: Checks Undertaken in Order to Determine Compliancy with Success Criterion 1.3.1 Information and Relations

Test Criterion 1.3.1 Indicators Passed Failed Marginal

Fail NA TOTAL

Is semantic markup used to designate headings (<h1>), lists (<ul>, <ol>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>, for example), etc. Semantic markup is used appropriately.

20 02 00 01 23

Are tables used to markup tabular data. 02 08 00 13 23

Where necessary, are data cells associated with their headers.

01 08 00 14 23

Are data table captions and summaries used where appropriate.

01 08 00 14 23

Are text labels associated with form input elements. 19 04 00 00 23

Are related form elements grouped with fieldset/legend. 05 08 00 10 23

TOTAL 48 38 00 52 138

Perceivable 1.3.1 Information and Relationships

0

5

10

15

20

25

30

35

Fail - Minor Fix Fail - Considerable Fix Fail - Major Redesign

Repair Type

Tota

l Num

ber o

f Rep

airs

Figure 9:Type of Repairs Required in order to Comply with Success Criteria 1.3.1 Information and

Relations

17

Perceivable 1.3.1 Information and Relationships - Repairs Required

Are related form elements grouped with fieldset/legend.

Are tables used to markup tabular data. Are data table captions & summaries used where appropriate. Are text labels associated with form input

elements.

Where necessary, are data cells associated with their headers.

Is semantic markup used to designate headings etc

0

1

2

3

4

5

6

7

8

9

Nu

mb

er o

f Fa

ilure

s

Minor FixConsiderable Fix RequiredMajor Re-Design Required

Figure 10:Type of Repairs Per Test Criterion for Success Criteria 1.3.1 Information and Relations

The most widespread failures associated with this Success Criteria was the incorrect use of tables. In many cases tables were not used to mark tabular data but were instead used for layout purposes. Within the Italian Ministry of Labour website (www.solidarietasociale.gov.it) the entire home page has been developed using tables.

18

Figure 11: The Italian Ministry of Labour Website and Associated HTML Code Reflecting the

Inappropriate Use of Tables

In contrast a good case example is the use of tables made by the BBC website (http://www.bbc.co.uk/)

where tabular data such as the weather forecast is properly coded with the use of tables. Within this

example, the HTML code uses attributes such as th, td, scope and summary to correctly distinguish data

cells from header cells. In this order, visitors using screen readers will be able to understand which header

cell a specific data cell refers to.

Figure 12: The BBC Website Weather Page and Associated HTML Code Reflecting the Appropriate Use of

Tables

When form fields provide a recognisable label, people using screen readers or text browsers will find it easier to fill the form out. The assigned label helps them understand the type of input required. This approach is well illustrated within the Irish Department of Enterprise Trade and Employment. (http://www.entemp.ie/) where within the Quick Search form Field – Enter search term has been added.

19

Figure 13: The Irish Department of Enterprise Trade and Employment Website and Associated HTML

Code Reflecting the Appropriate Use of Form Field Labels.

2.2.1.5 Meaningful Sequence

Perceivable 1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its

meaning, a correct reading sequence can be programmatically determined. (Level A)

The purpose of this Success Criterion is to enable a user agent such as a screen reader to provide an alternative presentation of content without altering the meaning or reading order of a web page. In order to achieve this success criterion it is important that content is programmatically determined

Of the 23 websites manually reviewed 21 websites fully complied with this Success Criteria and 2 websites Failed.

Of these failings 100% (N=2) Repair Type for achieving this Success Criteria were deemed Minor Fixes.

2.2.1.6 Use of Colour

Perceivable 1.4.1 Use of Colour: Color is not used as the only visual means of conveying information,

indicating an action, prompting a response, or distinguishing a visual element. (Level A)

The purpose of this Success Criterion is to ensure that all users can access information that is conveyed within a web page by colour differences. This criterion is especially important in instances where colour has a meaning assigned to it, since individuals with visual impairments may not be able to see colour and perceive the information associated with it.

Of the 23 websites manually reviewed 21 websites fully complied with this Success Criteria and 2 websites Failed.

Of these failings 100% (N=3) of Repair Types for achieving this Success Criteria were deemed Minor Fixes.

Table 10: Checks Undertaken in Order to Determine Compliancy with Success Criterion 1.4.1 Use of Colour

Test Criterion 1.4.1 Indicators Passed Failed Marginal

Fail NA TOTAL

Is colour is used as the sole method of conveying content or distinguishing visual elements.

21 02 00 00 23

Ensure colour alone is not used to distinguish links from surrounding text unless the luminance contrast between the link and the surrounding text is at least 3:1 and an additional differentiation (e.g., it becomes underlined) is provided when the link is hovered over or receives focus.

22 01 00 00 23

TOTAL 43 03 00 00 46

20

21

2.2.2 Principle 2 – Operable

Principle 1: Operable – User Interface components and navigation must be operable.

This second principle refers to the way in which a user interacts with a website independently of the device they are using or the response time required. Additionally, it also refers to the need for a website to facilitate a user's navigation through the content of the site and avoid the use of flashing content.

Guidelines relating to the Operable Principle concern the following:

Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.

Guideline 2.2 Enough Time: Provide users enough time to read and use content.

Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures.

Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.

Of the nine success criteria which were assessed to test the above guidelines, six proved to be most problematic. These are described below.

2.2.2.1 Keyboard

Operable 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface

without requiring specific timings for individual keystrokes, except where the underlying function requires

input that depends on the path of the user's movement and not just the endpoints. (Level A)

Note 1: This exception relates to the underlying function, not the input technique. For example, if using

handwriting to enter text, the input technique (handwriting) requires path-dependent input but the

underlying function (text input) does not.

Note 2: This does not forbid and should not discourage providing mouse input or other input methods in

addition to keyboard operation.

The purpose of this Success Criterion is to facilitate users who are not able to use traditional mechanisms such as a mouse to access content. It is intended to ensure that content can be operated or accessed through a keyboard, keyboard interface or other such input device which act as a keyboard emulator.

Of the 23 websites manually reviewed 19 websites fully complied with this Success Criteria and 2 websites Failed and 2 Websites Marginally Failed

The extent to which these Failures associated with this test criterion could be repaired ranged from Minor Fixes to Major Fix Required. More specifically, 25.0% (N=1) were deemed Considerable Fixes, 25.0% (N=1 Major Fix, 25.0% (N=1) Marginal Fail – Minor Fix, 25.0% (N=1) Marginal Fail – Considerable Fix.

Table 11 indicates the Test Criterion and where the majority of Failures occurred.

Table 11: Checks Undertaken in Order to Determine Compliancy with Success Criterion 2.1.1 Keyboard

Test Criterion 2.1.1 Indicators Passed Failed Marginal

Fail NA TOTAL

Is all content functionality available using the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard (e.g., free hand drawing).

19 02 02 00 23

Page-specified shortcut keys and accesskeys (accesskey should typically be avoided) do not conflict with existing browser and screen reader shortcuts.

06 00 00 17 23

TOTAL 25 02 02 17 46

All failings concerned website elements that can only be accessed using the mouse, which brings these websites to fail this Success Criteria.

Within the German Federal Ministry of Education and Research (http://www.bmbf.de/) website the video player functionality is not available for users using a keyboard.

Figure 14: German Federal Ministry of Education and Research Website where the Video Player on the

Home Page is not Available for Users using a Keyboard.

22

An example of a website illustrating a menu that is not fully accessible when using the keyboard to navigate is that of the Deutsche Telecom website (http://www.deutschetelekom.com/). The current example reflects the websites sub-menu which is not accessible using a keyboard.

Figure 15: Deutsche Telecom website where the Sub-Menu is not Accessible using a Keyboard

In contrast, the BBC web site behaves in the same way when using a mouse or a keyboard to navigate. For example the “Add more to this page” button, which expands the topics panel, is accessible via keyboard and mouse and behaves in the same way. Furthermore once the panel is expanded the panel content is also accessible via the keyboard.

Figure 16: BBC website where the Sub-Menu is Accessible using a Keyboard

23

24

2.2.2.2 Pause, Stop, Hide

Operable 2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true: (Level A)

Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and

Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

The purpose of this Success Criterion is to avoid distracting users during their interaction with a web page. "Moving, blinking and scrolling" refers to content in which the visible content conveys a sense of motion as is the case with motion pictures, synchronized media presentations, animations, real-time games, and scrolling stock tickers. "Auto-updating" refers to content that updates or disappears based on a preset time interval such as automatically updated weather information, news, stock price updates, and auto-advancing presentations and messages.

Of the 23 websites manually reviewed this Success Criteria was Not Applicable to 21websites 1 website Failed and 1 Website Marginally Failed.

Of these failings 50.0% (N=1) Failing was deemed a Minor Fix and the 50.0% (N=1) a Considerable Fix. The following table indicates the Test Criterion where the majority of Failures occurred.

Table 12: Checks Undertaken in Order to Determine Compliancy with Success Criterion 2.2.2 Pause Stop Hide-Text & Associated Results

Test Criterion 2.1.2 Indicators Failed Passed Marginal

Fail NA TOTAL

Is all content functionality available using the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard (e.g., free hand drawing).

00 00 01 22 23

Page-specified shortcut keys and accesskeys (accesskey should typically be avoided) do not conflict with existing browser and screen reader shortcuts.

01 00 00 22 23

TOTAL 01 00 01 44 46

2.2.2.3 Bypass Blocks

Operable: 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)

The purpose of this Success Criterion is to enable those individuals who navigate web pages via a key board or screen reader to directly access the primary content of the Web page without having to sequentially move through a webpage. Having the ability to skip links and move directly to content increases the efficiency of a web page and limits repetitive actions.

Of the 23 websites manually reviewed none of the websites complied with this Success Criteria.

Of these 23 Failing 100% ( N=23) were deemed a Minor Fix. The following table reflects the test indicators against which the websites failed.

Table 13: Checks Undertaken in Order to Determine Compliancy with Success Criterion 2.4.1 Bypass Blocks & Associated Results

Test Criterion 2.4.1 Indicators Passed Failed Marginal

Fail NA Total

Is a descriptive text transcript (including all relevant visual and auditory clues and indicators) provided for non-live, web-based audio (audio podcasts, MP3 files, etc.).

00 23 00 00 23

Is a descriptive text transcript (including all relevant visual and auditory clues and indicators) provided for non-live, web-based audio (audio podcasts, MP3 files, etc.).

05 01 00 17 23

Is a text or audio description provided for non-live, web-based video-only (e.g., video that has no audio track).

03 00 00 20 23

TOTAL 08 24 00 37 69

Two mistakes were commonly made by websites in relation to this Success Criteria which resulted in failure.

Firstly, all of the 23 websites did not offer a bypass link. This oversite is well illustrated within the Spanish Ministry of Economy and Employment (http://www.la-moncloa.es/default.htm) website where a user who is not using a mouse, has to navigate through a number of links before reaching the content, A screen reader user would have to listen to all the links before reaching the content.

Figure 17: Spanish Ministry of Economy and Employment when Bypass Links have not been Provided

25

In the case of the BBC website for example a bypass links are provided but these links are not visible in

graphic browsers such as Internet Explorer and Firefox. The BBC provides three bypass links but are only

usable with text browsers or screen readers.

26

Figure 18: BBC website where the Bypass Links are Provided but are not Visible in a Graphics Browser

W

2.2.2.4 Page Titled

hile hidden bypass links help visitors using screen readers, they are of no help to users navigating witha keyboard. Therefore, bypass links should always be visible or at least become visible on keyboard focus.

Operable 2.4.2 Page Titled: Web pages have titles that describe topic or purpose. (Level A)

ithin it by The purpose of this Success Criterion is to help users identify content and orient themselves wensuring that each web page has a descriptive title. Titles identify the current location of a page without requiring users to read or interpret page content. Titles are also used in site maps or lists of search results, which facilitate users to quickly identify the content they are looking for.

Of the 23 websites manually reviewed none of the 19 websites complied with this Success Criteria and 3 websites Failed.

deemed a Minor Fix. Of these Failings 100% (N=4) were

strian Federal Ministry of Labour Social Affairs An example of websites that filed this criteria was the Auand Consumer Protection ( www.bmsk.gv.at). This website uses the same Title for the Home, Contact and Search Page. In this way the page purpose is not clearly described and the user is confused. A visually impaired user using a screen reader will have to wait for the reader to reach the content in order to understand the type of page.

Figure 19: Austrian Federal Ministry of Labour Social Affairs and Consumer Protection Website where the Same Title is used for the Home, Contact and Search Page

2.2.2.5 Focus Order

Operable 2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)

The purpose of this Success Criterion is to ensure that when users navigate sequentially through content,

they encounter information in an order that is consistent with the meaning of the content and can be

operated from the keyboard.

Of the 23 websites manually reviewed none of the 19 websites complied with this Success Criteria 3 websites Failed and 1 website Marginally Failed

Of these Failings 100% (N=4) were deemed a Minor Fix.

2.2.2.6 Link Purpose (In Context)

Operable 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)

The purpose of this Success Criterion is to help users understand the purpose of each link so they can decide if they want to follow the link. Whenever possible, link text should be provided that identifies the purpose of the link without needing additional context.

Of the 23 websites manually reviewed none of the 18 websites complied with this Success Criteria 4 websites Failed and 1 website Marginally Failed

Of these Failings 100% (N=5 (4 Fail and 1 Marginal Fail) were deemed a Minor Fix. The following table reflects the test indicators against which the websites failed.

27

Table 14: Checks Undertaken in Order to Determine Compliancy with Success Criterion 2.4.4 Link Purpose & Associated Results

Test Criterion 2.4.4 Indicators Passed Failed Marginal

Fail NA Total

Can the purpose of each link (or form image button or image map hotspot) 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).

23 00 00 00 23

Are links (or form image buttons) with the same text that go to different locations are readily distinguishable.

06 04 01 12 23

TOTAL 29 04 01 12 46

The lack of additional information on the repeated links is confusing, especially for visitors using screen readers. A good illustration of this is the German Federal Ministry of Education and Research (http://www.bmbf.de) as reflected in the following figure where the word mehr is used without an further explanation.

Figure 20: German Federal Ministry of Education and Research Protection Website where the Purpose of a Link is not Explained.

28

There are cases where links with the same text lead to different locations. A good way to differentiate these links is to use the <title> tag like such as that used by the German Federal Government (www.bundesregierung.de).

Figure 21: German Federal Government where the Link is explained by the <title> tag

2.2.3 Principle 3 – Understandable This third principle ensures that website content and functionality should be as easy to understand and

use as possible.

Guidelines relating to the Understandable Principle concern the following:

Guideline 3.1 Readable: Make text content readable and understandable.

Guideline 3.2 Predictable: Make Web pages appear and operate in predictable ways.

Guideline 3.3 Input Assistance: Help users avoid and correct mistakes.

Five success criteria are used to test the Understandable Guidelines, of which the following consistently presented a problem for the websites that were reviewed.

2.2.3.1 Language of Page

Understandable 3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. (Level A)

The purpose of this Success Criterion is to ensure that information provided within a web page enables user agents to present the text and linguistic content correctly. Both assistive technologies and web browsers can display content accurately when the language of the web page is defined. Furthermore, screen reads can load the correct pronunciation rules etc. In the HTML code, the language of a web page can be indicated by using the lang attribute (lang=”en” for English).

Of the 23 websites manually reviewed none of the 17 websites complied with this Success Criteria and 6 websites Failed.

Of these Failings 100% (N=6) were deemed a Minor Fix.

Within the following example the Federal Chancellery of Austria (www.austria.gv.at) web site clearly uses the lang attribute within the website’s html code in order to reflect the language of the website.

In contrast the Portuguese Ministry of Labour and Social Solidarity (www.mtss.gov.pt) website incorrectly uses the English language code instead of Portuguese within the websites html code resulting in confusion for screen readers.

2.2.3.2 On Input

Understandable 3.2.2 On Input: Changing the setting of any user interface component does not

29

30

automatically cause a change of context unless the user has been advised of the behaviour before using

the component. (Level A)

The purpose of this Success Criterion is to ensure that when a user enters data or selects a form control the end result is a predictable effect. Changing the setting of any user interface component is changing some state in the control that will persist when the user is no longer interacting with it. So checking a checkbox or entering text into a text field changes its setting, but activating a link or a button does not.

Of the 23 websites manually reviewed none of the 21 websites complied with this Success Criteria, 1 website Failed and 1 Marginally Failed.

Of these Failings 100% (N=2 (1 Fail and 1 Marginal Fail) were deemed a Minor Fix.

2.2.3.3 Error Identification

Understandable 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. (Level A)

The purpose of this Success Criterion is to ensure that users are aware that an error has occurred and that they can determine what is wrong. The error message should be as specific and appropriate 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 therefore a textual description of the error must be provided. Screen reader users, for example, will not know there was an error until they encounter one of the indicators. They may abandon the form altogether before encountering the error indicator, thinking that the page simply is not functional.

Of the 23 websites manually reviewed none of the 17 websites complied with this Success Criteria and 6 websites Failed.

Of these Failings 100% (N=6) were deemed a Minor Fix. The following table reflects the test indicators against which the websites failed.

Table 15: Checks Undertaken in Order to Determine Compliancy with Success Criterion 3.3.1 Error Identification & Associated Results

Test Criterion 3.3.1 Indicators Passed Failed Marginal

Fail NA Total

Do required form elements or form elements that require a specific format, value, or length provide this information within the element's label (or if a label is not provided, within the element's title attribute).

10 03 00 10 23

If utilized, do form validation cues and errors (client-side or server-side) alert users to errors in an efficient, intuitive, and accessible manner. The error is clearly identified, quick access to the problematic element is provided, and user is allowed

12 03 00 08 23

TOTAL 22 06 00 18 46

31

2.2.4 Principle 4 – Robust

Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

This last principle aims to ensure that website content is properly and conventionally coded thereby ensuring its compatibility with current and future user agents, especially assistive technologies. In the case of mark-up languages such as HTML they should comply and conform to their standardised specifications, whereas in the case of programming language API features should be utilised.

Guidelines relating to the Robust Principle concern the following:

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

Of the two success criteria which were assessed to test the above guidelines, one proved to be most problematic which is described below.

2.2.4.1 Parsing

Robust 4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)

Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.

The purpose of this Success Criterion is to ensure that user agents can properly and accurately interpret and parse content. This criterion requires that HTML is properly used and that important grammatical rules such as using start and end tags for any element and properly nesting them are observed. The validation of HTML can be verified by using the following link: http://validator.w3.org/

Of the 23 websites manually reviewed none of the 6 websites complied with this Success Criteria and 17 websites Failed.

Of these Failings 24.53% (N=4) were considered Minor Fixes, 41.18% (N=7) Considerable Fixes and 35.29%(N=6) Major Fixs

One common error within the websites tested was the start tag e.g. <div> not having an equivalent end tag </div> or elements that not correctly nested. An example of this is the Spanish Ministry of Economics and Employment (www.la-moncloa.es) where several passing errors were identified such as:

Line 22, Column 8: end tag for element "HEAD" which is not open

Robust 4.1.1 Parsing

0

1

2

3

4

5

6

7

8

Minor Fix Considerable Fix Major Redesign

Repairs Types

Nu

mb

er o

f W

ebsi

te F

ailu

res

Figure 22: Type of Repairs required for Success Criteria 4.1.1 Parsing

2.3 Results of the Websites that did not pass WCAG1.0 automated testing

Please note the following results concern 79 websites that did not comply with WCAG 1.0 Automatic Testing. The only exception to this is the BBC website which could not be automatically tested but was however included in the batch for Manual testing given its leading position in Web Design and Accessibility Standards. None the websites that did not pass WCAG 1.0 Automatic Assessment and were submitted for WCAG2.0 Manual Assessment – successfully passed the WCAG2.0 Success Criteria for Level A Conformance.

WCAG 2.0 Success Criteria Failures

0

5

10

15

20

25

30

Websites which Failed WCAG 1.0 Automated Testing

Tota

l Num

ber

of W

CAG

2.0

Figure 23: Total Number of Failures per Website UPDATE

32

33

In general the website failures ranged from between 3–27 failures Table 16 reflects the percentage of websites that Passed, Failed or Marginally Failed to comply with each of the Success Criteria for Level A WCAG 2.0 Guidelines.

Table 16: Percentage of Website Compliancy with WCAG 2.0 Success Criteria Level A - N=80

Success Criteria* for Level A compliance of WCAG 2.0

% of Websites

which Failed

% of Websites

which Passed

% of Websites

Marginally Failing

% of Websites where the

Criteria was NA

PERCEIVABLE: 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose

34.86% 31.11% 1.81% 32.22%

PERCEIVABLE: 1.2.1 Audio-only and Video-only (Pre-recorded): An alternative is provided for pre-recorded audio-only and video-only media.

1.88% 0.00% 0.00% 98.13%

PERCEIVABLE: 1.2.2 Captions (prerecorded): Captions are provided for all prerecorded audio content in synchronized media, except when media is a media alternative for text and is clearly labelled as such.

13.75% 0.00% 0.00% 86.25%

PERCEIVABLE: 1.2.3 Audio Description or Media Alternative (Prerecorded): An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when media is a media alternative for text and is clearly labelled as such.

13.75% 0.00% 0.00% 86.25%

PERCEIVABLE: 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

41.96% 28.18% 1.04% 28.81%

PERCEIVABLE: 1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

5.00% 95.00% 0.00% 0.00%

PERCEIVABLE: 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.

0.00% 30.00% 0.00% 70.00%

PERCEIVABLE: 1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

25.63% 71.88% 2.50% 0.00%

PERCEEIVABLE: 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

0.00% 1.25% 0.00% 98.75%

OPERABLE: 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints

16.88% 39.38% 0.63% 43.13%

OPERABLE: 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

8.75% 91.25% 0.00% 0.00%

34

Success Criteria* for Level A compliance of WCAG 2.0

% of Websites

which Failed

% of Websites

which Passed

% of Websites

Marginally Failing

% of Websites where the

Criteria was NA

away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys, the user is advised of the method for moving focus away.

OPERABLE: 2.2.1 Timing Adjustable: Give users control over time limiting functions.

0.00% 0.00% 0.00% 100.00%

OPERABLE: 2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true:

14.38% 5.00% 0.00% 80.63%

OPERABLE: 2.3.1 Three Flashes or Below Threshold: Web pages do 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.

1.25% 15.00% 0.00% 83.75%

OPERABLE: 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

44.17% 10.42% 0.00% 45.42%

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

25.00% 75.00% 0.00% 0.00%

OPERABLE: 2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

5.00% 91.25% 2.50% 1.25%

OPERABLE: 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

16.25% 52.50% 1.25% 30.00%

UNDERSTANDABLE: 3.1.1 Language of page: The default human language of each Web page can be programmatically determined.

47.50% 52.50 0.00% 0.00%

UNDERSTANDABLE: 3.2.1 On Focus: When any component receives focus, it does not initiate a change of context.

6.25% 91.25 1.25% 1.25%

UNDERSTANDABLE: 3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

6.25% 88.75% 2.50% 2.50%

UNDERSTANDABLE: 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.

20.00% 41.25% 0.63% 38.13%

UNDERSTANDABLE: 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input.

27.50% 36.25% 0.00% 36.25%

ROBUST: 4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

95.00% 5.00% 0.00% 0.00%

35

Success Criteria* for Level A compliance of WCAG 2.0

% of Websites

which Failed

% of Websites

which Passed

% of Websites

Marginally Failing

% of Websites where the

Criteria was NA

ROBUST: 4.1.2 Name, Role, Value: For all user user-interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

77.50% 11.25% 8.75% 2.50%

Table 17 reflects the total number of Failures and Marginal Failures according to each Test Indicator used to determine Success Criteria Compliancy. In order to determine if a website failed Success Criterion 1.1.1 Non-text Content 9 distinct tests were conducted. Please Refer to Section 2.1 for a Description of the Success Criteria and their associated test indicators.

Table 17: Failures and Marginal Failures According to each Test Indicator used to determine Success Criteria Compliancy

Success Criteria* for Level A compliance of WCAG

2.0

Number of

Failures %

Number of

Marginal

Failures

%

PERCEIVABLE: 1.1.1 Non-text Content* 251 34.86% 13 1.81%

PERCEIVABLE: 1.2.1 Audio Only and Video Only

(Pre-recorded) 03 1.88% 00 0.00%

PERCEIVABLE: 1.2.2 Captions (Pre-recorded) 11 13.75% 00 0.00%

PERCEIVABLE: 1.2.3 Audio Description or Media

Alternative (Pre-recorded) 11 13.75% 00 0.00%

PERCEIVABLE: 1.3.1 Info and Relationships 201 41.96% 05 1.04%

PERCEIVABLE: 1.3.2 Meaningful Sequence 04 5.00% 00 0.00%

PERCEIVABLE: 1.4.1 Use of Color 41 25.63% 04 2.50%

OPERABLE: 2.1.1 Keyboard: 27 16.88% 01 0.63%

OPERABLE: 2.1.2 Keyboard Trap: 07 8.75% 00 0.00%

OPERABLE: 2.2.2 Pause, Stop, Hide 23 14.38% 00 0.00%

OPERABLE: 2.3.1 Three Flashes or Below

Threshold 01 1.25% 00 0.00%

OPERABLE: 2.4.1 Bypass Blocks 106 44.17% 00 0.00%

OPERABLE: 2.4.2 Page Titled 20 25.00% 00 0.00%

OPERABLE: 2.4.3 Focus Order 04 5.00% 02 2.50%

OPERABLE: 2.4.4 Link Purpose (In Context) 26 16.25% 02 1.25%

UNDERSTANDABLE: 3.1.1 Language of page 38 47.50% 00 0.00%

UNDERSTANDABLE: 3.2.1 On Focus 05 6.25% 01 1.25%

36

Success Criteria* for Level A compliance of WCAG

2.0

Number of

Failures %

Number of

Marginal

Failures

%

UNDERSTANDABLE: 3.2.2 On Input 05 6.25% 02 2.50%

UNDERSTANDABLE: 3.3.1 Error Identification 32 20.00% 01 0.63%

UNDERSTANDABLE: 3.3.2 Labels or Instructions 22 27.50% 00 0.00%

ROBUST: 4.1.1 Parsing 76 95.00% 00 0.00%

ROBUST: 4.1.2 Name, Role, Value 62 77.50% 07 8.75%

TOTAL 976 38

Table 18: Summary of all Failures, Passes and Marginal Fails according to each Test Indicator used to determine Success Criteria Compliancy

Failed Passed Marginal Failure

NA TOTAL

25.96%

N=976

34.34%

N=1291

1.01%

N=38

38.68%

N=1454

100.00%

N=3759

Once all the website failures were identified they were then categorised into three distinct types of repairs according to complexity.

Please Note: This estimate is based on an experienced staff employed at EWORX (web designer/developer) familiar with WCAG2.0 Success Criteria and how they can be resolved.

Table 19: Repair Type and Average Repair Estimate

Repair Type Average Time Required to Repair

Minor Fix An hour or up to a day or so

Considerable Fix Considerably more effort likely to be needed,

possibly 3-5 Days

Major Fix A lot more effort likely to be needed, may be more than 5 days and could be considerably

more in some cases

In view of the failures identified in Table 19 the Repair Type attributed to Failure is reflected in the following table.

Table 20: Complexity of Repairs Required to Meet WCAG 2.0 Success Criteria Level A for Websites where a Criteria Failed or Marginally Failed

Website where Types of Repair Totals %

Minor Fix 732 72.19%

Considerable Fix 184 18.15%

FAILED or MARGINALLY FAILED a TEST CRITERIA*

Major Fix 98 9.66%

TOTAL 1014 100.00%

* Please Note – the Marginal Fails at this Level should not be confused with a Website Overall Marginally Failing. Here we are discussing Test Criteria.

37

2.4 Review of WCAG 2.0 checkpoint failure for the Websites that did not Pass WCAG 1.0 Automated Testing

2.4.1 Principle 1 – Perceivable

Principle 1: Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

This first principle refers to the way in which information and user interface components are presented to users. They should be presented in such a way so that users missing one or more human senses will be able to perceive it.

Guidelines relating to the Perceivable Principle concern the following:

Guideline 1.1 Text Alternatives: 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.

Guideline 1.2 Time-based Media: Provide alternatives for time-based media.

Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example

simpler layout) without losing information or structure.

Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including

separating foreground from background.

2.4.1.1 Non Text Context

PERCEIVABLE: 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose

The purpose of this Success Criterion is to ensure that information presented by non-text content is accessible through the use of a text alternative.

Of the 80 websites manually reviewed 7 websites passed this Success Criteria and 73 Failed.

Table 21: Checks Undertaken in Order to Determine Compliancy with 1.1.1 Non-Text Content & Associated Results

Test Criterion 1.1.1 Indicators Failed Passed Marginal

Fail NA Total

Do all images, form image buttons, and image map hot spots have appropriate, equivalent alternative text.

47 25 1 7 80

Are all decorative images implemented as CSS backgrounds.

13 59 1 7 80

In cases where there is a null alt text (alt="") is the meaning conveyed by a text description within the content.

61 2 0 17 80

Do all linked images have descriptive alternative text. 34 35 10 1 80

Are Equivalent alternatives to complex images provided in context or on a separate (linked and/or referenced via longdesc) page.

0 1 0 79 80

Marginal Test Criterion 1.1.1 Indicators Failed Passed NA Total

Fail

Do all form buttons have a descriptive value. 18 60 0 2 80

Form inputs have associated text labels or, if labels cannot be used, a descriptive title attribute.

37 40 1 2 80

Is embedded multimedia identified via accessible text. 14 1 0 65 80

Are frames appropriately titled. 27 1 0 52 80

TOTAL 251 224 13 232 720

Of the websites that Failed 89.02% (N=235) of Repair Types were considered Minor Fixes and, 6.06% (N=16) were considered as requiring Considerable Fixes whereas another 4.92% (N=13) were considered as Marginal Fails - Minor Fixes.

Perceivable 1.1.1. Non-Text Content Repairs Required

Fail - Minor Fix Fail - Considerable Fix MF- Marginal Fix0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

100.00

Repair Types

% o

f R

epai

rs

Figure 24: Website Repair Types for Success Criteria 1.1.1 Non-Text Content

2.4.1.2 Audio Only and Video Only (Pre-Recorded)

Perceivable 1.2.1 Audio-only and Video-only (Prerecorded): For pre-recorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labelled as such: (Level A).

The purpose of this Success Criterion is to make information conveyed by pre-recorded audio-only and prerecorded video-only content available to all users. Alternatives for time-based media that are text based make information accessible because text can be rendered through any sensory modality (for example, visual, auditory or tactile) to match the needs of the user.

For prerecorded video content, authors have the option to provide an audio track. This makes it possible for users with and without vision impairment to review content simultaneously. The approach can also make it easier for those with cognitive, language and learning disabilities to understand the content because it would provide parallel presentation.6

6 http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-av-only-alt.html

38

39

Of the 80 websites manually reviewed 2 websites failed this Success Criterion.

Of these Failings 66.67% (N=2) Repair Types were deemed as Minor Fixes and 33.33% (N=1) Repair Type was deemed as a Considerable Fix. The following table reflects the test indicators against which the websites failed.

Table 22: Checks Undertaken in Order to Determine Compliancy with Success Criterion 1.1.1 Non-Text Content & Associated Results

Test Criterion 1.2.1 Indicators Failed Passed Marginal

Fail NA Total

Is a descriptive text transcript (including all relevant visual and auditory clues and indicators) provided for non-live, web-based audio (audio podcasts, MP3 files, etc.).

2 0 0 78 80

Is a text or audio description provided for non-live, web-based video-only (e.g., video that has no audio track).

1 0 0 79 80

TOTAL 3 0 0 157 160

2.4.1.3 Captions (Pre-Recorded)

Perceivable 1.2.2 Captions (Pre-Recorded): Captions are provided for all prerecorded audio content

in synchronized media, except when the media is a media alternative for text and is clearly labelled as

such. (Level A)

The purpose of this Success Criterion is to enable users who are deaf or hard of hearing to view the audio

content of synchronised media presentations through the use of captions.

Common web accessibility guidelines indicate that captions should be7:

Synchronized - the text content should appear at approximately the same time that audio would be available

Equivalent - content provided in captions should be equivalent to that of the spoken word

Accessible - caption content should be readily accessible and available to those who need it

Given the onset of multimedia and its rapid growth, this Success Criteria is relevant to all synchronised media presentations played through multimedia players such as Quicktime, RealPlayer, or Windows Media Player, but is also relevant to such technologies as Flash, Shockwave, or Java when audio content is a part of the multimedia presentation

Of the 80 websites manually reviewed 11 websites that used videos did not comply with this Success Criteria i.e. Captions were not provided.

Of these Failings 9.09% (N=01) Repair Types were deemed as Minor Fixes and 90.91% (N=10) Repair Types were deemed as Considerable Fixes.

2.4.1.4 Audio Description or Media Alternative

Perceivable 1.2.3 Audio Description or Media Alternative (Pre-Recorded): An alternative for time-based media or audio description of the pre-recorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labelled as such. (Level A)

The purpose of this Success Criterion is to enable users who are blind or visually impaired to access visual information in a synchronized media presentation. Web designers can choose 1 of two approaches to implement this success criterion.

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

40

The first approach is to provide audio description of the video content. The audio description augments the audio portion of the presentation with the information needed when the video portion is not available. During existing pauses in dialogue, audio description provides information about actions, characters, scene changes, and on-screen text that are important and are not described or spoken in the main sound track.

The second approach involves providing all of the information in the synchronized media (both visual and auditory) in text form. An alternative for time-based media provides a running description of all that is going on in the synchronized media content. The alternative for time-based media reads something like a screenplay or book. Unlike audio description, the description of the video portion is not constrained to just the pauses in the existing dialogue. Full descriptions are provided of all visual information, including visual context, actions and expressions of actors, and any other visual material. In addition, non-speech sounds (laughter, off-screen voices, etc.) are described, and transcripts of all dialogue are included. The sequence of description and dialogue transcripts are the same as the sequence in the synchronized media itself. As a result, the alternative for time-based media can provide a much more complete representation of the synchronized media content than audio description alone.8

Of the 80 websites manually reviewed 11 websites that used videos did not comply with this Success Criteria i.e. Captions were not provided.

Of these Failings 18.18% (N=2) Repair Type was deemed as Minor Fix and 81.82% (N=9) were deemed a Considerable Fix

2.4.1.5 Information and Relationships

Perceivable 1.3.1 Information and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

The purpose of this Success Criterion is to ensure that visual and auditory formatting are preserved when the presentation format changes. Presentation formats for instance a likely to change when content is read by a screen reader or alternatively when a style sheet is substituted for the style sheet provided by the user. In order to preserve formatting this must be coded within the web page appropriately in order to indicate the structure of the page and the relationship between its different elements such as headings, paragraphs, list forms, tables etc. For instance within HTML the appropriate attributes and elements must be included within the code in order to describe the role of all page items.

Of the 80 websites manually reviewed 18 websites passed all 6 test indicators and therefore fully complied with this Success Criteria. The remaining websites, Failed 1 or more instance

test indicators.

The extent to which these Failures could be repaired ranged from Minor Fixes to Major Fix. More specifically 65.05% (N=134) of Repair Types were considered Minor Fixes, 13.11% (N=27) of Repair Types were deemed Considerable Fixes and 19.42% (N=40) were deemed Major Fixs and 2.43% (N=5) were Marginal Fails-Minor Fixes.

Table 23 reflects the test indicators against which the websites failed whereas Figures 25 indicates the types of repairs required in order to ensure compliance with this Success Criterion.

8 http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-audio-desc.html

Table 23: Checks Undertaken in Order to Determine Compliancy with Success Criterion 1.3.1 Information and Relations

Test Criterion 1.3.1 Indicators Failed Passed Marginal

Fail NA TOTAL

Is semantic markup used to designate headings (<h1>), lists (<ul>, <ol>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>, for example), etc. Semantic markup is used appropriately.

22 53 5 0 80

Are tables used to markup tabular data. 48 12 0 20 80

Where necessary, are data cells associated with their headers.

44 3 0 32 79

Are data table captions and summaries used where appropriate.

44 9 0 27 80

Are text labels associated with form input elements. 37 40 0 3 80

Are related form elements grouped with fieldset/legend. 6 18 0 56 80

TOTAL 201 135 5 138 479

Perceivable 1.3.1. Information and Relationshops Repairs Required

Fail - Minor Fix Fail -Major Redesign MF - Minor Fix0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

Repair Types

% o

f R

epai

rs

Fail - Considerable Fix

Figure 25: Type of Repairs Required in order to Comply with Success Criteria 1.3.1 Information and

Relations

2.4.1.6 Meaningful Sequence

Perceivable 1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its

meaning, a correct reading sequence can be programmatically determined. (Level A)

The purpose of this Success Criterion is to enable a user agent such as a screen reader to provide an alternative presentation of content without altering the meaning or reading order of a web page. In order to achieve this success criterion it is important that content is programmatically determined

Of the 80 websites manually reviewed 76 websites fully complied with this Success Criteria and 4 websites failed.

Of these failings 50.0% (N=2) were deemed as Considerable Fixes and 50.0% (N=2) as Major Fixs.

41

42

2.4.1.7 Use of Colour

Perceivable 1.4.1 Use of Colour: Color is not used as the only visual means of conveying information,

indicating an action, prompting a response, or distinguishing a visual element. (Level A)

The purpose of this Success Criterion is to ensure that all users can access information that is conveyed within a web page by color differences. This criterion is especially important in instances where colour has a meaning assigned to it, since individuals with visual impairments may not be able to see colour and perceive the information associated with it.

Of the 80 websites manually reviewed 42 websites fully complied with this Success Criteria and 38 websites failed.

Of those that Failed 86.67% (N=39) are considered Minor Fixes and, 4.44% (N=2) are considered as requiring Considerable Fixes. Of those web pages that Marginally Failed 8.89% (N=4) are considered as Minor Fixes. The following table reflects the test indicators against which the websites failed.

Table 24: Checks Undertaken in Order to Determine Compliancy with Success Criterion 1.4.1 Use of Colour

Test Criterion 1.4.1 Indicators Failed Passed Marginal

Fail NA TOTAL

Is colour is used as the sole method of conveying content or distinguishing visual elements.

9 71 0 0 80

Ensure colour alone is not used to distinguish links from surrounding text unless the luminance contrast between the link and the surrounding text is at least 3:1 and an additional differentiation (e.g., it becomes underlined) is provided when the link is hovered over or receives focus.

32 44 4 0 80

TOTAL 41 115 4 0 160

2.4.2 Principle 2 – Operable

Principle 1: Operable – User Interface components and navigation must be operable.

This second principle refers to the way in which a user interacts with a website independently of the device they are using or the response time required. Additionally, it also refers to the need for a website to facilitate a users navigation through the content of the site and avoid the use of flashing content.

Guidelines relating to the Operable Principle concern the following:

Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.

Guideline 2.2 Enough Time: Provide users enough time to read and use content.

Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures.

Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.

Of the nine success criteria which were assessed to test the above guidelines, six proved to be most problematic. These are described below.

43

2.4.2.1 Keyboard

Operable 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface

without requiring specific timings for individual keystrokes, except where the underlying function requires

input that depends on the path of the user's movement and not just the endpoints. (Level A)

Note 1: This exception relates to the underlying function, not the input technique. For example, if using

handwriting to enter text, the input technique (handwriting) requires path-dependent input but the

underlying function (text input) does not.

Note 2: This does not forbid and should not discourage providing mouse input or other input methods in

addition to keyboard operation.

The purpose of this Success Criterion is to facilitate users who are not able to use traditional mechanisms such as a mouse to access content. It is intended to ensure that content can be operated or accessed through a keyboard, keyboard interface or other such input device which act as a keyboard emulator.

Of the 80 websites manually reviewed 52 websites fully complied with this Success Criteria 27 websites Failed and 1 website Marginally Failed

Of these Failings 28.57% (N=8) Repair Types were deemed Minor Fixes, 67.86% (N=19) were deemed Considerable Fix and 3.57% (N=1) was a Marginal Fail – Minor Fix. The following table indicates the Test Criterion where the majority of Failures occurred.

Table 25: Checks Undertaken in Order to Determine Compliancy with Success Criterion 2.1.1 Keyboard

Test Criterion 2.1.1 Indicators Failed Passed Marginal

Fail NA TOTAL

Is all content functionality available using the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard (e.g., free hand drawing).

27 51 1 1 80

Page-specified shortcut keys and accesskeys (accesskey should typically be avoided) do not conflict with existing browser and screen reader shortcuts.

0 12 0 68 80

TOTAL 27 63 1 69 160

2.4.2.2 Keyboard Trap

Operable 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 interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A).

The purpose of this Success Criterion is to ensure that that content does not "trap" keyboard focus within subsections of content within a Web page

Of the 80 websites manually reviewed 73websites fully complied with this Success Criteria and 7 websites failed.

Of the websites that Failed 57.14% (N=4) repairs are considered Minor Fix and 42.86% (N=3) are considered Considerable Fixes.

2.4.2.3 Pause, Stop, Hide

44

Operable 2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true: (Level A)

Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and

Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

The purpose of this Success Criterion is to avoid distracting users during their interaction with a web page. "Moving, blinking and scrolling" refers to content in which the visible content conveys a sense of motion as is the case with motion pictures, synchronized media presentations, animations, real-time games, and scrolling stock tickers. "Auto-updating" refers to content that updates or disappears based on a preset time interval such as automatically updated weather information, news, stock price updates, and auto-advancing presentations and messages.

Of the 80 websites manually reviewed 19 websites failed this Success Criterion the remaining Websites either Passed or it was Not Applicable.

Of these failings 30.43% (N=7) Repair Type was deemed a Minor Fix and 69.57% (N=16) a Considerable Fix. The following table reflects the test indicators against which the websites failed.

Table 26: Checks Undertaken in Order to Determine Compliancy with Success Criterion 2.2.2 Pause Stop Hide-Text & Associated Results

Test Criterion 2.2.2 Indicators Failed Passed Marginal

Fail NA Total

Does automatically moving, blinking, or scrolling content that lasts longer than 3 seconds 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 3 seconds

14 5 0 61 80

Can automatically updating content (e.g., automatically redirecting or refreshing a page, a news ticker, AJAX updated field, a notification alert, etc.) be paused, stopped, or hidden by the user or the user can manually control the timing of the updates.

9 3 0 68 80

TOTAL 23 8 0 129 160

2.4.2.4 Three Flashes or Below

Operable 2.3.1 Three Flashes or Below Threshold: Web pages do 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. (Level A)

The purpose of this Success Criterion is to allow users to access the full content of a site without inducing seizures due to photosensitivity.

Of the 80 websites manually reviewed 12 of the websites complied with this Success Criteria, for 67 websites this Success Criteria was Not Applicable and 1 websites Failed.

For the website that Failed 100% (N=1) of the Repair Type was deemed a Considerable Fix.

45

2.4.2.5 Bypass Blocks

Operable: 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)

The purpose of this Success Criterion is to enable those individuals who navigate web pages via a key board or screen reader to directly access the primary content of the Web page without having to sequentially move through a webpage. Having the ability to skip links and move directly to content increases the efficiency of a web page and limits repetitive actions.

Of the 80 websites manually reviewed none of the websites complied with this Success Criteria.

Of these Failing 100% ALL were deemed a Minor Fix. The following table reflects the test indicators against which the websites failed.

Table 27: Checks Undertaken in Order to Determine Compliancy with Success Criterion 2.4.1 Bypass Blocks & Associated Results

Test Criterion 2.4.1 Indicators Failed Passed Marginal

Fail NA Total

Is a descriptive text transcript (including all relevant visual and auditory clues and indicators) provided for non-live, web-based audio (audio podcasts, MP3 files, etc.).

80 0 0 0 80

Is a descriptive text transcript (including all relevant visual and auditory clues and indicators) provided for non-live, web-based audio (audio podcasts, MP3 files, etc.).

3 22 0 55 80

Is a text or audio description provided for non-live, web-based video-only (e.g., video that has no audio track).

23 3 0 54 80

TOTAL 106 25 0 109 240

2.4.2.6 Page Titled

Operable 2.4.2 Page Titled: Web pages have titles that describe topic or purpose. (Level A)

The purpose of this Success Criterion is to help users identify content and orient themselves within it by ensuring that each web page has a descriptive title. Titles identify the current location of a page without requiring users to read or interpret page content. Titles are also used in site maps or lists of search results, which facilitate users to quickly identify the content they are looking for.

Of the 80 websites manually reviewed none of the 62 websites complied with this Success Criteria and 20 websites failed.

Of these Failings 100% (N=20) Repair Types were deemed a Minor Fix.

2.4.2.7 Focus Order

Operable 2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)

The purpose of this Success Criterion is to ensure that when users navigate sequentially through content,

they encounter information in an order that is consistent with the meaning of the content and can be

operated from the keyboard.

Of the 80 websites manually 73 websites complied with this Success Criteria for 1 website this Success Criterion was Not Applicable. 4 websites Failed and 2 Marginally Failed.

46

Of these Failings 66.66% (N=4) were deemed a Minor Fix (2 Fails & 2 Marginal Fails) 16.67% (N=1) was deemed a Considerable Fix and 16.67% (N=1) a Major Fix.

2.4.2.8 Link Purpose (In Context)

Operable 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)

The purpose of this Success Criterion is to help users understand the purpose of each link so they can decide if they want to follow the link. Whenever possible, link text should be provided that identifies the purpose of the link without needing additional context.

Of the 80 websites manually reviewed 51 websites complied with this Success Criteria for 1 website it was Not Applicable, 26 websites Failed, 2 Marginal Failed

Of these Failings 100% (N=28) Repair Types were considered Minor Fixes (26 Fails and 2 Marginal Fail). The following table reflects the test indicators against which the websites failed.

Table 28: Checks Undertaken in Order to Determine Compliancy with Success Criterion 2.4.4 Link Purpose & Associated Results

Test Criterion 2.4.4 Indicators Failed Passed Marginal

Fail NA Total

Can the purpose of each link (or form image button or image map hotspot) 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).

1 78 0 1 80

Are links (or form image buttons) with the same text that go to different locations are readily distinguishable.

25 6 2 47 80

TOTAL 26 84 2 48 160

2.4.3 Principle 3 – Understandable This third principle ensures that website content and functionality should be as easy to understand and

use as possible.

Guidelines relating to the Understandable Principle concern the following:

Guideline 3.1 Readable: Make text content readable and understandable.

Guideline 3.2 Predictable: Make Web pages appear and operate in predictable ways.

Guideline 3.3 Input Assistance: Help users avoid and correct mistakes.

Five success criteria are used to test the Understandable Guidelines, of which the following consistently presented a problem for the websites that were reviewed.

2.4.3.1 Language of Page

Understandable 3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. (Level A)

The purpose of this Success Criterion is to ensure that information provided within a web page enables user agents to present the text and linguistic content correctly. Both assistive technologies and web browsers can display content accurately when the language of the web page is defined. Furthermore, screen reads can load the correct pronunciation rules etc. In the HTML code, the language of a web page can be indicated by using the lang attribute (lang=”en” for English).

47

Of the 80 websites manually reviewed 42 websites complied with this Success Criteria and 38 websites failed

Of these Failings 100% N=38 were deemed a Minor Fix.

2.4.3.2 On Focus

Understandable 3.2.1 On Focus: When any component receives focus, it does not initiate a change of

context. (Level A)

The purpose of this Success Criterion is to ensure that functionality is predictable as visitors navigate their way through a document. Any component that is able to trigger an event when it receives focus must not change the context. Examples of changing context when a component receives focus include, but are not limited to:

Forms submitted automatically when a component receives focus;

New windows launched when a component receives focus;

Focus is changed to another component when that component receives focus;

Of the 80 websites manually reviewed none of the 73 websites complied with this Success Criteria, for 1 website it was Not Applicable, 5 websites Failed and 1 Marginally Failed.

Of these Failings 66.67% (N=4) were deemed as Minor Fix, 16.67% (N=1) a Considerable Fix and 16.67% (N=1) a Marginal Fail – Minor Fix.

2.4.3.3 On Input

Understandable 3.2.2 On Input: Changing the setting of any user interface component does not

automatically cause a change of context unless the user has been advised of the behaviour before using

the component. (Level A)

The purpose of this Success Criterion is to ensure that when a user enters data or selects a form control the end result is a predictable effect. Changing the setting of any user interface component is changing some state in the control that will persist when the user is no longer interacting with it. So checking a checkbox or entering text into a text field changes its setting, but activating a link or a button does not.

Of the 80 websites manually reviewed none of the 71 websites complied with this Success, for 2 website it was Not Applicable and 5 websites Failed and 2 Marginally Failed

Of these Failings 100% (N=7) were deemed as Minor Fix (5 Fail and 2 Marginal Fails

2.4.3.4 Error Identification

Understandable 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. (Level A)

The purpose of this Success Criterion is to ensure that users are aware that an error has occurred and that they can determine what is wrong. The error message should be as specific and appropriate 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 therefore a textual description of the error must be provided. Screen reader users, for example, will not know there was an error until they encounter one of the indicators. They may abandon the form altogether before encountering the error indicator, thinking that the page simply is not functional.

Of the 80 websites manually reviewed 26 websites complied with this Success Criterion for

48

27 website this Success Criterion was Not Applicable 27 Failed 1 Marginally Failed

Of these Failings 84.85% (N=28) were deemed a Minor Fix (27 Fails and 1 Marginal Fail) and 15.15% (N=5) were deemed a Considerable Fix. The following table reflects the test indicators against which the websites failed.

Table 29: Checks Undertaken in Order to Determine Compliancy with Success Criterion 3.3.1 Error Identification & Associated Results

Test Criterion 3.3.1 Indicators Failed Passed Marginal

Fail NA Total

Do required form elements or form elements that require a specific format, value, or length provide this information within the element's label (or if a label is not provided, within the element's title attribute).

18 28 0 34 80

If utilized, do form validation cues and errors (client-side or server-side) alert users to errors in an efficient, intuitive, and accessible manner. The error is clearly identified, quick access to the problematic element is provided, and user is allowed

14 38 1 27 80

TOTAL 32 66 1 61 160

2.4.3.5 Label or Instructions

Understandable 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A).

The intent of this Success Criterion is to help users avoid making mistakes when their input is required. To help avoid mistakes it is good user interface design to provide simple instructions and cues for entering information. Some users with disabilities may be more likely to make mistakes than users without disabilities or recovery from mistakes may be more difficult, making mistake avoidance an important strategy for users with disabilities. People with disabilities rely on well documented forms and procedures to interact with a page. Blind users need to know exactly what information should be entered into form fields and what the available choices are. Simple instructions visually connected to form controls can assist users with cognitive disabilities or those accessing a page using a screen magnifier.

The intent of this Success Criterion is not to clutter the page with unnecessary information but to provide important cues and instructions that will benefit people with disabilities. Too much information or instruction can be just as much of a hindrance as too little. The goal is to make certain that enough information is provided for the user to accomplish the task without undue confusion or navigation.

Of the 80 websites manually reviewed none of the 29 websites complied with this Success Criteria, for 29 websites this criterion was Not Applicable and 22 Websites Failed

Of these Failings 90.91% (N=20) Repair Types were deemed a Minor Fix and 9.09% (N=2) a Considerable Fix.

2.4.3.6 Principle 4 – Robust

Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

This last principle aims to ensure that website content is properly and conventionally coded thereby ensuring its compatibility with current and future user agents, especially assistive technologies. In the case of mark-up languages such as HTML they should comply and conform to their standardised specifications, whereas in the case of programming language API features should be utilised.

Guidelines relating to the Robust Principle concern the following:

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

Of the two success criteria which were assessed to test the above guidelines, one proved to be most problematic which is described below.

2.4.3.7 Parsing

Robust 4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)

Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.

The purpose of this Success Criterion is to ensure that user agents can properly and accurately interpret and parse content. This criterion requires that HTML is properly used and that important grammatical rules such as using start and end tags for any element and properly nesting them are observed. The validation of HTML can be verified by using the following link: http://validator.w3.org/

Of the 80 websites manually reviewed 4 websites complied with this Success Criteria and 76 Failed.

Of these Failings 14.47 (N=11) Repair Types were considered Minor Fixes, 47.37% (N=36) a Considerable Fix and 38.16% (N=29) a Major Fix.

Robust 4.1.1 Parsing Repairs Required

0

5

10

15

20

25

30

35

40

1

Repair Types

% o

f R

epai

rs

Fail-Minor FixFail - Considerable FixFail - Major Redesign

Figure 26: Type of Repairs Required in order to Comply with Success Criteria 4.1.1 Passing

2.4.3.8 Name, Role, Value

Robust 4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A).

The purpose of this Success Criterion is to ensure that Assistive Technologies (AT) can gather information about, activate(or set) and keep up to date on the status of user interface controls in the content.

Of the 80 websites manually reviewed 9 websites complied with this Success Criteria, for 2

49

50

websites this was Not Applicable, 62 Failed and 7 Marginally Failed

Of the Failings 7.46% (N=5) were considered Minor Fixes 46.27% (N=31) Considerable Fixes and 38.81% (N=26) Major Fixs. Of the 7 Marginal Fails 7.46% (N=5)were considered Minor Fixes, 2.99% (N=2) Considerable Fixes.

51

3 Detailed Success Criteria for Level A – WCAG 2.0

Check

Point Guidelines Success Criteria Pass/Fail Criteria

1.1.1

PERCEIVABLE: 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (including) Controls, Input: If it is a control or accepts user input, then it has a

name that describes its purpose. CAPTCHA: If it is to confirm that content is being accessed by a

person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided.

Decoration, Formatting, Invisible: If it is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

Do all images, form image buttons, and image map hot spots have appropriate, equivalent alternative text?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Are all decorative images implemented as CSS backgrounds? PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

In cases where there is a null alt text (alt="") is the meaning conveyed by a text description within the content?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Do all linked images have descriptive alternative text? PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Are equivalent alternatives to complex images provided in context or on a separate (linked and/or referenced via longdesc) page?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Do all form buttons have a descriptive value? PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Do form inputs have associated text labels or, if labels cannot be used, a descriptive title attribute?

PASS = YES MARGINAL FAIL = MOSTLY

53

Check

Point Guidelines Success Criteria Pass/Fail Criteria

FAIL = NO, SOME

Is embedded multimedia identified via accessible text? PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Are frames appropriately titled? PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

1.2.1

PERCEIVABLE:1.2.1 Audio only and Video only: For pre-recorded audio-only and pre-recorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labelled as such: Pre-recorded Audio-only: An alternative for time-based media is

provided that presents equivalent information for prerecorded audio-only content.

Prerecorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for pre-recorded video-only content.

Is a descriptive text transcript (including all relevant visual and auditory clues and indicators) provided for non-live, web-based audio (audio podcasts, MP3 files, etc.)?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Is a text or audio description provided for non-live, web-based video-only (e.g., video that has no audio track)?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

1.2.2 PERCEIVABLE: 1.2.2 Captions (pre-recorded): Captions are provided for all pre-recorded audio content in synchronized media, except when media is a media alternative for text and is clearly labelled as such.

Are synchronized captions provided for non-live, web-based video (YouTube videos, etc.)?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

54

Check

Point Guidelines Success Criteria Pass/Fail Criteria

1.2.3

PERCEIVABLE: 1.2.3 Audio Description or Media Alternative (Prerecorded): An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when media is a media alternative for text and is clearly labelled as such.

Is descriptive text transcript OR audio description audio track provided for non-live, web-based video?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

1.3.1 PERCEIVABLE: 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Is semantic markup used to designate headings (<h1>), lists (<ul>, <ol>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>, for example), etc. Semantic markup is used appropriately?

PASS =YES MARGINAL FAIL = Mostuil FAIL =NO, SOME

Are tables used to markup tabular data?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Where necessary, are data cells associated with their headers?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Are data table captions and summaries used where appropriate?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Are text labels associated with form input elements? PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Are related form elements grouped with fieldset/legend? PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

1.3.2 PERCEIVABLE: 1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

55

Check

Point Guidelines Success Criteria Pass/Fail Criteria

Is the reading and navigation order (determined by code order) logical and intuitive?

PASS=YES FAIL=NO

1.3.3

PERCEIVABLE: 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.

Do instructions not rely upon shape, size, or visual location (e.g., "Click the square icon to continue" or "Instructions are in the right-hand column")?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Do instructions not rely upon sound (e.g., "A beeping sound indicates you may continue.")?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

1.4.1 PERCEIVABLE: 1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Is colour used as the sole method of conveying content or distinguishing visual elements?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Ensure colour alone is not used to distinguish links from surrounding text unless the luminance contrast between the link and the surrounding text is at least 3:1 and an additional differentiation (e.g., it becomes underlined) is provided when the link is hovered over or receives focus.

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

1.4.2

PERCEEIVABLE: 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

Is a mechanism provided to stop, pause, mute, or adjust volume for audio that automatically plays on a page for more than 3 seconds?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

56

Check

Point Guidelines Success Criteria Pass/Fail Criteria

2.1.1

OPERABLE: 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Is all content functionality available using the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard (e.g., free hand drawing)?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Ensure Page-specified shortcut keys and access keys (access key should typically be avoided) do not conflict with existing browser and screen reader shortcuts.

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

2.1.2

OPERABLE: 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 interface, and, if it requires more than unmodified arrow or tab keys, the user is advised of the method for moving focus away.

Ensure that keyboard focus is never locked or trapped at one particular page element. The user can navigate to and from all navigable page elements using only a keyboard.

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

57

Check

Point Guidelines Success Criteria Pass/Fail Criteria

2.2.1

OPERABLE: 2.2.1 Timing Adjustable: For each time limit that is set by the content, at least one of the following is true: Turn off: The user is allowed to turn off the time limit before

encountering it; or Adjust: The user is allowed to adjust the time limit before

encountering it over a wide range that is at least ten times the length of the default setting; or

Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or

Real-time Exception: the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or

Essential Exception: The time limit is essential and extending it would invalidate the activity; or

20 Hour Exception: The time limit is longer than 20 hours.

If a page or application has a time limit, the user is given options to turn off, adjust, or extend that time limit. 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.

PASS=YES FAIL=NO

58

Check

Point Guidelines Success Criteria Pass/Fail Criteria

2.2.2

OPERABLE: 2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true: Moving, blinking, scrolling: For any moving, blinking or scrolling

information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and

Auto-updating: For any auto-updating information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

Can automatically moving, blinking, or scrolling content that lasts longer than 3 seconds 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 3 seconds.

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Can automatically updating content (e.g., automatically redirecting or refreshing a page, a news ticker, AJAX updated field, a notification alert, etc.) be paused, stopped, or hidden by the user or the user can manually control the timing of the updates?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

2.3.1 OPERABLE: 2.3.1 Three Flashes or Below Threshold: Web pages do 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.

Ensure that 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. (See general flash and red flash thresholds).

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

2.4.1 OPERABLE: 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

59

Check

Point Guidelines Success Criteria Pass/Fail Criteria

Is a link provided to skip navigation and other page elements that are repeated across web pages?

PASS=YES FAIL=NO

Are there any internal anchors? If so, are they working properly? PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

If a page uses frames and the frames are they appropriately titled, this is a sufficient technique for bypassing individual frames.

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

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

Does the web page have a descriptive and informative page title? PASS=YES FAIL=NO

2.4.3

OPERABLE: 2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

Is the navigation order of links, form elements, etc. logical and intuitive? PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

2.4.4

OPERABLE: 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

Can the purpose of each link (or form image button or image map hotspot) 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)?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

Are links (or form image buttons) with the same text that go to different locations readily distinguishable?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

3.1.1 UNDERSTANDABLE: 3.1.1 Language of page: The default human language of each Web page can be programmatically determined.

60

Check

Point Guidelines Success Criteria Pass/Fail Criteria

Is the language of the page identified using the HTML lang attribute (<html lang="en">, for example)?

PASS=YES FAIL=NO

3.2.1 UNDERSTANDABLE: 3.2.1 On Focus: When any component receives focus, it does not initiate a change of context.

When a page element receives focus, 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.

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

3.2.2

UNDERSTANDABLE: 3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

When a user inputs information or interacts with a control, 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.

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

3.3.1 UNDERSTANDABLE: 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.

Do required form elements or form elements that require a specific format, value, or length provide this information within the element's label (or if a label is not provided, within the element's title attribute)?

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

If utilized, do form validation cues and errors (client-side or server-side) alert users to errors in an efficient, intuitive, and accessible manner? The error is clearly identified, quick access to the problematic element is provided, and user is allowed to easily fix the error and resubmit the form.

PASS = YES MARGINAL FAIL = MOSTLY FAIL = NO, SOME

3.3.2 UNDERSTANDABLE: 3.3.2 Labels or Instructions: Labels or

instructions are provided when content requires user input.

Are sufficient labels, cues, and instructions for required interactive elements provided via instructions, examples, properly positioned form labels, and/or fieldsets/legends?

PASS = YES MARGINAL FAIL = MOSTLY

Is markup used in a way that facilitates accessibility? This includes following the HTML/XHTML specifications and using forms, form labels, frame titles, etc. appropriately.

PASS = YES MARGINAL FAIL = MOSTLY

61

Check

Point Guidelines Success Criteria Pass/Fail Criteria

FAIL = NO, SOME

4.1.1

ROBUST: 4.1.1 Parsing: In content implemented using mark-up languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

Are significant HTML/XHTML validation/parsing errors avoided? Check at http://validator.w3.org/

PASS=YES FAIL = NO

4.1.2

ROBUST: 4.1.2 Name, Role, Value: For all user user-interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

FAIL = NO, SOME

4 Benefits of an Accessible Website Increase in Reach

The statistics on the number of users who may face difficulties due to your website's accessibility are quite startling. Within the UK alone:

There are 8.6 million registered disabled people in the UK - 14% of the population (source: Disability Rights Commission - DRC);

One in 12 men and one in 200 women have some form of colour blindness - 9% of the UK population (source: Institution of Electrical Engineers);

Two million UK residents have a sight problem - 4% of the population (source: RNIB); and

There are 12 million people aged 60 or over - 21% of the UK population (source: UK government).

Although there is inevitably some overlap between the aforementioned groups, adding up these numbers provides a total of 48% of the UK population that could potentially face problems with a website's accessibility.

It is not just disabled users however who may experience difficulties with a website's accessibility. Not everyone accesses websites with the latest version of Internet Explorer, with all the plug-ins and programs that may be required for users to optimise their web experience.

If a website for instance relies on images, Flash or JavaScript, and fails to provide alternatives, then the website will not be accessible to users who either do not have these facilities installed or have disabled them. The following examples are a common occurrence:

• PDAs and mobile phones offer limited support for large images, Flash and JavaScript. This growing marketplace should not be underestimated. In 2008 alone an estimated 58 million PDAs will be sold (source: eTForecast) and one third of the world's population will own a wireless device (source: ClickZ).

• Users on slow connections regularly turn images off to enable a quicker download time. Some browsers, such as the text-only Lynx browser do not display images at all.

• Not every user has downloaded the latest Flash program that is required to access a website. Additionally, the download time on Flash websites often takes so long that users lose patience and don't even wait to see the content. Just 25% of web users in the UK are connected to the Internet via broadband (source: National Statistics 16).

• JavaScript is a scripting language that can cause changes to a page, often through mouse functions, buttons, or other actions from the user. For example, pop-ups are opened using JavaScript. JavaScript is unsupported by about 5% of web users, either because they have turned it off to prevent pop-up adverts or because their browser doesn't support it (Source: The Counter). Any JavaScript-driven content provided on a website will not be accessible to these users.

In addition to the aforementioned reasons for making a website accessible there are also a number of businesses reasons that should be taken into account such as:

An accessible website will make an organisation more money; and

An accessible website will save an organisation money.

There are seven explanations for this assumption which are briefly described below.

Accessible Website are Easier to Manage

An accessible website separates the content (the words and images that we see on the screen) and presentation (the way that these words and images are laid out) of each page. Each web page has an HTML document that contains the words and images for that page (the content), and calls up a CSS document that includes the presentation information - this CSS document is shared by all the pages on the website.

To adjust the layout of a website, web developers/designers need only to make changes to the CSS file, saving considerable time (and therefore money).

Accessible Website are Compatible with New Browsing Technologies

Within the near future, the use of PDAs, mobile phones and in-car browsers will all be regularly used to access the Internet. The people making use of these new technologies are generally high-income individuals. In order to reach this lucrative target audience, a website will need to be accessible in order to be able to be used by this technology.

Accessible Website Appear Higher in Search Engine Ranking

An accessible website is more accessible to search engines. Search engines cannot usually understand images, JavaScript, Flash, audio and video content. By providing alternative content to each of these, all areas of a particular website will be accessible to search engines, which in turn will have a better understanding of the websites understanding of its purpose.

The more confident a search engine is of a website's purpose, all other things being equal, the higher it will place the website in the search rankings.

Not all of the accessibility guidelines will help a websites search engine rankings, but there are certainly numerous areas of overlap which are briefly addressed below.

ALT Descriptions Assigned to Images (see Section 3.1.1 Not Text Content)

Screen readers, used by many visually impaired web users to surf the web, cannot understand images. As such, to ensure accessibility an alternative description needs to be assigned to every image and the screen reader will read out this alternative, or ALT, description:

<img src="filename.gif" alt="image description goes here" />

Like screen readers, search engines cannot understand images either and will not take any meaning from them. Many search engines can now index ALT text, so by assigning ALT text search engines will be able to understand a websites images.

Descriptive Link Text

Visually impaired web users can scan web pages by tabbing from link to link and listening to the content of the link text. As such, the link text in an accessible website must always be descriptive of its destination.

Search engines place a lot of importance on link text also. They assume that link text will be descriptive of its destination and as such examine link text for all links pointing to any page. If all the links pointing to a page about widgets say ‘click here’, search engines cannot gain any information about the page in question without visiting it. If on the other hand, all the links say, ‘widgets’ then search engines can easily guess what that page is about.

Website Functions with JavaScript Disabled

JavaScript is unsupported by about 5% of web users (source: The Counter), either because they have turned it off (for example to prevent pop-up adverts) or because their browser does not support it. Many forms of JavaScript are not accessible to web users utilising screen readers.

Furthermore, search engines cannot understand JavaScript either and will be unable to index any JavaScript-driven content. Perhaps more importantly, they will also be unable to follow JavaScript-driven links.

Alternatives to Flash-based Content Provided

Flash, like JavaScript, is not accessible to many users, including those using screen readers. Equally, search engines cannot access Flash therefore alternatives need to be provided.

Transcripts Available for Audio

Hearing impaired users obviously require written equivalents for audio content to be able to access it. Search engines also cannot access this medium, but transcripts provide them with a large amount of text for them to index.

Site Map Provided

Site maps can be a useful tool for visually impaired users as they provide a straightforward list of links to the main pages of a site.

Site maps are also great for search engines as search engines can instantly index an entire website when they arrive at the site map.

Meaningful Page Title

When users access a web page the first thing that appears, and the first thing that visually impaired users hear, is the page title. This latter group of web users do not have the privilege of being able to quickly scan the page to see if it contains the information they are after, so it's essential that the page title effectively describes the page content.

A Web Page Title is the most important attribute on the page. If it adequately describes the content of that page then search engines will be able to more accurately guess what that page is about.

Headings and Sub-Headings Used

Visually impaired web users can scan web pages by tabbing from heading to heading, in addition to tabbing from link to link. As such, it's important for accessibility to make sure that headings are correctly marked up by using <h1>, <h2> etc.

Search engines assume that the text contained in heading tags is more important than the rest of the document text, as headings describe the content immediately below them. Search engines assign the most importance to <h1>, then <h2>, and so on. As such heading tags should be properly used and not abused, as the more text contained in heading tags, for example, the less importance search engines assign to them.

CSS used for layout

Screen readers can more effectively work through the HTML code of CSS-based sites as there's a greater ratio of content to code. Websites using CSS for layout can also be made accessible to in-car browsers, WebTV and PDAs. Search engines also prefer CSS-based sites and are likely to score them higher in the search rankings because:

The code is cleaner and therefore more accessible to search engines;

Important content can be placed at the top of the HTML document; and

There is a greater density of content compared to coding.

Legal Fees will not be Incurred

The RNIB (Royal National Institute for the Blind) and the DRC (Disability Rights Commission) have been exerting pressure on companies and the government to make their websites accessible. Indeed, the DRC has now published their findings from their accessibility investigation of 1000 websites. They have warned firms that they will face legal action and the threat of unlimited compensation payments if they fail to make their websites accessible to people with disabilities.

The Download Time of a Website will be Significantly Improved

Accessible websites generally download quicker than websites with poor accessibility. Just 25% of web users in the UK are connected to the Internet via broadband (source: National Statistics ). Website that take much longer than ten seconds to download will frustrate users and result in a loss of customers.

The Usability of a Website will be Enhanced

There is a certain amount of overlap between web accessibility and web usability. One of the main benefits is increased usability, which according to usability guru, Jakob Nielson, can increase the sales/conversion rate of a website by 100% and traffic by 150%.

An accessible website is not automatically more usable but there are many areas of overlap which are briefly described below.

Descriptive Link Text

Visually impaired web users can scan web pages by tabbing from link to link and listening to the content of the link text. As such, the link text in an accessible website must always be descriptive of its destination.

Equally, regularly sighted web users do not read web pages word-for-word, but scan them looking for the information they are after. Compare the following two paragraphs:

No: 1 - This is some text, lots and lots of lovely text. Now, here's a sentence with a link in it. To

read more about our widgets please click here. Following this, there is more text, lots and lots of

lovely text. And one more sentence, containing yet more text to illustrate this point.

No: 1 - This is some text, lots and lots of lovely text. Now, here's a sentence with a link in it.

Please read about our widgets whilst visiting our website. Following this, there is more text, lots

and lots of lovely text. And one more sentence, containing yet more text to illustrate this point.

The first paragraph has poor accessibility and usability as both regularly sighted and visually impaired web users scanning the paragraph will take no meaning from the word ‘click here’. The second paragraph, with its link text that effectively describes its destination, is far easier to scan and facilitated the user in understanding the destination of the link without having to read its surrounding words.

Prompt Text Assigned to Form Unput

Compare the following two checkboxes:

This is bad This is good

They may look similar but the first box is not accessible since the prompt text is not assigned to the box. To make it accessible the <label for> tag should be used as is the case with the second checkbox:

<input type="checkbox" id="good" /><label for="good">This is good</label>

Making it accessible in this way has also a usability advantage: the text becomes clickable too. Checkboxes are small and pernickety for even the steadiest of hands so by increasing the clickable region everyone benefits.

Large Chunks of Information Divided Up

There are a number of techniques that can be taken to increase the usability for visually impaired users, who have to listen to the information on each page and try to remember it. By structuring information into small, manageable groups, enhanced usability for these users can be achieved.

Methods to accomplish this can include using sub-headings to break up body content, grouping form items with the fieldset command and using lists. Breaking down groups of information is obviously highly useful for sighted web users too, as it greatly enhances our ability to scan the screen quickly.

Site Maps

Site maps can be a useful accessibility tool for visually impaired users as they provide a straightforward list of links to the main pages on the website. Site maps are of course useful for everyone as they provide us with a way of finding pages quickly and help us visualise the structure of the website.

Simple and Easy Language

From an accessibility point of view, this benefit is important for people with reading and/or cognitive disabilities and site visitors whose first language is not the original language of the website. Reading from computer screens is tiring for the eyes and about 25% slower than reading from paper. As such, the easier the style of writing the easier it is for site visitors to absorb your words of wisdom. Wherever possible shorten your sentences. Use, ‘apply’ instead of ‘make an application’ or ‘use’ instead of ‘make use of’.

Consistent Navigation

Having consistent navigation across web pages is important for maximising accessibility to people with reading and/or cognitive disabilities, but again everyone benefits. Each time a user visits a new website it takes a few seconds to adjust to the unique layout and user interface of that page.

By having a consistent interface across a website users can instantly locate the navigation and page content without having to look around for it. In reality, most websites do have consistent navigation across most pages. The main culprit for falling foul of this guideline is the homepage, which some websites structure quite differently to the rest of the site. By having a consistent interface across the entire website users can instantly locate the page content without having to look around for it.

No Unannounced Pop-Ups

For web users utilising screen readers pop-ups can be a real accessibility nuisance. Screen readers read out the content of whichever window is on top of the others. Pop-ups display over the top of the main website so will always be read out first. For visually impaired users this can be frustrating as they may not realise that what they're hearing isn't the ‘real’ website.

So, pop-ups are bad for accessibility. Many toolbars, such as the Google toolbar, now come packaged with a pop-up blocker so allow you to surf the web without the irritation of new windows popping up.

CSS used for layout

CSS-based sites are generally have a greater ratio of content to HTML code so are more accessible to screen readers and search engines. Websites using CSS for layout can also be made accessible to in-car browsers, WebTV and PDAs.

As well as improved accessibility, CSS-based websites have one large usability benefit: increased download speed. Broadband may not be accessible to all. In the UK for example, just one in four web users are hooked up to broadband (source: Office of National Statistics 16) so improving the download speed of a web page could provide a great usability advantage.

Transcripts available for audio

One group of web users with special accessibility needs that do not get much press is hearing impaired users, who need written equivalents for audio content. Providing transcripts is in fact highly beneficial to all users. Many of site visitors probably can't be bothered to wait for a 3Mb audio file to download and start playing. They may prefer just a quick outline of what's contained in the audio content.

By providing a transcript, broken up by sub-headings and with the key terms highlighted, non-disabled site visitors can skim through it and get a general idea of the content. They can then make a more informed decision about if they want to wait for the 3Mb audio file to download.

Screen Flickering and Movement Avoided

Some epileptic web users must be careful to avoid screen flicker of between 2 and 55 Hz. Web users with reading and/or cognitive disabilities and those using screen magnifiers will struggle to keep up with scrolling text (if scrolling text is provided a mechanism to stop it must also be provided).

In addition to being a bad idea for accessibility, neither flickering nor scrolling text are good for usability either. The former can be distracting when users are trying to read something and flashing occurs out the corner of a users eye; the latter isn't good either as you have to wait for the content to slowly appear.

The other disadvantage of scrolling or changing text is that a user might see something that they might want to click on, but before you know it it's gone. And now they have to wait 30 seconds for it to re-appear again!