Content publishers and web accessibility
Content publishers can affect the accessibility of web content. In most cases, web content is published using a content management system that uses common templates. Although the templates may have been optimised for accessibility, it is still possible to publish inaccessible content. Therefore, writers and editors should become familiar with the Web Standards related the content editing and publishing process.
The New Zealand Government Web Accessibility Standard requires that web pages meet the W3C's Web Content Accessibility Guidelines (WCAG) 2.0. Eleven of the relevant WCAG 2.0 Success Criteria directly relate to the work of content creators. Additionally, the fourth WCAG 2.0 conformance requirement that technologies are only used in accessibility supported ways also has an impact on the work of content publishers.
1.1.1 Non-text content
For any non-text content that delivers meaning (with the exception of complex visual maps), a text equivalent must be provided. So if charts, graphs, photos and documents that may have been scanned are published, a text equivalent must also be published to accommodate those who are unable to visually perceive the content. Read more about 1.1.1 Non-text content from the W3C.
1.2 Audio and Video
The following summary of requirements for audio and video incorporates the relevant temporary exceptions in the Web Accessibility Standard.
- Audio-only recordings: Provide a descriptive text transcript that includes all information conveyed via the audio.
- Video-only recordings: Provide a descriptive text transcript that includes all information conveyed visually. While optional, an audio description should be provided if the recording includes high-stakes information or services.
- Video and audio recordings (synchronised media): This is a common problem area for many organisations. The work required will depend to some degree on the audio and video content of the recording.
- Provide a descriptive text transcript that includes all information conveyed via the recording's video and audio tracks.
- Provide captions for all dialogue and information conveyed via the audio.
- Optionally, provide an audio description for any visual information that is not also conveyed through the recording's original dialogue or audio track, especially if it includes high-stakes information or services.
Fortunately, recent developments in web technology now allow web content producers to create their own captions with very little training, minimal time, and low cost. For example, Google's CaptionTube is an application that enables the creation of captions for YouTube videos. There are also inexpensive and easy-to-use 3rd party captioning services. See the blog post, Video captioning: it’s not that complicated.
1.3.1 Information and Relationships
The visual presentation of content structure and relationships must equally be present in HTML. For example, if you present a list on your web page, ensure that it is marked up correctly as a list using HTML. Otherwise, assistive technologies may struggle to interpret the content and it can be inaccessible. Read more about 1.3.1 Information and Relationships from the W3C.
1.3.3 Sensory characteristics
People who are blind and people who have low vision may not be able to understand information if it is conveyed by shape and/or location. For example, "Click the button on the right…" and "Select the round button to access…" can be inaccessible to these groups. Read more about 1.3.3 Sensory characteristics from the W3C.
1.4.1 Use of Colour
Do not rely exclusively on colour to demonstrate meaning in your web content. Colour can be used but also include some other method to show meaning. For example, on a line chart, include symbols like triangles or squares to differentiate content in addition to colour. Read more about 1.4.1 Use of Colour from the W3C.
1.4.3 Contrast (minimum)
Provide enough contrast between text and its background so that it can be read by people with moderately low vision. WCAG 2.0 specifies a luminosity contrast ratio of 4.5:1 between foreground text and background colour for small text, and a ratio of 3:1 for large text (18 point, or 14 point bold text). Read more about 1.4.3 Contrast (minimum) from the W3C.
1.4.5 Images of text
Don't use images to present text as some users need to be able to adjust font size and this functionality is not possible when an image is used as text. In general, text in logo images is permitted, but for other content, use actual text. Read more about 1.4.5 Images of text from the W3C.
2.4.2 Page title
The page's title should clearly identify the content of the page and distinguish it uniquely from every other page. Use the page's main content heading, followed by the name of the site. Read more about 2.4.2 Page title from the W3C.
2.4.4 Link purpose
Write link text that clearly identifies the destination or purpose of the link to users without needing additional context. For example, do not use "click here". Similarly, with links to non-HTML documents, e.g. PDFs, make sure to include the file size and format, preferably as part of the link's text. Read more about 2.4.4 Link purpose from the W3C.
2.4.6 Heading and labels
Descriptive headings and labels help users understand what information is contained in web pages and how that information is organized. When headings are clear and descriptive, users can find the information they seek more easily, and they can understand the relationships between different parts of the content more easily. Read more about 2.4.6 Heading and labels from the W3C.
3.1.2 Language of parts
If a web page includes a section of content in another language, this section needs to use the appropriate HTML to specify the change in language. Read more about 3.1.2 Language of parts from the W3C.
To conform with WCAG 2.0, web pages must use technologies only in ways that are accessibility supported. For the time being, because of variable support in some common assistive technologies used by people with disabilities, content published in PDF format must also be published in another, accessibility supported format, e.g. HTML. Even though an accessible alternative to the PDF needs to be provided, it nonetheless remains best practice to ensure that the PDF itself is accessible. For more, see the guidance on Accessibility supported technologies.
- Last modified: