2005 Usability and Accessibility report

This page give a summary of the report, and links to the full report, and downloadable MS Word versions.

Go to full report page

Summary of AccEase Accessibility and Useability Assessment for CommunityNet Aotearoa

These extracts from the AccEase report were collated by Bill Dashfield, CommunityNet project manager. Actions taken since the audits are shown in italics.

Click on the image to download

Accessibility Test by 'People with Disabilities':

Each panel member was given the same test — a series of tasks to accomplish. They were asked for specific comments on each task and on the application as a whole.

The range of people was:

• Switch and Voice-Input User
• Visually-Impaired Users using screen settings, ZoomText, Jaws and BrailleNote (software).
• Mobility-Impaired User using normal settings
• Cognitively-disabled User.

Of our eight testers, one rated the site as "excellent", three "very satisfying", one as "almost very satisfying" and three as "satisfying". This is the only site we've tested in the 2004/2005 year that received no "poor" or "terrible" ratings.

The major issues — preventing a very satisfying or excellent user experience — were:

• the sheer volume of information
• some lack of clarity in the heading navigation (this has been revised)
• some misalignment in some sections when text was enlarged
• the fact that some documents are available only in Word or (less commonly) pdf; links to non-compliant sites also caused some hiccups
• some specific problems with BrailleNote (relating to code structure)

Performance across a range of browsers and operating systems

In addition, we checked the site under a number of different browsers and operating systems to see whether there were any accessibility issues on less common or older technology.

• Your site is optimised for 800 x 600, and responds well to display on lower or higher resolution screens, including a mobile screen.
• The site works largely as expected in the latest version of the three browsers tested.
• Pages download quickly on broadband and dial-up using a 56k modem
• Most non-html documents are also small enough to download within a reasonable time.
• The size of text can be varied in all three browsers elegantly, wrapping to the next line in order to avoid scrolling. There are overlap problems in a few places, but not sufficient to prevent access to information.
• Access keys are enabled.
• Neither the text browser nor the voice browser had problems.
• We tested the site in a hand-held computer emulation: it was good.
• We tested in earlier versions of Firefox, Netscape, Opera and Explorer under Windows 98.Speed was slower — but still very acceptable.
• We also tested using a text-reader emulation. Without images, it is at least no harder than in a normal browser.

Compliance with guidelines

Finally, we reviewed the site against the Web Accessibility Initiative guidelines and the New Zealand Government internet accessibility guidelines. We used two different software packages, and we also manually checked compliance with each guideline using three different machines, ranging from a high-end Pentium 4 and a broadband connection to a Pentium 3 on a 56 kbs modem.

(Note: The Guidelines overlap: for conciseness, only the first reference to a failure is listed. Notes in Italics show the action being taken.)

Priority 1 checkpoints

Failing means some groups will find it impossible to access information.

The site complies with all WAI level 1 checkpoints

The site fails to comply with the following e-government guidelines:

• 6.3.3 requires that html validates. There were a few minor validation warnings and errors in the pages we tested. (This has been largely checked and correcterd.)
• 6.4.2 requires that the format and size of any non-html file should be available as part of the link. Your site provides the required information, but not as part of the link. (Added)
• 6.4.2 also says that use of pdf alone is strongly discouraged. Your site provides links to pdf documents that are not tagged for accessibility or bookmarked. We suggest a disclaimer regarding off-site material. (Added)
• 6.4.4 requires that designers incorporate globally a set of access keys for people who cannot use the mouse, using the standard government set. Your site has a non-standard set of access keys. (Changed to standard keys)
• 6.4.7 requires good contrast between text and background. There two places where contrast could be improved. (Changes made)
• 6.4.8 suggests that tables should not be used for layout, as not all browsers for all technologies support tables. You have between six and 13 tables on your pages, nested to three levels.(Tables removed; site design now implemented in CSS Style Sheets.)
• 7.4.2 requires the use of the legend attribute if the fieldset tag is used in forms, and that each input field in a form should be associated with its descriptive label. (Changes made.)

Priority 2 checkpoints

Failing means that some groups will find it difficult to access information.

The site fails to comply with checkpoint 12.4:

• Checkpoint 12.4 requires that labels are associated explicitly with their controls. Your forms do not use labels. (Changes made.)

The site also fails to comply with the following e-government guidelines:

• 6.3.6 recommends that urls should be in lower-case. The site uses some mixed case text in urls. Note: The site is not case sensitive.Therefore, although the site is technically in breach of 6.3.6, we are not aware of any accessibility consequences in this instance. (New URLs are all lower case. Existing URLs will be changed progressively.)
• 6.4.3 recommends that titles be no more than 60 characters, and preferably around 30. Provided the user has sufficient information for a navigation decision (they do), longer titles should not have an accessibility consequence.
• 6.4.6 recommends that alt text should end with a fullstop and a space. This is not always done. (Noted for future Alt text.) 6.4.6 also recommends that information-rich images should have links to full descriptions. The image at www.community.net.nz/CaseStudies/rap.htm does not comply. (Full description added.)

Priority 3 checkpoints

Failing to comply with one or more WAI priority 3 guidelines means that one or more groups will find it somewhat difficult to access information on your site.

The site fails to comply with the following checkpoints: 14.2

• Guideline 14.2 requires that organisations supplement text with graphic or auditory presentation where they will facilitate comprehension. We suggest that better use could be made of multimedia to support multi-modality. (Use of multimedia has generally been avoided because readers with older equipment or slow line speeds cannot download it in a reasonable time.  However, it will be increasing used for supplementary information where appropriate.)

The site complies with all the optional third-level e-government guidelines that apply.

Go to full report page