|Scottish Sensory Centre|
|Home > Resources > VI > SSC documents|
Adapting Video for VI Learners
How to make HTML accessible
Now for a slight diversion from video clips themselves into the design of easy-access HTML pages. You might want to create HTML for Web delivery of your videos, or (as in our case) as a way of making your material available across platforms on CD-ROM. Poor web page design can ruin all your care in making your video clips accessible.This page is aimed at folk with experience of web page design using HTML. If all this is new to you, you'll want to read some background first, and a helpful web site is that run by the Trace Research & Development Center.
HTML has grown from a simple system with little graphical content and almost no layout control into an extendible monster with embeddable animations, video, speech and music, complex tables, forms and frames. Things which used to be a boon to partially sighted users - like HTML's inherent ability to display content in different font sizes and for different monitor sizes - were exactly the features which irritated graphics designers. Annoyed by the lack of control over final page layout, they demanded more and more positioning features. The upshot is that page designers can now get exuberant in their designs, to the point where a visually impaired reader can't tell information content from eye candy, and has trouble locating navigation hot-spots amongst the welter of colour. When such pages are rendered as text for a screen reader, the result can be impossible for its blind user. (The same disregard for the strengths of the HTML medium in favour of emulating formats like paper also causes problems to sighted web users whose screens don't fit the designers' aspirations: hand-held browsers will make this worse, so the design problems which exercise us here will re-emerge in other forums).
We took these issues into account when we built these pages. Our aim was to balance accessibility with aesthetically pleasing - or at least not ugly - design. Compared with some more avant-garde web sites and the output from multimedia packages our pages look a bit conservative, but they play to the strengths of those with special access needs. To make the pages, we started out with some agreed design rules and guidelines which all our writers used, along with templates to avoid duplication of effort. Here are the rules we set for ourselves.
Most browsers can be set up to increase default font size to suit a partially sighted user, and can readjust the layout of page contents to make best use of the monitor to hand. But only if you play to HTML's strengths. It is very easy to mess this up by putting fixed-width items into your content, or by making layout demands through tables, frames and columns which take up screen space and therefore limit the user's ability to tweak. Offending fixed-width items include maps, fancy text rendered as graphics, and injudicious use of the 'WIDTH='. We use old-standard single column layouts wherever possible, and make width hints for the likes of rulers relative rather than absolute (e.g. specifying percentage rather than pixels).
Any non-text element in HTML can have an alternate text rendering. This is used not only by readers using combinations of text browsers and speech synthesisers, but also by any browser user who has turned off the downloading of pictures for speed. 'ALT=' can be both a benefit and a curse: imagine having to sit through a speech synthesiser repetitiously spelling out that someone has used a 'green-brown small left arrow' for a bullet enhancement. Here are our rules, derived in part from the Trace guidelines.
Where you use graphics for effect, especially bullets, set their alternatives to 'ALT=" "'. Note the space between the double quotes - the result is invisible to those text users it would annoy. Where a picture carries content, either describe within the ALT itself, or put a very brief description in the ALT, and set up an adjacent link to a detailed description: mark the link '(D)'. The '(D)' mark is becoming widely recognised as a cue for a long description for pictures or video.
Where you can't avoid a graphically intensive page or one with complex layout, consider a complete text alternative page. Signal it early in your graphic page (we use the convention 'Text alternative available' in the title and on the first line of the graphic page). If there are many of these, you should consider mirroring your complete set of pages with text alternates.
At the time of writing, all of these pose problems for screen readers and plain-text browsers. We have tended to use tables and frames sparingly where they help layout, and avoided columns. The worst and most abused offender is the frame, which is a pity because it offers such a nice way of keeping a navigation map in view whilst reading content. However, a text browser user often only sees one frame, so we've avoided over-relying on them in this version of our pages.
Instead, consider setting up a navigation bar at both top and bottom of the page, minimising the space taken where you can. (This page is set up like that: our advice pack restricts page length and navigation depth instead, and uses a static frame for access to top level index pages).
Keep checking though: the HTML specifiers, browser makers, and screen reader designers are making huge changes, and accessibility is getting to be higher on the agenda.
It's easy to get lost in hyperspace, especially if you can't easily see clues hinting at where you are. Establish a simple metaphor for the whole set of pages, and stick to it. Our metaphor is book-like, having chapters, sections - and - topics, and references. We avoid where possible the kind of links which turn this hierarchy into a web. Consider using different background colours for each chapter (taking care over colour choices), and a consistent left justified width-tolerant logo within each chapter, section, and reference. If you have enough space, you can use the logos for visual navigation button cues, by repeating miniatures of the pictures along with background colours as hints in offpage navigation icons. In this page, we stick to a regular 'top and tail' navigation bar, which helps us reduce clutter in the printed version.
The title for a web page is the part which appears in a special place in the browser layout, usually in the Window Title. The title for this page is 'Making HTML accessible'. Most sighted people don't really take much notice of it, but it has special significance for those using speech synthesisers to read screens: this is the first part of any page which appears, and can really help speed up navigation. This is especially true when you are returning to the main flow from a several levels deep diversion. If the title is not informative, the reader have to wait until some distinguishing text is read out before they can know if they are back to the right place, and this might be quite far down a page.
Consider choosing colours within a given section so as to give a subliminal reminder of where the reader is. Reflect these in any maps. When you choose colours, take into account the need for good contrast, and try to avoid problematic colour combinations. In our pages, even though to do so reduced our background colour options, we have also tried to avoid changing the colour of the hot-link words, because it is otherwise easy to miss links or to believe because of the unfamiliar colour that you have read them when you haven't. When choosing distinctive backgrounds, you should avoid over-textured or picture backdrops. It is worth checking how your chosen scheme works on grey scale monitors; on different platforms and browsers; and on monitors with different colour depths. What looks subtle on your own machine might be very difficult to read or plain ugly on another.
People are good at learning and using landmarks. We use consistent graphics at the tops of our pages both to relieve the text and to help establish and sustain the navigation metaphor. We repeat miniatures of our pictures along with background colours as hints in offpage navigation icons. Such pictures act as headings, so that their 'ALT=' codes should offer the same organising cues to non-sighted readers as the pictures do for sighted readers.
If you include video clips, bear in mind that you need to support three classes of viewer. Some people will be able to view the video directly (they have the right plugin and the visual acuity to use it). Some will not have the plugin, either because their equipment isn't up to it, or because they find video distracting. For these folk you should provide a still picture with content which shows as best you can the essence of the missing clip. (You can trigger this with a <NOEMBED> </NOEMBED> tag in some browsers). Finally, there will be those using just text browsers. The same principle applies as for graphics - you provide a (D) cue, and behind it a description of the video. (We actually work the other way round, devising the text first as a cut-down script, and then making the video to match it).
Give both textual and visual hints as to where you are leading the reader. In this example page we use a navigation bar at the top and bottom. Since blind user's landmarks are the titles, we try to help by incorporating the title of the target page in the text version of each link. And we consistently use the word 'back' and the backward arrow to remind people when they are returning to a previous page rather than extending their search.
Again, try to distinguish these from offpage links, both textually and visually. Use a 'Contents' table for forward links, placing 'up to page top' links at ends of topics within the page. The up arrow is used consistently as a visual cue. (We also try to avoid overlong pages).
Identifying links can be difficult for a visually impaired reader, especially if the browser doesn't alter the cursor as it passes over a link. We suggest using some active buttons, which with the right browser software animate just slightly. This can be distracting, so the best way is to animate only as the mouse is passed over them. You can build these using Active-X or by scripting: we like Java-script because of its cross platform power. Be sure that your scripts are hidden from non-Java-Scriptable browsers, though.
These can be useful, but like all graphical cues they need to be supplemented by text equivalents. This is one reason for using a hierarchical metaphor like a tree or a book: the map is more easily visualised as an indented set of text links than would be a web, or the kind of 'town' metaphor sometimes used in commercial sites.