Authoring Tools
Jutta Treviranus1
1University of Toronto, AdaptiveTechnology Resource Centre, Faculty of Information Studies,
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 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 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 (
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 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-Zahra2007). 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.
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 non-integrated 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 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, or intelligent assistants should integrate accessible authoring practices in the standard authoring practices demonstrated or described.