Accessible Web Content

Web content is all content available on the web, including webpages, files, multimedia. All of these content types need to be accessible.

The best approach to making accessible web content is to keep it simple, and to bear a few key principles in mind as you create your content.


  1. How can you increase the accessibility of your content as you make it?
  2. How do you place the content in a webpage?
  3. How do your users need to operate the content?

Meeting WCAG 2.0

A To claim Single A conformance, all of your pages and documents must meet all Single A requirements for all content

A A To claim Double A, all of your pages and documents must meet all Single A and all Double A requirements

A A A To claim Triple A, all of your pages and documents must meet all Single A, Double A and Triple A requirements

About forms

Forms need to have the right background code so that they can be used by screen readers. The order and structure of the forms is also important so that the form makes sense. They should also be fully accessible to people with mobility impairments who may be using the keyboard.

Single A

Making forms

It is sometimes tempting to remove labels and even submit buttons to streamline design. Doing this can sometimes result in keyboard traps because javascript is usually added to provide the functionality that the missing visible element would provide, particularly for submitting forms or navigating through select lists. The added javascript may not include functionality for the keyboard. Make everything visible and keep it simple.

The UWCMS automatically adds labels and submit buttons to forms built in this system.

Making the purpose of your forms clear

The visible text labels for forms should be positioned where the user expects to find them, generally immediately before for text boxes and select lists, and immediately after for radio buttons and check boxes. This also means that all form fields should have a visible label. Also

Operating the form in a webpage

All form elements should be accessible with the keyboard.

When using the form, the user should be

Double A

Making the form

No specific requirements

Making the purpose of your form clear

If the form is a legal, financial or data gathering form, provide a means of letting the user review the data before submitting.

Operating the form in a webpage

No specific requirements

Triple A

No specific requirements

About headings and accessibility

Headings can be used by assistive technology and search engines if they are correctly made in the background code. Since headings are usually have a different appearance to other text content, they can help people browse the page and understand the content, because it is visually divided into easy-to-see sections.

Single A

Making headings

Headings must be made with the heading tag; h1, h2, h3, h4, h5 and h6. Each heading should have a proper hierarchy, with headings at a higher number identifying sub-sections.

In the UWCMS

Start your headings at h3 and below when you are making a page, because h1 is already used as the site title, and h2 is the page title.

Making the purpose of your headings clear

Headings should be descriptive. This means putting the most important information at the beginning of the heading.

Operating headings in a webpage

Organise the information in a page using headings. If you do this, people using screen readers can browse the page as a list of headings, so they can get an idea of the content without having to listen to the whole page. They can also move from one heading to another, so headings should identify each block of content.

Double A

No specific requirements.

Triple A

No specific requirements.

About images and accessibility

Someone who is visually impaired may be using a screen reader. A screen reader can identify images, so they should be placed in the page in a way that this technology can access. Images can add immense value to the content and to the users' understanding of the content. For people with low vision, combining colour with pattern can help them distinguish elements of an image.

Single A

As part of a webpage, images are all downloaded and rendered before the page content can be used by assistive technology such as a screen reader. Therefore, to reduce the wait for people using assistive technology, images should be optimised (reduced to the smallest usable size and with the lowest quality needed for display) before they are put in a webpage. Faster webpages are also ranked higher by Google.

Making images

If using animated gifs, they should stop blinking within 5 seconds, and not flash more than three times in any one second period. If flashing images are a vital part of the page, keep the flickering area safely small. There are formulas to help calculate the safest size of the flickering area for people who have photosensitive epilepsy.

Use pattern with colour to provide more information, for example, a map showing alternative routes in different colours should also have different markers along each route.

Making the purpose of your images clear

Images need to be placed in the page using the programmatic language of the page, for example, as using the img element in HTML. The alt text, which is part of the img tag, can be used to provide more information about the image.

If the image is for decoration only, then the alt text can be left blank: alt="". A screen reader will 'ignore' the image.

If the image is an important part of the content, it must have a text alternative that serves the same purpose. This alternative can be

Or, a short description of the image and a long description in the text near the image, with a reference to the long description in the short description.

