Maintaining Web Accessibility
There are a number of issues to be considered when maintaining the accessibility of a newly designed or upgraded website including policy, buy-in from staff, staff training, and processes for creating and publishing content to the site. The following sections provide guidance on each of these issues.
It is important that any accessibility specific policies, publication procedures and staff guides or training are incorporated into any existing general web governance policies and procedures.
Accessibility Policy Document
Accessibility should be explicitly identified as a key feature of your organisation's IT strategy and should be expressed in the appropriate policy documents. Your accessibility policy should cover:
- accessibility targets for the website(s) to include the required conformance rating with WAI WCAG;
- the use of inclusive, user-centred design processes;
- methods to be used to consult with and involve people with disabilities;
- policy on maintaining accessibility to include procedures on how new content is checked for accessibility before being published to the site;
- awareness raising and skills building amongst staff; and
- policy on dealing with suggestions, comments or complaints regarding the accessibility of your ITIT-based products and services.
To foster a culture of inclusion, all staff should be made aware of the accessibility policy.
Upskilling and training
You should consider carefully what kind of training would be best for your staff. For example, although classroom-based training "courses" often fit more easily into corporate training and continuous professional development policies, this type of training is costly to organise and may not be the most effective approach for accessibility.
The knowledge transfer your staff gained from the auditors during the auditing process is a good start to upskilling staff. People who are informed and have a new awareness of accessibility are more likely to be able to maintain it.
Classroom-based training can be a good approach for general accessibility awareness raising or in-depth training specific to a person's task. For ongoing development, however, a mentoring or technical support approach may work best. This can be organised as a consultancy contract to supply a certain amount of assistance over a period of time on an as-needed basis - for example, a half day here and a half day there, to discuss "issues that have arisen since we last met". A fast-response help-desk service may also work.
Publishing new content to the site
It may arise during the audit that the content management system used on the website does not always produce accessible content. It may also arise that long-established protocols and processes in place within the organisation mean that inaccessible content is sometimes published to the site. After an audit is the best time to address both of these issues.
Content management systems
If you have a content management system (CMS) in place that does not always produce accessible content, you may need to look at customising the CMS further to improve the accessibility of its output. You may need to contact the CMS vendor to assist you with this.
If this does not lead to a satisfactory result, you may need to consider moving to a CMS that fully supports accessibility.
No matter how technically proficient a CMS may be at producing accessible HTML, it is only a tool that can be used to aid the accessibility of content. Ultimately, all users of the CMS must have some knowledge of accessibility. Without this knowledge, no CMS can ensure that only accessible content is published to the site. For example, a CMS may be capable of producing code that conforms to the latest HTML/XHTML standard. However, if a content creator uses link phrases such as "Click here" in content being published to the site, this will present an accessibility barrier to some users. This also means the content will not conform to one or more of the WAI WCAG checkpoints. Therefore, staff using a CMS must have the necessary training and supports, such as style and accessibility guides, to enable them to produce and publish accessible content.
A note on Microsoft Word. MS Word is the most commonly used word processor. There are a number of things that can be done when writing content in Word that will assist in the conversion to accessible HTML later on. Issues include the use of correct headings and including alt text for images. More detailed advice on this is available on the WebAim website.
A CMS may be part of a larger and long-established publication process within your organisation. Such publication processes may also present obstacles to ensuring new content published to the website is checked for accessibility. For example, the webmaster or other personnel involved in publishing content to the site may be given content in formats such as MS Word and Adobe PDF and instructed to publish this as is to the site. In order to avoid such scenarios, a clear accessibility policy that provides direction on such matters is required and this must be communicated to all staff.
There is no "one size fits all solution" for ensuring a publication process facilitates accessibility. However, there are a number of issues to consider when reviewing a publication process:
- Do the technologies used (word processors, CMSs etc) enable users to create accessible content? For commonly used applications such as MS Word, look at ways of supporting staff to create content that can lend itself to being converted later to accessible HTML;
- If content is commissioned externally, can anything be done to ensure that it is created in a reasonably accessible way?
- Where content such as reports, information leaflets and factsheets are sent out for print publication, is a master copy of the content maintained? There are 2 issues here:
- It is much easier to produce accessible HTML from MS Word than it is from the PDFs typically created by print and design houses;
- Often revisions are made to the PDF version of the content before it is finalised. If the MS Word version is used to create the accessible HTML for the website then issues of version control may arise. Ensure that a master copy of the MS Word version is kept and used for creating the HTML for the website.
Other issues to consider
Other steps to safeguard gains and build on the audit may include:
- creating accessibility guidelines and checklists for internal use, specific to your organisation;
- building accessibility into processes for managing the website and periodically checking that these are being followed;
- including accessibility awareness in induction training for new staff;
- scheduling a follow-up web accessibility audit;
- joining accessibility initiatives such as the NDA's Excellence through Accessibility Award.