Answers to Exercises, Chapter 13

These are answers to the exercises in the 3rd edition of Digital Multimedia (published February 2009) only. Do not try to use them in conjunction with the 2nd edition.

Test Questions

1. The precise difficulties you might encounter following a repetitive strain injury will depend on the severity and exact nature of the injury. If it was the type of injury caused by excessive use of a mouse, you would be unable to use a pointing device, and so you could not point, click or drag. (If you are right-handed and try to use your left to operate the mouse, or vice versa, your pointing will be erratic, so you will still have problems with the mouse that you didn't experience before.) You would have to learn keyboard actions for operations such as selecting a sequence of text instead of dragging over it. Even after you had learned to use the keyboard for everything, certain features of interfaces designed without accessibility in mind would cause you problems. A more serious injury would prevent you from typing for more than a few minutes at a time, so you would be unable to enter any extended text using the keyboard.

   Web browsers allow users who cannot use a mouse to move between the controls and links on a page using the tab key. If a Web designer had not provided special "skip links" you might find, for example, that you had to tab through all the navbar links on every page before you could put the cursor in a form field to enter data. Any slider controls that could not be operated using arrow keys as a substitute for dragging the "thumb" would be impossible for you to use. Dragging scroll bars or turning a scroll wheel can be problematical for RSI sufferers, so long pages would present an obstacle to you. Any JavaScript event listeners (see Chapter 14) that responded to mouse clicks but not to any keyboard events could never be triggered. Any graphical interface that required you to point to something and used the coordinates of the cursor to determine what you were pointing at would be inaccessible to you.

   If you were unable to use the keyboard as well as the mouse, you would have extreme difficulty interacting with your computer at all. You would be reduced to a passive consumer of information presented to you, since you would not be able to do much more than click on links and buttons. If such a condition were to persist, you would have to use voice recognition software, which presents its own difficulties. In particular, although accuracy rates well in excess of 90% are achievable, this still leaves plenty of room for mistakes, which you would be constantly forced to correct.

2. The contention that testing five or so users is sufficient is based on the belief that all users are more or less the same. Accessibility is concerned with the problems faced by users who are suffering from some condition which interferes with their ability to use their computers by way of the usual interfaces. By definition, people with accessibility problems are not the same as people without them.

   Consider, for example, the question of colour vision. We know that the probability of a Caucasian male being red/green colour blind is 1 in 12. A simple statistical argument will show that there is only a 35% chance that a group of 5 randomly-chosen Caucasian males will include one who is colour blind. Thus, most of the time, even assuming we choose our test subjects from the group with the highest likelihood of suffering from this visual defect, testing 5 people will fail to identify any problems caused by colour blindness. Similar arguments apply to other types of disability, leading to the conclusion that it is necessary to identify potential accessibility problems and test specifically using people who may be likely to experience difficulties.

3. Recall that if markup is separated from presentation, the information about the document's structure is explicitly expressed in the markup, and not implicit in the particular way parts of the document are presented (for example, in large bold type). This means that these two aspects of the document can be processed independently. The structure is a property of the document's contents, and is required no matter how the content is presented to a user. The presentation depends on the particular way in which the document is being accessed.

   Structural markup thus contributes to making pages perceivable, because it allows them to be presented in different media, with appropriate presentation. In particular, it allows the structure of the document to be processed easily by a screen reader, which can then present it in a way that makes it easier for someone who cannot see the page to appreciate its structure, for example by extracting a list of headings, identifying links or by "speaking" emphasized passages with appropriate emphasis.

   Structural markup contributes to making pages operable, by making explicit the relationship between controls and their labels, so that controls can be identified by non-visual user agents, and by allowing controls to be described in terms of elements with a particular function, instead of as concrete regions of the screen.

   Structural markup contributes to making pages understandable, by providing elements to which metadata can be attached to aid comprehension. For example, the title attribute of the abbr element in XHTML can be used to provide the expanded form of the abbreviation that is the element's content. The lang attribute of any element can be used to specify the natural language of the element's content.

   Structural markup contributes to making pages robust because it captures the unchanging structure of the document, so that it can be presented effectively by new user agents and in unforeseen media. Structural markup must conform to relevant standards (e.g. XHTML must be valid) to contribute to robustness in this way.

4. There is, of course, plenty of scope for variety in the exact phrasing of the alt-text for any image.

   The alt-text of a photograph that is intended for looking at should consist of a short description of its content that is adequate to let someone who cannot see the image know what it represents. Here, "A small car ferry approaching a slipway" might be appropriate, for example, although it is not the only way of describing this photograph (and in fact the slipway is not visible in the picture). Among other things, the presence of such a description would allow someone to understand a textual reference to "the picture of the ferry" as referring to this photograph. Context may also play an important part when writing alt-text, however. On a Web site devoted to all the car ferries serving the Western Isles of Scotland, for example, the alt-text we just suggested might be applicable to many images on the same page, which would be both repetitive and confusing. In this case it would be necessary to distinguish between them. In such a case the alt-text for this photograph would actually be something like "The Tobermory to Ardnamurchan ferry approaching the Kilchoan slipway"

   For images that convey information, the alt-text should summarize the information. It is probably useful to include some introductory phrase to indicate that the information is presented visually on the page. In this case, we might have "A diagram showing that in interlaced video alternate lines belong to the odd and even fields."

5. Colour vision defects do not interfere with people's ability to perceive brightness, so the easiest way to ensure that a Web site will not cause difficulties for anybody who is colour blind is by making sure that there is sufficient tonal contrast between elements that must be distinguishable. In particular, there must be adequate contrast between text and its background.

   You can test whether a Web page will be readable by someone with defective colour vision by viewing it using a colour blindness simulator, if you have access to one. Alternatively, just switch your monitor to greyscale. (Asking a colour-blind person is a useful thing to do, if you can, but remember that there is more than one type of colour defect.)

6. If you need to explain this to your client, it would not do much good to base your appeal on aesthetic grounds. Instead, you should tell them about photosensitive seizure disorders, and explain that rapidly flashing content can cause people who suffer from such disorders to have seizures resembling epileptic fits, which can require hospitalization and may even cause death. You should also mention that flashing buttons will have a distracting effect, which will detract from the page's content for all visitors to the page, and may cause confusion and possibly distress in people with some sorts of cognitive disorder. If this is not enough to convince the client, point out that legislation in most countries requires them to conform to accessibility criteria which effectively rule out the use of blinking elements.

7. The most obvious accessibility problem resulting from the use of images as navbar items is that the content of the images – which presumably tells a sighted visitor where the links lead – is not available to screen readers, so visitors who cannot see will not be able to find out from the image what the link is for. This problem is easily remedied, though, by making sure that each image that serves as a link is provided with alt-text (in the form of an alt attribute) which provides a clear and unambiguous alternative label for the link.

   It is not so easy to adapt image links for people with low vision, or for those who have trouble reading small print. Such people can increase the font size in their browser to make type easier to read, but this does not affect images. All the main browsers now provide a "page zoom" function, which increases the size of everything on the page, including images, but zooming a whole page is not always a good idea – it usually causes the width to increase which may mean that horizontal scrolling is needed to read each line of text. Furthermore, Web browsers usually do a poor job of resampling images, so text in an image that has been enlarged may become blurry.

   The best way of avoiding such problems is to use ordinary text for links. If it is essential to a design that the links appear in some particular font or using styling that cannot be achieved in CSS as it is currently implemented, you can use tricks to hide the text and show an image using CSS, so that – if necessary – users can turn off CSS and see the textual links without styling.

8. A good choice for the link text would be something like 'Read more about X', where X was a brief summary of the article's content. Alternatively, you could repeat the article's title, and add 'continued...', although this is not quite so perspicuous. What you must avoid is using exactly the same expression, such as 'More...' as the text for every link, because screen readers may create a list of links to enable a user to scan all the links without reading the full text of the page. This means that it must be clear from the link text in isolation roughly what each link points to. A collection of a dozen links all of which say 'More...' offers no clues as to which might be worth following and is therefore worthless out of context.
9. As we explained in the answer to question 1, people who cannot use a pointing device must tab through all the links in a navbar before they can get the cursor into a form control or a link. Similarly, people using screen readers must listen to all the links in the navbar before they can hear the page's actual content – and this will be repeated on every single page. By providing a "skip link", you make it possible for users to jump over these links if they want to and move the cursor straight to the controls on the page, or allow their screen reader to start the real page content straight away. (Note that many screen readers provide a facility for jumping straight to the first level 1 heading, which makes skip links redundant if you always provide such a heading for every page, but it seems that many users prefer the explicit skip links.)

Discussion Topics: Hints and Tips

1. Unlike the earlier WCAG 1.0 guidelines, which were almost entirely devoted to standard Web technologies, WCAG 2.0 attempts to provide guidelines which are applicable to any multimedia technologies, so you could start by seeing whether Flash conforms to these guidelines. More accurately, does Flash provide adequate means for designers to create accessible movies?

   Flash is more accessible on Windows than on other platforms, so you must consider whether it is justifiable only to consider the accessibility features provided on Windows.

2. Nobody argues that everyone who uploads personal video clips to YouTube should provide captions and transcripts, but some people insist that YouTube have a responsibility to do so. Do you agree, or should such material simply be exempt from accessibility considerations? If you think it should be exempt, what are your reasons?
3. The W3C note on How People with Disabilities Use the Web may provide a useful starting point for this discussion. If possible, try using the Web yourself by means of a screen reader, without looking at the screen.

Practical Tasks: Hints and Tips

1. This is not a simple task. The WCAG 2.0 Techniques provide you with over 300 things to check, although not all of them will be applicable. There are services which offer to perform accessibility checks automatically, but if you read the documents you will see that many criteria require intelligent interpretation by people and cannot be verified automatically. Try to be as rigorous as possible – choose a small and simple site if you find a large one too much work.
2. This is a challenge.