Specific techniques

Note: Using the longdesc attribute, a recommended WCAG 2.0 technique; although longdesc is used by screen readers, it is not shown or rendered by any of the major browsers. It is better to add a visible link to a longer description. That way, everyone can use it.

Double A

No specific requirements for images.

Triple A

No specific requirements for images.

Using images as links

Using images as links is perfectly acceptable, but they do need some special attention. A screen reader can identify images used as links, so they should be placed in the page in a way that this technology can access. This means they must have alt text and it must be relevant.

See also the guidelines for

Single A

Making images into links and describing their purpose

Images are made into links by wrapping an a tag around the img tag. Luckily this is done automatically by most webpage editing software, but still needs some attention to getting it right.

Example of an image used as a link

The image code may have been:

<img src="icon.gif" alt="icon" />
 

When made into a link, the alt text needs to say where the link is going to take the user. A screen reader will read this out as a link, and use the alt text as the link text. Therefore, it is important that the alt text describes the link purpose, not the image appearance:

<a href="products.html"><img src="icon.gif" alt="Our Products" /></a> 
 

In this example, keeping the alt text as icon' would not be informative.

See also

Double A

No specific requirements for making images into links.

Triple A

No specific requirements for making images into links.

About links and accessibility

Someone who is visually impaired may be using a screen reader. A screen reader can identify links. Someone with a mobility impairment may be using the keyboard to navigate around a webpage, for example, using the tab key. When they do this, the cursor should visit each link in turn. Each link can then be activated by pressing 'enter'.

Single A

Making links

Links need to be built in the programmatic language of the page, for example, as links formed using the a element in HTML. This means that assistive technologies can identify links and make use of them. This means that there should not be any content on the page that mimics links in appearance.

As well being a different colour from surrounding text, links should also include additional visual clues such as underlining for those with poor colour vision, or those using a screen in a high glare environment.

From a usability point of view, links in menus do not necessarily need underlining, if all text is a link.

A special case is using images as links.

Making the purpose of your links clear

Links must have text that describes the purpose of the link. For this reason, web addresses or URI's are not considered informative and should not be used.

At the very least, links should be organised in a meaningful sequence for people using assistive technology. This is because assistive technology does not render stylesheets, which may have been used to arrange content on the page. To test this, turn off stylesheets, and see how the order of the page changes.

If you want to get fancy, the links should also be put in an order that follows logical sequences and relationships with the content. This may mean changing the default tab order of links and other interactive elements.

Operating the links in a webpage

All links should be operable with the keyboard and should be visible (highlighted) when they receive focus.

The number of links that open new windows and tabs should be kept to a minimum. If a link opens a new window, then the user should be warned.

For links in table cells, the reading order is important for tables containing links in table cells, but the context of the link in the cell, which includes the text in the cell and its associate heading, should make sense.

Double A

Making links

Links can be identified as a different colour from surrounding text, as long as link text has a contrast ratio of 3:1 from non-link text (and they are underlined).

Making the purpose of your links clear

Links that have the same function in a website or page, should have consistent link text. For example, all links that go to a 'Contact Us' page, should have the same text.

Operating the links in a webpage

To make sure links are visible if someone is using the keyboard, developers should at least keep the default 'focus' functionality of the browser, assistive technology or operating system.

Triple A

Making links

The minimum contrast ratio between a link and its background should be 7:1.

About lists and accessibility

Lists are recognised by assistive technology and can help group content into easy to navigate sections.

Single A

Making lists

Lists must be made using ol, ul, and dl, and can be used for text or groups of links.

No shortcuts!

It is tempting to create a list using the break tag (br), but this will not be interpreted by screen readers and will not provide any information to help screen readers users navigate the page.

Double A

No specific requirements.

Triple A

Definitions of words and phrases can be provided in definition lists.

Images are the quickest way to add bulk to a web page or any other document (Powerpoint, PDF etc) and slow it down. If your web page is aimed at external (off campus) users, then it should load in no more than 8 seconds. Documents can take a little longer, but you must include the file size in the link text.

