For over two decades, New Zealand’s accessibility standards for the public sector have governed one thing: web content. The draft Digital Accessibility Standard (DAS) proposes to change that, replacing the current Web Accessibility Standard. DAS would bring all Information and Communication Technology (ICT) from websites and mobile apps to documents, software and hardware under a single accessibility standard. 

DAS is expected to take effect in early 2027. The draft went out for public consultation, which closed on 7 August 2026, so we now have a good idea of what’s coming.  

Here’s our interpretation of what’s in the draft, what it could mean for your agency, and what you can do now to prepare for it. Keep in mind that some details may still change before the standard is finalised. 

Who and what DAS will apply to 

The draft has indicated which public service agencies may be required to meet DAS. These are public service departments, departmental agencies, interdepartmental executive boards and interdepartmental ventures. Note that the agencies covered are still being confirmed, so the final scope may shift. Agencies outside the mandate will still be encouraged to follow DAS as guidance.  

The draft covers more than just public-facing ICT. It also applies to internal ICT, such as the software that employees use day to day. 

The deadlines are tighter than they look 

The draft sets phased deadlines for different contexts and technologies from the standard’s start date. Any new or changed ICT must comply from that start date. Existing web pages, mobile apps and documents have one year to comply. Non-web software has three years, and hardware and everything else has five years. 

One year sounds generous until you set it against the complexity of how government delivers. Some products may have a large backlog of accessibility issues, and the fixes have to be slotted into your existing release and maintenance schedules. We know not every agency has the capacity or capability in-house, and procuring vendors for the remediation takes lead time too. 

And the moment you change part of a page, that part must comply, bringing the deadline forward. For example, your existing website has a one-year deadline, but you redesign it in month three. That redesign counts as a change, so the changed parts must meet the standard in month three, not month twelve. 

What this means for you: Web, content and communications teams will be affected first by the one-year deadline. Start sizing up the work, what you have, and how much of it needs fixing. Treat any redesign on your roadmap as the point at which that changed part must comply. 

The underlying technical standard 

The Web Accessibility Standard is based on the Web Content Accessibility Guidelines (WCAG) version 2.2. DAS will be based on EN 301 549 (Accessibility requirements for ICT products and services), which also references WCAG for web content and extends it to other technologies.  

Note that DAS proposes to meet a future version of EN 301 549 (v4.1.1) that is expected to reference WCAG 2.2. This is important as it will keep DAS aligned with the Web Accessibility Standard rather than moving backwards. 

What this means for you: DAS rests on the same WCAG foundation as the Web Accessibility Standard, so any work you’ve done towards meeting the current standard carries over. If your websites largely conform to WCAG, and you’ve also used WCAG to assess your mobile apps and documents, you’ve already done much of the work. 

Non-web software and hardware are where most agencies will be starting fresh. A good early step is to get an idea of what software and hardware you’re responsible for. 

What’s excluded from the requirements 

The draft excludes internal working materials, and “inactive” ICT, so long as the ICT has instructions on how to get an accessible alternative. The draft also excludes third-party content that an agency doesn’t fund, build or control and that isn’t needed to use the agency’s product or service. 

Third-party content is the one to watch. Our take is to treat it as in scope by default, unless the content clears both conditions above. Fail either, and the content stays in scope. 

For example: 

  • An application form uses a third-party identity verification that a person must complete to progress. The identity verification widget is in scope, because it’s needed to use the service. 
  • A page has an embedded YouTube player showing a video produced by the agency. The player is needed to view the video content, so it’s in scope. 

Other cases may be harder to judge. For example, a third-party “Was this page helpful?” widget asks for optional feedback on a page. On the one hand, people visit the page to read the information, and giving feedback on the page isn’t part of that task, so the widget is out of scope. On the other hand, you could argue the feedback mechanism is itself part of what the service offers, and in this case the widget stays in scope.  

What counts as “needed to use” a product or service isn’t always clear, and it’s the kind of call agencies will have to make for their own content. We look forward to getting some guidance on this from the final DAS. 

What this means for you: In practice, most third-party content may not qualify for exclusion. List the third-party content on your websites such as video players, maps and chat tools. Check if they are in scope. For those that are, the responsibility for the fix often sits with the vendor who provides them. 

How exceptions work 

The draft allows for exceptions to be claimed under certain, set circumstances. Sometimes a requirement genuinely can’t be met, and that’s what the exceptions process is for. It gives you a way forward and helps you focus effort where it’s achievable. 

You can claim exceptions on one of two grounds: when meeting a requirement is technically infeasible, or when meeting a requirement creates a disproportionate burden. Any exception you claim must also be recorded with evidence and reviewed regularly. 

Technical infeasibility is the easier of the two to assess. It’s about the absence of a feasible technological solution, rather than time or money.  

With the disproportionate burden exception, conformance is technically possible, but to achieve it would put unreasonable strain on the agency relative to the benefit gained by end users. This is where we expect the most debate. The draft names three factors to weigh, cost, capacity, and the impact on users, but doesn’t set thresholds for any of them. How much cost is too much? How do you trade cost against impact? It comes down to judgement, and different agencies could reach different conclusions on similar cases. The draft provides an example of a small agency with millions of scanned documents, which, to convert to an accessible format would cost that agency more than its annual budget. Most cases likely won’t be that clear. 

What this means for you: Exceptions are only for specific requirements you can’t meet, not whole sections of the standard. And since the whole point of DAS is to improve access for disabled people, treat an exception as a last resort. A disproportionate burden claim, in particular, will need to be defensible and have good evidence. 

What we find encouraging 

There’s a lot to like in the draft. A few things that stood out to us: 

  • Accessibility Plan and Accessibility Statement: The draft requires agencies to develop and make available these two key documents. An Accessibility Plan is worth having whether or not DAS ends up mandating it. Preparing one forces you to map your current state and see where the gaps are. While the Accessibility Plan is internal, the Accessibility Statement is external. The Statement is how you stay accountable to the disabled people who use your products and services. Together these documents cover planning the work and being open with users about it. 
  • HTML-first publishing: The draft advises agencies to publish information “primarily as accessible HTML web pages” rather than only as documents or mobile apps. If done right, HTML web pages adapt to different devices, user settings and assistive technologies, and people don’t have to download a mobile app just to access a product or service. 
  • Plain language: Including plain language in the draft recognises that comprehension is part of access. This will benefit many people who find government-speak hard to understand.  
  • Testing with disabled people: This requirement is included alongside automated and manual testing. Automated tools catch only a small number of issues, and manual testing checks the product against the standard. Neither substitutes for testing with disabled people. A product can pass every technical check but still be hard to use.  
  • Accessibility in procurement: Every ICT contract must require that what it buys meets the standard. Building accessibility into what you buy is far cheaper than retrofitting it once it’s in use.  

What’s next 

While the final standard is expected in early 2027, you don’t have to wait for the final wording to get moving. Here are a few practical first steps: 

  • Work out what’s in scope: List everything DAS would cover from websites, mobile apps and documents to software and hardware. This list is what everything else builds on. 
  • Prioritise your one-year items: Websites, mobile apps and documents are due first. That’s still a big list, so start with your most-used, most critical products and services and check those against DAS to see what needs fixing. 
  • Build accessibility into procurement now: Ask prospective ICT vendors whether their products meet EN 301 549 and build it into contracts. A tool you sign for today but receive next year will already be in scope. 

At Intopia, we’re happy to see the New Zealand government taking this step to improve access for disabled people. We’ll be following DAS closely as it’s finalised, so we can help you make sense of it and get a plan in place.