Accessibility in Educational Website Design: Print versionContents
OverviewDelivery of education online, in place of or as a supplement to traditional delivery methods, has become imperative for many institutions. Accessibility of online media is a major issue in ensuring equity, effectiveness and efficiency of web delivery, and this raises issues in several areas, including economic, technological, cultural and physical considerations. This website is a resource for educators and web designers to become familiar with accessibility issues in online education in general, and website production in particular. It also provides technical advice for website production, and links to resources for further exploration. Macromedia Dreamweaver and WebCT are the principal formats used for educational website production at UNSW, and this site particularly explores the use of these tools, but the principles discussed have wide application to website production in general, regardless of specific software. The site may be worked through as a tutorial on accessibility. Simply work through the menu items in a linear fashion. A discussion forum and self-test activities are included (sorry, UNSW community only). Or, if you are looking for information on a particular topic, please go to the site map. I have also provided links to many other resources available on the web - a full list of resources can be found in the Links & tools section of this site. A printable version of this site is available here. Additional information developed at UNSW is available in the document Guidelines for Accessible Online Courses (link from EDTeC website) What is Accessibility?'Accessibility' of computer technology has been recognised as an issue for the disabled user, but it is more appropriate to view users as 'differently-abled', with any individual at any time experiencing a range of limitations affecting access. Emerging technologies bring with them new opportunities for communication and education - they also bring new barriers to accessibility, particularly for visually and physically disabled users. Opportunities include:
Barriers include:
Barriers of distance, economics and culture may also represent a 'disability' in the context of accessing online education. Many of these issues may not be under the direct control of education developers, however it is important to be aware of the broader issues, and to be able to advise administrators appropriately. Digital Divide Network addresses the gap between those people and communities who can make effective use of information technology and those who cannot: http://www.digitaldividenetwork.org/content/sections/index.cfm
Accessibility issues - economicIssues:
Solutions:
Accessibility issues - social & culturalIssues:
Solutions:
Accessibility issues - technologicalChallenge:
Solutions:
Accessibility issues - physicalChallenges:
Solutions:
Course designPedagogical, technical, content design and student support issues The same principles that apply generally to the development of flexible education - the offering of a range of options to suit the widest range of learner needs - apply to the development of online courseware. A key element in offering flexible options for access is in the provision of alternatives or equivalents:
Alternatives should, wherever possible, provide an 'equivalent' experience to each user, that is 'of equal value. Pedagogical issues
These issues are effectively presented in a paper by Robert Luke of the Adaptive
Technology Resource Centre, University of Toronto which discusses the relationship
between pedagogical and technological accessibility in online education: Technical issues
Content design
Support
Accessible web designBasic web design rules apply egardless of the target audience for your site. Clarity of navigation and content, speed of download and easy access for the user to what they need are priorities. Web design should ideally be 'transparent': the design is a tool for the user to access information and functions, not an element in itself. Jakob Nielsen's basic 'usability' heuristics are applicable, particularly in an educational context where effectiveness, efficiency and accessibility are all essential. Also worth considering are his articles Top ten mistakes in Web design (May 96) and Top ten new mistakes of Web design (May 99), which proscribe the use of such elements as frames and multimedia elements (eg Flash) unless identifed as essential elements which will improve the usability of the site. These guidelines relate to general usability, and may not be applicable to all circumstances, particularly in an educational environment which has some different requirements to the general web environment. They do, however, present a useful checklist of elements that should be very carefully considered before using. Special requirements for disabled accessibility are a substantial additional issue, and Nielsen recommends (http://www.useit.com/alertbox/990613.html) that web developers follow the Web Accessibility Initiative Standard (WAI) developed in conjuction with the World Wide Web Consortium (W3C). The WAI group has developed a set of basic guidelines for web content accessibility (http://www.w3.org/TR/WAI-WEBCONTENT/). This has been extrapolated into a prioritised checklist of design rules, with 17 high-priority rules (for major accessibility issues), 33 medium priority rules (for moderate accessibility issues) and 16 lower-priority rules (which have a minor effect on accessibility). However, any amount of guidelines cannot replace the 'web sense' which is developed by exploring the web, investigating adaptive technologies, and finding out through discussion with disabled users what their needs are. Specific accessibility issues are addressed in the following pages: Content & navigation, HTML, Interactive & other media, WebCT accessibility issues and Validation Content & navigationThe first consideration is for the organisation of content and navigation, with consistency the guiding principle. ContentIn a 1996 article (http://www.useit.com/alertbox/9606.html), Nielsen recommends that content should be organised in an 'inverted pyramid' structure - main points and conclusions readily accessible before complex elaborations of information . This relates to the educational principles espoused in Reigeluth's 'elaboration theory', which recommends the initial presentation of an 'epitome', to be followed by increasingly detailed 'elaboration' of subject matter. While linear pathways through the subject matter may still be appropriate in many cases, structuring of content to permit alternative pathways will enhance the flexibility of learning, and utilise a major strength of online delivery. Content formatting recommendations include:
Guidelines for Accessible Online Courses (link from EDTeC website) discusses organising content for online education. NavigationThe following guidelines will ensure that navigation is available to all users:
HTMLMany aspects of basic HTML coding require accessibility considerations, including text formatting, links, colours, images, imagemaps and tables. HTML 4.0, although not yet fully supported by all browsers, provides some significant accessibility improvements. Most of these are simple to create or apply using Dreamweaver or other web editors, while some elements require tweaking of the code for full accessibility. Go to Using Dreamweaver for issues particularly relating to that software. A tutorial on creating accessible sites using FrontPage is available at: http://www.webaim.org/howto/frontpage.php Go to the next page for more advanced HTML functions - forms, frames, DHTML and dynamic web pages. Text formattingCSS (cascading style sheets) CSS permits users to set their browser to override author styles, allowing users to adjust font size, colour etc to enhance legibility. CSS also supports 'aural style sheets', which specify how a document will sound when rendered as speech. The CSS data should preferably be included in the page information rather than in a separate document. CSS is, however, accessible only by more recent browsers, and even then the implementation is not consistent (Netscape 4.x has particular problems). The W3C Checklist recommends that documents should be organised so that they will still be accessible if style sheets are turned off or not supported. See http://css.nu/pointers/bugs.html for details of some documented bugs in particular browsers when using some CSS functions. CSS stylesheets can be created in Dreamweaver - Guidelines for Accessible Online Courses (link from EDTeC website) shows how. An excellent overview on the use of CSS is at: http://www.zeldman.com/askdrweb/index.html. Fonts Size - Font face - Logical rather than physical formatting tags - Some previously standard HTML elements are now 'deprecated', in that they have been replaced with more useful alternatives. It is advisable to avoid using deprecated tags. W3C advises:
In Dreamweaver, text styles (such as 'strong') which are not available as a button in the properties window may be accessed from the 'text' menu. See HTML:HTML 4.0, below, for more information about deprecated elements. Do not use text to represent graphical information LinksUse default link colours Be explicit in linked text Make links keyboard accessible Allow skipping of links ColoursUse adequate contrast between text and background colours The use of 'websafe' colours The use of colour to differentiate information (as in table cells) should be avoided, as it will not translate to a text-only or text-to-speech browser. This chart shows how web colours appear to colourblind viewers, or go to http://www.vischeck.com to check individual graphics or web pages. ImagesUse of graphics should be minimised All images should be accompanied by descriptive 'ALT' tags. Graphics used for design and layout purposes that are decorative or spacer graphics should be accompanied by ALT tags which are empty or contain a single space (eg <ALT=""> or <ALT=" ">), which allows screen readers to skip over the graphic. An empty tag can be difficult to apply in a WYSIWYG editor, so a single space may be the easiest to apply, with the disadvantage that 'tool tips' in MS Explorer will then display an empty box when the cursor rests on the graphic, which may be distracting. The use of style sheets for layout can minimise the necessity for using spacer graphics, and this is recommended by W3C, however layout styles ('layers' in Dreamweaver) do not yet behave consistently between browsers, with notoriously poor support in Netscape 4.x, so the use of spacer graphics and layout tables is likely to be prevalent for some time yet. Guidelines for Accessible Online Courses (link from EDTeC website) shows how to apply ALT text to an image using Dreamweaver. ImagemapsWhere image-maps are used they should always be client-side Go to http://www.webaim.org/howto/graphics2a for more information about 'ALT' tags, descriptions and imagemaps. TablesWhen using tables for presentation of tabular data rather than for layout
purposes: HTML 4.0 also allows you to explicitly link header information to columns and rows using the "headers" attribute of the <TD> and <TH> elements. This needs to be done in the code, it is not supported by Dreamweaver or other WYSIWYG editors. For more in formation on how to do this, see: http://www.webaim.org/tutorials/tables. When using tables for layout purposes: More information can be found at http://www.webaim.org/howto/tables. Guidelines for Accessible Online Courses (link from EDTeC website) shows how to add a header tag to cells using Dreamweaver. If you use tables, test them in a text-only browser. HTML4.0HTML 4.0, developed and recommended by WAI/W3C, provides many accessibility benefits over HTML 3. These include the use of CSS (see 'HTML: Text formatting') and additional options for alternate content, such as:
A full description of HTML4.0 elements which improve accessibility can be found at http://www.w3.org/WAI/References/HTML4-access. HTML 4.0 'deprecates' some HTML elements - that is they have been outdated by new elements with improved functionality. Here is a list of new, deprecated and outdated elements. Perhaps the most significant of these is the deprecation of the FONT tag in favour of using style sheets to set font attributes. HTML 4.0 is supported by the most recent versions of major browsers (Jul 2001), but if you wish your site to be accessible to older browser software, it should not be dependent on HTML 4.0 elements. Your web pages should specify HTML 4.0 format for the purposes of validation (see 'Formatting your Dreamweaver template' for more info), however as not all HTML 4.0 elements are yet supported by all browsers, this is not foolproof in determining accessibility. For a fully detailed description of HTML and accessibility, see the WAI document 'HTML Techniques for Web Content Accessibility' (http://www.w3.org/TR/WCAG10-HTML-TECHS/). Advanced HTMLMore complex html functions with accessibility implications, include forms, frames, HTML 4.0, dynamic HTML and dynamic web pages (web applications). Use of these elements should be carefully considered and, in some cases, eliminated or minimised. Forms Forms should be simple and straightforward in their layout, and controls should
be adjacent to their relevant labels. HTML markup can be used to associate the
controls explicitly with their labels. Text boxes in forms should have default content that suggests the kind of information the user should enter. Users with screen readers or unable to use a mouse can use the TAB key to access form elements - use the 'tabindex' attribute to define the order of elements. The following list shows elements that support the tabindex attribute:
See http://www.webaim.org/tutorials/device#9.4 for more information on using 'tabindex'. Here are example form controls with accessibility features added: http://www.webaim.org/howto/forms4 The HTML 4.0 'accesskey' attribute supports specification of direct keyboard
access to form controls. For information on creating accessible forms, see http://www.webaim.org/howto/forms. FramesMinimise use of frames to avoid confusion One major disadvantage of frames is the difficulties that arise with bookmarking and referring URLs (the URL is the web address of the page, which in the case of a frames-based site is generally the main frameset, or entry page). Setting up individual framesets for each page is one way to avoid this, although this goes some way towards negating the convenience of using frames. When using a development application such as WebCT, the use of frames is intrinsic to the application, and is not optional. (See WebCT accessibility issues). Dynamic HTMLUnfortunately, most DHTML (client-side scripted HTML, which is usually accomplished with Javascript) is totally inaccessible to the keyboard. This means that individuals who are dependent upon the keyboard, whether it be because of muscular limitations or visual disabilities, are unable to use the DHTML functions on your pages. A commonly used function is the onMouseover command. If an onMouseover (or similar) element does not contain any important information (e.g. the script causes a button to “glow”), then there is no consequence for accessibility. If this scripted event reveals important information, such as a drop-down menu, then a keyboard-accessible alternative is required. Using 'logical' (eg onSelect) rather than 'device-dependent' (eg onMouseOver) event handlers in scripts is recommended. See http://www.webaim.org/tutorials/device#9.3 for more information. Dynamically generated webpagesPages that are generated dynamically from databases require user-input via form fields. See Forms (above) for information about accessible form design. The pages generated should have the same accessibility checks as regular HTML. Dynamic pages also present problems in archiving for offline-browsing. Using DreamweaverAccessible web content may be created using practically any authoring tool. Unfortunately, many of the more useful accessibility features of HTML are not programmed directly into the Dreamweaver interface (or any of the other commonly used HTML editors). However there are some things that you can do in Dreamweaver without having to go to the source code. Formatting the default Dreamweaver templateThe default Dreamweaver template needs some adjustment for HTML4.0 compatibility. You can follow the instructions here: http://www.webaim.org/howto/dreamweaver#h21. or save this page to replace the existing template (in Dreamweaver>Configuration>Templates). From WebAIM, here is a summary list of the features that either are or aren't available in the Dreamweaver graphical interface (WYSIWYG interface: What You See Is What You Get).
How to implement each of the above items is explained in some detail at: http://www.webaim.org/howto/dreamweaver. This page also describes how to enhance the accessibility features of Dreamweaver. A similar tutorial on creating accessible sites using FrontPage is at: http://www.webaim.org/howto/frontpage.php Interactive & other mediaAccessibility issues abound in the use of embedded media and plug-ins. The media types discussed here are: PDF, Powerpoint, Flash & Shockwave and video & audio. Problems with Plug-insProblems for users with disabilities include inaccessibility of content within the object displayed by the plug-in, and interference or incompatibility with the assistive technology that is being used. Although many plug-in technologies do not make it possible to create fully accessible content, it is important for developers to make the content as accessible as possible. Guidelines developed by WebAIM can increase the accessibility of plug-in content - these guidelines are similar to those relating to development of all types of web content, and are, in summary:
See http://www.webaim.org/Articles/plugins.php for a full description of guidelines. Adobe Acrobat PDF (Portable document format) is a common format for distributing documents electronically. It has the advantage of preserving formatting and embedding fonts, as well as being non-editable, and is accessed with a freely distributed plugin, Acrobat Reader. Acrobat Reader 5.0 allows screen readers to access appropriately formatted PDF documents. However, not all users have this version installed, and not all PDF documents are text-based (some are scanned in as graphics), which renders them useless to many assistive technologies. It is recommended that an accessible HTML version be made available as an alternative to PDF, which may require that images scanned as graphics be processed using OCR (optical character recognition) software for conversion to text. Adobe Capture (http://www.adobe.com/products/acrcapture/main.html) has the ability to convert image files to tagged PDF files, also see Adobe's website for more information on accessibility features: http://access.adobe.com/information.html). Guidelines for Accessible Online Courses (link from EDTeC website) shows how to make PDF documents accessible. PowerPoint PresentationsPowerPoint has the ability to export as HTML, but these documents are problematic for assistive technologies. To make a PowerPoint slide show fully accessible requires their conversion to HTML using Word or a web-authoring tool. Guidelines for Accessible Online Courses (link from EDTeC website) shows how to make Powerpoint documents accessible. WebAIM suggests the use of this "Save as accessible HTML" Powerpoint plug-in, with the proviso that: "This plug-in is still under development, so there is room for improvement": http://www.rehab.uiuc.edu/ppt/. See http://www.webaim.org/howto/powerpoint for more information on accessible conversion of Powerpoint files. Flash/ShockwaveMacromedia Flash and Director are popular applications for the production of interactive and animated elements, allowing compact and complex interactivity that is extremely technically accessible (works on any platform with the freely provided Flash or Shockwave player plugin). They do however present accessibility issues for disabled users, with all content (text, video, audio) embedded in the 'object' and not accessible to assistive software. See http://www.macromedia.com/macromedia/accessibility/features/flash.html for Flash features that support accessibility. Macromedia also provides design guidelines (http://www.macromedia.com/software/flash/productinfo/accessibility/guidelines/) and developer techniques (http://www.macromedia.com/software/flash/productinfo/accessibility/flash_techniques/) which go some way towards addressing inherent accessibility problems. Also see HTML4.0 for the use of the OBJECT element to specify alternative content. Video/audioFor audio or video content, it is necessary to provide some equivalent information for those who cannot access the visual or auditory content. The provision of images and sounds is beneficial to many students who may have difficulty reading text, so that information displayed visually can make content more accessible. To ensure accessibility of multimedia elements consider the following points:
Media technologies behave differently, depending on whether the media object is embedded in the web page or accessed as a standalone element. See: 'To Embed or Not To Embed - A Comparison of Media Player Technologies': (http://www.webaim.org/Articles/embeddedmp.php) which compares Windows Media Player, QuickTime and RealMedia Player. Options for accessibility: The main formats that can be used to produce acccessible media for the web are: The Synchronized Multimedia Integration Language (SMIL) specification
was created to allow developers to integrate independent media objects into a
synchronized multimedia presentation. SMIL affords authors the means to make their
multimedia presentations accessible by incorporating captions, audio descriptions,
and subtitles which the user can toggle on or off and which are synchronized with
the other media elements. The SMIL specification is maintained and updated by
the W3C. QuickTime (developed by Apple) is a powerful, yet easy to use, tool
for authoring and viewing content. QuickTime supports SMIL 1.0, but also allows
developers to easily add caption, subtitle, and audio description tracks in its
native format. SAMI (Synchronized Accessible Media Interchange) is Microsoft's specification
for adding captions to online media. It supports a variety of features for captioning,
but is used only by the Windows Media Player. RealNetworks uses SMIL 1.0 in order to make its media accessible. RealText,
RealPix, RealAudio, and RealVideo can all be referenced from a SMIL file and synchronized
with one another. XHTML+SMIL (formerly known as HMTL+TIME) More information on these formats are available at the National Center for Accessible Media - Resource Center for Developers of Rich Media (http://ncam.wgbh.org/richmedia/index.html). A variety of tools and tutorials are available at: http://ncam.wgbh.org/richmedia/learning.html. Media Access Generator (MAGpie) - NCAM's free software for adding captions to QT, SMIL and SAMI media files is available at: http://ncam.wgbh.org/webaccess/magpie/. WebCT accessibility issuesGeneral guidelines for accessible design are no different within the WebCT environment. Specific problems have arisen because of default elements in the WebCT interface over which the designer has little or no control, such as the lack of ALT tags for images, and the use of frames. Recent versions of WebCT address some of these problems, including the provision of a specific Help Section on Accessibility and WebCT. For information on accessibility contained in the WebCT Help, click on 'Help' in the top WebCT menu bar, go to the Help Index, and choose Accessibility, the first item in the index. Note that you must be the designer of the course to view this help info. Guidelines for Accessible Online Courses (link from EDTeC website) discusses organising content using WebCT. See the following sections of the WebCT website for how WebCT is addressing accessibility issues: http://www.webct.com/products/viewpage?name=products_accessibility and http://booboo.webct.com/otln/webct_accessibility.htm Following are relevant links sourced from the WebCT home page and discussion forums:
ValidationValidation is a checking process that ensures the validity of HTML code and can also check for possible accessibility problems. While it is useful to submit pages to a validation process, it is far from foolproof. It is usual for pages to generate what appears to be a list of 'errors', when the page is in fact conforming to accessibility guidelines. The reason for this is that validity checkers cannot determine:
When checking this page for errors, the Dreamweaver accessibility check advised that some links were to audio files and required a transcript - in fact the links are to URLs with a '.au' extension - an Australian domain not recognised by the USA-centric software! It is commendable that software developers are now ensuring that the latest versions of their software (eg Macromedia Dreamweaver, Adobe Acrobat) enable users to produce documents that are as accessible as possible, and include a function to check for accessibility. It does not necessarily follow that all accessibility requirements are yet supported by the software interface. For example, the Dreamweaver accessibility check will advise you to provide 'longdesc' tags, while not supporting that in it's interface. This issue is in continual development, and it is advisable to check software developer websites for any support or upgrades that may be available:
Validation services are also available on the internet:
The bottom line is, however, that no check is as useful as one performed by a developer who is aware of accessibility guidelines, and is thorough in applying them. Adaptive technologyIt is important for website developers to familiarise themselves with the range of available assistive technologies. Here is a summary of commonly used adaptive technologies
For a comprehensive list of alternative browsing technologies, see W3C 'Alternative web browsing': http://www.w3.org/WAI/References/Browsing WebAIM has created a simulation of how a screen reader interprets a web page: http://www.webaim.org/tutorials/simulations/screenreader. It is even more useful, if possible, to discuss with users the assistive technology being used in your institution and to try it out for yourself. 'How People with Disabilities Use the Web', is a useful W3C document, describing a range of disabilities, and how a combination of accessible design with adaptive technology is able to assist them: http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/Overview.html Links & toolsGeneral accessibility:
Web Accessibility:
Organising content:
Web Usability:
Software archives:
Multimedia:
Web browsers:
Software developer resources:
WebCT accessibility:
Validation:
Adaptive technologies:
Discuss the issues - under developmentA discussion forum is being developed for the UNSW community to discuss issues relating to the subject of accessibility. In the meantime, the following may be of interest: WebAIM accessibility forum: http://www.webaim.org/discussion/ WebCT accessibility forum: http://www.webct.com/webct/forum/topics?discussion=7816&topic=21849 A List Apart Accessibility forum: http://www.alistapart.com/discuss/list.cfm?forum=76&collapse=1 FeedbackHas this site been useful? Would you like to add anything? How could it be improved? Please let us know if you have any comment on the site - positive or negative - that will allow us to better meet your needs in the future. Comments should be emailed to edtec@unsw.edu.au. UNSW staff can also respond to a survey relating to Faculty needs for skill development in the area of website production, which will assist us in developing appropriate resources. Site informationSite designed and constructed by Belinda Allen, EDTeC UNSW This site has been designed to conform to W3C accessibility guidelines, and is 'Bobby' approved. While we are happy for this site to be used for reference, and for you to link to it, please do not reproduce any material from this site without prior permission. Email EDTeC@unsw.edu.au with any enquiries.
|