PGDEL/DECP03/Unit1/21
Uttarakhand Open University
Post Graduate Diploma in e-Learning
| 
Unit 3.1 Multimedia Basics
Web Authoring tools and techniques
http://www.w3.org/TR/WAI-AUTOOLS/
The term “Web Authoring Tool” refers to the wide range of software used for creating Web content, including:
• Editing tools specifically designed to produce Web content (e.g., WYSIWYG HTML and XML editors);
• Tools that offer the option of saving material in a Web format (e.g., word processors or desktop publishing packages);
• Tools that transform documents into Web formats (e.g., filters to transform desktop publishing formats to HTML);
• Tools that produce multimedia, especially where it is intended for use on the Web (e.g., video production and editing suites, SMIL authoring packages);
• Tools for site management or site publication, including 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 (e.g., CSS formatting tools).
Authoring tools enable, encourage, and assist users ("authors") in the creation of accessible Web content through prompts, alerts, checking and repair functions, help files and automated tools. It is just as important that all people be able to author content as it is for all people to have access to it. The tools used to create this information must therefore be accessible themselves.
Because most of the content of the Web is created using authoring tools, they play a critical role in ensuring the accessibility of the Web. Since the Web is both a means of receiving information and communicating information, it is important that both the Web content produced and the authoring tool itself be accessible.
To achieve these goals, authoring tool developers must take steps such as ensuring conformance to accessible standards (e.g., HTML 4), checking and correcting accessibility problems, prompting, and providing appropriate documentation and help. For detailed information about what constitutes accessible content, refer to the Web Content Accessibility Guidelines 1.0 (http://www.w3.org/TR/WCAG10/ ).
Accessibility
"accessible Web content" and "accessible authoring tool" mean that the content and tool can be used by people regardless of disability. To understand the accessibility issues relevant to authoring tool design, consider that many authors may be creating content in contexts very different from your own:
• They may not be able to see, hear, move, or may not be able to process some types of information easily or at all;
• They may have difficulty reading or comprehending text;
• They may not have or be able to use a keyboard or mouse;
• They may have a text-only display, or a small screen.
Accessible design will benefit people in these different authoring scenarios and also many people who do not have a physical disability but who have similar needs. For example, someone may be working in a noisy environment and thus require an alternative representation of audio information. Similarly, someone may be working in an eyes-busy environment and thus require an audio equivalent to information they cannot view. Users of small mobile devices (with small screens, no keyboard, and no mouse) have similar functional needs as some users with disabilities.
Guidelines
1. Support accessible authoring practices.
If the tool automatically generated markup, many authors would remain unaware of the accessibility status of the final content unless they expended extra effort to review it and make appropriate corrections by hand. Since many authors are unfamiliar with accessibility, authoring tools are responsible for automatically generating accessible markup, and where appropriate, for guiding the author in producing accessible content.
Many applications feature the ability to convert documents from other formats (e.g., Rich Text Format) into a markup format specifically intended for the Web such as HTML. Markup changes may also be made to facilitate efficient editing and manipulation. It is essential that these processes do not introduceinaccessible markup or remove accessibility content, particularly when a tool hides the markup changes from the author's view.
2. Generate standard markup.
Conformance with standards promotes interoperability and accessibility by making it easier to create specialized user agents that address the needs of users with disabilities. In particular, many assistive technologies used with browsers and multimedia players are only able to provide access to Web documents that use valid markup. Therefore, valid markup is an essential aspect of authoring tool accessibility.
Where applicable use W3C Recommendations to ensure accessibility and interoperability. If there are no applicable W3C Recommendations, use a published standard that enables accessibility.
3. Support the creation of accessible content.
Well-structured information and equivalent alternative information are cornerstones of accessible design, allowing information to be presented in a way most appropriate for the needs of the user without constraining the creativity of the author. Yet producing equivalent information, such as text alternatives for images and auditory descriptions of video, can be one of the most challenging aspects of Web design, and authoring tool developers should attempt to facilitate and automate the mechanics of this process. For example, prompting authors to include equivalent alternative information such as text equivalents, captions, and auditory descriptions at appropriate times can greatly ease the burden for authors. Where such information can be mechanically determined and offered as a choice for the author (e.g., the function of icons in an automatically-generated navigation bar, or expansion of acronyms from a dictionary), the tool can assist the author. At the same time, the tool can reinforce the need for such information and the author's role in ensuring that it is used appropriately in each instance.
4. Provide ways of checking and correcting inaccessible content.
<font face="verdana" size="3" Many authoring tools allow authors to create documents with little or no knowledge about the underlying markup. To ensure accessibility, authoring tools must be designed so that they can (where possible, automatically) identify inaccessible markup, and enable its correction even when the markup itself is hidden from the author.</font>
Authoring tool support for the creation of accessible Web content should account for different authoring styles. Authors who can configure the tool's accessibility features to support their regular work patterns are more likely to accept accessible authoring practices. For example, some authors may prefer to be alerted to accessibility problems when they occur, whereas others may prefer to perform a check at the end of an editing session. This is analogous to programming environments that allow users to decide whether to check for correct code during editing or at compilation.
5. Integrate accessibility solutions into the overall "look and feel".
When a new feature is added to an existing software tool without proper integration, the result is often an obvious discontinuity. Differing color schemes, fonts, interaction styles, and even software stability can be factors affecting author acceptance of the new feature. In addition, the relative prominence of different ways to accomplish the same task can influence which one the author chooses. Therefore, it is important that creating accessible content be a natural process when using an authoring tool.
6. Promote accessibility in help and documentation.
Web authors may not be familiar with accessibility issues that arise when creating Web content. Therefore, help and documentation must include explanations of accessibility problems, and should demonstrate solutions with examples.
7. Ensure that the authoring tool is accessible to authors with disabilities.
The authoring tool is a software program with standard user interface elements and as such must be designed according to relevant user interface accessibility guidelines. When custom interface components are created, it is essential that they be accessible through the standard access mechanisms for the relevant platform so that assistive technologies can be used with them.
Some additional user interface design considerations apply specifically to Web authoring tools. For instance, authoring tools must ensure that the author can edit (in an editing view) using one set of stylistic preferences and publish using different styles. Authors with low vision may need large text when editing but want to publish with a smaller default text size. The style preferences of the editing view must not affect the markup of the published document.
Authoring tools must also ensure that the author can navigate a document efficiently while editing, regardless of disability. Authors who use screen readers, refreshable braille displays, or screen magnifiers can make limited use (if at all) of graphical artifacts that communicate the structure of the document and act as signposts when traversing it. Authors who cannot use a mouse (e.g., people with physical disabilities or who are blind) must use the slow and tiring process of moving one step at a time through the document to access the desired content, unless more efficient navigation methods are available. Authoring tools should therefore provide an editing view that conveys a sense of the overall structure and allows structured navigation.
8. Provide equivalent alternatives to auditory and visual content.
Provide content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content.
Although some people cannot use images, movies, sounds, applets, etc. directly, they may still use pages that include equivalent information to the visual or auditory content. The equivalent information must serve the same purpose as the visual or auditory content. Thus, a text equivalent for an image of an upward arrow that links to a table of contents could be "Go to table of contents". In some cases, an equivalent should also describe the appearance of visual content (e.g., for complex charts, billboards, or diagrams) or the sound of auditory content (e.g., for audio samples used in education).
The power of text equivalents lies in their capacity to be rendered in ways that are accessible to people from various disability groups using a variety of technologies. Text can be readily output to speech synthesizers and braille displays, and can be presented visually (in a variety of sizes) on computer displays and paper. Synthesized speech is critical for individuals who are blind and for many people with the reading difficulties that often accompany cognitive disabilities, learning disabilities, and deafness. Braille is essential for individuals who are both deaf and blind, as well as many individuals whose only sensory disability is blindness. Text displayed visually benefits users who are deaf as well as the majority of Web users.
Providing non-text equivalents (e.g., pictures, videos, and pre-recorded audio) of text is also beneficial to some users, especially nonreaders or people who have difficulty reading. In movies or visual presentations, visual action such as body language or other visual cues may not be accompanied by enough audio information to convey the same information. Unless verbal descriptions of this visual information are provided, people who cannot see (or look at) the visual content will not be able to perceive it.
9. Don't rely on color alone.
Ensure that text and graphics are understandable when viewed without color.
If color alone is used to convey information, people who cannot differentiate between certain colors and users with devices that have non-color or non-visual displays will not receive the information. When foreground and background colors are too close to the same hue, they may not provide sufficient contrast when viewed using monochrome displays or by people with different types of color deficits.
10. Use markup and style sheets and do so properly.
Mark up documents with the proper structural elements. Control presentation with style sheets rather than with presentation elements and attributes.
Using markup improperly -- not according to specification -- hinders accessibility. Misusing markup for a presentation effect (e.g., using a table for layout or a header to change the font size) makes it difficult for users with specialized software to understand the organization of the page or to navigate through it. Furthermore, using presentation markup rather than structural markup to convey structure (e.g., constructing what looks like a table of data with an HTML PRE element) makes it difficult to render a page intelligibly to other devices (refer to the description of difference between content, structure, and presentation).
Content developers may be tempted to use (or misuse) constructs that achieve a desired formatting effect on older browsers. They must be aware that these practices cause accessibility problems and must consider whether the formatting effect is so critical as to warrant making the document inaccessible to some users.
At the other extreme, content developers must not sacrifice appropriate markup because a certain browser or assistive technology does not process it correctly. For example, it is appropriate to use the TABLE element in HTML to mark up tabular information even though some older screen readers may not handle side-by-side text correctly. Using TABLE correctly and creating tables that transform gracefully (refer to guideline 5) makes it possible for software to render tables other than as two-dimensional grids.
11. Clarify natural language usage.
Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text.
When content developers mark up natural language changes in a document, speech synthesizers and braille devices can automatically switch to the new language, making the document more accessible to multilingual users. Content developers should identify the predominant natural language of a document's content (through markup or HTTP headers). Content developers should also provide expansions of abbreviations and acronyms.
In addition to helping assistive technologies, natural language markup allows search engines to find key words and identify documents in a desired language. Natural language markup also improves readability of the Web for all people, including those with learning disabilities, cognitive disabilities, or people who are deaf.
When abbreviations and natural language changes are not identified, they may be indecipherable when machine-spoken or brailled.
12. Create tables that transform gracefully.
Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents.
Tables should be used to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables"). Tables for any use also present special problems to users of screen readers.
Some user agents allow users to navigate among table cells and access header and other table cell information. Unless marked-up properly, these tables will not provide user agents with the appropriate information.
13. Ensure that pages featuring new technologies transform gracefully.
Ensure that pages are accessible even when newer technologies are not supported or are turned off.
Although content developers are encouraged to use new technologies that solve problems raised by existing technologies, they should know how to make their pages still work with older browsers and people who choose to turn off features.
14. Ensure user control of time-sensitive content changes.
Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped.
Some people with cognitive or visual disabilities are unable to read moving text quickly enough or at all. Movement can also cause such a distraction that the rest of the page becomes unreadable for people with cognitive disabilities. Screen readers are unable to read moving text. People with physical disabilities might not be able to move quickly or accurately enough to interact with moving objects.
15. Ensure direct accessibility of embedded user interfaces.
Ensure that the user interface follows principles of accessible design: device-independent access to functionality, keyboard operability, self-voicing, etc.
When an embedded object has its "own interface", the interface -- like the interface to the browser itself -- must be accessible. If the interface of the embedded object cannot be made accessible, an alternative accessible solution must be provided.
Note. For information about accessible interfaces, please consult the User Agent Accessibility Guidelines ([WAI-USERAGENT]) and the Authoring Tool Accessibility Guidelines ([WAI-AUTOOL]).
16. Design for device-independence.
Use features that enable activation of page elements via a variety of input devices.
Device-independent access means that the user may interact with the user agent or document with a preferred input (or output) device -- mouse, keyboard, voice, head wand, or other. If, for example, a form control can only be activated with a mouse or other pointing device, someone who is using the page without sight, with voice input, or with a keyboard or who is using some other non-pointing input device will not be able to use the form.
Note. Providing text equivalents for image maps or images used as links makes it possible for users to interact with them without a pointing device. Refer also to guideline 1.
Generally, pages that allow keyboard interaction are also accessible through speech input or a command line interface.
17. Use interim solutions.
Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.
For example, older browsers do not allow users to navigate to empty edit boxes. Older screen readers read lists of consecutive links as one link. These active elements are therefore difficult or impossible to access. Also, changing the current window or popping up new windows can be very disorienting to users who cannot see that this has happened.
18. Use W3C technologies and guidelines.
Use W3C technologies (according to specification) and follow accessibility guidelines. Where it is not possible to use a W3C technology, or doing so results in material that does not transform gracefully, provide an alternative version of the content that is accessible.
The current guidelines recommend W3C technologies (e.g., HTML, CSS, etc.) for several reasons:
• W3C technologies include "built-in" accessibility features.
• W3C specifications undergo early review to ensure that accessibility issues are considered during the design phase.
• W3C specifications are developed in an open, industry consensus process.
Many non-W3C formats (e.g., PDF, Shockwave, etc.) require viewing with either plug-ins or stand-alone applications. Often, these formats cannot be viewed or navigated with standard user agents (including assistive technologies). Avoiding non-W3C and non-standard features (proprietary elements, attributes, properties, and extensions) will tend to make pages more accessible to more people using a wider variety of hardware and software. When inaccessible technologies (proprietary or not) must be used, equivalent accessible pages must be provided. Even when W3C technologies are used, they must be used in accordance with accessibility guidelines. When using new technologies, ensure that they transform gracefully (Refer also to guideline 6).
Note. Converting documents (from PDF, PostScript, RTF, etc.) to W3C markup languages (HTML, XML) does not always create an accessible document.Therefore, validate each page for accessibility and usability after the conversion process If a page does not readily convert, either revise the page until its original representation converts appropriately or provide an HTML or plain text version.
19. Provide context and orientation information.
Provide context and orientation information to help users understand complex pages or elements.
Grouping elements and providing contextual information about the relationships between elements can be useful for all users. Complex relationships between parts of a page may be difficult for people with cognitive disabilities and people with visual disabilities to interpret.
20. Provide clear navigation mechanisms.
Provide clear and consistent navigation mechanisms -- orientation information, navigation bars, a site map, etc. -- to increase the likelihood that a person will find what they are looking for at a site.
Clear and consistent navigation mechanisms are important to people with cognitive disabilities or blindness, and benefit all users.
21. Ensure that documents are clear and simple.
Ensure that documents are clear and simple so they may be more easily understood.
Consistent page layout, recognizable graphics, and easy to understand language benefit all users. In particular, they help people with cognitive disabilities or who have difficulty reading. (However, ensure that images have text equivalents for people who are blind, have low vision, or for any user who cannot or has chosen not to view graphics.
Using clear and simple language promotes effective communication. Access to written information can be difficult for people who have cognitive or learning disabilities. Using clear and simple language also benefits people whose first language differs from your own, including those people who communicate primarily in sign language.
|
Work in progress, expect frequent changes. Help and feedback is welcome. See discussion page. |
|
