Download part-3-chapter

Authoring Tools
Jutta Treviranus1
1
University of Toronto, AdaptiveTechnology Resource Centre, Faculty of Information Studies, [email protected]
1 Introduction
Authoring tools play two very critical roles in Web accessibility: they offer a powerful mechanism for promoting the creation of accessible Web content, and they are
the key to equal participation in communication via the Web. This chapter will discuss the role authoring tools can play in promoting broader compliance to Web accessibility guidelines and the importance of authoring tools in the equal participation
of people with disabilities in the phenomenon that is the Web.
Most Web content is authored using an authoring tool, there are very few authors
left who code Web pages using raw HTML. These authoring tools greatly influence
the Web content created. Some markup is automatically generated for the author by
the tool, authors are presented choices and advice, authors are offered pre-authored
content and templates, and authors are assisted in checking and revising their content. Each of these functions presents an opportunity to promote the creation of accessible Web content.
The Web is presently one of the primary loci for communication, information
sharing and community building. It has become far more than a supplementary information source. To date the focus of Web Accessibility discourse has been on
access to information or on people with disabilities as consumers of information. It is
just as critical that people with disabilities be producers of information and participants in the global and local conversations occurring on the Web. This is not possible
without accessible authoring tools.
2
Jutta Treviranus
2 Overview and History of the Field
A cursory review of publishing and discourse on the topic of Web accessibility
shows a preponderance of information, legislation and discussion regarding Web
content accessibility and Web content accessibility guidelines with very little focus
on authoring by people with disabilities or the use of authoring tools to promote
accessibility. The Web Accessibility Initiative of the World Wide Web Consortium
was established in April 1997 with three major guideline initiatives: Web content,
authoring tools and user agents. Since then 26 jurisdictions around the world have
adopted legislation regarding Web content accessibility, the majority based upon the
W3C Web Content Accessibility Guidelines 1.0 (WCAG).
The Authoring Tools Accessibility Guidelines 1.0 (ATAG) became a W3C recommendation in February 2000. These guidelines describe how to create a Web
authoring tool that helps authors to create accessible Web content (that conforms to
WCAG) and how to create an authoring tool that can be used by people with disabilities. The guidelines are primarily intended for developers of authoring tools. Authoring tools are very broadly defined to encompass any software application, tool,
script, or wizard that produces Web content. This includes:







