Web guides
Related guidance

 See the Technical web guides for advice on moving to WCAG2.0, and other topics.

Applications and accessible alternatives

Principle

Users must have access to an application's core information irrespective of their ability to use client-side scripting, their ability to use a mouse, or their need to use assistive technology.

Such access should, in the first instance, be available via the application itself, something that’s best achieved by building the application to web standards and using progressive enhancement. If this is not possible, access may also be provided via an accessable online alternative (possibly supported by offline means). This principle applies to all applications, including those designed to entertain and/or educate, such as Flash games.

Note though that where an inaccessible application or other technology does not convey core information, no accessible alternative is required. For example, a Flash-powered clock.

Note also that Flash, PDF and javascript are not necessarily inaccessible technologies. However, their accessibility depends in part on users having access to the latest versions of assistive technology (ie, screenreaders etc). This is one of the reasons why these technologies have retained their “use but don’t rely on” status under the Technical standards' New Zealand-specific requirements.

Aim

The aim is not to provide all users with an equally rich experience of your original application, or to over-simplify your web development to accommodate some users. Rather, the aim is provide all users with access to your application’s core information or services.

Options

These options are listed by preference. If the application is needed, building it with progressive enhancement in mind is the strongest approach.

1. Consider whether the application is required to achieve your goals

If the application cannot be made to be accessible, that is, it depends on non-accessible technologies to deliver its information and not just to enhance the user experience, consider whether the application is the best medium. That is, could your informational aims be better achieved in a simpler, accessible way? Are the functions that make it inaccessible really necessary to get your message across?

In planning, use the audience, message and tactics approach. Ask:

2. Create an accessible application

An accessible application is one built to web standards. This means meeting the New Zealand implementation of WCAG2.0, which includes the requirement that client side scripting, Flash, etc may be used but not relied on for content or service delivery.

For applications relying on javascripting, use progressive enhancement. This methodology uses web technologies in a layered way that allows all users to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing those with better bandwidth or more advanced browser software an enhanced version of the page. See Progressive enhancement, WCAG2.0 and ARIA, below.

Note that apart from not relying on javascript, accessible applications must also meet the WCAG2.0 criteria summarised below. An important aspect of this is to ensure the application is keyboard navigable.

A note on Flash and Silverlight

Because of the widespread use of older versions of assistive technology in New Zealand, all Flash and Silverlight applications require an accessible alternative as described below. (It no longer matters that they require plugins.)

However, its still very worthwhile creating Flash and Silverlight applications to each's accessibility guidelines, which take into account the WCAG2.0 requirements (and on which Adobe and Microsoft both advised).

3. Create an accessible alternative to the application

Where it is not possible to create an application that will provide core information in an accessible way, create an "accessible alternative". An accessible alternative must provide equivalent information and services to the inaccessible version, and be updated as often as the inaccessible version. Note that, if necessary, the accessible alternative can include offline contact services. The accessible alternative must be accessible (most often this means linked to) from the inaccessible version.

Examples

Progressive enhancement, WCAG2.0 and ARIA

As described above, the best approach to accommodating accessiblity in applications is to ensure the application's core information can be delivered without relying on javascript, plugins, or keyboard access. Applications achieving this are considered accessible and do not require an alternative.

To achieve this, applications should be designed to meet our implementation of WCAG2.0, employ the principles of progressive enhancement and, where an alternative to mousing is required or where asynchronous updates are used, use the ARIA specifications.

1. WCAG2.0

The interfaces of all applications must meet the success criteria of WCAG2.0, which have been adopted as the New Zealand technical standards. Note that WCAG2.0 is designed in part to help support accessible applications, and outlines when the ARIA techniques may be used in meeting WCAG2.0.

The following key themes of should be kept in mind when creating applications:

Perceivable

Operable

Understandable

Robust

See the Technical standards web guides for more information.

2. Progressive enhancement

Progressive enhancement uses Web technologies in a layered way that allows access to a page's content and functionality irrespective of browser type or Internet connection, while also providing those with better bandwidth or more advanced browser software an enhanced version of the page. A key aspect of progressive enhancement, in the applications context, is unobtrusive javascript.

Approach summary

Developer Christian Heilmann's seven rules of pragmatic progressive enhancement:

  1. Separate as much as possible
  2. Build on things that work
  3. Generate dependent markup
  4. Test for everything before you apply it
  5. Explore the environment
  6. Load on demand
  7. Modularize code

Advantages

In Hijax: Progressive Enhancement with Ajax, developer Jeremy Keith outlines the advantages of progressive enhancement:

Examples

The following sites and code examples illustrate the approach.

Intros and tutorials

Unobtrusive javascript

Javascript’s status in the New Zealand Government Web Standards is "use but don’t rely on", meaning it can be used, but the page or application must work without it. One way to achieve this is by using javascript unobtrusively.

Another set of seven from Heilmann puts it like this:

  1. Do not make any assumptions (JavaScript, the unreliable helper)
  2. Find your hooks and relationships (HTML, the base to build on)
  3. Leave traversing to the experts (CSS, the faster DOM traveller)
  4. Understand browsers and users (build on existing working usage patterns and create what you need)
  5. Understand Events (Event handling to initiate change)
  6. Play well with others (Namespacing, scope and patterns)
  7. Work for the next developer (Making maintenance easier)

Intros and tutorials

3. ARIA

WAI-ARIA, the Accessible Rich Internet Applications Suite (ARIA for short), especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. ARIA is a developing W3C specification that allows webpages (or portions of pages) to declare themselves as applications rather than as static documents, by adding role, property, and state information to dynamic web applications.

ARIA provides a way of describing roles, states, and properties for custom widgets so that they are recognisable and usable by assistive technology users. ARIA also provides a mechanism to ensure that users of assistive technologies are aware of updates in the application.

Note that while New Zealand may adopt ARIA as a standard at some point, at present it is considered good practice only.

Notes

Specialist audiences

Content intended for specialist audiences must take into account the same accessibility considerations as content for non-specialist audiences. Standards exemptions for specialist audiences should not be presumed, as members of a specialist audience cannot be presumed to be without disabilities affecting their Internet use, or to have scripting- or plugin-enabled browsers. Note, however, the web standards recognise that there will be cases where the use of specialist software formats is required for which there is no accessible alternative (eg, CAD, some financial and economic modelling tools).

Considerations for project planning

Ensure your RFP, terms of reference and other relevant documents specify the need for progressive enhancement, or accessible alternatives to inaccessible applications.