When you have optimised your images, follow the accessibility guidelines for

Optimise Images to Reduce Download Speed

  • Reduce images dimensions properly in an image editor: If you just change the width and height attribute to shrink it, the image will still take the same amount of time to download because it is still the same size in bytes
  • Crop extraneous information: Either change the size of the image 'canvas', or remove coloured areas
  • Save at a lower resolution or quality: How far you reduce the image will depend on what it is for, and what looks OK on the screen:
    - Reducing the quality of JPEG or JPG images will make the image blurry
    - Reducing the number of colours used in GIF files will make the image blotchy. GIF is a good format for images that have few colours, such as logos

Optimise Images With Software

Optimise Images Online

Search here for free online image optimisers

About tables and accessibility

There are two ways tables are used in webpages; data and layout tables. Data tables contain information that benefits from two-dimensional presentation and has column and row headers. Layout tables are used to position page content, certainly before CSS became widespread. Accessibility issues occur because both types of tables use the same code in the background, but table code was designed for data tables. One of the issues is that screen readers read the content across each row of the table. Unless some thought has been been put into how the table is populated, specially for layout tables, the content may not make sense when read out this way.

Using tables for layout

Layout tables are not prohibited by WCAG2.0 , but content layout is better managed with style sheets. If you want to use a layout table, please contact Web Services, who will be able to show you alternatives. However, some development environments for software packages rely on tables for layout (an example is Oracle Apex). Again, please contact Web Services for advice.

However, if the table is correctly used for data, with identifiers for each row and column, screen reader users can interrogate each cell and get the row and column information. For a detailed explanation of table accessibility, WebAIM has good information.

Single A

Making tables

Tables should be used for tabular data rather than page layout. Additional information can be added by using the th (table header) tag to replace some of the td or table data tags. In this example, the cells with times and days of the week are all th.

Table headers

Example of a table with table headers


Monday Tuesday Wednesday Thursday Friday
8:00-9:00 Meet with Sam



9:00-10:00

Doctor Williams Sam again Leave for shack

Code for this table:

<table class="table" summary="Weeks Activities">
  <thead>
    <tr>
      <th> </th>
      <th>Monday</th>
      <th>Tuesday</th>
      <th>Wednesday</th>
      <th>Thursday</th>
      <th>Friday</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th>8:00-9:00</th>
      <td>Meet with Sam</td>
      <td> </td>
      <td> </td>
      <td> </td>
      <td> </td>
    </tr>
    <tr>
      <th>9:00-10:00</th>
      <td> </td>
      <td> </td>
      <td>Doctor Williams</td>
      <td>Sam again</td>
      <td>Leave for shack</td>
    </tr>
  </tbody>
</table>

Note that the blank top left cell is not a header cell.

Id and header

Using id and header attributes to associate data cells with header cells, for tables where data cells are associated with merged header cells or row cells

Example of table needing id and header attributes

Homework Exams Projects
1 2 Final 1 2 Final
15% 15% 15% 20% 10% 10% 15%

Code for this table:

<table class="table" summary="sample table with merged cells">
<tr>
<th rowspan="2" id="h">Homework</th>
<th colspan="3" id="e">Exams</th>
<th colspan="3" id="p">Projects</th>
</tr>
<tr>
<th id="e1" headers="e">1</th>
<th id="e2" headers="e">2</th>
<th id="ef" headers="e">Final</th>
<th id="p1" headers="p">1</th>
<th id="p2" headers="p">2</th>
<th id="pf" headers="p">Final</th>
</tr>
<tr>
<td headers="h">15%</td>
<td headers="e e1">15%</td>
<td headers="e e2">15%</td>
<td headers="e ef">20%</td>
<td headers="p p1">10%</td>
<td headers="p p2">10%</td>
<td headers="p pf">15%</td>
</tr>
</table>

In tables used for layout, the summary can be blank: summary="".

Making the purpose of your tables clear

To add more information to your data table

  • Use the table caption to describe the table; this caption will appear on the page
  • Use the table summary, which will not appear on the page but is read out by screen readers. All data tables should have a summary

