CommunityNet 2005 Accessibility and Usability report

The complete report, and supporting files, can be read or downloaded here.

Accessibility and usability assessment for CommunityNet Aotearoa

June 2005

Click on an image to download. (Click here for Download Help)

 

Contents

1. Introduction
2. Purpose and audience
3. Our testing
4. Results from the user panel
5. Volume of information and clarity of headings
6. Some enlargement issues
7. Non-web documents
8. Links outside your site
9. Specific issues with BrailleNote
10. Contrast
11. Bouquets
12. How the site performs across a range of browsers and operating systems
13. Using latest versions of three most common browsers
14. Using alternative browsers
15. Using older technology
16. Compliance with guidelines
17. Priority 1 checkpoints
18. Priority 2 checkpoints
19. Priority 3 checkpoints
20. Suggestions for home page
21. Appendix: Testing Principles and Methodology
22. Principles
23. Methodology
24. Accessibility Test by 'People with Disabilities'
25. Technical test
26. Number of internet users July 2004

 

Introduction

Purpose and audience

The CommunityNet Aotearoa site is designed to share information with and between community-based groups, which means that the potential audience may come from all segments of the community.

Given the diversity of this audience, we do not consider that any assumptions can be made about the technology to which users might have access, about their socio-economic status or literacy, or about their degree of familiarity with internet conventions.

Users are likely to have older technology than may be the case in organisations with a profit motive. (This assumption is supported by your browser and operating system statistics.) This makes it particularly important that the site should be accessible to all people whatever barrier they may face or technology they may use.

Our testing

As requested, we submitted the website to our user panel. 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. In setting the test, and during our technical verifications, we noted a few accessibility issues. These are reported in the "results from our user panel" section of the report.

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.

Finally, we reviewed the site against the Web Accessibility Initiative guidelines and also (since these represent one best practice model, and were specifically included) the New Zealand Government internet accessibility guidelines. We undertook technical verifications using two different software packages, and we also manually checked compliance with each guideline using three different machines, ranging from a high-end Pentium 4, 2.8Ghz with 1Gb of RAM, a 20 inch monitor and a broadband connection to a Pentium 3 with 198 Mb of RAM, a 15 inch monitor and a dial-up connection on a 56 kbs modem. (See Appendix for further details on our testing principles and methodology.)

Results from the user panel

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. (Our scores range from excellent, through very satisfying, satisfying and poor to terrible.)

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

