Skip to Content

Disabil-IT? Part 2: Software for Students With Dyslexia, and Software Design Issues

Printer-friendly versionPrinter-friendly versionSend to friendSend to friend

Isobel Stark presents the second part of her report on the Disabil-IT? Conference. In this article, software for students with dyslexia is looked at, and issues to bear in mind when designing software which may be used by students with disabilities are listed.

Software for Students with dyslexia

Ted Pottage of the British Dyslexia Association [1] and Ian Litterick of iANSYST gave a presentation on software for dyslexic students. They emphasised the facts that design for accessibility also is design for the able-bodied, for example what is good for a wheelchair is good for a pushchair; technology is only as good as the person using it and the use they get out of it; to always look for a low tech solution of possible (it is cheaper if nothing else) and that dyslexia, which often has associated short term memory problems, has only just been recognised in the past decade.

Expectation in dyslexic undergraduates are now quite high as the new undergraduates have come up through a schools system which allows the use of word processors in exams etc. Computers are important for dyslexic students: the use of IT can help in teaching (if the software is good enough); it can support and help develop skills thus providing a crutch for those who need it to get stronger; it can liberate and motivate.

Ted Pottage then demonstrated the IBM VoiceType [2], a piece of voice recognition software that costs less than £80 and runs under Windows 95. VoiceType corrects its interpretation of individual spoken words by comparison of context with preceeding and succeeding words. The user can correct the interpretation at the end of sections or paragraphs. The drawback of the package is that you cannot dictate straight into the package, but via a word processor and copy.

Other programs that help dyslexics include TextHelp which guesses words as you type them and presents a list of words from which the user selects the correct word. Planning software can also often help as dyslexics are frequently better at visualising rather than linear planning and such software can help them plan visually and then turn that plan into a linear outline format.

Design Issues

Mike Wald, LSU, Southampton [3], gave a general overview of design issues to bear in mind when designing software which may be used by students with disabilities. These guidelines are very similar to general good design guidelines which all good software designers should use. The guidelines, some of which are listed below, should become available from the TLTP Advisory Committee [4] in the near future.

Whatever software is designed support for the user and the robustness of the program are pivot to the final design of the program. Other important factors, but by no means all, include :

Benefits of Designing Accessible Courseware
  • little or no increase in cost,
  • grater users base,
  • good design benefits everyone,
  • more pleasing to international markets,
  • meets legislation demands.
Colour
The Apple Organisation design booklet always states that colour should be redundant - all software should work as well on monchrome as colour monitors.
Use of colour should also take into account cultural differences, for example red signifies left on the sea, not right as used in one program.
Control and Navigation
  • appropriate flexible range of input methods,
  • appropriate flexible range of output methods,
  • keyboard and mouse input (keyboard is 9 times as quick),
  • access to all parts of the program,
  • conceptual maps,
  • consistency of interface,
  • simplicity of interface,
  • levels of menus,
  • be aware of icons and metaphors (for example the dustbin on Mac's),
  • shortcuts for experienced users,
  • exit facilities,
  • undo facilities,
  • feedback to user (where am I? what's happening?),
  • confirmation of lethal actions,
  • mixed word/picture icons are more meaningful.
Learning
A program may be magnificent in all ways, but if it doesn't help the user learn what they need to know, it is rather useless!
  • identify user needs,
  • what are users' pre-experience, skills, knowledge,
  • task analysis,
  • prototype the program,
  • iterative design,
  • assess the quality and quantify of the learning experience.
Psychology factors to consider
  • enjoyment,
  • motivation,
  • minimise memorisation,
  • consistent placement of information,
  • consistent and simple interface design,
  • grouping of information.
Text
As with the other factors listed, this is not the definitive list, but does contain many major points.
  • keep screens uncluttered,
  • layout can help readability,
  • 12pt serif or 10pt sans serif have proved most readable,
  • only 2 typefaces on the screen at once,
  • don't use underlining,
  • use bold, italics and colour for emphasis,
  • upper case is slower to read,
  • left justified is easier to read than fully justified,
  • small character size is more readable (but not too small!),
  • short line length (8-10 words).
Conttrol and Navigation for Accessibility
  • keyboard controls,
  • time responses,
  • control and stability of on-screen messages,
  • consistent use of keyboard.
Sound for Accessibility
  • volume control is essential,
  • all information given through sound should also be in visual form,
  • added visuals shouldn't distract the hearing user,
  • text representation of aural information should be synchronised with visual information etc.
Text for Accessibility
  • no bit-mapped text images,
  • customisable font style and size.
HTML for Accessibility
  • use alt text for all images,
  • concise text descriptive caption of all images, audio files or videos,
  • description of images should be as close to the image as possible,
  • alternative provision of text selection to graphic selection link,
  • minimise the number of links on one line,
  • vertical lists of link preferable to horizontal,
  • punctuation should be used to end sentences, list items etc.,
  • only use informative words as links (don't use 'click here!),
  • large documents should be provided in smaller sections,
  • text only versions of highly graphical resources should be provided,
  • only use standard HTML,
  • keep layouts simple and straightforward (for example columns can be difficult for screen readers).

Best of all evaluate and do trials involving people with disabilities!

References

  1. British Dyslexia Association
    http://www.bda-dyslexia.org.uk/
  2. IBM Special Needs Solutions
    http://www.austin.ibm.com/sns/
  3. La Sainte Union College of Higher Education
    http://www.lsu.soton.ac.uk
  4. Technology in Learning and Teaching Programme (TLTP)
    http://www.tltp.ac.uk/tltp/

Author Details

Isobel Stark,
Information Officer,
UKOLN,
Email: i.a.stark@ukoln.ac.uk
Phone: 01225 323343
Address: UKOLN, University of Bath, Bath, BA2 7AY

Date published: 
19 March 1997

This article has been published under copyright; please see our access terms and copyright guidance regarding use of content from this article. See also our explanations of how to cite Ariadne articles for examples of bibliographic format.

How to cite this article

Isobel Stark. "Disabil-IT? Part 2: Software for Students With Dyslexia, and Software Design Issues". March 1997, Ariadne Issue 8 http://www.ariadne.ac.uk/issue8/disability-two/


article | about seo