The table summary is useful when the table is complex. Both the caption and summary can be present, but they should not have the same text, as this will repeat the information read out by a screen reader. In tables used for layout, the summary can be blank: summary="".

Layout tables should not contain table headers, summary (unless blank) or a caption.

Operating tables in a webpage

Tables themselves are not hard to 'drive' in a webpage, as long as the content makes sense when read across each row, the table will make sense to people using screen readers.

Reading order is important for tables containing links in table cells, but the context of the link in the cell, which includes the text in the cell and its associate heading, should make sense.

Double A

No specific requirements.

Triple A

No specific requirements.

About Writing for the Web and accessibility

Writing accessible content will help people with cognitive difficulties and visually impaired people. It will also help people from a different language background. Although there are no specific WCAG 2.0 guidelines for writing at single A, it is good practice to make your content as succinct as possible. This is done by reducing the number of words in total, and laying them out on the page so they are easier to understand.

Easy to scan means easy to absorb
  • Use headings
  • Use bulleted lists
  • Use links, as these add credibility and clarity to your content.
Order and amount of information

People skim when reading on the screen, so it is important to provide the essence of the message at the beginning of each page.

  • Have one idea per paragraph
  • One idea per sentence
  • Use the inverted pyramid style, starting with the conclusion
  • Prune your web content
Half the content will do just as well, remove
  • 'Fluffy', 'Welcome' text, or give it a page of its own
  • Marketese, boasts (both bad for site credibility)
  • Metaphors, similes or figures of speech
  • Jargon, scientific words, foreign phrases, puns
  • Do not use a long word, when a short word will do
  • If you can cut a word out, cut it out
  • Break any of these rules sooner than say anything outright barbarous
  • Generally, you can remove 50% of the words without affecting the meaning of a web page.
Always build good quality web content

Good quality web content is written using the standards for HTML languages, and using HTML tags for their intended purpose.

  • Use valid HTML (validate it)
  • Use tags for their intended purpose, some examples:
    -  Make proper lists, rather than using the break (<br>) tag
    -  Use structural elements eg, h1, h2, and tables properly
    -  Use current tags eg, no <font> tags, as these have been deprecated or phased out (in preference for CSS)
    -  Explain acronyms with the <acronym> tag
  • Provide sufficient contrast between the background and text
  • Provide a text equivalent for all non-text elements
  • Write unique titles for web pages.

All of these tips will also make your content better suited to search engines.

Improve the impression your content gives (credibility)

How do people know they can trust your content? They may not, because of problems with many web sites (slow downloads, poor page layout and low content quality), undermine confidence in ALL content. To build credibility:

  • Verify content accuracy and credentials with links
  • Show organisational affiliation (who is behind the site)
  • Make it easy to contact you
  • Use a professional design
  • Make your site easy to use and useful
  • Keep the content up-to-date and error-free
  • Avoid fluff and guff (discussed above)

See the Stanford Web Credibility Project, and in particular the Stanford Guidelines for Web Credibility.

Language used: Talking to your clients
  • Use clear, simple language
  • Use the active voice and standard register - these are easier to read
Active Voice

In sentences written in active voice, the subject performs the action expressed in the verb; the subject acts.

The written order is subject, verb, object.

Passive Voice

In sentences written in passive voice, the subject receives the action expressed in the verb; the subject is acted upon. The agent performing the action may appear in a "by the . . ." phrase or may be omitted.

The written order is object, verb, subject.

Examples of Voice

Active: The chairman signed the contract

Passive: The contract was signed by the chairman

Or, Yoda: Signed by the chairman, the contract was

