Accessibility and Govt.nz — time to pause and reflect

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

We launched Govt.nz 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 Govt.nz 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?

Tools

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 Govt.nz 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 Govt.nz 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 Govt.nz a truly good user experience — for all users.

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

9 comments

  1. Comment #1. Rachel Prosser Rachel Prosser:

    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.

    Cheers

    Rachel

  2. Comment #2. Silke Noll

    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. Comment #3. Donal:

    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. Comment #4. Tim Robinson:

    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.

    “Scope

    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. Comment #5. Tim again:

    Link included: it’s in the About section…

  6. Comment #6. Silke Noll

    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. Comment #7. Jason Kiss

    @Tim

    Thanks for the comment about the text in About the Web Usability Standard. 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. Comment #8. Kay:

    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. Comment #9. Silke Noll

    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:

    Email marketing guide – how to create accessible EDM campaigns

    HTML Email Design Guide

    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: Best Practices for Plain Text Emails + A Look at Why They’re Important.

Navigate Posts