Make your Websites more Accessible

Make sure that any information and services that you provide through your websites are accessible to customers with disabilities.

Web Content Accessibility Guidelines (WCAG) 2.0

The best way to make sure that your website is accessible to your customers is to make sure that everything on it has Level AA conformance with the Web Content Accessibility Guidelines (WCAG) 2.0. That includes:

• HTML pages
• PDF documents
• Word documents
• Audio
• Videos
• Games
• Maps.

Make sure your content writers, web designers, and web developers are very familiar with the WCAG 2.0. The WCAG 2.0 have advice and simple techniques to help you answer these questions:

• Have you provided a suitable text equivalent for everything that’s not text?
• Can customers get all the important information from your videos and audio, even if they can’t see them? Can customers get all the important information from your videos and audio, even if they can’t hear them?
• Did you structure your information, so that your customer’s technology can understand its structure?
• Is there enough colour contrast between the website’s written information and its background? Is there enough volume contrast between your website’s spoken information and its background noises?
• Can your customers use your website with only a keyboard?
• Does your website give your customers enough time to read and use your website?
• Have you made sure that nothing flashes quickly?
• Can your customers get around your website easily? Can your customersfind what they’re looking for on your website?
• Can your customers read your information easily, and can they understand it?
• Does your website work as your customers would expect it to work?
• Does your website help prevent your customers making mistakes? Does your website explain your customers’ mistakes clearly?
• Have you constructed your website properly, so that it will work on as many modern computers, phones, and browsers as possible?

Even if the company who design, develop, or host your website tell you that your website will be accessible, ask an expert (who’s not affiliated with the company) to check the website’s accessibility before signing off on it.

The National Disability Authority’s Centre for Excellence in Universal Design has web accessibility techniques for developers, designers, and content providers and editors.

Writing accessible content

Members of staff who write content for your website need to know how to use their word processing software, such as Microsoft Word, properly, to create properly structured, accessible information. Assistive technology helps people with disabilities to navigate and understand information. For example, “screen reader” software can read a document aloud to a person with a vision impairment. If that document contains properly structured headings, the screen reader can announce those too. That makes the document easier to understand. Your organisation’s webmaster cannot make everything accessible without help from other staff. Members of staff who write content for your website and want your webmaster to publish it to the web should:

• Write the document (or at least a summary of the document) in clear English
• Use the menus and toolbars in their word processing software, such as Microsoft Word, to specify:
  • headings
  • Lists
  • Tables
  • Language changes
  • Alternative text for anything that is not text, such as:
    • images
    • Charts
    • Videos
    • Audio
    • Presentations.

It’s important that the staff who write the content make it accessible, because other members of staff, such as the webmaster, probably won’t be familiar enough with the subject to know how to make sure it’s accessible. For example, a webmaster probably won’t know what alternative text to give to a chart in a document about water quality. Also, if the person who wrote the document make some text look like a heading by making it bigger or colouring it differently, the webmaster probably won’t know whether that text should be a main heading or some level of sub-heading.

Learn how to use word-processing software properly

Download these Word documents:

• Good document.doc
• Bad document.doc

In Good document.Doc:

1. Insert a table of contents (see “Create a table of contents automatically” if you haven’t done that before)
2. Add a new item to the middle of each list
3. Add a new row to the middle of the table.

Those steps are all quite easy, because the author of that document used the menus and toolbars to specify the headings, lists, and table. The word-processing software can identify each heading, list, table, and can treat them as such. For example, it can create a table of contents based on its understanding of the headings in the document. That document is accessible to customers with disabilities, because assistive technology software, such as a screen reader, will also be able to describe each item’s function to the customer.

In Bad document.Doc, try to:

1. Insert a table of contents
2. Add a new item to the middle of each list
3. Add a new row to the middle of the table.

Those steps are all quite time-consuming, because the author of that document didn’t use the menus and toolbars to specify the headings, lists, and table, and just used formatting to make text look like headings, lists and a table. The word-processing software cannot identify the “fake” headings, lists, and table, and cannot treat them as such. For example, it cannot create a table of contents based on the “fake” headings in the document. That document is not accessible to customers with disabilities, because assistive technology software, such as a screen reader, will not be able to describe each item’s function to the customer.

Notice that the bad document has no alternative text for its images and (depending on the software that you open it in) has squiggly red lines under its French phrase.

Making audio and video information accessible

WCAG 2.0’s guideline 1.2, Time-based Media, explains how to make audio and video information accessible to customers with disabilities. Here’s a quick summary of that guideline:

