While mandated organisations will be provided in advance with an approved assessment methodology and report format, what follows can be taken as general guidance for all NZ Government organisations on how to approach risk in the context of the web standards.

This guidance directly supports the aims of the Strategy for a Digital Public Service.

Web standards conformance and risk

Most NZ Government organisation websites must comply with the New Zealand Government Web Accessibility and Web Usability Standards. These Standards identify a number of requirements regarding web content, legal and policy issues, and notably web accessibility. If your organisation is mandated to implement the Standards, it’s important to know how your sites do or do not conform, as the kind and degree of non-conformance may be placing your organisation at risk.

For example, if your site does not meet certain technical or accessibility requirements, some disabled people or those who use different devices might not be able to access your site. The inability of an individual or group of individuals to use your site because it’s inaccessible could lead to negative consequences, including reduced uptake of online services and formal human rights complaints.

Similarly, if your site does not provide clear copyright and privacy statements, there may be no easy recourse when some of the site’s content is inappropriately repurposed, or when a citizen raises concerns about the circumstances in which their personal information has been used.

Web Accessibility Standard

Web Usability Standard

Internal sites

Public facing websites that do not meet the Standards are obviously subject to risk in the public sphere. An internal website, however, can still present risks, for example, in terms of employee support and accommodation. This is particularly the case where the Web Accessibility Standard is concerned, as the Human Rights Act (1993), the legislation underpinning the accessibility requirements, applies equally within the NZ Government workplace as it does between the Government and the public.

Additionally, the State Sector Act (1988) arguably requires the Public Service to ensure that its systems, including intranets and computer applications, are accessible to employees with disabilities. For these reasons, the Web Accessibility Standard applies also to internally facing web pages.

Web Accessibility Standard

Human Rights Act (1993)

State Sector Act (1988)

Non-mandated organisation websites

Even if your organisation is not mandated to comply with the Web Accessibility and Web Usability Standards, it remains important to know how each of your web products performs in terms of risk as your organisation remains subject to the Human Rights Act (1993) and the Bill of Rights Act (1990).

Bill of Rights Act (1990)

Assess and manage the risk

The identification, review, and management of risk form part of the regular strategic, operational, and planning activities surrounding any major project such as a website. Risk assessment and management help ensure that a project can achieve its objectives with the minimum of disruption and cost.

To understand the risks and consequences associated with your website’s level of accessibility or compliance with the Web Standards, a risk assessment and management plan should be created. This will enable your organisation to better address any risks your site presents, and mitigate any related outcomes.

Follow a process

Chances are that your organisation or branch already has a formal risk assessment and management process. While responsibility for each organisation’s implementation of the Web Accessibility and Web Usability Standards lies ultimately with its Chief Executive (CE), different teams at different levels within the organisation will be responsible for registering, reviewing, monitoring, and managing risk. This includes those risks generated by a site’s level of conformance to the Web Standards.

It’s suggested that, where possible, you leverage your organisation’s standard risk management process and any available in-house expertise. Where this is not possible, you may wish to use a process like the following.

Identify risks

Failure to meet any aspect of the Web Accessibility or Web Usability Standard does not, in itself, present a risk. The risk lies in the consequences of that failure.

A “risk” is an event or condition (A) that leads to an outcome (B) that has an impact on the business (C). Without an impact on the business (C), there is no risk.

Risk statements

With respect to the Web Accessibility Standard, identify the failures and write corresponding risk statements. Obviously, in most cases it won’t make sense to write a risk statement for every single failure of the Standard that you find. For many websites, the individual failures will be many. Instead, it will make more sense to group and classify the failures based on their type and effect. You may also wish to include known issues that aren’t direct failures of the Web Accessibility Standard but may still cause a risk, such as the use of CAPTCHAs or very small font sizes.

The risk statement might look something like one of the following (fictitious) examples:

• “The instructional videos on our site are not captioned, which means a significant community (Deaf) is not able to use our online services, causing a negative impact on their uptake by the public and giving rise to the possibility of a human rights complaint.”
• “Licence application forms on our site fail WCAG 2.1 Success Criterion 2.1.1 and are not usable by keyboard users. Some users therefore cannot apply for a licence online, which incurs extra cost and the inconvenience of providing face-to-face service, and exposes the organisation to risk of complaint to the Human Rights Commission (HRC) on the grounds of discrimination.” 

  WCAG 2.1 Success Criterion 2.1.1

• “Our publishing procedures result in inaccessible PDF documents without accessible alternatives, which results in requests via our 0800 number, which in turn incurs additional costs for printing and posting out hard-copy documents.”

Assess the risks

Risk severity

Assess the nature and severity of each risk on a spectrum from minimal to severe.

The tables below show the severity of potential risks in different areas — reputation, service delivery, legal and fiscal — if your organisation does not conform with the Web Accessibility Standard.

Risk likelihood

Next, assuming that a particular risk’s cause has not been addressed or mitigated, what is the likelihood of the business impact of that risk manifesting? In the area of accessibility, business impacts may include:

• the cost and resource of a response to a complaint or action against the organisation, or
• the impact on the extent of uptake of an online service, or
• the often hidden cost of potential online users resorting to face-to-face or call centre service if they are unable to use an online, self-service option.

Assess what impacts there may be for your organisation’s services, and then assess the likelihood of that impact becoming real.

For example, in the context of risks associated with a failure to meet the Web Accessibility Standard, the following questions could be asked to assess that risk’s likelihood:

• How widespread is the failure? Does the failure occur in isolated instances, or is it endemic across a site?
• Does the failure prevent or hinder access to high-stakes information or services?
• What is the impact on users? Does the failure merely hinder or does it completely prevent access to information or services for some users?
• What type of disability groups are most affected by the failure? Are multiple disability groups affected?
• Is the failure 1 that’s already been described in the Office for Disability Issues’ list of common website accessibility barriers and solutions?

Office for Disability Issues

Risk rating

Rate the unmitigated risks by plotting them in a matrix like the 1 below that relates the severity of risk impact to the likelihood of the risk occurring. Using the matrix, you can assign each risk a rating from 1 to 25. A higher risk rating represents a greater risk and a higher priority for mitigation. Each risk rating has an associated colour to depict its general risk level: red for extreme, orange for high, yellow for moderate, and green for low).

The risk rating matrix is table for rating risk level as the product of a risk’s impact severity (left column) against its likelihood (first row).

Respond to the risks

Consider the effect of remediation or repair on each risk. What measures or controls could be applied to reduce or eliminate the level of risk, and what costs would be involved? Risk reduction can result from a reduction of either or both the risk’s severity or likelihood. Removing the risk’s original cause usually eliminates the risk entirely.

Put together a list of risks and the ways to address them. This can be used to evaluate and prepare a plan to reduce the number of risks or their impact.

Next, re-assess the severity, likelihood, and rating of each risk were it to be treated with the proposed controls and measures. Any risk that remains after treatment is ‘residual risk’. Residual risk should be accepted and signed off by an appropriate level of management.

Report the risks

Escalation

Organisations should establish an escalation path to ensure appropriate levels of management are aware of the risks that the organisation or project carries, and be in a position to decide or agree on appropriate action. It may look something like the following:

Risk register

To keep track of the risks you are managing, plot each risk in a register. For each risk, describe it, its area of impact, its consequences, and any controls that could mitigate that risk. Also note the severity, likelihood, and risk rating of the risk in both its untreated and treated forms.

Below is an example of a basic risk register. Three sample issues have been entered into the template. Please note that, while certainly possible, these are fictitious issues only. In the context of a real organisation and website, the same risks might present themselves with different potential consequences, receive different assessments, and suggest different responses.

Something is better than nothing

Where the approach described above is not possible, or where a formal risk assessment is not a requirement, you should at least take some time to review the state of your site’s adherence to the Web Standards, and based on this:

• identify risks related to shortcomings in your site’s accessibility and standards-compliance;
• assess and rate the likelihood and possible consequences of those risks; and,
• plan responses for each potential risk scenario, including what can be done immediately to reduce the likelihood and later impact of those risks.