Introduction

It is important during the design of web pages to take into account accessibility issues of electronic content. Web designers should understand that many users operate in different contexts than others. There are users who cannot see, hear, process any kind of information either with difficulty or not at all. Users who may have difficulty reading or understanding text. Users who cannot use a keyboard or mouse. Users who may have a text-only screen, or a small screen, or a slow Internet connection. Users who may not fluently understand the language in which the text is written. Users who may have some weakness in their eyes, ears or hands to be busy (e.g. driving, working in a noisy environment, etc.).

Content producers must be aware of these different situations during the design of a page. Of course, there are other situations that they should be aware of, however, any access option favors groups of people with disabilities and the web community in general.

The specifications address accessibility issues and provide design solutions. For example one of the specifications explains how content producers make images accessible. Some users cannot see images, some others may be using browsers that do not support images, while other users may have disabled image support due to a slow Internet connection. The specification does not assume the avoidance of images as a way to optimize accessibility. Instead, they explain that producing a text equivalent to an image helps with accessibility.

Standards

This text contains fourteen specifications of general principles for accessibility in design. Specifications are guidelines that must be considered for optimization in page design.

Specification 1. Providing alternative ways of representing audio and visual content.

Purpose. Providing content that gives the user the same functionality as audio and visual content.

Control Points.

– Provide text for each non-text element (eg, using “alt”, “longdesc”). Apply to: images, graphic representations of texts, maps, animations, applets, scripts, sounds, stand-alone audio files, video files.

-Where the access applications (web browser, WAP browser, etc) try to automatically read the corresponding text of a multimedia presentation, there should be an audio description of the most important information to be heard.

-For the time needed by each multimedia presentation (eg, film or animation), to synchronize its alternative descriptions (eg, audio descriptions).

Specification 2. The design should not be based only on the colors.

Purpose. Confirmation that text and graphics are understandable and free of coloration.

Control Points.

-Confirmation that the information conveyed with coloring is also available without coloring.

Specification 3. Use metadata language (markup) and default information representation standards (style sheets).

Purpose. To structure the files with markup rather than with other building elements. The design should be done with style sheets rather than with other presentation elements.

Control Points.

-When it is possible to use a markup language, it is better to use it than to convey the information with an image.

Specification 4. To clarify the use of natural language.

Purpose. To use a metadata language (markup) that facilitates the pronunciation or translation of abbreviated or foreign texts.

Control Points.

-Determine changes between the natural language of the text and its alternatives.

Specification 5. Create tables that are easily modified.

Purpose. Ensuring that tables have the appropriate markup so that they can be easily modified by browsers and other access applications.

Control Points.

–In tables of contents, differentiate column headings from row headings.

-Tables of content that have two or more logical levels of row or column headings should use markup to link cell contents to their headings.

Specification 6. Pages containing new technologies should be easy to modify.

Purpose. Confirmation that pages are accessible even if newer technologies are not supported or disabled.

Control Points.

–Organize files so they can be read without style sheets. For example an HTML file can be rendered without the associated style sheets.

- Confirmation that pages can be used even when scripts, applets or other programming files are not supported or disabled.

Specification 7. Confirm that users can control time-sensitive content changes.

Purpose. Confirmation that the user can stop or stop the movement, flickering, scrolling or automatic updating of files.

Control Points.

-Until accessibility apps allow users to control flickering, screen flickering should be avoided.

Specification 8. Confirmation that the user has direct access to integrated functionalities with the interface environment.

Purpose. Confirmation that the interface environment follows design accessibility principles: independent operable devices, operable keyboard, etc.

Control Points.

- Creation of programming elements, such as scripts and applets directly accessible or compatible with assistive technologies.

Specification 9. Appropriate design to allow device independence.

Purpose. Use elements to enable elements on a page to be activated via input devices.

Control Points.

–Provide client-side image maps instead of server-side except for areas that cannot be defined by any available schema.

Specification 10. Use of intermediate solutions.

Purpose. Use intermediate access solutions so that assistive technologies and older browsers work properly.

Control Points.

-Until accessibility apps allow users to close multiple windows, the flow of the presentation will not be interrupted by new windows, and windows will not appear to change the content the user is seeing.

Specification 11. Use of W3C technologies and specifications.

Purpose. Use of W3C accessibility technologies and specifications.

Control Points.

-If an accessible page cannot be used, there should be a link to an alternative page that uses W3C technologies, that is accessible, that has equivalent content and that is updated as often as the non-accessible one.

Specification 12. Providing information for orientation and navigation.

Purpose. Provide orientation and navigation information to help users understand difficult pages or elements.

Control Points.

– To give a title to each page frame so as to optimize their recognition and navigation.

Specification 13. Provision of navigation mechanisms.

Purpose. Provision of navigation mechanisms, orientation information, control bars, site map, etc. so as to increase the probability of the user finding what he wants.

Control Points.

– the text accompanying a link must be understandable and explanatory.

Specification 14. Confirmation that files are simple and clear.

Purpose. Ensuring that files are simple and clear so that they are easier to read.

Control Points.

- To use the simplest and clearest language for the content of a site.

More Special Specifications for Speech Synthesis Technology for PWD support

Speech synthesis systems, and text-to-speech technologies in particular, have a wide range of applications and worldwide research and developments in this field are extremely important nowadays. Much of the effort is focused on helping people with disabilities to improve their ability to interact with IT applications and systems. This has a direct effect both on increasing productivity and upgrading the socialization of the disabled.

Operational needs of ESAEA

Regarding voice synthesis systems for converting electronic text into speech, ESAEA proposes the following functional requirements that such a system must satisfy:

– Support of the Greek language.

– Support of latest versions of MS Windows windowed environment.

– Ability to integrate functionality into widely used external windowed applications (eg Word) through standard application intercom automations.

– Ability to link speech functions to specific file types via the appropriate shell extensions.

– Support for multiple ways of activating speech functions through the operating interface (with text selection, speaking a file with right click, speaking a file with drag'n'drop, displaying functions in the toolbar, etc.).

– Low response times and smooth speech flow even in long sentences.

– Possibilities to expand and customize the language repertoire of the application.

– Ability to adjust the tone and timbre of the mechanical voice.

– Natural pronunciation and intonation. Possibilities to pronounce a question or exclamation from the punctuation marks of the text (prosody algorithm).

– Ability to develop numbers and abbreviations in plain text.

– Possibility of integration in an application server environment through the appropriate programming interface (API).