• the sheer volume of information
• some lack of clarity in the heading navigation (that is, people didn't always understand what a particular term meant until they had explored the site a little)
• 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 (which may be BrailleNote problems, or may relate to code structure, as noted below).

Several people also made suggestions for improvement of the home page.

Volume of information and clarity of headings

Issue

In general, the structure of the site lends itself to easy access to the huge quantity of information available. However, users did not always find information easily, even when they were in the right page.

A selection of comments from our users shows how they found the information to answer our test questions.

I found this [finding contact details for a conference] a bit tricky. Tried Search without much success (too much info). Then discovered a section on Hui and conferences on first page. This revealed exact information. Scrolled to bottom of page and found contact details.

I looked on the Home page, which took a while as it is a large page with a lot of information on It and it took some scrolling. I tried help, which took me to access keys. Firstly there are no access keys to get to this point for anyone, and secondly it supports IE Netscape and Mac, but not Firefox [Note: in fact, the access keys do work in FireFox, though this is not noted in the on-site documentation]. Finding the access keys via Help is a bit obscure, and given the attention obviously given to accessibility the site could have a direct link to accessibility features.

Used search facility "submit photographs". Clicked on case study guide 1 and by scrolling through eventually found answer under "graphics". Took a bit longer but not sure if accessibility could be any easier when considering the huge amount of information on site.

I found a link labelled "Case Studies" at the top of the home page. This directed me to a "Case Study Guide" which was conveniently placed near the beginning of the information on case studies. I then had to scroll down through a great deal of information before I found what I was looking for. I would have found it more convenient if each of the headings had a link from the top of the page taking me straight to the information I wanted.

A comment from one user seems to sum up the general feeling:

This is a very nice site, full of useful information. I am satisfied overall with the availability of the information being accessible to all though having a lot of information on the pages makes them a bit confusing to sort through. Heading navigation could be clearer.

Recommendation

We like the way you provide a brief summary of the information people will find when they select a link, as is done in About Us. Perhaps this practice could be more widely adopted.

Some enlargement issues

Issue

One user of Firefox commented:

With enlargement the site was slightly wider than my screen but I was not required to read long lines of text so this was less trouble than it might have been.

She goes on to say:

I discovered a little overlap and misalignment with enlargement, but not enough to be a problem, once again in the case studies section, with the combination of a coloured rule and a line of text under a heading because there were two lines in the heading.

Recommendation

Check that there is sufficient room for text to enlarge to +2 in Firefox or Opera without overlap or loss of context.

Non-web documents

Issue

Our BrailleNote user was unable to access the pdf document that formed part of the test. Our low-vision users were able to access the pdf, but dislike the format, as it tends to have poorer contrast, takes longer to download, and enlarges in a less friendly way than html.

Recommendation

We understand that you provide a forum for other organisations to publish information, and suggest that you make this clear somewhere in your accessibility statement (a sort of "all care and no responsibility" clause). At the same time, we recommend that you let your contributors know the problems that pdfs can cause. Please feel free to use the articles on our website (with appropriate attribution, of course).

Links outside your site

A similar point can be made regarding links outside your site. As one of our users puts it:

It might be useful to have a disclaimer on the site that links may take you to inaccessible sites, and that while every effort has been made to achieve accessibility not every community group has the skills or resources to make their postings fully accessible, and where information is not accessible contact should be made with the organisation.

Specific issues with BrailleNote

Issue

BrailleNote had some difficulties with some of the links, which it recognised as links but didn't label.

The BrailleNote did not handle this well. I located the following:

Case Study Format. The format for presenting case studies is flexible. Any of the following formats would be considered:

The BrailleNote could not read the following links. It showed a bullet, and had indicators which identified many links. The links did not have labels in my version of KeySoft. I opened one or two to check that they worked, but without knowing which link I was opening it could have taken a long time to chance upon the correct one.

When we checked the page, there were no links, but just a bulleted list. However, some on the code related to this list appeared unusual in it form, and this, it appears, was confusing BrailleNote.

Contrast

Issue

We had only positive comments from the users on contrast. A typical comment was:

The pastel colours and clear text was easy on the eyes and the information easy to find. The colours were directly relevant but not intrusive and prevented the site from being completely bland.

We noted that two of the colours did not pass the colour contrast analyser test (Note: the higher the number, the better the contrast or brightness):

Page element	Colour of element	Colour difference (500 is a pass)	Brightness difference (125 is a pass)
Hot topics	dark blue on orange (Note, black on orange has a contrast result of 612, which is a pass)	459	196
How-to Guides	dark blue on blue	480	196

Solution

It is close, and we received no comments from users, but you may wish to consider changing the colours, improving the contrast.

Bouquets

Users found information easily using both the search and the site navigation. Several commented favourably on the restful colours and the ability to resize text. Below are some of the remarks from the general comments section of the test:

"Very satisfied" seems to give the impression that nothing needs to be done to improve the site, whereas there is some room for improvement… My first impression of this site was "warm and fuzzy." The soft colours, the greeting in Maori and its English translation, the prominent search facility, and the brief, enticing synopses under the headings that related to the links made me keen to find out more about what this site had to offer. I have a preference for home pages that are easy on the eye and offer information in plain, easy to understand English… Site needs very little change to put it in the "fantastic" basket.

It was very easy to navigate with Zoom Text. I only need to use the search box once. There is not too much colour which was good.

It was obvious when using this site that attention had been paid to good structure, organisation of information, and accessibility

I felt this site worked well and had no real issues with it, it works well with zoomtext… If only more sites could be that simple.

I would rate the site as being satisfactory to navigate — almost very satisfactory in my case.

This is a very nice site, full of useful information.

As this was my first real attempt to access a site I have no means of comparison. I did find it attractively set out and reasonably easy to follow.

How the site performs across a range of browsers and operating systems

In deciding what browsers, operating systems and screen resolutions to test, we looked at statistics for likely users. As noted above, we do not believe that assumptions can be made about the literacy (computer or otherwise) or socio-economic level of prospective users.

• 75% of New Zealanders have access to the Internet (Internet Society, 2004).
• Many home and business users are dependent on dialup connections, rather than broadband. December 2003 figures from the Ministry of Economic Development (MED) show that the total number of broadband connections is low by international standards — around 30% of the average of the top 20 OECD countries (2.9 connections per 100 people). (MED, June 2004). In December 2004, there were around 165,000 broadband subscribers and 900,000 dial up subscribers in New Zealand (Research and Markets).
• There is some indication that home users are likely to be using older technology than business users, and certainly access speeds are likely to be slower at home than at work. According to Neilson/Net Ratings, 5% of New Zealand homes have a broadband connection. An Ericsson/Melbourne University study published in November 2004 predicts that 50% of all home connections will be broadband in two years. This means that a substantial percentage of home users will be making connection by dial up for the foreseeable future.

Households in the highest income quintile are five times more likely to have internet access than households in the lowest income quintile. Households with children are more likely to have internet access than households without.

Around 20% of Internet users internationally are using a superceded version of their preferred browser, more than 30% are using an older Windows (2000 or before) operating system, and 5% are using Mac or Linux operating systems.

The most popular browsers on the web are:

Browser	Percentage of all users
1. Microsoft Internet Explorer 6.0	68.5%
2. Mozilla	19.3%
3. Microsoft Internet Explorer 5.0	5.0%
4. Opera	2.2%
5. Netscape Navigator 7	1.2%
6. Netscape 4 or earlier	0.4%

Source: Refsnes Data November 2004

(We note that your site statistics put the number of Netscape users somewhat higher than this.)

The most popular operating systems are:

Operating system	Percentage of all users
1. Microsoft Windows XP	59.1% (64% in April 2005)
2. Microsoft Windows 2000	23.7%
3. Microsoft Windows 98	5.6%
4. Linux	3.1%
5. Apple Macintosh	2.7%
6. Microsoft Windows (other)	1.3%

Source: Refsnes Data November 2004

In October 2004, 35% of users had a screen resolution of 800 x 600 or lower, and 35% had a colour depth of 16 bits or less (Refsnes Data — international figures).

Given these statistics, we suggest a site of this type should be optimised for dial-up access on a 800 x 600 screen with 16 bit colour, and that it should work as expected in Internet Explorer 5+, Mozilla and Firefox. Note that a small (and shrinking) percentage of the population may view sites in 640 x 480 resolution at 256 colours, and an increasing percentage use higher resolutions, higher colour settings, and more recent browsers. However, using only the 216 web-safe colours "future proofs" you against use on mobile technology, which is still 8-bit.

Your site is optimised for 800 x 600, and responds well to display on lower or higher resolution screens, including a mobile screen. Note, though, that the top menu bar — on enlargement in some browsers — may be too wide for the screen (the body text scales to fit the size available, however).

Using latest versions of three most common browsers

The site works largely as expected in the latest version of the three browsers tested (Mozilla, Opera and Explorer 6.0) used under Windows XP on a PC.

Pages download quickly on broadband (under a second). On dial-up using a 56k modem and an older computer, pages still download quickly. Our test machine was a Pentium III computer with 128 Mb of RAM — by no means the slowest machine still used by many home computer users.

Most non-html documents are also small enough to download within a reasonable time. However, users should always be provided with information about the format and size of a document before deciding to download. This information is always available, but is not included as part of the link, which means it may be missed by a blind person tabbing through the links. The non-html documents we found are all quite small and would download easily on a dial-up network.

The size of text can be varied in all three browsers using the browser's menu controls and the Opera and Mozilla shortcut keys. Text enlarges elegantly, wrapping to the next line in order to avoid scrolling. As noted above, there are some overlap problems in a few places, but not sufficient to prevent access to information.

While it is possible in all three browsers to override the author's styles — and this works well — not all users will know how to do this.

Access keys are enabled.

Using alternative browsers

Neither the text browser nor the voice browser had problems with the site.

We tested the site in a hand-held computer emulation to see how it coped with the small screen format. It was good — with or without images turned off.

Using older technology

We tested in earlier versions of Firefox, Netscape, Opera and Explorer under Windows 98.

Speed was slower — but still very acceptable, when using a dial-up connection via 56Kb modem with an older machine (a Pentium III with 128Mb of RAM). Html pages all loaded within the recommended eight seconds.

We also tested using a text-reader emulation. Without images, it was still possible to move around the site — or at least no harder than in a normal browser.

Compliance with guidelines

We tested the site against W3C Web Content Accessibility Guidelines 1.0. There are three levels to the guidelines.

• Priority 1: failure to comply means that the affected information is inaccessible to some users; compliance with this level only means the site is A compliant
• Priority 2: failure to comply means that the affected information is very difficult for some users to access; compliance with level 1 and level 2 means the site is AA compliant
• Priority 3: failure to comply means that the affected information is somewhat difficult for some users to access; compliance with all three levels means the site is AAA compliant.

Note that the terms A, AA and AAA compliant also refer to these checkpoints: a triple-A compliant website meets all priority 1, 2 and 3 checkpoints; a double-A meets priority 1 and 2, and an A-compliant website meets only priority 1 guidelines.

New Zealand's e-government guidelines prescribe best practice techniques for achieving these guidelines, and introduce specific New Zealand guidelines (again in three levels, using a 'must', 'should' and 'may' terminology).

This section of the report details non-compliance for each priority level, examining first the WAI then supplementary e-government checkpoints.

Priority 1 checkpoints

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

The site complies with all WAI level 1 checkpoints

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

1. 6.3.3 requires that html validates. There were a few minor validation warnings and errors in the pages we tested.
2. 6.4.2 requires that the format and size of any non-html file should be available as part of the link. This gives information to users who are blind so that they can decide whether or not to proceed with the download. Giving the information as part of the link text helps those who are tabbing through the links — a common navigation strategy, particularly for those who are mobility and/or sight impaired. Your site provides the required information, but not as part of the link.
3. 6.4.2 also says that use of pdf alone is strongly discouraged. If no html version provided, then Acrobat Accessibility Guidelines must be followed. Your site provides links to pdf documents that are not tagged for accessibility or even bookmarked. A search on "pdf" finds 77 references, some of which have multiple links to pdfs, such as www.community.net.nz/How-ToGuides/CDResourceKit/PublicationsResources/good-practice-guidelines.htm. As noted above, we suggest a disclaimer regarding off-site material.
4. 6.4.4 also requires that designers incorporate globally a set of access keys for people who have difficulty using the mouse, using the standard government set. In the absence of an international standard list of access keys, we suggest it would make it easier for New Zealanders if New Zealand websites adopted the New Zealand e-government standard list. This is:
   • 0 for a list of access keys
   • for home
   • for a site map
   • for search
   • to 8 agency defined
   • for contact us
   • for beginning of main content
   • for go to govt.nz.

   Your site has a non-standard set of access keys.

   (Note that, while regarded as a Level 1 requirement by the e-government guidelines, use of access keys is also a WAI Priority 3 checkpoint.)

5. 6.4.7 requires good contrast between text and background. As discussed in the section on the user panel test, there are a couple of places where contrast could be improved. (This is also a WAI Priority 2 checkpoint.)
6. 6.4.8 suggests that tables should not be used for layout, as not all browsers for all technologies support tables. If they are used, they should not be nested and as few columns as possible should be used. You have between six and 13 tables on your pages, nested to three levels. For example, the home page has 13 tables, nested up to three levels. Most of the front sections of the main menu items have six tables nested up to three levels. The page www.community.net.nz/Links/ has nine tables. www.community.net.nz/About/Submit/SubmitVacancy.htm has seven.
7. 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 by means of a label tag with the "for" attribute. (This is also a WAI Priority 2 checkpoint.)

Priority 2 checkpoints

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

The site fails to comply with checkpoint 12.4, but is otherwise compliant to level 2.

1. Checkpoint 12.4 requires that labels are associated explicitly with their controls. Your forms do not use labels.

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

1. 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. Mixed case is used in URLs for readability, but all lower case should always work too. The purpose of the recommendation is to ensure that it is easy for people linking to your site to enter the correct url, so making sure that the site is not case sensitive should make the recommendation redundant. Therefore, although the site is technically in breach of 6.3.6, we are not aware of any accessibility consequences in this instance. However, note the recommendations of Jakob Nielsen: www.useit.com/alertbox/990321.html
2. 6.4.1 recommends that file size of non-web documents be shown in the link. As noted above, you disclose the size of your non-web documents, but not as part of the link.
3. 6.4.3 recommends that titles be no more than 60 characters, and preferably around 30. Some of yours are long: "Community Notices — Jobs, events, news, classifieds and training — CommunityNet Aotearoa New Zealand" is 88 characters not including spaces. Note: These titles are automatically built, and have the most important words first. Significant information is always in first 60 characters. Some search engines and other technology have a limit to the number of characters they can display — for example, Google displays 66 characters; Internet Explorer's favourites window displays 60 characters. This means that the page title will be cropped in search, history and bookmark lists. Provided the user has sufficient information for a navigation decision, longer titles should not have an accessibility consequence.
4. 6.4.5 says that there should be good contrast between text and background. This has been discussed above.
5. 6.4.6 recommends that alt text should end with a fullstop and a space. This is not always done. 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.
6. 7.4.2 recommends the use of the fieldset tag with forms, and mandates the use of "legend" if fieldset is used. Your forms do not use the fieldset tag.

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: 2.2, 14.2

1. Checkpoint 2.2 requires that you ensure that foreground and background color combinations in text provide sufficient contrast for those using a black and white screen or with colour perception difficulties. As noted above, two of your colours are less than optimal.
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.

Suggestions for home page

As requested, we noted a few points for consideration as you redevelop your home page. Our users felt that there was too much information on the front page, and several commented that the headings over the synopses should be clickable.

I would have preferred to have the headings over the synopses on the home page double as links. Although many had links to recent additions to the page, to get an overview the user often had to go to the relevant link at the top of the page. [Note: we note that, in fact, there is always a link to the overview, called e.g. more case-studies. This does appear below a line (for design reasons) — and was clearly not seen by this user. In fact, we polled several of our users, including our low-vision users, who had all missed seeing the link. In our view, the line acts as an information break, providing a visual cue that is actually wrong in this instance — that anything below the line does not relate to the current information block.]

I would keep the coloured categories under their headings, particularly on the left, and make them clickable. Take out the narrative underneath. On the right, under the heading Community centre I suggest you keep as clickable links Job Vacancies, Hui conferences and events, news, classified, training, panui. And then website notices. The narrative from the front page could be incorporated into the introduction in each section.

We note that the title of the site has an alt referring to a survey — "click here to take the survey". Clicking doesn't work, and the alt seems to be out of date.

Appendix: Testing Principles and Methodology

Principles

The following principles inform our testing

• It is not possible to simulate the experience of a disabled person using a web site, thus all of our task-based testing is carried out by people with disabilities. (We seek to ensure that our test panel comprises people using a range of adaptive technologies and facing a range of disadvantages in their web use). Our testers are experienced in internet use with the assistive technology they use on a daily basis and this reduces the variables when evaluating a site.
• Successful accessibility testing can only be carried out in a situation where a strong amount of trust exists between the person running the test and the person carrying out the testing, thus a lot of emphasis is put on creating powerful working relationships with our testers.
• We seek recommendations (from our testing) that benefit as many people as possible.
• Testers should be asked to perform tasks that the site owner would expect a user to be able to perform easily.
• A disabled person has exactly the same level of expectation of ease of use and overall satisfaction with a web site as a non-disabled person.
• We seek to learn new things and improve our testing methodology every time we carry out a test.

Methodology

Accessibility Test by 'People with Disabilities'

A panel of people with disabilities carried out a series of tasks that required them to seek information we had previously identified on the site. They then answered a specific series of questions in relation to each task. The range of people was as follows:

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

A follow up interview was carried out where necessary, to interpret the results of the testing and determine web-site design implications.

Technical test

The technical test has three phases:

• a spot test of at least three typical pages using a accessibility checking software tool
• a page by page check against the WAI checkpoints by an accessibility expert
• a sampling of a number of pages using a variety of browsers (including a text reader emulation), operating systems and computers, and also under a number of constraints, including:
  • 640 x 480 screen
  • 256 colour
  • No Javascript

Number of internet users July 2004

Home Country	Neilson//Net Ratings (active, at home)	Computer Industry Almanac
Australia	8,790,000	13,100,000
Brazil	11,610,000	22,320,000
France	14,290.000	25, 470,000
Germany	29,740,000	41,880,000
Hong Kong	2,730,000	4,580,000
Italy	15,700,000	25,530,000
Japan	34,710,000	78,050,000
Netherlands	7,780,000	9,790,000
New Zealand	1,520,000 (Dept of Statistics, 2003)	2,340,000
Spain	7,990,000	13,440,000
Sweden	4,410,000	6,120,000
Switzerland	3,000,000	4,600,000
United Kingdom	22,410,000	33,110,000
United States	136,660,000	185,550,000
TOTALS	287,064,290	405,460,025

Source: ClickZ Stats — September 10, 2004

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