Prize there is for the person who discovers where Yoda provides content for UTAS web sites (this one doesn't count).

However, the active voice can sound a bit hostile or repetitive:

Active: You have not paid this bill

Passive: This bill has not been paid by you

  • If you leave off the object of the sentence, it can sound less threatening.
Registers

Formal (can be described as 'stuffy'):
The Board is required by ordinance to monitor the quality of supervision of candidates.

Informal (can be a bit ambiguous):
Supervisors are checked out by the Board.

Standard (nice and plain):
The Board monitors the quality of research supervision.

Double A

No specific requirements.

Triple A

The following techniques will add value to your content and make it easier to understand.

Explaining unusual words and terms
Pronunciation
Adding value

About PDF

PDF (Portable Document Format) files usually present real text quite well (unless the PDF only contains scanned text), but the readability for assistive technology such as screen readers, may fail for more complex files. There are differences between screen readers in how they interpret PDF files, particularly forms. For example, checkboxes in a form may not be 'checkable', or may be identified as checked when they are not. Form fields may not be accessible at all. The main strength of PDF is its preservation of format for printing. The best solution for accessibility for everyone is to keep the PDF content simple and use the latest authoring software available.

Managing the accessibility of PDF files

Many UTAS sites use PDF, some containing many hundreds of files. It can be quite daunting wondering where to start. Look to review all files regularly, but start with the most used. Web Services can provide statistics to help you decide where to start.

Making new files

Does the information need to be in a PDF? If it does, present an alternative. Can it be done in HTML? The aim is to preserve the information for the user, not necessarily the appearance (particularly for people with visual impairments).

If the file will work best as PDF, you will need a PDF authoring tool to make some changes, or add some features in software such as WORD before you convert the document. Adobe Readers is only a reader so you will need an editor. The accessibility of PDF files has increased with later versions of software such as Adobe Acrobat Pro, so if possible, upgrade to the latest version of Acrobat Pro, which can be obtained through IT Services. The later versions of Acrobat Pro have a built-in accessibility checker, which will give you a report on the most serious issues.

The following tips and techniques rely on you having a PDF authoring tool.

Single A

Making PDF

If the PDF is the only source of information for a client who is parting with money or making an important decision such as enrolling in a course, provide an HTML alternative.

The Human Rights and Equal Opportunity Commission have provided an advisory note on PDF, to help you decide which is the best option. The Australian Government is also mandating compliance with WCAG 2.0.

Making the purpose of your PDF clear
File structure
Content
Images
Forms

Does the form need to be in PDF? HTML may be a better option. Contact Web & Learning Services to discuss any options.

However, to create more usable forms

Operating the PDF in a webpage

The UTAS Web Publishing Guidelines require that links to non-HTML files include the format and size in the link text, as this makes the link purpose clear

Double A

Making the PDF

If you have a scanned picture of text, this can be converted into text using Optical Character Recognition.

Making the purpose of your PDF clear
File structure
Operating the PDF in a webpage

No specific requirements

Triple A

Making the PDF

No specific requirements

Making the purpose of your PDF clear
Operating the PDF in a webpage

No specific requirements

About Office documents

All documents linked in web pages are covered by WCAG 2.0 guidelines. The more recent the version of your software, such as Microsoft WORD, the better will be the features that help you make the document accessible.

Making office documents

All content, such as headings, images, tables and forms and need to be accessible.

If the office document is the only source of information for a client who is parting with money or making an important decision such as enrolling in a course, provide an HTML alternative.

Using accessibility features in office software

The Accessible Digital Office Document Project has guidelines on making WORD, spreadsheets and presentations accessible, using the features of these packages.

Making the purpose of your document clear

Documents still need to follow the guidelines for writing for the web.

Operating documents in a webpage

The UTAS Web Publishing Guidelines require that links to non-HTML files include the format and size in the link text, as this makes the link purpose clear.

About live audio-only and accessibility

Live audio is any sound captured from a real-world event and transmitted without delay to a webpage. There may be a short delay to allow some censoring, but not enough to allow for significant editing. Making live audio accessible will benefit people who have a hearing disability.

Single A

Making the intent of your audio clear

Because an audio file is not text, it cannot be 'read' by a screen reader. Therefore, it must have a text alternative that serves the same purpose. This alternative must also be identified so people know it is non-text content. This alternative can be

Or, a brief description of the audio, or a descriptive label of the audio and:

Operating the audio in a webpage

People must be able to operate the audio by any input device. Therefore, just providing functionality for the mouse is not enough, although the mouse should be able to access any content on the page. The keyboard must be able to operate the all functionality of the audio including pausing and restarting, and must not trap the keyboard.

Don't enable autoplay, because the audio file will 'speak' over the top of the screen reader and sound confusing, but if sound is played automatically, the

Also,

Double A

Making the intent of your audio clear

Captions should be provided for live audio content, either open (always visible), or closed captions.

Operating the audio in a webpage

The controls to operate the audio should be accessible with a keyboard, and should be visible (highlighted) when they receive focus. Therefore it is best to keep it simple, so developers should keep the default 'focus' functionality of the browser, assistive technology or operating system.

Triple A

Making the intent of your audio clear

A text alternative can be provided by

About live audio with video and accessibility

Making live audio with video (multimedia) accessible can benefit people with movement, visual, hearing, cognitive or seizure-related disabilities.

Single A

Making the multimedia

Starting with 'shooting' with a camera or capturing video, make sure that:

Making the purpose of your multimedia clear

Because a multimedia file is not text, it cannot be 'read' by a screen reader. Therefore, it must have a text alternative that serves the same purpose. This alternative must also be identified so people know it is non-text content. This alternative can be

Or, a brief description of the multimedia and:

Operating the multimedia in a webpage

People must be able to operate the multimedia by any input device. Therefore, just providing functionality for the mouse is not enough, although the mouse should be able to access any content on the page. The keyboard must be able to operate the all functionality of the multimedia. Also

Double A

Making the multimedia

No specific requirements relating to pre-recorded multimedia production. Although if any text is included in the video, as screens or information added to precede the viewing of the multimedia, such as credits or advertisements

Making the purpose of your multimedia clear

Captions must be added to the audio in live multimedia to help people with hearing or cognitive impairments understand the content. They also help people understand content if the language of the captions is unfamiliar. Captions must be

  • Synchronised with the audio and video displaying information that applies to the timeline
  • Contain enough information to provide an alternative to the combined content of the video and audio
  • Operable by the user (if closed)

Captions can be

If the multimedia is clearly identified as a media equivalent to text content, captions are not required.

Operating the multimedia in a webpage

The controls to operate the multimedia should be accessible with a keyboard, and should be visible (highlighted) when they receive focus. Therefore it is best to keep it simple, so developers should keep the default 'focus' functionality of the browser, assistive technology or operating system.

Triple A

Making the multimedia
Making the purpose of your multimedia clear

About live video-only and accessibility

Live audio is any image information captured from a real-world event and transmitted without delay to a webpage. An example of live video may be a webcam of a nesting sea eagle.

Single A

Making the video

Starting with 'shooting' live action with a camera, make sure that

Making the purpose of your video clear to everyone

Because a video-only file is not text, it cannot be 'read' by a screen reader. Therefore, it must have a text alternative that serves the same purpose. This alternative must also be identified so people know it is non-text content. This alternative can be

Or, a brief description of the video, or a descriptive label of the video and:

Operating the video in a webpage

People must be able to operate the video by any input device. Therefore, just providing functionality for the mouse is not enough, although the mouse should be able to access any content on the page. The keyboard must be able to operate the all functionality of the video. Also,

Double A

Making the video

No specific requirements relating to live video production. Although if any images of text, as screens or information added to precede the viewing of the video, such as credits or advertisements

Operating the video in a webpage

The controls to operate the video should be accessible with a keyboard, and should be visible (highlighted) when they receive focus. Therefore it is best to keep it simple, so

Triple A

Making the video

About pre-recorded audio-only and accessibility

Making pre-recorded audio accessible can benefit people with hearing or cognitive disabilities, or for whom English is their second language.

Single A

Making the purpose of your audio file clear

There needs to be an alternative representation of audio-only content, unless the audio file is a media alternative to text and clearly labelled as such.

Because an audio file is not text, it cannot be 'read' by a screen reader. Therefore, it must have a text alternative that serves the same purpose. This alternative must also be identified so people know it is non-text content. This alternative can be

Or, a brief description of the audio, or a descriptive label of the audio and:

Operating the audio in a webpage

People must be able to operate the audio by any input device. Therefore, just providing functionality for the mouse is not enough, although the mouse should be able to access any content on the page. The keyboard must be able to operate the all functionality of the audio including pausing and restarting.

Don't enable autoplay, because the audio file will 'speak' over the top of the screen reader and sound confusing, but if sound is played automatically, the

Also,

Double A

Operating the audio in a webpage

The controls to operate the audio should be accessible with a keyboard, and should be visible (highlighted) when they receive focus. Therefore it is best to keep it simple, so

Triple A

Making the audio file

The foreground audio, for example, speech, must be 20 decibels louder that any background noise. This can be achieved during recording or by mixing the audio file to maximise the audibility of foreground sound

About pre-recorded audio with video and accessibility

Making pre-recorded audio with video (multimedia) accessible can benefit people with movement, visual, hearing, cognitive or seizure-related disabilities. Accessible video can also benefit people using certain technologies, which might not support video. For example, some mobile devices have limited FLASH support.

Single A

Making the multimedia

Starting with 'shooting' with a camera or capturing video via a software package such as Captivate, or creating an animation, make sure that:

Making the purpose of your multimedia clear

Because a video-only file is not text, it cannot be 'read' by a screen reader. Therefore, it must have a text alternative that serves the same purpose. This alternative must also be identified so people know it is non-text content. This alternative can be

Or, a brief description of the video, or a descriptive label of the video and:

Captions must be provided for all pre-recorded audio in multimedia to help people with hearing or cognitive impairments understand the content. They also help people understand content if the language of the captions is unfamiliar. Captions must be

  • Synchronised with the audio and video displaying information that applies to the timeline
  • Contain enough information to provide an alternative to the combined content of the video and audio
  • Operable by the user (if closed)

Captions can be

If the multimedia is clearly identified as a media equivalent to text content, captions are not required.

Specific techniques
Operating the multimedia in a webpage

People must be able to operate the multimedia by any input device. Therefore, just providing functionality for the mouse is not enough, although the mouse should be able to access any content on the page. The keyboard must be able to operate the all functionality of the multimedia

Also,

Double A

Making the multimedia

No specific requirements relating to pre-recorded multimedia production. Although if any text is included in the video, as screens or information added to precede the viewing of the multimedia, such as credits or advertisements

Operating the multimedia in a webpage

The controls to operate the multimedia should be accessible with a keyboard, and should be visible (highlighted) when they receive focus. Therefore it is best to keep it simple, so developers should keep the default 'focus' functionality of the browser, assistive technology or operating system.

Triple A

Making the multimedia
Making the purpose of your multimedia clear

About pre-recorded video-only and accessibility

Video or animation can be a stand-alone file, with or without audio or user interaction. Making pre-recorded video accessible can benefit people with visual, cognitive or seizure-related disabilities. Accessible video can also benefit people using certain technologies, which might not support video. For example, some mobile devices have limited FLASH support.

Single A

Making the video

Starting with 'shooting' with a camera or capturing video via a software package such as Captivate, or creating an animation, make sure that:

Making the purpose of your video clear

An alternative to video can be a document that describes the intent and purpose of the video, or an audio file that describes the video immediately before or after the video.

Because a video-only file is not text, it cannot be 'read' by a screen reader. Therefore, it must have a text alternative that serves the same purpose. This alternative must also be identified so people know it is non-text content. This alternative can be

Or, a brief description of the video, or a descriptive label of the video and:

Specific techniques
Operating the video in a webpage

People must be able to operate the video by any input device. Therefore, just providing functionality for the mouse is not enough, although the mouse should be able to access any content on the page. The keyboard must be able to operate the all functionality of the video

Also,

Double A

Making the video

No specific requirements relating to pre-recorded video production. Although if any text is included in the video, as screens or information added to precede the viewing of the video, such as credits or advertisements

Operating the video in a webpage

The controls to operate the video should be accessible with a keyboard, and should be visible (highlighted) when they receive focus. Therefore it is best to keep it simple, so

Triple A

Making the video
Making the purpose of your video clear

Tell the same 'story' in the video in a separate document.