A history lesson: where did the website accessibility guidelines come from and what’s in them?
1995: The first web accessibility guidelines were compiled by Gregg Vanderheiden shortly after the 1995 Chicago WWW II Conference.
1998: University of Wisconsin–Madison compiled the Unified Web Site Accessibility Guidelines.
1999: they formed the basis for WCAG 1.0.
WCAG 1.0. were focused on HTML and web pages.
Each with a priority level: A, AA. AAA.
A Compliance: the guidelines must be satisfied otherwise it will be impossible for one or more groups to access the Web content.
AA Compliance: should be satisfied, otherwise some groups will find it difficult to access the Web content.
AAA Compliance: may be satisfied: to make it easier for some groups to access the Web content.
14 WCAG 1 Guidelines
Guideline 1: Provide equivalent alternatives to auditory and visual content.
Guideline 2: Don’t rely on colour alone.
Guideline 3: Use markup and style sheets, and do so properly.
Guideline 4: Clarify natural language usage.
Guideline 5: Create tables that transform gracefully.
Guideline 6: Ensure that pages featuring new technologies transform gracefully.
Guideline 7: Ensure user control of time-sensitive content changes.
Guideline 8: Ensure direct accessibility of embedded user interfaces.
Guideline 9: Design for device independence.
Guideline 10: Use interim solutions.
Guideline 11: Use W3C technologies and guidelines.
Guideline 12: Provide context and orientation information.
Guideline 13: Provide clear navigation mechanisms.
Guideline 14: Ensure that documents are clear and simple.
WCAG 2 – Published 2008
Not just websites, but also PDF, Google Docs, Spreadsheets, e-Books… and other ‘digital assets’.
WCAG 2.1 – Published 2018
WCAG 2.1 does not deprecate or supersede WCAG 2.0.
The differences between WCAG 2.0 and 2.1 are mostly related to the use of tablets and mobile devices.
They are designed to make content more accessible to a wider range of people, including accommodations for blindness and low vision.
WCAG 2.1 Based on 4 Principles
What do the principles mean?
WCAG speak: information and user interface components must be presentable to users in ways they can perceive.
Jim speak: the site visitor must be able to recognise that the content exists. For example, by being able to see it, hear it or touch it.
WCAG speak: user interface components and navigation must be operable.
Jim speak: the site visitor must be able to navigate around the site and use the features and functions presented.
WCAG speak: information and the operation of user interfaces must be understandable.
Jim speak: not only should visitors be able to recognise the existence of the content and be able to interact with it, but they must also be able to understand it.
WCAG speak: content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Jim speak: it must be possible to access the content using everything from a text-only web browser to the latest Firefox browser. And everything in between, including screen readers and all the different brands and versions of browsers now available.
Each Principle Has A Set Of Guidelines
1. Perceivable: the guidelines relate to:
Text alternatives for non-text content.
Captions and other alternatives for multimedia.
Content can be presented in different ways, including by assistive technologies, without losing meaning.
Operable: the guideline Relate To:
Ensuring functionality is available for keyboard users.
Giving users enough time to read and use content.
Avoiding content that causes seizures or physical reactions.
Help users navigate and find content.
Making it easier to use inputs other than by keyboard.
Understandable: the guideline Relate To:
Make text readable and understandable.
Make content appear and operate in predictable ways.
Help users avoid and correct mistakes.
Robust: the guideline Relate To:
Maximising compatibility with current and future user tools.
For example, by using valid code.
For Each Principle
There are guidelines – these are the basic goals that authors should work toward in order to make content more accessible.
And For Each Guideline
Ther are ‘testable success criteria’.
Three levels of conformance are defined as: A (lowest), AA, and AAA (highest).
Techniques and examples are provided for meeting those criteria.
All ‘success criteria’ apply to mobile platforms as well as desktop platforms.
However, the techniques sections does not yet fully cover mobile techniques.
This document I outlines how to make your MS Word or MS Office document accessible.
Run the accessibility checker
The first thing you should do is to open run the built-in accessibility checker. Find it via Tools/Check Accessibility or from the tools ribbon at Review/Check Accessibility.
When you run the checker it will open a set of tabs on the right-hand side of the page. The text field within the accessibility tab shows any issues found.
Underneath the list of issues, Word provides a short explanations and suggested fixes.
Accessibility issues commonly found include, images with missing alternative text, images that are not inline, and contrast issues. The accessibility checker is a great tool but it does not check everything. So, you should also check that all headings, lists, paragraphs and so on are formatted using styles.
Add document structure by formatting text using styles
Using styles adds semantic structure to your page content.
A clear, hierarchical document structure will help screen reader users summarise and understand document content; for example, they can extract a list of headings or links – and jump quickly between them. If headings are not marked up properly (i.e if you just made the text a bit bigger and bold) assistive technologies will not recognise them as headings – therefore making it more difficult or certain users to navigate the document.
The structure will be retained when the document is exported as a PDF.
Use the navigation pane to check how your heading are organised
To view the sidebar click on the View tab, then click the ‘Navigation Pane’ box in the show group. You will be able to navigate through your document quickly by clicking on the headings. This gives you an overview of your document structure and a sense of how screen reader users summarise content and navigate via headings.
Remove superfluous spacing
If you need to create space above and below paragraphs, use the ‘Spacing Before’ and ‘Spacing After’ paragraph properties, rather than hitting the Enter key. If you had previously added spaces manually (i.e. by hitting the return key) go through you document to remove it.
Styles should be used to set the formatting for:
blocks of text
URLs and email addresses
Tables of contents
Turn on automatic formatting
If you are not adding styles, ensure that the preference for automatic formatting is set – this will assist in the creation of lists, internet, email addresses and so on.
Setup automatic formatting:
Select Tools>Autocorrect Options
Click the ‘Autoformat AsYou Type’ tab and check the following:
• Automatic bulleted lists
• Automatic numbered lists
• Internet and network paths with hyperlinks
• Define styles based on formatting
For documents that are expected to be converted to PDF, XML or RTF – be more deliberate in your application of styles (e.g. Heading 1, Heading 2, lists and so on).
Add alternative text to images
The latest version of Microsoft Word adds Alt Text automatically when you insert a new image; it does this based on the file name of the image.
Right-click on the image, select ‘Edit Alt Text’ and change the default text. Keep the alt text short but describe the image adequately.
When adding decorative images, tick the ‘Mark as decorative’ box instead of adding a text description.
How to write alt text descriptions
Keep your descriptions short, say between 2 and 7 words. Granted, you will sometimes need it to be longer, and that’s fine, but keeping text descriptions as concise as possible is always a good idea.
In terms of the wording; consider the context; think about why the photo or image is being used; what was the writer trying to add or clarify by using that photograph or image? For example, if it’s just an image of the author, the alt text can be just their name and their job title. If it’s a photo of a craft item on a sales page, you should describe the item; ‘A packet of multicoloured glass beads’. Always be thinking, ‘why is this image here?’ ‘What’s it for?’ And you will come up with an appropriate text description.
Never add, ‘image of’ or ‘photo of’ prior to your description. Screen readers announce images by saying the word, ‘Image:’ If you add ‘Image of…’ to your text description, you have added redundant text.
Adding alternative text to complex images
Alt text should be short, but what do you do if the image contains a lot of complex information? In that case, add an appropriate short description, but also add a longer description in the body of the article, close to the image.
Word offers five different text wrapping styles: inline with text, square, tight, behind text, and in front of text.
Only inline retains the graphics’ position relative to the document’s text. The other wrapping styles are treated as floating objects.
For accessibility graphics should be inserted inline with the text. This will ensure that they retain their proper reading order. You may have to adjust your layout if you have previously used a different wrapping style.
An explanation for using inline with text
Floating objects appear on a different ‘Drawing Layer’ from the surrounding content. It’s a bit like the having your main text sitting under a piece of glass and placing you images and text boxes on the glass itself, i.e. they float about the text. Screen readers can find it difficult to deal with these floating objects and text boxes.
For example, JAWs, can recognise the floating objects, but it has problems placing them in the correct sequence with surrounding content.
So, avoid using floating objects and text boxes. Instead put them ‘inline with text’. This places them on the same layer as the surrounding text.
The downside to this change, is that it will effect the layout of your page. You will have less flexibility in terms of where you place objects such as pull-quotes or images.
One additional issues is that floating objects do not translate well to other formats, e.g. conversion to PDF.
Check colour contrast
If you are using coloured text in your document check that the colour has sufficient contrast with the background. The WCAG provide guidelines for minimum colour contrasts as a ratio. 1:1 means white on white. 21:1 means black on white. For standard text the ratio should be at least 4.5:1 for and for large text (18pt and above) it should be at least 3:1
To check colour contrast select your text, click on the coloured text icon then click ‘More Colours’ and copy the hex value for the colour (on Mac the hex value can be found on the colour sliders tab). I use the contrast checker tool provided by the WebAim website to check the contrast between the text colour and background colour. That tells me if the contrast is above or below the required ratio to pass WCAG (Web Content Accessibility Guidelines) guidelines. The WCAG guidelines are as relevant to offline documents as they are to online documents.
Ensure links are accessible
Ensure that links use meaningful text. Don’t use ‘click here’ and don’t use a URL as the link text. A screen reader will read out URLs a letter at a time, which will be very irritating. It also makes it difficult to for them to know where a link goes.
To make a link descriptive, right click and choose Edit Link (or Edit Hyperlink – depending on what version of Word you are using). Change the link text to something meaningful.
Alternatively type your text in first, then add the link. To add the link right-click and choose ‘Link’. Add the URL.
If the document is for printing you can add the URL, in brackets, after the link.
Create accessible tables
Simple tables can be made accessible within MS Word, however, when it comes to trying to make more complex tables accessible Word has some limitations. For example, with more complex tables, you often need to know both the table row heading and table column heading to understand the content of a cell. MS Word is unable to add that level of detail; therefore, screen readers cannot give users the information they need to understand the contents of each cell.
More complex table can however be made accessible within Adobe PDFs and within HTML pages.
Create a table of contents
A table of contents is another way to add structure to your document. Put your cursor at the point where you want to add the table of contents, the go to the References tab then click the ‘Table of Contents’ icon. Choose the style you prefer and click that style. This will insert the table of contents.
Identify document language
From the Applications menu select Tools/Language and define the default language of your document. You can also set a different language for different sections of your document by selecting the text and then choosing Tools/Language to update for the selected text.
Note: if you are converting the document to PDF, you will need to redefine the language after conversion as the language does not survive the conversion process.
Convert to an accessible PDF
Once you have ensured that you Word document is accessible you want to ensure that all the work you have done is preserved when you convert it into a PDF. Export the file to PDF and ensure that ‘Document structure tags for accessibility’ has been checked within the export preferences pane.
Creating PDF from Apple Mac Word
If you are using Word on Mac choose Save As, choose PDF as the File Format option form the pull-down menu and then click the check box next to the option, “Best for electronic distribution and accessibility”.
Do not ‘print to PDF as this will not preserve the documents accessibility features.
Older versions of Word
Office 2007 and 2003 require a plug-in. The Adobe PDFMaker Plugin ships with Adobe Acrobat Pro and appears as an Adobe toolbar and menu item in Office. With the plug-in installed, use the Adobe toolbar or the Adobe menu item to Save As PDF. By resulting PDF preserves the document’s accessibility features.
Accessibility features were not included in Word until Office 2011, and options to save to tagged PDF were not included until Office 2016.
Add document summary information
After you have created your PDF document, you should always add summary information. Document summary information is used by search engines to create the text for the search results page.
Select File>Document Properties and add a document title and summary.
Document Accessibility Checklist
Documents will be optimised for accessibility if the following guidelines have followed:
Use simple and straightforward layouts.
Use styles to format headings, paragraphs, lists and other page elements.
Avoid unnecessary ornamentation – such as background images, text overlaying graphics, overlapping figures and so on.
Don’t use the return key to add spaces between paragraphs, headings and other items on your pages. Instead add the appropriate amount of space using styles.
Ensure good contrast between text and background colours. You can obtain the RGB values from Words text colour palette and then use an online contrast checker such as the one provided by the Level Access website. Minimum contrast ratio for standard text is 4.5:1 for and for large text it is 3:1.
Avoid using text boxes. Text boxes are know to create difficulties for people using adaptive technologies such as screen readers . Avoid creating watermarks (as these require text boxes).
Do not paste graphics into a text box – as they are considered floating objects in the page.
To create a table, use the Insert Table Command, or Draw Table tool. Don’t use tabs and spaces to create tables. Keep tables simple; avoid split cells, merged cells and nested tables. Ensure you add structure to the table by specifying the header row.
When creating columns use the Columns command, i.e. don’t use tabs to simulate columns. Format/Column and adjust as required. For maximum accessibility avoid using multiple columns.
Use common sans serif fonts: for example, Arial and Helvetica.
Provide alternative text for all images and graphs. Newer version of Word will automatically add default text for an image, which you can then edit.
Avoid using overlapping text and graphics. Overlapping text can result in text being unreadable or garbled by screen readers. It also makes it more difficult to read for people with visual impairments and cognitive conditions such as dyslexia.
Ensure links use meaningful text; don’t use URLs as links. Screen reader users will find URLs difficult to understand – as it reads them out one letter at time. The user will not necessarily know where the link goes. Don’t use ‘click here’ as screen reader users are likely to be reading the link out of context.
Add a document summary via File>Document Properties.
Run the accessibility checker before converting to PDF.
When converting to PDF use the export option and click the “Best for electronic distribution and accessibility” checkbox.
Insert graphics inline with the text, and ensure images and photos are close to the content they refer to.
Create a table of contents. A table of contents is another way to add structure to your document.
Remove superfluous spacing. Often if documents were originally created without using styles the author will have used the return key to add space between different page elements. These returns should be removed.
PDFs are generally created from source documents; often that is an MS Word document – which has to be made accessible before being exported (or in the Mac version, saved) as a PDF.
In this short article I outline the steps you need to take to ensure your PDFs are accessible after you have gone through the conversion process. The information in this article assumes that you have already read my article on how to create an accessible Word Document (outlined in my ‘Creating Accessible Word Documents’ guide).
A summary: how to create an accessible Word document
In summary to make your Word document accessible you must:
Use styles to add semantic structure, i.e. to create headings, paragraphs, lists and so on.
Ensure your images have appropriate alt descriptions.
Ensure that link text makes sense when read out of context and that you avoid using URLs as link text.
Remove superfluous spacing.
Avoid using text boxes and floating images; instead use use ‘inline with text’ for images.
Ensure that you have good contrast between text and background colours.
Create and format your tables correctly to ensure that they are accessible.
How to create an accessible PDF
Once you have ensured that you Word document is accessible you are ready to convert it to PDF What you are now trying to do is to ensure that all the work you have done is preserved during the conversion process.
Luckily it is easy, as all you have to do is, export the file to PDF and ensure that ‘Document structure tags for accessibility’ has been checked within the export preferences pane. Don’t print to PDF – that will not preserve the work you have done in your Word document.
Once you have exported the file to PDF there are still a few things that you need to do to complete the process. You have to carry these steps out within Adobe Acrobat Pro DC.
Check that PDF tab order is set to use ‘Use Document Structure’. Show thumbnails, select all thumbnails then right-click (Ctrl click on Mac) and on the resulting menu choose Page Properties.
Click ‘Tab Order’ tab and check click ‘Use Document Structure’.
Give the document a title via File / Properties / Description.
And finally, run the built-in accessibility checker. Via, View/Tools/ Accessibility/Open/Accessibility Check.
Accessible PDFs are tagged documents
The major difference between an accessible PDF and an inaccessible PDF is that the accessible version will be tagged, i.e. each element of the document will have a tag. In simple terms, that means each element has a text label saying what type of element It is, i.e. is it a paragraph, a heading, an image a bulleted list and so on.
It is these tags that allow accessibility technologies to read and organise the content in ways that make it accessible. For example, a blind person can use a screen reader, such as JAWS to list all of the headings in the document and jump to the section they are interested in – only because the headings in the document are identified as headings – using tags. If there were no tags in the PDF document JAWS would not be able o recognise headings from all of the other text in the document.
Developing An Accessible Searchable Directory For Evenbreak
Published: June 6, 2017
I’d like to tell you about a project that I have recently been working on called, Evenbreak. They provide such a fantastic service that I feel I need to spread the word.
The aim of Evenbreak is to help disabled people and inclusive employers find each other. Employers upload jobs and disabled people register their employment interests and upload their CV’s. Evenbreak was set up by Jane Hatton as a social enterprise and it is one of those rare projects that is run by and for disabled people.
“With Evenbreak, inclusive employers can be confident that they will attract additional disabled candidates that they may not find through any other recruitment channels. Disabled jobseekers can be confident that employers who have chosen to place their vacancies on this site are serious about looking beyond their disabilities to identify what skills they have to offer.”
“Evenbreak is run by disabled people, for disabled people. As a social enterprise we are keen to promote a positive image of disabled people in employment, and any surplus income will fund positive publicity campaigns promoting the benefits of employing disabled people, to balance out some of the current negative, and inaccurate, portrayals of disabled people in the media.”
Jane Hatton got in touch to ask if I could develop a new companion website that would provide employers with “confidence around the practical issues around inclusion and accessibility in the work place.” The new website would be a searchable resource of content related to inclusive employment. It would be a members only website.
Although the visual design of the site was already existed (i.e. the existing Evenbreak site), my job was to create all the functional aspects. I.e. all of the membership requirements (registration, secure login, members access levels and so on), a way to add, edit, tag and display the content, a way to hide content from non-members and alternative ways to search the content. Although most of the content would be hidden there would need to be a way to show some ‘teaser’ content to encourage new members to join.
Jane already had a huge amount of content to add to the new site, including over 300 documents on every imaginable subject related to employing disabled people. All of this content needed to be stored, categorised and tagged appropriately to ensue it could be found. All the forms needed to be accessible and easy to use.
Within the constraints of fulfilling the aims for the site I was given a free rein in terms of the technologies used and the approach taken.
As the budget was small I decided to create the site using WordPress and where possible to create the functionality using existing technologies and modifications of existing plugins. The budget did not stretch to creating a custom application from scratch.
The other constraint, apart from money, was time. It all had to be functioning by the time of a pre-arranged meeting that Jane had set up to show the service to a room of potential corporate clients. The meeting date was set for 6 weeks from the point Jane got in touch.
Given the complexity of the project this was an incredibly tight time-frame. However, I did manage to provide a fully functioning website by the time of the meeting. The site was still located on my development server rather than on the evenbreak server at that point but nonetheless it was a bit of a miracle to get it done so quickly. The new site had to include a huge number of document and rsources so that the breadth of content could be demonstrated during the presentation.
I was delighted when Jane provide the following ‘testimonial’ which is so good it would get my in to heaven. 🙂
“Jim came highly recommended from experts in web accessibility, and so we engaged him to take over the Evenbreak site for us. However, Evenbreak is an online job board, and therefore a very complex site, with facilities for employers to pay for and post their roles, candidates to register and search for jobs, and many other complexities. Jim took all of this in his stride, having to understand the thinking of the previous developers very quickly. In addition to all of this, we asked Jim to design a bespoke portal for us, with very little lead-in time, which he worked on tirelessly, ensuring it was up to a fantastic standard for when we launched it.”
“I have vast confidence in Jim’s abilities, and am frankly quite amazed that he met all of our very demanding requirements so quickly and so professionally! We will be asking him to entirely re-build our site using his talents to build in both accessibility and responsiveness from the start. Many developers claim to have knowledge in these areas, but in my experience, very few if any have the practical knowledge and pragmatic approach that Jim has. I would advise any organisation looking for a high quality accessible website to talk to Jim. You won’t be disappointed (heąs also incredibly easy to work with).” Founder/Director, Evenbreak.
Give me a shout if you have an idea for a development project you would like to see realised. Tel: 07810 098119
Making non-text elements, particularly images, accessible is fundamental to accessible web design; even if you attended to this issue alone, you would make a big impact on the accessibility of your site.
All non-text elements must have labels (i.e. add the alt attribute); the alt attribute is a requirement for both HTML 4 and XHTML W3C standards based documents.
Text labels should serve the same purpose as the visual or auditory content it describes or replaces.
When all non-text elements are labelled by using alt attributes this ensures that:
The text labels can be read out by screen readers
People browsing with images off will still be able read the text
Search engines can index the text – helping the page to be found by potential visitors.
Text equivalents are needed for the following:
graphical representations of text
images used as list bullets
In these notes I will concentrate on how to add labels to images. However, the same principles described here will apply to other non-text elements.
Using the ‘alt’ attribute
The alt attribute is used to add a text label to non-text content.
The following example is from the photography gallery at the Glasgow West End website
<img src=”http://www.glasgowwestend.co.uk/imageuploads/uniave203bwsmall.jpg” alt=”Photo: University Avenue.” height=”206″ width=”319″ >
In the example above I have given a very short description of the photograph, using alt=”Photo: University Avenue.”. You will notice I have also included the additional text ‘Photo:’ – In the discussion part of this document I will explain my reasoning behind adding this additional text.
Should the text label describe the image, or describe the function of the image?
When trying to decide on the appropriate text to use: think, ‘what is this image for?”
Is it just a photograph as part of an image gallery?
Is it a photograph of a person?
Is it a submit button for a form?
Is it a navigation bar?
Is it a graph?
Is it a decorative image, spacer gif, or horizontal rule?
Labels for image gallery photographs, and photographs of people
For a photograph as part of an image gallery, a short description of the photo, like the example above, is appropriate.
Similarly with a photo of a person I would use the alt attribute to provide the persons name:
<img src=”http://www.glasgowwestend.co.uk/images/jimbyrne.jpg” height=”116″ width=”76″ alt=”Photo: Jim Byrne”>
There are other HTML attributes, namely the title and longdesc attributes, you can use to add further information – we will have a look at these shortly.
How to decide what to write in your descriptions?
In the case of a photograph or a decorative image – if I said, “what does the picture/image look like” and you had to sum it up in a only a few words, your reply to me is what you write as your alt attribute. Alt attributes should be short and to-the-point. More verbose descriptions can be provided by the use of the title and longdesc attributes, if necessary.
An image as a button
If the image is a button or link – then the label should describe the function or destination of the button or link. Usually the alt text is what you would have written if the link had just been text. For example: if you have a button and text written on it says, ‘About MCU’ , then your alt attribute value will be ‘About MCU’.
An example from the BBC website; the button they use on their search form is an image:
Both the image and the alt text say the same thing: ‘Search’.
In this example the alt attribute text describes the function of the image – it is not a description of what the image looks like.
When images are used as links, as they are on many navigation bars, the alt attribute should describe the destination of the link – in this case the function is to tell you about the contents of the page linked to. Here is another example from the BBC website:
In the above example the text in the alt atribute simply describes the page you are linking to, in this case the weather page.
How long should alt text be?
There are no technical limits to the length of alt attributes – but keep them short. Joe Clark in ‘Building Accessible Websites’ suggests limiting alt text to 1,024 characters – which seems a bit too long to me.
Use your own judgement when deciding how long your alt text should be, however, consider the following possible problems.
Problems with long alt attribute text.
Alt text if too long can be unreadable if the text is wider than the width of the image it describes. If you browse the web with images off you will come across many examples. Here is an example from part of the ‘Apple Computers’ home page:
As you can see, none of the above descriptions are readable, because the text in each case stretches beyond the width of the original image size.
Using the title, and longdesc attributes
Both the title, and longdesc attributes can be used to provide additional information for a non-text element.
the title attribute
The W3C explains the function of the title attribute:
“This attribute offers advisory information about the element for which it is set”
Not terribly clear, but the general idea is simple enough; use the title to provide some additional information over and above that used in the alt attribute. In the following example I have added the title attribute to the image tag used to display the photograph of University Avenue,
<img src=”http://www.glasgowwestend.co.uk/imageuploads/uniave203bwsmall.jpg” alt=”Photo: University Avenue.” height=”206″ width=”319″ title=”A photograph of University Avenue in the West End of Glasgow, taken on a bright winter morning” >
On many web browsers, when titles are used, a pop up speech bubble, or strip of text, appears on the screen when the pointer hovers over the picture (i.e. ‘tool tips’).
Adding longer descriptions – use the longdesc attribute
Unfortunately the longdesc attribute is not supported by current browsers, but it is still considered good practice to add it when appropriate to accommodate future browser revisions.
Use of the longdesc provides the opportunity to give a longer description or explanation than can be provide by either the alt or title attribute. The longdesc points to a full html page containing the description, e.g.
<img src=”http://www.glasgowwestend.co.uk/imageuploads/uniave203bwsmall.jpg” alt=”Photo: University Avenue.” longdesc=”uniavenue.html”>
The file, ‘uniavenue.html’ is a standard HTML page containing the text describing the look or the function of the image. The longdesc attribute would be appropriate for describing information contained within a graph or similar complex image.
Examples by type of image
Describe the most representative or final frame of the animation.
arrows and bullets
Use HTML entities, or left or right arrows or -> <-
Bullets use alt=”*” or use entitites: alt =”*” or alt=”&ast'”.
If you would like to use images as bullets in a list specify them in a style sheet:
ul [list-style: url(urlofimage)]
If you feel you really need to create a bulleted list without style sheets use star the character or the appropriate entities in the alt attribute.
<IMG SRC=”bullet.gif” ALT=”* “>
Company and Organisation Logos
The alt attribute should contain the name of the organisation or the company – do not describe the logo. There is no need to add the word ‘logo’ onto the organisation name. If the logo is also a link to the home page of the site, you can add the word ‘ – home to the end of the organisation name.
When a clickable button is followed by a text link, and clicking both leads to the same page, leave the alt tag empty for the button. Otherwise screen readers will read the same text twice.
Spacer images or decorative images with no ‘content’
Many web designers make use of what is called the ‘single pixel gif trick’, i.e. they use single pixel gifs resized appropriately to help create page layouts.
Always ensure that you add alt attributes to spacer or purely decorative images. Use the space character in the alt attribute, or leave the alt attribute empty:
<IMG src=”spacer.gif” hspace=100 vspace=10 alt=” “>
This will ensure that screen readers ignore these images.
Other non-text elements
When using the FRAME element, the title attribute, and/or the longdesc attribute, should always be added:
<FRAME src=”body.htm” longdesc=”maindesc.htm” title=”Main content.”>
Add the alt attribute to audio files:
<A HREF=”hello.wav”> <IMG SRC=”helloaudio.gif” ALT=”Sound file: Hello. “> The sound of hello.
Adding labels to images is a not always a simple matter
The value of an alt attribute for a non-text element is, for a certain group of users, one of the most contentious issues in the area of accessible Web design.
After publishing article on how to create accessible HTML tables (called ‘Table Manners’) I got an e-mail from Jouni Heikniemi pointing out what he saw as a problem with my use of the alt attribute for the photographs on the page. To summarise – he suggested I should use empty alt attributes for my pictures, (i.e. no labels) because the content of the pictures did not add to his understanding of the page.
The argument he put forward was that for people using screen readers, the introduction of a text description of the photographs just ‘got in the way’ and the content of the label could lead to confusion.
My take on it is that many of the disagreements spring from the following beliefs,
Alt attributes are all about making pages accessible to blind or visually impaired users.
Alt attributes are for the benefit of everyone, including those who surf with images off, but like to retain the choice to click to download the images they are interested in – and need the alt attribute to help them make that decision.
The problem is that implementation of alt attributes will be different for each of these groups. Let’s take the example of the picture on some of the MCU pages. If you have looked at any pages on the site you will see that I have used photographs at the top of some of the pages. Sometimes these photographs will add to the understanding and meaning of the page, and sometimes they are merely decorative, or acting as section breaks.
For those images that do not directly add to the meaning of the page, the consensus seems to be that the first group above, i.e. those who believe that alt tags are purely for the benefit of blind users, will best be served by making the image invisible, by putting a space character, or no content, in the alt attribute. Doing it this way means that phrases like, ‘picture of a flower’ will not suddenly be read out (out of context) by a screen reader such as Jaws. This approach does, of course, take away the choice to know about all the images available on the page.
The above problem does not occur for those surfing with images off, because the text label occupies its own physical space on the page, and will generally be ignored by a user reading the main text. For visual readers, there is no chance of the image, or its text label, getting ‘in the way’ of the ‘real’ text. The visual user gets the benefit of knowing what the image is, even if it is only decorative.
The ideal situation may be one where information about decorative images is always given, and users can choose to make the text descriptions invisible or visible. For people using screen readers, the ability to turn the labels of decorative images off, while still having access to the labels of navigation bars or form buttons would be a good solution.
This implies that we need to be able to provide more ‘meta’ information about the images that appear on Web pages. How else would the client know what is a decorative and what is not a decorative image?
As a solution to the possible problems created by my use of alt attributes on the ‘Table Manners’ article I have added the ‘meta’ text ‘Decorative image:’ followed by a description of the image.
The photos, although mostly decorative are used on occasion to add a comment, or provide a humourous or analogous connections with the text. These are not intended to be obvious and are not essential for understanding of the text. An example would be the stop sign’ that is the first image on the ‘Table Manners’ article, in long hand I could be saying – “Stop! you shouldn’t be using tables for layout”, or I might not. The reader may, or may not, make a connection. By providing some text descriptions of the photo this ‘function’ is still retained.
Making this into a general rule, I now add a short descriptive label to all of my image labels. If I am adding a alt attribute to the image tag of a photograph I add ‘photo:’, if it is a decorative with useful content I put ‘image:’. However, I make decisions whether to add a text label at all, on a ‘case by case’ basis, depending on the context. On my image gallery in the Glasgow West End website I aways add image descriptions, in an article about a technical topic, such as one about making web text accessible, for decorative photos I leave the alt attribute empty if the content of the photo or image does not add to the understanding of the page.