Introduction

It is important to consider issues of accessibility of electronic content when designing websites. Web designers need to understand that many users operate in different contexts than others. There are users who can not 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 can not use keyboard or mouse. Users who may have a screen that contains only text, or a small screen, or a slow Internet connection. Users who may not easily understand the language in which the text is written. Users who may have a weakness in their eyes, ears or hands are busy (eg while driving, working in noisy environments, etc.).

Content creators need to be aware of these different situations when designing a page. Of course there are other situations to be aware of, however any access option favors groups of people with a disability and the web community in general.

The specifications address accessibility issues and provide design solutions. For example, one of the specifications explains how content creators make images accessible. Some users may not see images, others may use non-image browsers, and others may have disabled image support due to a slow Internet connection. Specifications do not presuppose image avoidance as a way to optimize accessibility. Instead, they explain that producing a text equivalent to an image helps in accessibility.

Standards

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

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

Purpose. Provide content that gives the user the same function as audio and visual content.

Checkpoints.

- Provide text for any non-text item (eg, using "alt", "longdesc"). Application in: images, text graphics, maps, animations, applets, scripts, sounds, stand-alone audio files, video files.

-Where access applications (web browser, WAP browser, etc.) automatically try to 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 it takes for each multimedia presentation (eg, movie or animation), to synchronize alternative descriptions (eg, audio descriptions).

Specification 2. Do not base the design only on the colors.

Purpose. Confirm that the text and graphics are understandable and without coloring.

Checkpoints.

Confirmation that the information conveyed by coloring is also available without coloring.

Specification 3. Use markup language and default style sheets.

Purpose. Build files with markup rather than with other build elements. The design should be done with style sheets rather than other presentation elements.

Checkpoints.

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

Specification 4. Clarify the use of natural language.

Purpose. Use a markup language to facilitate the pronunciation or translation of abbreviated or foreign texts.

Checkpoints.

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

Specification 5. Create tables that can be easily modified.

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

Checkpoints.

–In table of contents, distinguish column headings from row headings.

In table of contents, which have two or more logical levels of row or column headings, markup should be used to link the contents of the cells to their headings.

Specification 6. Pages containing new technologies are easy to modify.

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

Checkpoints.

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

Confirm 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. Confirm that the user can stop or stop the movement, flicker, scrolling or automatic file updates.

Checkpoints.

-Until access applications allow users to control flicker play, screen flicker is avoided.

Specification 8. Confirm that the user has instant access to embedded functionalities with the interface.

Purpose. Confirmation that the interface environment follows the principles of accessibility in the design: standalone devices with functionality, applicable keyboard, etc.

Checkpoints.

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

Specification 9. Proper design that allows device independence.

Purpose. Use of data that enables data to be activated on a page via input devices.

Checkpoints.

–Provide image maps on the client side instead of the server except for areas that cannot be defined by an available format.

Specification 10. Use of intermediate solutions.

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

Checkpoints.

-Until the access applications allow the users to close the multiple windows, the flow of the presentation from new windows is not interrupted and windows do not appear that change the content that the user sees.

Specification 11. Use of W3C technologies and specifications.

Purpose. Use of W3C accessibility technologies and specifications.

Checkpoints.

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

Specification 12. Providing information for orientation and navigation.

Purpose. Provide information for navigation and navigation to help users understand difficult pages or items.

Checkpoints.

- Give a title to each page box so as to optimize recognition and navigation in them.

Specification 13. Providing navigation mechanisms.

Purpose. Provide navigation mechanisms, orientation information, navigation bars, web map, etc. so that the user has a greater chance of finding what he wants.

Checkpoints.

- the text accompanying a link is comprehensible and explanatory.

Specification 14. Confirm that the files are simple and clear.

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

Checkpoints.

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

Special Specifications of Voice Composition Technology for the support of the disabled

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

Operational needs of ESAEA

Regarding voice composition systems for the conversion of electronic text into speech, ESAEA proposes the following functional requirements that such a system must meet:

- Support of the Greek language.

- Support for the latest version of MS Windows.

Ability to integrate functions into widely used external windows applications (eg Word) through standard application intercom automation.

Ability to connect pronunciation functions to specific file types through the appropriate shell extensions.

- Support for multiple ways to activate pronunciation functions through the operating environment (by selecting text, right-clicking a file, dragging a file with drag'n'drop, displaying functions in the toolbar, etc.).

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

Possibilities of extending and configuring the language repertoire of the application.

- Ability to adjust the tone and tone of the mechanical voice.

- Natural utterance of speech and emphasis. Possibilities of expressing a question or admiration from the punctuation marks of the text (prosody algorithm).

Ability to develop numbers and abbreviations in plain text.

- Ability to integrate into an application server environment through the appropriate programming interface (API).