To ensure long-term conformance, accessibility must be an integral part of the publishing process, ingrained in workflows and supported by technology. Agencies should review the technical infrastructure and publishing workflows to enable the production of accessible web content. This will help build an efficient and effective publishing environment that suit the needs of all users.

Why should I?

Within Phase 1: Preparation, under work item 1.3, of the Web Accessibility National Transition Strategy (NTS) agencies are asked to complete a website infrastructure assessment. This process will help agencies ascertain the capabilities of their technical infrastructure to support accessibility conformance, as well as assist the integration of accessibility into the publishing processes and workflows that generate content destined for publication on agency websites.

An assessment of the scope of any changes to technical infrastructure and/or publishing processes and workflows will assist agencies in developing their own work program for WCAG 2.0 conformance.

How do I?

In order to complete work item 1.3, agencies should undertake two reviews of both the technical infrastructure as well as the publishing processes used within the agency to create and support the development and management of web content. They are explored in detail below.

Technical infrastructure review

Technical infrastructure includes but is not limited to content management systems (CMSs) that may be commercial off the shelf, customised, or hybrid builds; web development platforms; or any technical components that allow for the creation, development or management of web content.

Web content, for the purposes of the NTS includes both web pages as well as down loadable documents such as Portable Document Format (PDF), Rich Text Format (RTF) or Microsoft Office file types. Current technical infrastructure should be included in the review, as well as planned platforms (for future websites or content) and web applications provided by third parties for which the agency may be unable to control (i.e. Facebook).

The purpose of the review is to consider:

1. Current infrastructure: what, if any, technical infrastructure is being utilised within the agency for which purposes, and where there is possibility to improve services?
2. Support: whether the technical infrastructure supports or inhibits the creation of accessible web content, and whether that support can be enhanced or changed.
3. Strategic improvements: whether there is ability to improve accessibility conformance comprehensively across single or multiple sites (i.e. through site wide fixes).

Current infrastructure

Agencies are not required to use a content management system(s) to support their websites, but may find them useful when managing multiple websites, a complex publishing environment (especially with decentralised publishing model), or if there is a limited number of skilled and experienced web developers or content authors within the agency. Regardless of the number and complexity of websites, agencies will likely find they use a combination of platforms and tools to create and manage web content, with varying levels of support for accessibility.

When assessing current infrastructure, agencies should consider the following:

• Agency website size and complexity (determined through work item 1.1 Agency Website Stocktake);
• Catalogue the name, type and age (development lifecycle) of all CMSs, tools and platforms being used by the agency (including third-party hosted websites):
  • How many websites are supported by how many tools?
  • Do the tools effectively support their websites? If not, how and why?
  • Would streamlining solutions offer efficacy in website management? (i.e. is there a clear business need to use multiple tools over one or more CMS?)
  • If no CMS is used, would a CMS better facilitate the agency’s web publishing model?
• When and how any required upgrades could be coordinated with existing refresh cycles.

Level of technical skill and experience possessed web development (and content authoring) staff.

• Less technically skilled staff will usually benefit from the use of a CMS, due to their lack of familiarity with underlying web technologies such as (X)HTML, CSS, JavaScript etc. Agencies may benefit too by ‘locking down’ templates and limiting ability to affect website design, structure or code.
• Conversely, more technically skilled staff may feel constrained by the limited amount of control that some CMS provide.

Support

To determine the level of support that infrastructure may hold over web content, agencies should review:

• The possibility for granular level control over the (X)HTML/CSS or other web technologies that underpin web content and/or the ability to ensure mark-up languages are created according to their specifications and semantic meaning (supporting WCAG 2.0 Guideline 4.1).
• The assurance that content creation or use of templates does not impact on meeting success criteria, for example, embedded multimedia elements are able to meet relevant requirements of WCAG 2.0: such as Guideline 1.2, Guideline 2.1 and Guideline 2.2; or out of the box templates are coded in ways to enable conformance immediately (e.g. controls and input fields have proper associated names, or developers are prompted to provide a name).
• Agencies should employ rigorous controls to evaluate vendor claims for accessibility compliance, and ensure procurement activities clearly articulate required WCAG 2.0 conformance. Vendors should be able to demonstrate how their products meet WCAG 2.0, and independent testing or references should be available to support such claims.

Strategic Improvements

Technical Infrastructure may enable the creation of more accessible web content through:

• Capability for use of templates or layouts that allow site-wide changes to common elements across entire or multiple websites, or can be locked to remove editing rights (especially useful in decentralised publishing models).
• Use of controls to ensure content is created accessibly through workflows, approvals or conditional formatting.

Publishing process review

The publishing processes are a crucial, but often overlooked aspect of ensuring accessibility. The entire end-to-end web content publishing process should be reviewed from: document design and planning; creation; revisions and reworks; to the final publication on the website, to consider where any points of failure exist that enable inaccessible content to be published. Where content changes frequently, agencies should ensure their review cycles include activity task to check the content for accessibility.

Ideally, accessibility should be considered both at the design and pre-publishing stages to ensure maximum conformance. As much as possible, authors should create accessible content, facilitated by web developers, communications or IT support teams testing the content prior to publishing. Accessibility is an ongoing business-as-usual (BAU) requirement in the management of websites, and should be checked at regular intervals or at least for every major release.

Agencies have a greater likelihood of improved conformance by ensuring accessibility early in the publishing process. They will also benefit from long-term reduced impact on resources by creating accessible content, as opposed to only testing after publishing. For example, content authors can create HTML web pages with properly structured headings (either through set templates, or in a CMS, or according to guidelines or training), or provide alternative text descriptions to images prior to content being published.

Similarly, web developers should always validate mark-up languages to ensure they parse before publishing. Simple BAU tasks inbuilt into current processes will lead to improved websites and minimise costs and resource burdens.

A review of existing publishing processes should consider the following questions:

• How is web content created in the agency?
  • Is accessibility considered in the design or development (or another) stage?
  • When are web developers/ communications staff engaged in content development?
  • Whose responsibility is accessibility assurance in the agency?
  • Whose responsibility is content ownership in the agency?
• How is web content tested for accessibility conformance?
  • Is there ability to integrate processes of content creation and accessibility testing?
• Does the agency use a distributed (decentralised) or centralised web publishing model?
  • Are templates, guidelines or training offered to content authors (to improve accessibility)? If not, could they be implemented?
• Are content authors aware of their responsibilities to facilitiate WCAG 2.0 conformance? For example:
  • Providing text alternatives for images, charts and graphs in documents (supporting WCAG 2.0 Guideline 1.1); Providing multimedia content that conforms to WCAG 2.0 requirements (supporting WCAG 2.0 Guideline 1.2); Writing content in such a way as to be appropriate for online publication (supporting WCAG 2.0 Guideline 3.1)
  • Where it is necessary to provide content in a file format for which there are no WCAG 2.0 sufficient techniques to support a claim of WCAG 2.0 conformance, an appropriate alternative format is supplied (e.g. PDF documents are commonly provided also in RTF).
• Are agency web teams or IT support staff trained and well versed in WCAG 2.0 requirements to know when content does not conform, and the process to rectify issues?

At the conclusion of the Website Infrastructure Assessment, agencies should have a clear understanding of:

• What infrastructure is currently in place, or planned, and the current accessibility features the infrastructure supports, or issues it creates.
• What publishing processes are used within the agency, and where consideration of accessibility in content creation can enable better conformance.

Subjects:

• technical infrastructure
• content management
• navigation