AusTender & WCAG 2.0

[Gruden]

A Strategy for Transition and Compliance

The following is a transcript of a talk given by Peter Howard at the recent*Accessibility Update for the Australian Government event in Canberra.

Today, I’m going to be talking about how we’re managing the transition to WCAG 2 on the AusTender system. I’m hoping that our approach to the transition can demonstrate how other teams can manage a task that may seem daunting.

I’ve been involved with the AusTender project since the time of its redevelopment back in 2006. Gruden’s involvement goes back another couple of years. Over the years, we’ve developed a close working relationship with the team at the Department of Finance. We regularly meet up to workshop current and upcoming work on the AusTender system. In a workshop last year, we thrashed out an approach to WCAG 2 that would work both for us as developers and for Finance as managers of the system.



The first thing we did was to assess our current conformance level. We’re currently*conformant to version 1 of the guidelines, to double-A. And we’ve had positive feedback from users. We’re working both to become*conformant to version 2, and to move into the future sustainably.

As part of our planning efforts last year, we did a basic review of the guidelines to look for areas where we expected to have problems.

There are a few changes in the guidelines that make it fairly clear we’re not conformant. One big example is that we used to rely on the fallback that if content was accessible with JavaScript disabled, it was accessible. That hasn’t been a reasonable assumption for some time, with recent surveys suggesting that JavaScript usage amongst screen reader users, for example, is just as high as among the general web browser population, in the high 90s

The version 2 guidelines require that functionality and controls provided by scripts are themselves accessible, with various mechanisms to achieve that. Additionally, the version 2 guidelines ask us to take into account more contexts of use, rather than just thinking of the screen reader “text only” alternative. We need to think about people using different input devices, accessing the site using only a keyboard, and to the extent it’s feasible, using mobile devices.

So we knew we had to go deeper.



We’re currently working through the next stage of the process. We’re undertaking a Compliance Review that delves much deeper, assessing both the public-facing and admin-facing systems against all three levels of the guidelines.

To a limited extent, we can use some automated tools to help guide us through this process. But the version 2 guidelines have been deliberately written so that automated tools can’t test for everything. They’re a good start though. So we’re working by selecting a few key pages on both the public and admin sites, and testing those. For example, most of the records within AusTender are modelled around common search, list, and view interfaces. We use a handful of common controls across most of the site, so we can assess those individually rather than having to check every page on which they appear. We’re then testing using some automation, then checking over the guidelines that are highlighted or that require manual follow-up.

Coming out of this process, we’ll have a list of the various issues that need to be addressed. We’ll then classify them depending on how easy or hard they are to fix, how significant a problem they are, and how visible their impact is.

This basic approach is something that anyone can apply. At Gruden, we’re using a similar approach with a few different clients. We, or your team, can look at your site* and select a range of typical pages, aiming for wide coverage without going into so much detail that the effort has few returns. We’d then use a combination of automated testing to highlight potential problems, and manual testing to cast an eye over page and content structures, and interactions or controls that may be problematic. Findings can then be prioritised.

The next stage will be to fix the problems. AusTender is a completely custom system; we manage the administration system, so we’re not dependent on a third-party CMS.

In addition, we regularly release updates to the application, either to support new reporting requirements or to make improvements to user interfaces. So our approach to Transition is to integrate fixes into our regular release cycles.



Our first step are the quick wins. There are a number of things we can do to improve use that are essentially “invisible” (air quotes) to most users. What I mean is, they’re not going to have any impact on layout nor on interactions, except where users rely on the additions. For example, we can use the W3C ARIA “landmark roles” (see image) to mark up different areas of content, such as search and navigation and main content. We can introduce “skip to content” links. We can make sure we’re including additional markup that provides metadata or additional information about existing content.



As far as the administration of the system goes, we have some benefits. In the system’s favour, administration is highly structured, and users are only given access to a limited subset of formatting tools. The example in the images (above) is taken from the admin and public screens for ATMs, with fields on the admin form corresponding to headings shown on the public screen.

This means we can control the output to ensure that data is output under clear headings, and that potentially inaccessible markup is avoided.

This is a big bonus. Hundreds of thousands of users access hundreds of thousands of documents through the AusTender system. If we can make a few small changes to ensure they all become accessible, it’s a big win for public access to government data.

There are a few “gotchas” in the version 2 guidelines. I mentioned the JavaScript issue. We’ve a number of controls, particularly on the public-facing site, that have been enhanced through the use of JavaScript. When we implemented them, we made sure the functionality was still accessible with JavaScript disabled, and we’ve paid careful attention to the usability of the controls in the most general cases. But we’re going to have to have another pass at them to consider other contexts. The little minus buttons in this image are an example.



To a sighted user, it’s clear what the minus button is going to remove. But if you’re navigating via a keyboard and a screen reader, we need to make sure we’re providing context as to what exactly is being removed, and just “where” a user’s focus ends up after the button they’ve just pressed is removed from the content. There are a range of “hints” we can provide with additional text that isn’t shown to sighted users, so doesn’t impact any of our layouts or interactions.



So what comes next? As we complete our Compliance Review and the early quick wins, we’ll be prioritising fixes for inclusion in subsequent release cycles.

We release updates every 2-3 months, so we’re currently optimistic we can have widespread if not full compliance by the end of the year.

More than that though, we’re preparing for the future. We’re modifying our own development workflows to ensure compliance is ongoing. It’s not enough to just get to the pointwhere we can tick a few boxes on a checklist. Accessibility is a whole state of mind. Back at Gruden, we’re working with our designers and developers to consider wider contexts of use when designing and implementing controls. We collect a lot of data about user behaviours, and by measuring and observing user patterns, we work to identify and improve potential usability issues. We’re going through a separate process with the AusTender team to document our interface standards, with the consistent usability and accessibility of our interfaces a key goal. And we’re building checkpoints into our release processes to ensure any new content models or interfaces have been designed, and are released, with accessibility in mind.

The specifics of our transition may not necessarily apply to your own sites. But I’d encourage you to think about the strategic approach. Pick an indicative range of pages or functions to test. Focus on the quick wins. And build accessibility into your development and authoring workflows. With this established, you can go through a transition and on into the future.

Get More from the original blog...