Recorded video (or slides) with audio

• Recorded video (or slides) with audio needs:
  • captions
  • Audio description in the video, or a transcription that details the visual information and the audio information
• Recorded video (or slides) with audio should have:
  • audio description
• Recorded video (or slides) with audio would, ideally, have:
  • Irish Sign Language
  • A version that has extra pauses in the video with extra audio description (if necessary)
  • Effective text descriptions

Recorded video (or slides) without audio

• Recorded video (or slides) without audio needs:
  • effective text descriptions or effective audio descriptions
• Recorded video (or slides) without audio would, ideally, have:
  • Effective text descriptions

Recorded audio without video

• Recorded audio (no video) needs:
  • Effective text descriptions

Live video

• Live video should have:
  • captions

Live audio

• Live audio would, ideally, have:
  • real time captioning (or the script if it is followed)

Note

When you provide either an Irish Sign Language version or a spoken version of some text purely to help customers who have trouble reading the text, you don’t need to provide audio description, captions, or text descriptions for those versions.

Related guidelines

Make sure that:

• There is little or no background noise or music during speech
• Customers don’t have to use a mouse
• Customers can pause, stop, or hide anything non-essential that starts automatically, is presented with other information, and moves or blinks
• Customers can pause, stop, hide, or change the speed of anything non-essential that updates itself, starts automatically, and is presented with other information
• Nothing flashes more than 3 times per second

Project planning

When you plan a project that will involve information being put on your website, allow enough time in the project for somebody to:

• Check the information’s accessibility
• Improve the information’s accessibility, if necessary.

Any electronic newsletters that you send should also have Level AA conformance with the Web Content Accessibility Guidelines (WCAG) 2.0. Even if the company who supply the service or templates say that the newsletters will be accessible, ask an expert who is not affiliated with that company to check that the newsletters are accessible before you sign off on them.

Usability testing

Ask users—including users with different disabilities—from your target audience to carry our tasks on your website, so that you can learn how usable your website it. You may need to change your website if users cannot use it easily. Your project’s budget and timeframe should allow for usability testing and subsequent changes.

Accessibility audits

Audit all of your websites regularly, to see whether they have Level AA conformance with the Web Content Accessibility Guidelines (WCAG) 2.0. There are a lot of factors involved in making a website accessible, so ask somebody—either a colleague or an external expert—who is familiar with WCAG 2.0 to audit your websites for you. The National Disability Authority have useful, detailed guidance about web accessibility auditing. After the audit, write a plan for improving the accessibility of your websites, including:

• Priorities
• Tasks
• Milestones
• Timeframes
• The name of the member of staff who is responsible for improving the accessibility of the websites.

You might not have enough resources to make every webpage on your website accessible. Prioritise your most popular webpages and webpages that are particularly relevant to customers with disabilities, and make them accessible. Then set a deadline, after which you will only publish information that is accessible.

If your website offers a service but you cannot make the relevant webpages accessible, make sure that customers can easily find an alternative way to access that service. For example, provide a phone number, email address and location, so that customers can avail of your service without using your website.

Web accessibility statements

Create a web accessibility statement for each website. You can use the National Disability Authority’s web accessibility statement template. Your web accessibility statement should state:

• Your commitment and approach to maintaining an accessible website
• The website’s conformance with official accessibility guidelines
• Areas for improvement and time-lines
• How customers can give you feedback about the website’s accessibility
• Accessibility features of the website.

Content management

You should have a system for making sure that new content on your websites will be accessible. This could be:

• A piece of software, called a Content Management System, that allows staff to insert, update, or delete content on a website, or
• A staff procedure for checking the accessibility of each piece of content before they publish it, or
• Both.

Content Management System software

Some Content Management System software is imperfect and prevents staff from producing fully accessible webpages. For example, some Content Management System software prevents users from adding extra structure or information that would make a webpage properly accessible. Other Content Management System software automatically adds extra structure or styling that decreases a webpage’s accessibility. If you are buying or developing a Content Management System, investigate how accessible the webpages that it produces will be, before you pay for it. Your Content Management System software should have Level AA conformance to the Authoring Tool Accessibility Guidelines (ATAG) 2.0.

Staff training and style guides

Staff who produce content should have training in:

• How to write for the web
• How to use clear English.

That applies to staff who:

• Write the information
• Approve the information
• Put the information on the website.

Make a style guide available to all relevant staff, so that they can refer to it when they write.

You could designate an expert in web accessibility to check each piece of information before staff publish it to the web, if necessary.