Reviews

Been waiting to see this for a while - findings from Accease's 2006 audit of NZ govt websites accessibility.

Overall I like this report and how it’s been presented. It manages to have an overall positive tone (this helps I think when you are critiquing other people’s work, and when you don’t want to put them off the entire topic of discussion!) It’s good to have the summary version as well as the fuller survey report , and there are some clear points made on what would help to improve sites’ accessibility.

Smaller issue / task focussed sites better for users?

A comment made in the summary report was that user testers found small sites focussed on an issue and specific set of tasks easier to use, as opposed to (my extrapolation) the larger monolith type sites. This is interesting and perhaps needs to be looked at more when agencies develop their web strategy.

Many of us working in the field see before us a sea (heh) of government websites and wonder why there need to be so many (it can feel like you are part of some kind of gravy train) - and when the Brits decided to delete 551 of their websites earlier this year, it sounded like a great idea.

Perhaps what needs to happen is less of an “org chart” effect with our government sites, (where an agency has a large website detailing all of their functions, services, etc) and just keep those for a kind of reference. And focus more attention on creating clear web facilities (as many as required) for users needing specific information or to complete specific tasks.

Possible approaches:

• Build a small site for each information block or task set.
• Have one larger site which contains many subsites, and use keywords to get users to the subsites quickly (like TVNZ does when they say ‘go to tvnz.co.nz and enter the keyword “tp”‘)

Technical compliance is up, but barriers still the same

Another point made in the summary was that although technical compliance levels had improved since the 2005 accessibility audit, accessibility barriers experienced by disabled users remained consistent with the 2005 report.

I wonder why this might be - some of the identified barriers would be easy to fix, so perhaps it could be that:

• One year is not enough time for a noticeable improvement?
• Specific information about the identified barriers (from 2005) was not communicated clearly enough to the right people?
• Agencies were focussed mainly on achieving technical compliance with the long list of requirements in the NZ Web standards and Recommendations ?

Common problems identified

I’ll mention some common problems discussed in the summary report, as this is good information to have I think, and affects overall usability as well as accessibility.

Navigation

Home pages too busy, too many links. (Appendix 5 of the detailed report mentions problems with complex navigation systems and large numbers of links on pages also.

This reminds me of the old argument about dropdown menus, and their usability/ accessibility. Check out these notes on a delicious link to something called “users decide first, move second” .)

Dodgy or absent skiplinks.

Accessibility information not available or difficult to find

(This should be easy to fix if the standard govt access key set is used consistently… but hang on, there used to be an access key - 0 - for a page listing a site’s access keys. Wonder why that got removed from the list.

Search

This is explained better in appendix 5 , but I think what they are saying would help is having fuzzy search (not just searching exactly what the user typed in the search box), and also to always indicate what the search term was above the list of results. In the appendix some suggestions are made about how search could work, which are worth looking at.

From working with backend developers I know that search can be very difficult to implement well and sometimes what’s suggested in the appendix (e.g. treating several words not in quotes as a phrase) may not be possible.

On medium to large sites it would be worth doing good user interaction testing, design, and putting lots of time into development and functional testing for search. Issues with search may well be less important with smaller sites.

PDFs not accessible

This is an obvious one, not sure that its always going to be easy to do everything in HTML format. One problem I came across recently is that many documents are not actually produced in their final version in anything remotely text-like, such as Word. This is for stuff like big annual reports, where they are produced in a layout/ design application like Adobe InDesign, and text edits all done there, so the only output produced is often PDF. Perhaps this editing process needs looking at?(I’d thought that it would be relatively simple to at least provide a Word version of things, but it seems not ;(

Have a contact form not just a mailto link

Should be a no brainer, and this is still in the standard set of access keys, at number 9.

I should stop now. The only other thing I would say is that it would be great to have some links to some of the sites mentioned in the user tester quotes in the report. Though I guess there would be some political issues with putting in these links. It’s always useful as a developer to have access to feedback about things from actual users, and to be able to see an example of what the user was talking about.

Weirdness with my front end code?

One last thing. I notice on appendix 4 there’s tables listing the ten fastest and slowest to use sites, by user impairment. Now weirdly, one site (it jumped out at me because I did the front-end build on it) is down in the fastest list for deaf, blind, and low vision user testers, but also in the slowest list for mobility impaired users.

What can be up with that? All I can think of is that either it’s the absence of search from that site, or perhaps it uses names for things which are tricky to say when you are using Dragon (speech input) to navigate the site ?