Skip to main content

Making it easy for people to find, access and use government information online. This is the team’s vision for remaking completely to meet user needs.

We launched on 29 July 2014. We haven’t stopped building, though: our agile project management approach ensures an ongoing process. Our aim is to continuously improve the site based on feedback we receive from our users. Because of this, our team members work together on a daily basis. They have a diverse range of skills, including:

  • web development and testing
  • marketing and communications
  • agency engagement
  • content design
  • user research and analysis.
At the moment, one of the things we’re working on in web testing is how to make a flagship for accessibility. We’re asking questions like:
  • is the site accessible to people who have difficulty seeing or understanding visual content?
  • is there enough contrast between text and its background to be readable for people with low vision, colour blindness, or who are in a bright environment?
  • are we providing text alternatives for visual content like images, or links and buttons that use images, etc? This is important for people who can't see images for whatever reason, whether they have a vision impairment, have turned off images to conserve bandwidth, or the images just haven't loaded.
  • are we making sure that the content’s structure (eg headings, lists, tables, etc) is available in the HTML markup to assistive technologies like screen readers?
  • can you do the same things with a keyboard as you can with a mouse?


There is a wide range of online accessibility tools to help with these sorts of questions. For example, WebAIM's WAVE tool and the new Tenon API are useful for finding accessibility issues in general or for testing against the Web Content Accessibility Guidelines (WCAG) 2.0.

The Tanaguru Contrast-Finder and Jonathan Snook's Colour Contrast Check can tell you about the colour contrast between text and its background, thereby helping to improve the text's legibility. We were really happy to see that gets good results on these tests.

There are many other online tools for testing different aspects of accessibility.

Manual testing

But wait! There’s more! We don’t just use online tests to check accessibility. We use detailed manual testing, too. Our testers recently found accessibility issues that wouldn’t have come up if we relied only on tools like those above.

What do we take from all this?

We’re thrilled that is addressing user needs to the extent we’re aiming for in our vision. And we want to keep that high standard. Testing is one of the ways we’re making sure we maintain quality throughout the improvement process. We aim to make a truly good user experience — for all users.

If you find any accessibility issues with, please do let us know.

Post your comment


  1. Rachel Prosser 04/12/2014 10:11am (5 years ago)

    Thanks Silke - always good to hear about the work your team is doing.

    I'd be interested in an example of the accessibility issues your manual testers found, that the accessibility tools missed.



  2. Silke Noll 04/12/2014 3:43pm (5 years ago)

    Thanks for your question, Rachel. A recent example is the drop-down feedback form we have at the bottom of pages on the website.

    We found that the 'Do you have some feedback?' control was missing some important markup to help screen reader users know that it was effectively a button that they could ‘click’ to change the expanded/collapsed state of the feedback form beneath it. The proper markup had been included in an earlier iteration of the site, but the code got lost during an upgrade. It was a relatively simple process to change it back :)

    However, further manual testing showed us there was more to the story than simply changing the code back to identifying the control as a button for screen reader users and noting its expanded or collapsed state. The team noticed that some screen readers didn't indicate the change in state when the button was activated. If the form was collapsed, activating the button should have caused the screen reader to say “expanded”, thus indicating the change in state. But it wasn’t doing this.

    We’ve made this into a full user story, with a requirement that we need to fix what's called a ‘polyfill’. A polyfill provides capabilities that aren’t already built into all the web browsers our users have.

    We haven't yet completed this second piece of work, but it's part of an upcoming sprint.

  3. Donal 09/12/2014 3:38pm (5 years ago)

    Glad to see govt websites are being check for colour contrast - it really annoys me when I can't read sites because of colour issues. However, it's not just text that sometimes causes issues - sometimes pictures, images, charts, graphs etc are not checked to determine if a colour vision impaired person can read them properly

  4. Tim Robinson 10/12/2014 1:23pm (5 years ago)

    Hi Silke,

    For the following text...should not the word 'Government' precede the word 'websites' in the first sentence? Otherwise, it looks like every website in the world would have to adhere to the nzws.
    Thanks; Tim.


    The NZ Government Web Usability Standard applies to all publicly available websites that can be accessed by individuals who are not employed by a NZ Government organisation subject to the Standard."

  5. Tim again 10/12/2014 1:28pm (5 years ago)

    Link included: it's in the About section...

  6. Silke Noll 10/12/2014 1:39pm (5 years ago)

    Thanks for your comment, Donal. Yes we do check pictures, images, charts, graphs etc. for colour contrast, too. But if you find an issue, please do let us know.

  7. Jason Kiss 10/12/2014 1:55pm (5 years ago)


    Thanks for the comment about the text in <a href="/guidance/about-the-standards/about-the-web-usability-standard/#scope" rel="nofollow">About the Web Usability Standard</a>. While only Government agencies are mandated to implement the Web Standards, and so, by extension, the Standards apply only to Government websites, you are right that we could make that even more explicit.

  8. Kay 28/01/2015 4:17pm (4 years ago)

    Is there a guide for email content too? Many of these principles would apply like including descriptions of images and links. I'd like to forward some information to colleagues about accessibility in email communications and I'm not sure where to find such a guide.

  9. Silke Noll 20/02/2015 10:56am (4 years ago)

    Hi Kay,

    Apologies for the late reply.

    We don't currently have a guide on creating accessible emails. Basically, the state of accessible email has not changed in a long time. In many ways, the most widely accessible email remains a plain text email. But images and colour make email more visually attractive, and can improve accessibility and comprehension for some users, so HTML email, carefully done, can be a good option. The trick is to keep the use of fancy HTML markup and CSS to a minimum. You might find the following two resources of use:

    <a href="" rel="nofollow">Email marketing guide – how to create accessible EDM campaigns</a>

    <a href="" rel="nofollow">HTML Email Design Guide</a>

    Ideally, you should be sending both HTML and a plain text versions of an email, and let the users' email clients and preferences select the one they want. Check out this article on doing exactly that: <a href="" rel="nofollow">Best Practices for Plain Text Emails + A Look at Why They’re Important</a>.

RSS feed for comments on this page | RSS feed for all comments