“Editing tools specifically designed to produce Web content, for example,
what-you-see-is-what-you-get (WYSIWYG) HTML and XML editors
Tools that offer the option of saving content in a Web format, for example,
word processors or desktop publishing packages
Tools that transform documents into Web formats, for example, filters to
transform desktop publishing formats to HTML
Tools that produce multimedia, especially where it is intended for use on
the Web, for example, video production and editing suites, SMIL authoring
packages
Tools for site management or site publication, including content managements systems (CMS), tools that automatically generate Web sites dynamically from a database, on-the-fly conversion tools, and Web site publishing
tools
Tools for management of layout, for example, CSS formatting tools
Web sites that let users add content, such as blogs, wikis, photo sharing
sites, and social networking sites” (Treviranus, McCathieNevile, Jacobs, &
Richards 2000).
These can be software applications or tools used on the web such as Wikis, chat
systems or blogs.
In the more than 7 years since ATAG 1.0 became a recommendation there have
been very few if any applications that have complied with all the priority 1 and priority 2 checkpoints within the guidelines. This is partly due to the volatile authoring
tool market. Several applications were almost fully compliant when company mergers caused them to be abandoned or absorbed (e.g., HomeSite, HotDog). There have
Authoring Tools and Document Engineering
3
been some notable research initiatives to develop authoring tools that encourage
accessible Web content and are accessible.
The first of these was a project initiated in 1996, led by a Canadian company,
SoftQuad Inc., in collaboration with the Adaptive Technology Resource Centre of
the University of Toronto. SoftQuad were the developers of the first HTML editor
HoTMetaL. HoTMetaL was redesigned to be accessible to users with disabilities and
incorporated a number of the principles that were later included in ATAG. For example, HoTMetaL prompted the author for alt-text when an image was inserted,
encouraged the use of CSS for styling and steered the author toward the use of appropriate structural markup. HoTMetaL was abandoned as a product when SoftQuad
was purchased by a larger company.
Another project led by the ATRC in 2005 addressed the challenge by modifying
an open source HTML editing component incorporated in many content management
systems. Tiny MCE was modified to comply to priority 1 and priority 2 checkpoints
of the ATAG 2.0 draft. The goal was to encourage wide proliferation of the accessible authoring supports. ATRC worked with Moxiecode Systems to retrofit their open
source JavaScript based “what you see is what you get” (WYSIWYG) HTML editor
to make it ATAG 2.0 conformant. This open source HTML editor was chosen as
TinyMCE is used in many popular Content Management Systems (CMS), used to
build Websites, blogs, wikis, and discussion forums etc., therefore, by focusing efforts on this one particular editor, it would be possible to quickly propagate accessible authoring practices to a number of other tools. In the past year, since the accessible version of the editor was released, there have been more than 500,000 downloads
of the TinyMCE editor. Among others, TinyMCE is currently being used in the following applications: ATutor, Mambo, Joomla, Drupal, Plone, Xaraya, XOOPS,
Typo3, b2evolution, QuickelSoft CMS, WordPress, Community Server, and Zope
(http://culturall.atrc.utoronto.ca/index.php?option=com_content&task=category&sec
tionid=12&id=15&Itemid=35).
Other chapters in this book cover the fundamental importance of Web accessibility to the lives of people with disability but also to society as a whole. The economic,
educational and social impact of lack of equal access to the Web is grave and far
reaching. Policy, advocacy, and legislation encouraging Web accessibility have
focused on the Web Content Accessibility Guidelines. Despite legislation in many
jurisdictions (some with very serious consequences associated with non-compliance)
a recent United Nations study shows that the majority of Web sites, including government Web sites, are still inaccessible (Nomenas, 2006). It would appear that current strategies to encourage Web accessibility have not been as successful as hoped
and efforts should be focused on new or additional strategies. Web accessibility
advocacy based solely on WCAG requires knowledge and understanding of the
guidelines by all Web authors. Web authors include a large part of the population
and a wide cross-section of the population. This cross-section includes such diverse
authors as professional Web editors, employees whose occasional task it is to author
Web content, grandparents, young children, and hobbyists. To fully understand and
adhere to the accessibility guidelines requires strong motivation and commitment on
4
Jutta Treviranus
the part of authors. Authors must also constantly update their knowledge as technologies change.
Another support for accessible Web content is the use of checking or evaluation
tools (Abou-Zahra 2007). These tools process a Web page or site to detect and report
any accessibility issues. The checking tools detect as many problems as possible
automatically but leave a number of issues to human judgment. Some tools guide the
author through a series of questions to determine whether the content is accessible.
The difficulty with this approach is that the checking occurs once the site has already
been created. Addressing Web accessibility problems at this stage requires retrofitting existing content and occasionally completely recreating a site. Many authors
rely solely on the automatic checking component ignoring the additional manual
checking that must occur.
Authoring tools that are compliant to ATAG may address these barriers to creating accessible content. Theoretically, using an ATAG compliant authoring tool to
produce accessible content does not require knowledge of the WCAG guidelines or
even motivation or commitment to create accessible content on the part of the content author. An authoring tool can encourage accessible practices and accessible
authoring choices from the very beginning, thereby precluding costly and onerous
retrofitting or reworking of sites. However, before this strategy can be effective,
ATAG compliant authoring tools must be developed and broadly deployed. The
advocacy effort to achieve this should not be as difficult as achieving WCAG compliance as the number of developers of authoring tools is far smaller than the number
of authors of Web content. What is needed is a concerted effort by policy makers,
advocates and companies developing authoring tools.
3 Discussion
3.1 Encouraging the Creation of Accessible Content
Authoring tools influence the design of the Web content created in a large number of
explicit but also in subtle and even hidden ways. The styles of influence differ according to the type of tool used whether it is a WYSIWYG tool, a tool that supports
direct manipulation of the mark-up or a tool that automatically converts content to
HTML (or DHTML). Web Accessibility is largely based upon the choice of formats
or technologies used (e.g., W3C open standards), the appropriate choice and use of
markup (e.g., use of headers rather than fixed text styling), the creation of equivalent
content in accessible formats (e.g., alt-text, captions, descriptions), appropriate structuring and description of content (e.g., for forms, tables, document structure) and
avoidance of certain content or authoring techniques (e.g., blinking, color coding).
Authoring tools can generate accessible content, influence the choices made, guide
and support good authoring practices, educate in explicit or subtle ways and encourage the adoption of accessible authoring habits and conventions.
Authoring Tools and Document Engineering
5
Little research has been conducted to determine the most effective means of encouraging accessible authoring practices. General user interface design research can
be applied, but even here much of the research is anecdotal. Determining the criteria
for successful support of accessible authoring within an authoring tool is a rich and
worthwhile research agenda that can be informed by user interface design research
and research into change management and learning. This section outlines some of the
techniques gleaned from informal heuristic evaluations, anecdotal observations and
experiences contributed by tool designers in developing the ATAG (treviranus et al
2000).
Many authoring tools or authoring tool functions make choices for authors by automatically generating markup, structure or file formats. This includes the choice of
markup in WYSIWYG tools and conversion-to-HTML functions in Word Processors. These automatic processes can deploy accessible technologies or markup by
default. This is a highly reliable and predictable method of creating accessible content.
When the author has a choice, given that there are accessible choices and inaccessible choices (or more and less accessible choices), there are many strategies that
can be employed to ensure or encourage an accessible choice. These choices may be
presented in menus, toolbars, dialog boxes, palettes or other user interface mechanisms. At the most basic level the choices available should include accessible choices. This is not always the case. For novice or less experienced authors the order of
choices influences the choice made, the first choices are the most likely to be selected. The prominence of the choice may also influence the decision. For example if the
accessible alternative is nested within several layers of menus it is less likely to be
chosen than if it is at the top level and obviously displayed. However, for most authors, it is important that the accessible choice not be seen as an add-on or nonintegrated alternative.
Some accessible practices require more than a set of accessible choices and cannot be performed automatically. This includes the creation of alt-text or other equivalent content such as captions for audio content, labels for form or table elements and
other authoring practices. In these cases authoring tools can use various mechanisms
to guide and support authors such as dialog boxes, wizards or intelligent agents.
Authoring tools can also provide supportive tools such as alt-text libraries to make
the task easier.
Wizards, assistants or intelligent agents have had a mixed reception in user interface design. Wizards are more likely to be received positively when the user wishes
to accomplish a goal that has several steps, when the steps need to be completed in a
set sequence or when users lack necessary domain knowledge. Wizards that attempt
to anticipate a user’s choice or intention are frequently dismissed as are wizards that
are inflexible or wizards that accomplish tasks that can be accomplished by other
means.
While the goal is to encourage accessible authoring, an authoring tool cannot be
dictatorial or inflexible, authors will usually respond by making perfunctory steps to
comply, finding work-arounds that are less than satisfactory from an accessibility
perspective, or rejecting the tool. An example of this might be a dialog box that will
6
Jutta Treviranus
not let the author proceed unless alt-text is filled into a text field when an image is
inserted. The author who wishes to insert the images in a batch will likely fill in any
text to proceed rather than taking the time to create an appropriate label. The author
should be given sufficient flexibility and leeway regarding the timing, order of steps
and choice of authoring options to avoid feeling constrained and at odds with the
authoring tool.
Similarly, intrusive prompts, pop-up windows or warnings, although they are
powerful mechanisms to address accessibility issues, interrupt the workflow and can
be seen as annoying by the author. These are more likely to be well received if the
author has chosen to activate them and can turn them off.
An assistive function that has become expected and has gained user trust is the
spell checking function. In standard spell checkers, errors are highlighted in an unobtrusive manner and can be dealt with immediately or in a batch. Similarly Web authors have come to trust and implement HTML or XML checking tools. Accessibility checking and repair functions integrated into an authoring tool can mimic these
more familiar tools to encourage greater acceptance. Checking and repair integrated
into an authoring tool has the advantage of enabling checking and repair at time of
authoring when the cost of revision is minor rather than after the fact when a number
of dependent steps may need to be reversed to address accessibility problems.
Most authors leave preference settings in the default or “factory preset” state, unless prompted to create a preference profile upon setup. To support the goal of accessible authoring, most accessibility supports, such as accessibility checking and repair, should therefore be ‘on’ by default.
Many authors implement templates, style sheets, and pre-authored content such
as clip art or scripts and applets. This has become even more prevalent with the increased use of dynamic, database driven Web sites delivered through content management systems. If these templates and pre-authored content elements are WCAG
compliant there is a high likelihood that the sites they form the basis of will also be
WCAG compliant. However there are instances when the author should be encouraged to modify the content, for example, when images are to be repurposed, stock
alt-text may no longer be appropriate for the new purpose and authors should be
instructed to modify the alt-text in line with the new meaning to be communicated by
the image.
Pre-authored applets, scripts or online user interface elements that are part of
many content management systems including learning management systems should
be accessible. With the prevalence of open source content management projects
exemplary accessible components can be shared and freely adapted across systems
making it easier to include accessible versions of functionality.
Ideally, accessible authoring should become a natural, integrated part of the authoring workflow. Accessible authoring practices should become habitual and assumed. Standard conventions for existing content types and for emerging content
types should include accessible practices. An authoring tool can encourage this by
integrating accessibility features and accessible authoring steps into any multi-step
process, as well as including accessible examples in any examples given in help,
tutorials, documentation or intelligent assistants. All tutorials, help, documentation,
Authoring Tools and Document Engineering
7
or intelligent assistants should integrate accessible authoring practices in the standard
authoring practices demonstrated or described.
3.2 Authoring Tools that are Accessible to People with Disabilities
It is just as important that people with disabilities be able to use authoring tools to
produce Web content as it is that content be accessible to people with disabilities.
This requires that the authoring tool user interface follow standard user interface
accessibility guidelines. Standard accessible user interface techniques are ably covered in a number of resources and will not be addressed in this chapter (Treviranus et
al 2000) In addition to standard accessible user interface principles there are a number of unique accessibility challenges that are presented by the task of authoring that
should also be addressed.
One unique accessibility challenge associated with authoring is that the default
presentation or rendering of the content that the author is creating may not be accessible to the author. The author should therefore be able to configure the tool interface
and rendering of the content independent of the final default rendering, while authoring. For example an author with low vision may require text to be presented in a 46
point size with a dark background and light foreground text. This may not be the
desired rendering of the Web site the author is creating. This can be addressed by
allowing the author to adjust the presentation of the user interface and content without affecting the styling of the authored content.
Standard authoring tasks include cutting, copying, moving and pasting content.
Typically this involves mouse-based, visually-dependent highlighting, dragging and
dropping. When the application is designed accessibly this can be achieved using
keyboard equivalents, however moving to and selecting the desired chunk of content
can be a considerable challenge when relying on the keyboard. Enabling navigation
using the structure (e.g., from one H1 to the next, through all H2s nested within an
H1 and then to the first paragraph) and selection of structural chunks (e.g., header,
body, paragraph, etc.) makes this important task much more efficient and accessible.
Authoring is frequently a collaborative task. When authoring a largely text-based
document, change tracking commonly relies on color-coding and other purely visual
cues. Modally independent alternatives must be developed for these cues (e.g., text
based alternatives or markup that can be interpreted as a change in voice if read by a
screen reader). When the collaborative environment or application is used to create
or to communicate through graphic information, such as a white board application,
more creative solutions are needed to make the information and the collaboration
accessible. One approach is a white board that offers a palette of vector graphic
shapes in place of free-hand drawing. These shapes can be combined or grouped and
new combinations can be added to the palette. For example a triangle on top of a
rectangle with smaller rectangles can be combined to be a rudimentary house that
can then be added to the palette. If each of these shapes and grouping of shapes has
an associated text label, an individual who is blind can decipher the visual model
being collaboratively constructed. The facility for a collaborative peer to also add a
8
Jutta Treviranus
text description of the graphically presented information will add to the accessibility
of the collaboration.
The most challenging online authoring environments from an accessibility perspective are communication environments in which the information is created synchronously or in real time and must be responded to in real time. These include text
chats, voice over IP and video over IP. These present a particularly difficult challenge because there is little opportunity to create equivalent content for audio or
visual information. Surprisingly even text-chat environments continue to present
barriers even though the communication medium is text. The primary accessibility
barrier in text chat environments is that screen readers and refreshable Braille displays are unable to logically handle focus. Thus a screen reader will intersperse
speaking a message being constructed by the screen reader user with messages coming in from other participants. This has been addressed in applications such as AChat (http://achat.atrc.utoronto.ca/). When real time communication occurs using
speech or video, providing equivalent content such as captions or descriptions is
much more challenging. Two options include relying on ad hoc peer captioning or
description or using a video or audio relay service (i.e., access to professional transcribers or sign interpreters through a remote link). The communication environment
or application should provide input supports to enable this peer or relay translation.
4 Future Directions
4.1 Rich Internet Applications
An as yet unmet accessibility challenge that has threatened to derail Web accessibility progress and affects authoring tools that are implemented as Web applications is
the accessibility of Rich Internet Applications, Web 2.0 or technologies such as
Ajax. Current techniques and strategies to make the Web or desktop applications
accessible to assistive technologies such as screen readers are confounded by rich
internet or Web 2.0 technologies. Rich internet applications have user interfaces that
are more varied and more responsive to user actions than traditional, page-based,
web sites. Rich internet application interfaces have controls and user interactions
built from available HTML elements, styled with CSS and given behavior or animation through JavaScript to perform functions not possible with traditional HTML. To
provide meaningful access to a person with a disability, not only must an assistive
technology communicate or describe a static page, it must describe a variety of interactions and a constantly changing page or display. Similarly alternative control devices such as on-screen keyboards must find actionable items or controls on a constantly changing display. This is not possible given the present functioning of
assistive technologies and the unpredictable and non-explicit nature of rich internet
interface components.
The recent Target lawsuit and other lawsuits of this kind in the United States
have attracted a great deal of attention to this issue (as an illustration type “Target
Authoring Tools and Document Engineering
9
lawsuit accessibility” into your Google search engine). Unfortunately the public view
of the issue has become polarized such that Ajax, the most popular Web 2.0 tool, has
been framed as anti-accessibility, and disability advocates are working to ban or
prevent its use. As the popularity of Ajax and related technologies increases this is
bound to fail and further characterize accessibility as anti-progress, anti-innovation,
and constraining technical creativity.
Several initiatives of significance have emerged to address this unfortunate dilemma. The Accessible Rich Internet Applications project (ARIA) is organized
through the World Wide Consortium with support from IBM, Sun and Mozilla. This
working group has been mandated to coordinate efforts to “fix the accessibility of
Rich Internet Applications” (http://www.w3.org/WAI/PF/ ). The primary tasks have
been to create a roadmap for Accessible Rich Internet Applications (see
http://www.w3.org/TR/aria-roadmap/ ), and to create the semantic markup needed to
adequately describe the roles, states and properties of widget, applets and UI components so that alternative access systems can adequately process these elements. To
create accessible Ajax or rich internet controls and widgets (which have functionality
outside the capabilities of HTML) there must be a mechanism to communicate the
role of a control and the state that it has in the web browser in a way that is comprehensible to the user who is relying on audio information or Braille. For example, this
mechanism might indicate that a part of the page is a progress bar and that it is at
60%. This work is not complete as new controls are developed almost daily and the
common vocabulary has not been implemented in Web 2.0 application toolkits.
4.2 Individual Optimization or “One Size Fits One”
Many Web sites currently offer the opportunity to log in and create a personalized
profile that persists on the site, or to express personal preferences regarding the interface or content on the site. This provides the opportunity to optimize the site for each
individual user. This can be an effective mechanism for delivering individually optimized accessibility as well. Standards and specifications have been created that
provide a common language for expressing accessibility preferences and needs, in
very functional terms, that apply to users with and without disabilities (Jackl, Treviranus & Roberts 2004; Norton & Treviranus 2003; http://jtc1sc36.org/). If these are
commonly implemented a user with a disability or any user can have a portable preference profile that they can take from application to application. These profiles can
also be context specific to accommodate varying needs caused by the device used,
the environment or other circumstances that may cause a shift in needs or preferences. For the site author this means that all accessibility guidelines do not need to
be addressed in a single instance of the site, the content and interface can be dynamically transformed or replaced depending on the user.
10
Jutta Treviranus
5 State of the Field
Despite extensive accessibility advocacy, policy and legislation, very few web
authors are aware of accessibility guidelines or knowledgeable in accessible authoring practices. Very few authors see accessibility as a priority when creating Web
sites. Most authors of web content, however, use some form of authoring tool to
create Web pages. Education, advocacy or compliance evaluation programs will not
effectively address the prevalence of inaccessible Web sites. These approaches demand skills and conventions that do not match the reality of Web authoring, not all
authors need to know the technical minutiae of accessible authoring practices, as all
authors do not need to know about HTML to author Web content. Evaluation and
repair programs or conformance testing occurs after a web site is created (often after
it is publicly available) causing the author or evaluator to retrofit or rewrite content.
The best and most efficient strategy for insuring that content is accessible is to
broadly implement the use of authoring tools that create accessible content. This
strategy would ensure that even authors who are not knowledgeable about or motivated to create accessible content do so, almost unconsciously. In this way, accessible authoring would also be an integrated part of the process rather than an afterthought, reducing the time required to repair accessibility problems. This approach
can be accomplished by mandating or promoting - through legislative or policy
mechanisms - the use of authoring tools that are compliant with ATAG.
The Web Accessibility Initiative was founded in an era when there was a clear
distinction between content, authoring tools and browsers or user agents. Today
these distinctions are blurring. Many Web environments have become collaborative
authoring environments where the distinction between content, authoring and viewing becomes an academic rather than practical distinction. Forums, Blogs, Wikis,
sites such as Flickr, YouTube, Myspace and Facebook, can be seen as content, authoring and special purpose user agents. It may be time to create a new conception of
accessibility guidelines to address this convergence. This new conception could be
based on more practical classifications of functionality such as professional and
amateur authoring, dynamically generated and manually authored content, software
development kits and component libraries. This new conception could also take into
account accessibility through personal optimization rather than through a single
universally accessible resource.
One of the key challenges facing the accessibility field at the moment is the reputation of accessibility among Web developers. Accessibility has been characterized
as anti-innovation, anti-creativity. Developers are cautioned or prevented from using
new technology due to accessibility concerns. Accessibility evaluation is frequently
seen as a policing, or punitive function. The sad irony is that the accessibility challenge is more in need of innovation and creativity than many other areas. Fortunately
it can be shown that inclusive design spurs creativity and innovation and benefits
everyone. To achieve an inclusive Web, accessibility advocates must work to ally
accessibility with innovation and creativity. This can be achieved in large part by
focusing on integrated accessible authoring rather than compliance testing and by the
promotion of more flexible accessibility strategies such as personal optimization
Authoring Tools and Document Engineering
11
which support the use of a variety of strategies and allows experimentation with new
technologies that are not necessarily accessibility vetted.
With the emergence of the participatory Web (Kelly 2005) it has become even
more critical that people with disabilities have equal access to communication over
the Web - to both receiving and expressing information. This is true from the perspective of the individual and the community. New technology-enabled social practices such as tag clouds and social bookmarking intensify the effect of nonparticipation. All things popular and current rise to the top and gain additional significance. Taking the example of tag clouds the most popular topics increase in size,
while the less popular shrink and eventually disappear. Thus the values of popularity
and newness gain prominence. This reinforces the popular view and any perspective
in the minority will never win the popularity contest. Perspectives that cannot participate are rendered invisible. If people with disabilities do not have accessible means
of contributing, their perspective and needs will disappear. Equal participation may
also bring about the promotion of more inclusive alternatives to popularity as influential values in these online communities.
6 Conclusions
Authoring Tools are a critical piece of the Web accessibility puzzle, they offer a
powerful and effective mechanism for supporting the creation of accessible Web
content and they are the key to equal participation on the Web. As more and more
important daily functions occur on the Web and as the Web becomes our source for
socialization and community this equal participation becomes even more critical. A
principle that has been underemphasized in Web accessibility efforts is that people
with disabilities must be producers as well of consumers of information on the Web.
This has become even more important with the emergence of the participatory Web.
If this participatory Web is inaccessible to people with disabilities, the contributions,
creativity, as well as needs of a large segment of society will become invisible. The
research agenda to address accessible authoring is of great magnitude but also of
great significance.
References
Abou-Zahra, Shadi(March 2007). Evaluation and Report Language (EARL) 1.0 Schema
W3C Working Draft 23 March 2007, Retrievied August 1, 2007 from
http://www.w3.org/TR/EARL10-Schema/
Nomensa (2006). United Nations Global Audit of Web Accessibility. Available from Nomensa
at http://www.nomensa.com/resources/research/united-nations-global-audit-ofaccessibility.html
Jackl, A., Treviranus, J., & Roberts, A. (2004). IMS AccessForAll Meta-data overview. Retrieved May 1, 2007, from
http://www.imsglobal.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.html
12
Jutta Treviranus
Kelly, Kevin (2005). We are the web. Wired, 13, August. Retrieved June 5, 2007
from http://www.wired.com/wired/archive/13.08/tech_pr.html.
Norton, M. & Treviranus, J. (2003). IMS learner information package accessibility for LIP
best practice and implementation guide. Retrieved March 1, 2007, from
http://www.imsglobal.org/accessibility/acclipv1p0/imsacclip_infov1p0.html
Treviranus, J., McCathieNevile, C., Jacobs, I. & Richards, J. (2000). Authoring tool accessibility guidelines 1.0. Retrieved May 1, 2007, from http://www.w3.org/TR/2000/RECATAG10-20000203