Software In Zicht

Software in Zicht is an independent conformity accessibility scheme.

What information about the Software in Zicht project can you find here?

Introduction: The situation in The Netherlands, Categories of students, project description, ëaccessibilityí and ëusabilityí.

SIZ 1: Testing software: Guidelines as to when software is ëaccessibleí; conclusion that only 17 programs are fully accessible; recommendations to manufacturers.

SIZ 2: Adapting software: Making software accessible for diverse target groups; contrasting functional needs; didactical issues; technical demands; types of accessible programs.

The remake of the software: What software did we choose to adapt?

††† * Phase 1 A: adapting the existing software
††† * Phase 1 B : building the new software

Evaluation: Inclusion; qualitative and quantitative evaluation; what we would do differently in future projects; future strategies.

Introduction

The project software In Zicht (SIZ) began in 2000, through the combined work of BartimÈus Education, Sensis, Visio (three Dutch institutes offering education for children with a visual impairment) and FOVIG (the Dutch national parentsí association).

SIZ on completion will have achieved:

††† * A series of accessible educational programs
††† * Guidelines for editors and programmers
††† * Insight into the feasibility of ëD4Aí (Design for All)

SIZ is run by Dorine in ët Veld and Dick Lunenborg.

In what follows, weíll highlight some issues that play an important role in the Netherlands and explain what categories of VI students we discern regarding computer use. Next weíll report on the project Software In Zicht.

The situation in The Netherlands

* BartimÈus, Sensis and Visio together support approximately 2500 visually impaired students, aged 4-18, and of all ability levels (including multiple disabled visually impaired).
* In The Netherlands more than 70% of the circa 1600 visually impaired students without mental impairment, attend mainstream schools. The students in the specialist schools often have specific additional learning- or behavioral problems, or light cognitive delay. (Due to the fact that there is no categorized registration, we have to present these figures as an indication/estimation).
* The rate of computerization in the specialist schools is very high.
* All blind and low-vision visually impaired students in the mainstream are equipped with a computer and assistive technology of their own.
* Partially sighted students usually have their own laptop in secondary education.
* In mainstream schools it is very common that students practice and develop skills in maths, grammar and spelling through the use of educational software. Very often, however, this software is not accessible for visually impaired students. This has social as well as educational consequences.

†There are a number of challenges to tackle. To mention a few: (focussing on what we are trying to achieve in our projects):

* Not only are visually impaired students in the Netherlands faced with the problem of inaccessible educational software (and websites), a further barrier is presented by the lack of legislation on accessibility.
* Due to the relatively low number of visually impaired students in the Netherlands, Dutch software manufacturers have shown limited interest in the accessibility of their products and other learning materials to this group.
* There is no physical concentration of VI students; they attend schools right across the country, so it is difficult to maintain knowledge from the teaching and experiences of one pupil for the benefit of others.
* This is further complicated by the nature of the system in place in the Netherlands; secondary education is taught in distinct streams and sub-streams and each school uses its own methods. There are therefore very few visually impaired students being taught within the same stream, and by the same methods.
* Because the students with additional impairments attend specialist schools, here it is simpler to bundle knowledge. Yet for some students who have cognitive delay, motor impairment and a severe visual impairment, no accessible software or websites are available.
* We can state that the problems of maintaining and building up expertise, or developing apt learning materials is difficult for the groups with the lowest numbers and the widest spread in mainstream: low vision and blind students.

Categories of students

The computer is essential in the education of the visual impaired. It is an aid to reading and writing, communication, finding information and working independently or in equal collaboration with others.

For our projects we distinguish 4 categories: those who...

1.††††† use the computer without assistive technology (maybe a larger screen) (40-50 %)

2.††††† require slight magnification (1.5 x to 2 x)† (again maybe a larger screen) (20-30 %)

3.††††† require magnification (> 2 x) and/or speech (10 %)

4.††††† use Braille and/or speech (10 %)

In each category we have students with additional disabilities, such as motor impairment, hearing impairment and learning difficulties. However, as there is no standardised categorisation or registration in terms of ICT requirements it is very difficult to obtain exact numbers for these 4 groups.

Software in Zicht - project description: two phases

In the first phase, 2001-2003, we developed a test protocol for the accessibility of existing software, and specific guidelines for programmers. We tested some 200 educational programs.

The results were compiled in a database which has been made available online along with an extensive resource of related software accessibility information at www.softwareinzicht.nl (the site language is Dutch).

In the second phase, 2004-2005, the testing continues at a slower pace. The project has been extended to include the adaptation of a series of existing educational software. This software is commonly used in more than 60% of mainstream primary schools and covers the key disciplines (spelling, reading, writing, grammar, maths, etc.)

The adaptation will enable use by blind, partially sighted, dyslexic, autistic spectrum and motor impaired students. This is being achieved in co-operation with a key Dutch educational software manufacturer, OWG, which has recently begun upgrading its software and adding speech output. A professional developer of software, QnAp, has been involved since August 2005.

ëAccessibilityí or ëusabilityí

These terms have not been distinguished in the above presentation. It is important to appreciate that a technically inaccessible program can be usable for a specific student. Examples can be found of low vision or even blind students performing well on a largely visual software program, such as on a Nintendo Gameboy game. Clearly factors other than accessibility play a role, such as motivation.

* Intrinsic motivation: the content, the sounds or other features can serve to make the software attractive (enhance usability) despite inaccessibility.
* Extrinsic motivation: the popularity of the program with sighted siblings and peers.

The users of our online database and software testers were encouraged to experiment with the concept of usability.

On the other hand, a technically accessible program can still be user-unfriendly. The text may be too complex for the target-group or level to which the program is intended. Attentional factors may be a problem if a task is too time consuming or unvaried. The database contains an introductory description of each program bearing in mind their usability features (or lack of).

Users of the SIZ website have been provided a means of giving feedback and sharing their own experiences. Teachers and professionals who have received training or attended a course in using and finding software co-ordinated by Software In Zicht have been surveyed for their experiences.

If you are interested or are currently involved in related research we welcome feedback, information of your own experiences and we are happy to share our own. One of our main goals was to provide teachers and parents with up-to-date practical advice: What is on the market, and what programs, or parts of, might be usable for a student with specific special educational needs.

SIZ 1: testing software

Testing was prepared with research. We found several sources of guidelines for diverse programming environments. (Microsoft, IBM Accessibility Center, NCAM (National Center for Accessible Media).) We built a testing instrument, an extensive checklist, based on the guidelines we found, regrouped. We trained testers (teachers of the visually impaired). We created awareness that visually impaired children may still play an inaccessible program, when it is attractive, or when it is played by peers. There are, for example, blind children that do well playing mainstream computer games just by listening carefully to the sounds.

We grouped a ëchildrenís juryí that would verify our findings at random and on ëkids jury daysí.

Guidelines: when is software ëaccessibleí?

We defined our guidelines in terms of how the program should perform. Our main testing issues were...

†† 1. is there an alternative for each mouse action (i.e. keyboard accessible)?
†† 2. can the user work with preferred colour and contrast?
†† 3. are there clear mouse pointers?
†† 4. can the user work with preferred font and size?
†† 5. is there a possibility to maximise programme to fill the desktop?
†† 6. is there an alternative for essential visual information (written text or spoken)?
†† 7. is there effective and consistent lay-out and controls?
†† 8. is there no movement or time pressure; nothing leaves the screen before it is perceived by the user?
†† 9. are Windowís accessibility options maintained in the program?
† 10. are accessibility options clearly documented?
† 11. is it compatible with and accessible when assistive technology (screenreaders, magnification) are in use?

Each issue has an extensive checklist, to be found on our website.

Results

* In the spring of 2001 we set out to test the 1600 educational programs that were available for primary and secondary education. By the evaluation in November 2003 we had tested 200 programs; 10% of the 2000 educational software titles available at that point. Indeed, by that time another 400 titles had been issued since the project began.
* The SIZ website has become well-known, particularly among educators and specialists.
* The project has increased awareness among software manufacturers, drawing a greater interest in the need to accommodate for this group of students.
* Our guidelines have been accepted as an authority by other institutes for the education of students with special educational needs. We were involved in the testing of software accessibility for students with other disabilities, and have made a protocol for the testing of software accessibility for special educational needs besides those already mentioned.
* This project has been implemented in a national database for educational software.
* We have organised courses and training for teachers.
* We have created a central source of information that teachers from all over the country refer to.

Only 17 programs fully accessible

By the end of phase 1 we had tested 200 out of 2000 available titles. By the end of phase 2 we will have tested 300 out of 3000 available titles. (The pace of assessing has slowed down because we have less testing capacity).

So far, we have found that only 17 programs were fully accessible, even for blind students: less than 1% of the programs tested!

All of these 17 programs except for one were either designed for the target group (such as the audiogame Drive), or adapted by editors because of our efforts.

For our category 1 and 2 students the situation was far better, although most programs contained many poorly accessible items.

Recommendations to manufacturers

On the completion of an assessment, manufacturers of tested programs receive a report recommending improvements. The most frequent recommendations are:

Provide a keyboard alternative for every mouse action. Not only does this improve accessibility for all those who cannot use the mouse (RSI, motor impaired, screenreader users), it also increases the quality of the programming, making it more consistent.

Provide options to:

†† 1. enlarge letters
†† 2. set contrasts
†† 3. choose a quiet background
†† 4. enlarge a picture
†† 5. make the program screen-filling
†† 6. choose a clear mouse pointer
†† 7. have an option to stop movement or allow more time for certain actions
†† 8. skip ërewardsí and other ëembellishmentsí in programs that are often experienced by users as annoying or time consuming.
†† 9. have certain texts spoken

Add:

† 10. short descriptions of pictures
† 11. alt tags to buttons and icons with only a picture

Improve:

† 12. Navigation and controls. In some programs it is confusing finding where next to click in an on-screen sequence.

Not only would our aforementioned 4 categories benefit, but the benefits are also obvious for students with motor impairments, dyslexia, Dutch as a second language, those within the autistic spectrum and those with trouble interpreting images correctly.

SIZ 2: adapting software

Still the number of fully accessible educational programs is much too small, especially for our categories 3 and 4. We were therefore pleased that the Dutch Ministry of Education granted us another subsidy after phase one in order to:

†† 1. investigate the feasibility of adapting software
†† 2. make existing software accessible for category 3 and 4 (low vision and blind), as well as for pupils with:

††† * motor impairments (problems using a mouse or keyboard)
††† * dyslexia (since there are large numbers of these students)
††† * autistic spectrum disabilities

We started this project together with OWG, a manufacturer that produces software that is usually designed by teachers. The programs we selected were ëpractice and drillí, very practical and in use in most of our primary schools and many secondary schools.

Obstacles for accessible programming

Manufacturers are often shocked when they receive our assessment reports to find out that their software is not accessible for visually impaired users. At the outset they are willing to adapt the software, but withdraw when they find out :

††† * The small numbers of category 3 and 4 students.
††† * That there are no simple directions for programmers.
††† * That it is rather complicated to test with screenreaders.
††† * That something may work with screenreader A, but not with screenreader B.

As to ësimple guidelinesí: programmers work should conform with MSAA. Many programmers are not familiar with MSAA. Another problem is that MSAA is not well applicable to new programming environments.

Another complicating factor is that most programmers are unfamiliar with the possibilities of low vision or blind users working with a computer.

The conclusion of the manufacturers is that it costs much time, thus money. High time input with low prospects of financial return.

For children with light visual impairment or with dyslexia the situation is better.

††† * There are ever increasing numbers of dyslexic students
††† * The improvements to be made are adding speech and improving layout and structure
††† * This can be tested easily by any programmer

There is one last obstacle to be mentioned. Besides unawareness, lack of expertise and the absence of a financial carrot or a legal stick, didactical problems play an important role. Many exercise forms in software depend very much on what the student sees or has to interpret on the screen, or what the student has to manipulate on the screen. Many exercise forms are not apt for students who cannot see the screen. It might be possible to make a program tell the blind student exactly how a graphic is shown on the screen. It might be possible that he can navigate with the arrow keys and thereby is told exactly what is on the screen. It might even be possible to make a program where he adds a line or a curve to that diagram. But imagine what a tremendous imagination and memory such a student would need if he would have to perform the task without any tactile feedback, or how much training he would need if we would find a way to support this with audio.

All these matters and techniques are still in research or under development. It is likely that within the next decade or so there will be no acceptable or affordable solutions, hence our project 'Filling the Gaps', where we also study the solutions Tactile Tablets can offer.

Making software accessible for diverse target groups

Preparations

When we started the project, the idea was that we would leave the programs we were to adapt as they were as much as possible. Our first priority was to make them accessible with screenreaders. If that could be done, we would continue with necessary improvements on the visibility side. An important issue of the project, however, was a feasibility study. Would this be possible? How much time and money would it cost?

Making software accessible for students with very diverse and even conflicting needs is a complex task! What are the needs of our various ëtarget-groupsí?
†
Motor Impaired

The accessibility requirements of students with motor impairments are mainly that they can use assistive technology instead of the mouse and/or keyboard, such as Intellikeys. If the software is programmed in a very ëstandardí way, and provides a keyboard alternative for every mouse action, it will function properly with assistive technology, and it will allow for accessibility options such as sticky keys to function properly.

Dyslexia

The needs of students with dyslexia are varied. Of particular importance are:

††† * Font and font size
††† * Contrast
††† * Quiet background
††† * Option for text to be read aloud
††† * Clear and consistent lay-out
††† * Flexible time-pressure (must allow extra time if necessary)

Technically speaking, dyslexic students have very much the same needs as our category one and two students.

Autistic spectrum

The needs of students in the autistic spectrum are even more diverse. Generally these students require a clear structure and predictability. Some students may be upset by specific colors or color combinations, or by sudden sounds or movements.

Partially sight

There is an enormous range of variation here. Weíll not go into medical details, but rather focus on what the student needs; what can they see?

To get an idea of just a few variations look at: http://cita.rehab.uiuc.edu/software/vis/?status=home. Here you find simulation software.

Some students need magnification, others by contrast, experience tunnel vision and need reduction to get the whole picture of something. Some need high contrast, others need dimming. Some see colors differently (various forms of ëcolorblindnessí). Some need more time because their vision is irregular; sometimes they notice a detail, sometimes they donít. Moving objects often present a problem. Some can read text, but long texts take too much time and are too tiring for their eyes.

Part of this group works without assistive technology. Often a large screen and the accessibility options of Windows provide enough help for them. That is, in programs where these options work (which is often not the case in educational software). We took this group as ëcategory 1í, see Categories of students. This is a fairly large group: 40-50 %. Some use additional speech for longer texts.

A second large group of partially sighted students, 20-30 %, use magnification, mostly factor 1,5 to 2, mostly Zoomtext or Supernova. These programs allow change of color and contrast, all kinds of magnification, and several ways of presenting text. For reading longer texts ëcategory 2í often use speech.

The larger the magnification is, the more important it is that there is a keyboard alternative for mouse actions. It takes many mouse miles to get to the next clickable item with magnification factor 4. Also it may be very difficult to find the next clickable item, if the layout is not consistent and buttons have a different location on each screen. Moving objects often present problems. You see something moving, but what is it, or where is it gone? Enlarged pictures may be unclear or it may be impossible to get an overview. Many students in this category (3), about 10%, are very much depending on the text being read out to them, pictures being described and clear and consistent navigation.
†
Blind

The group dependent on speech and, provided they can learn and use it, Braille, is also about 10%. Only an estimated 20% of the blind students see nothing at all. 80% may see where the light comes from, may discern brighter spots on the screen or may, with their nose again the screen even see some details/parts of the screen. Sometimes these students see only one spot, sometimes they see nothing on the centre of the screen, but discern things in the periphery of the screen (often not very sharply).

Contrasting functional needs

Studying all these needs, we see similarities as well as conflicts. To simplify matters: for all those who can use the mouse and see the (whole) screen (dyslexia, autistic spectrum, category 1), lay-out is of utmost importance. For this group clear pictures may be simpler to use than text (although there certainly is a group that has difficulties in interpreting images).

This goes for our category 2 as well, provided the screen is designed in such a way, that magnification is unnecessary. In other words: as long as it is possible to magnify letters and/or images, and not the screen itself. If the screen is enlarged twice, only one fourth of a normal screen is visible, so many items are out of sight.

For category 3 and 4, the layout is less important or without relevance, as long as their screenreaders can get them everywhere and read out all of the text and/or display it in Braille.

But here lies a source of conflicts of needs: most (newer) educational programs are self-voicing with either .wav files or synthetic speech. It is impossible to listen to both the speech of the program and the speech of a screenreader at the same time!

Motor impaired students are somewhere inbetween. If they have no visual impairment or dyslexia, the only thing that is important for them is that there is a keyboard alternative for mouse actions, that it is unnecessary to press more than one key at a time, that time pressure can be adjusted and/or movement can be stopped.

Didactical issues

Real tough questions however are of a didactical nature. What if a student cannot see the geometric figure that is shown or rotated in various directions on the screen? Or if the student is asked to interpret an image, for example a map or a diagram? Or if the student should draw a line or manipulate an image?

We work on this question in another project: ëFilling the Gapsí, but it cannot go unmentioned here. And we do encounter this problem in the adaptation of the series of software that we are working on.

What are the problems? You can add description (and sound) to images (video, diagrams, schemes and so on). This is the only way for a blind person to have an idea of what is visible on the screen. However: often a tactile overlay to explain properly is indispensable. With objects disappearing or moving on the screen it can be very difficult to keep track. Only the more able students will be able to do this.

Finally, if you describe for example a line in a diagram or an area on a map you give away the interpretation you might want to train with the sighted students. Giving enough information without giving away the answers is yet another difficulty to work around.

Technical demands

A final issue that cannot go unmentioned because it plays a key role in the adaptation of software is of a technical nature. In order to be able to use a program with assistive technology, there are some technical demands. For example, magnification must not lead to crashing, the ëfocusí (active area) must be followed, pictures must stay clear when enlarged.

If a screenreader is to read text (speech or Braille), the program must be programmed with items the screenreader knows. Unfortunately different screenreaders may approach the same items (buttons, radio buttons, dialogue boxes, text fields and so on) in a different way.

Surely there are guidelines for accessible programming. Youíll find them for example at Microsoft, IBM Accessibility Center and NCAM (National Center for Accessible Media). If you take a look there, youíll find long texts. It takes quite some study to know all about accessible programming.

Simple and clear instructions for programmers in different programming environments on how to prevent a specific screenreader to read things we do not want it to read, do not exist. Screenreaders for example may pick up pieces of programming code that are not visible on the screen and that you donít want them to read at all. It is very much a matter of trial and error. Mainly error! We think this is a situation that cries for improvement, if we ever wish to create accessible educational software that can be used with screenreaders.

Screenreaders do provide an option to direct the spoken content on a given page. You can tell them what to read and what to ignore. This is painstaking and timeconsuming work that can only be performed by sighted (and often expensive) specialists. The ëmapí created will only work in a specific configuration. A teacher or parent will have to install it, which again is a rather advanced activity. In other words, this is not a feasible or user-friendly option.

In a scheme, assembling functional, didactical and technical demands:
†

†

Types of accessible programs

There are basically two types of accessible programs:

†† 1. Screenreader accessible. For example: Word, Internet Explorer, Outlook, Excel, Powerpoint. Output in speech and/or Braille. Graphical functionalities are not accessible within these programs.
†† 2. Stand alone, self-voicing programs. Tell you what to do next. No Braille or speech output. Speech of the program conflicts with screenreader speech: either one (the latter) must be switched off.

Our ideal was to convert software into a version that would belong to both categories at the same time: screenreader accessible and with all the features that would be beneficial not only to partially sighted, but in fact to everyone.

The remake of the software

What software did we choose to adapt?

OWG, the editor-partner in this project, issues a series of practice and drill software for primary education. It is in use in over 60% of the primary schools in The Netherlands and Belgium. We thought that a good thing to start with, more so since all programs are designed by teachers and can be used with any method. In a number of programs, the teacher can add (downloadable or home made) wordlists.

Apart from this we thought it was a good choice because:

* Firstly it was software that didnít seem too far from being accessible and it was just about to be upgraded. It's already self-voicing. The adjustments would render the software as more usable for dyslexics, of which there is a growing number. With speech the program would be more attractive and user friendly for everyone. This seemed a very apt moment to include other Special Needs features as well.

* Secondly we had done a pilot with a program of the same series: Playing with Words. We were not quite satisfied, because there were quite a few bugs. They obviously were caused by the adaptations. Software is like a house of cards... donít try to remove a card! But we were optimistic that we could find a way and we planned to redo this program to fix the bugs.

* Thirdly, it would be very useful the blind and severely visually impaired students, for whom access to current titels was most restricted. The situation was such that for a blind student to practice for example spelling, this would require his teacher to manually prepare examples specifically for this student, for example in Word. After the student has completed the exercises, he then has to wait for them to be corrected. In this case thereís a lot of time between the exercise and the feedback.

Alternatively, an adult sits to practice with the student. In this case there is direct feedback but no possibility for independent autonomous study and interactive feedback from an engaging computer program.

It also seemed feasible. We had a very small budget per program: 36 hours only for accessibility testing and redesigning by the SIZ-team, and 2.500 Euro for reprogramming and testing the end version. All programs in the series have the same basic interface, so we would have to redesign the main interface just once, and next adapt the exercise forms per title, which on average there were 8 of. But still, we would have to work very efficiently.

In year 1 we planned to adapt 12 titles (phase 1A) and we would investigate 5 totally different programs on ëadaptabilityí (Phase 1B). After that we would decide on 8 more titles to adapt (Phase 2)

First 12 titles choosen to adapt:

††† * Playing with the Alphabet / Spelen met het Alfabet (learn the alphabet)
††† * Playing with Words / Spelen met Woorden (spell words); a ëredoí
††† * Letterrain / Letterregen (spell, mark syllables, flash-words and so on)
††† * Toetsie (learning to touch-type)
††† * Tables / Tafels (multiplication tables)
††† * Top 100, 4 programs (the hundred-table: count, make ëtensí, add, substract)
††† * Divisible / Deelbaar (dividing)
††† * Sssplitsss (split digits, for example: 5 can be split into 1 and 4 or 2 and 3)
††† * Decimal points / Kommagetallen (put the decimal point in the right position)

The programs work as follows. A student selects his group and name. Next he can either choose an exercise, or, if the teacher has set out a path, directly enters into an exercise. Each title has a theme. Each theme has a series of varying exercises. Each exercise contains a series of tasks. How many tasks the student has to perform, is regulated in the teacher part of the program. The teacher also sets how much time the group of students or a particular student gets and how many wrong answers can be given.

The student gets direct feedback from the programs: was the answer right or wrong; can he try again? If a wrong answer is given, the right answer is revealed. If the teacher chooses the option, the task will come back later. The programs administrate how the student performs, so the teacher can monitor the student's progress.

Phase 1A: adapting the existing software

What had to be improved

††† * There was not always a keyboard-alternative.
††† * The programs were not screenreader-accessible (see first point: buttons had no labels and most exercises were mainly graphical).
††† * With magnification the focus was not always being followed
††† * With magnification question- and input-fields were often spaced too wide apart
††† * Tab-order or arrow-order (if present) was often random
††† * Contrasts werenít always sufficient.
††† * The letters in the programs were often too small for partially sighted and dyslexic students.
††† * Layout was sporadically inconsistent, for example buttons changed places.
††† * Many screens were too full and busy; real picture puzzles for most partially sighted.
††† * The title bar should bear the title of the particular screen instead of the name of the program.
††† * Spoken help and/or description or sounds indicating items on the screen were needed.
We started with Playing with the Alphabet. First we focused on the general part, the main interface, which would be (almost) the same in the other programs. After that we did the exercises.
Adapting the general part: a learning process
First you got into a welcome screen and then a second welcome screen; we combined these:
Old start screen + Old second start screen
First design new start screen

+

†††††

†

We arranged the focus order (the red numbers in the screenshot above), told the programmers (how) to make the program keyboard-accessible and added a welcome text, explaining the program.
Here we met our first problem: adding speech. You want enough, but certainly not too much. The description must be simple, and clear. The text in the example above is too long and too complex; it contains too much information. It tells the students that they can at any moment ask for help or change colors and font size with the buttons on the left or with the corresponding function keys.
Not only the quantity, but also the description itself often caused problems. For a blind student you need more explanation than for a student that can see the screen.
Much in this first try-out changed. First of all the buttons. They got ënamesí (like Help, Explanation, Score, and so on). Originally we wanted to give all students the options of changing the appearance of the programs. But research and interviews with experts taught us that for many children in the autistic and dyslexic spectrum too much choice is a problem. They need structure. It should be the teacher deciding which student can make the choice by himself. Students who can make the choice by themselves get a ësecret keyí from the teacher.
Here you see the end result:
New start screen

The program says: Weíre going to practice the Alphabet. Click OK to start.
For blind children we provide extra information for first time use: the focus is on the OK button when this is said. All they need to do is press space bar or Enter.
The other buttons are Help (tells you the hotkeys) and Stop. They are clearly visible, and when the mouse is over them there is spoken help. The focus is shifted with a press of the Tab key. So simple! (Incidentally, this screen could have many other color settings; and in the final version the letters will be bigger).
In the following screen you have to select your group and name. Letters were too small for dyslexic users and most partially sighted children. The contrasts were also too poor.
Old application screen
Design new application screen.

When we had a trial version we found that for most partially sighted students it was very difficult and for the blind students impossible to enter their name in the given field, so we added an option ëfree choiceí. Under this option the child is not monitored. Often children are allowed to work on the computer for a while as a reward. If not, the teacher generally will set out a path for a group or a specific student. In the present version both selections are very simple for everyone, as you can see in the example below.

Note how the buttons never change place. The active buttons are grey. The inactive buttons are only indicated and have grey letters. This may seem an illogical choice, but this way there is always good contrast for the active buttons. (There is no option to choose for a grey background as you will understand).

†

†

†

†

†

As you see there is a new button. When pressed (e.g. Tab + Enter) there is a pop-up screen explaining what you can do and how you can do it (without a mouse). You leave that screen with Escape.

†

†

In the next screen the student has to choose an exercise and sometimes a level. (If your teacher made settings, you will skip this screen and go directly to the exercises).

†

†

Here you see a big screenshot of what this screen looked like in the original program. This is what the screen looks like now. Even a small screenshot shows that the letters are big enough and the contrast is good.

†

†

†

New exercise screen

At this point students who are allowed to change the appearance can go to the option screen.

Adding an option screen

With the above analysis of all the needs and demands in mind, it is clear that flexibility is important. We wanted students, or their teachers, to have option to customise:

* Colour scheme of text and background.
* Font size and font weight.
* Speech options:
- speak all
- speak tasks only
- speak nothing (for children who donít need/want speech and for screenreader-users)
* Button options:
- Buttons
- No buttons (for students who work without a mouse, hotkeys are better; and for screenreader users it is simpler if there are no buttons; they do not need to tab so much)
* Feedback on the input of a right or wrong answer:
- Picture feedback
- Animations / no movement
- A funny sound (indicating right or wrong answer)
- Spoken (for example: ìGood!î, or ìTry againî).

Screenshot of initial design for option screen

†

Option screen

Originally we had wanted the choice for buttons to have pictures or text. For many children pictures are helpful. But that proved incompatible with the option of changing the background and letter combination. If one would choose a black background, the black parts in pictures would remain black and become ëinvisibleí. We had to skip that option.

Below you will find a few examples of what the revised option screen looks like. The option no buttons has moved to the teacher part, as has the choice for the kind of feedback.

blue on green

†

In the following yellow on black combination you might find the text on the buttons less clearly visible. We don't consider this a big problem: it is easy to find the active buttons and after using one program you know what is on them. If not, you have the spoken help anyway. Some combinations seem surprising, but we learnt that children sometimes have funny preferences or just like the fun of changing.

†Yellow on black

Orange on red

†

†

†

†

Adapting the exercises ñ new challenges

Our starting point had been that the programs should be fully accessible for the group for whom there is hardly any educational software available: blind and severely partially sighted students. We wanted Braille output for them, not only audio. Sighted users would be able to see the letters and digits; Braille users should have them in Braille.

When using the program with a screenreader, you have to be able to switch off the speech of either the screenreader or the program. In the general part, we had no major problems here. The exercises were a different story.

We found, that, as soon as you have other exercises than ëlinear onesí...

†† 1. question ñ open answer (to be typed)
†† 2. question ñ multiple choice (to be selected)

...there were insolvable problems when using a screenreader alone.

For example: what would you do without the sounds and speech of the programs in situations where a child has to count objects. It is possible to make the program beep when you bump into an object while navigating with arrows. But you cannot make the screenreader do so.

We also encountered problems when a student has to perform several tasks before he can give the answer. For example: first tell how many Ö, then how many Ö, then multiply both digits and give your answer. Or when the student has to drag and drop several items. In these cases he must be able to navigate freely on the screen and keep track of where he is and what is where. Impossible! The screenreader then must ëfollowí. But screenreaders follow their own rules! And this applies not only to the speech, but to the Braille output as well!

This was affirmed by another investigation we did at BartimÈus Education. One can tell the screenreader to change its normal routines and procedures and to do this first and then that, where it would normally follow another procedure, but only if you address the program that is operating the screenreader.

That would be possible technically speaking, but not within the budget we had:

o†††††† it takes a lot of expertise (specialized programmers)
o†††††† it takes a lot of time to program
o†††††† the software you need is very expensive (Ä 25.000,-)

It was not a desirable option either, since one always gets a configuration-specific program. As soon as there is an upgrade of the operating system or the screenreader software (which quite often happens), you need to revise it.

Changes in the project
†
We started January 2004, it was May 2005. By this point we had had so many bugs, that we hadnít been able to properly test the trial versions on accessibility or usability with the target group. We had only one program, Playing with the Alphabet, crashing all the time. We felt a slight panic rising. Time ñ and budget ñ were soon to be running out. The project should be finished in December 2005.

Both OWG and the SIZ team took drastic decisions.

Decisions of the SIZ team:

a.††††† The SIZ team had to take a very regrettable decision. We would skip Braille output. The programs would be self voicing and would be audio-accessible.

In order to work with the program without seeing the screen at all would require either extra spoken help or a little extra introductory explanation. We chose for the latter in order to prevent too much speech in the program, which would be irritating for sighted users. We had already planned to make tactile screenshots for blind students with a little explanation. We could add here the necessary short introductions.

Because the programs are so consistent, blind students need this introduction only the first (few) time(s). They soon develop routines.

b.††††† We also had to give up the thought of adapting more programs with the same interface or even programs with another interface. We had been investigating 5 of them, that were very much text-based, as to whether they could be made screenreader accessible.

In fact these programs were very much ëdigital booksí with exercises (question and answer type) in between. It would not be particularly difficult to make them accessible. It was a matter of providing keyboard accessibility, options for colors and fonts, adding tags and descriptions. Adding descriptions would improve the content, since not all students would look at the pictures properly or pick out their topics. And it would enhance their verbalizing skills. There were some maps included; they would have to be provided in a tactile form.

They were in fact very suitable to be made web-based. A web environment can be made accessible thanks to the W3 consortium. DAISY format would also be possible.

The results would have been very accessible but it would be a lot of work. We decided not to do it; not only were we running out of time, these products appeared to be at the end of their life cycle too.

The new plan was:
†† 1. Make the 12 titles self-voicing.
†† 2. Make short introductions for screenreader users (and their teachers).
†† 3. Make a program screenreader-user accessible (program number 13).

This program number 13 would be a bit experimental, giving alternatives for exercises that would not be accessible with (only) audio. It would be a framework program, where the content, in the form of question and answer or multiple choice would be made accessible for a screenreader-user with Braille output.

Decision of OWG:

At first we tried to adapt the software. After more than a year of bugs, OWG decided to hire a new programmer, QnAp, who would build the programs from scratch.

This proved a breakthrough, since for the first time during the process we had trial versions that would work properly and not crash all the time. Finally we were able to to test our ideas on accessibility and usability.

Results of this decision:

Of course this lead to new insights and changes here and there. And again to a lot of unforeseen work. However, OWG was pleased with the results and decided not to have Special Editions, but to do away with the old versions.

This was very positive news not only from the perspective of inclusion. It also meant that we could change, skip or add exercises. We didnít have to ëstick to the originalí; this was the new original.

Now would it not be great if after all, with such splendid programmers, it would prove to be possible to have Braille output, or just only the questions and the answers. We had skipped the no-buttons version, since that would be less work. Now we re-introduced it and ñ a miracle ñ a test proved that we got what we wanted on the Braille display!

Not quite though. Screenreader JAWS gives good results. Hal however (Supernova) doesnít simply display the question. It can display the question, if one uses advanced options. But that is not user-friendly, especially not for young children. This means that all the questions must be rebuilt into a read-only edit box that can have the focus. As we would have done in program 13Ö

Another problem still is that Hal does not cope well with the (new .Net) environment QnAp uses. But JAWS does, so letís hope that the manufacturer of Hal fixes the bugs!

†

Phase 1B: building the new software

†With a newly designed, rebuilt software, we were able to test the programmes on the target group.

Above we described what had to be improved: keyboard accessibility, consistent layout, voice-over, etc. Here weíll show you how we proceeded. The font size, the clear and consistent layout and the voice-over make the programs apt for dyslexic students wanting to practice the same as everyone else.

Though it is difficult to appreciate the changes without hearing the audio and experiencing the easy navigation, we give an impression showing screenshots from the original version (left) and the beta-version of December 2005 of Playing with the Alphabet. Please remember that a teacher can decide what type of feedback she wants for a particular student (for example in the autistic spectrum).

We show different colour combinations. The pictures in the white field still need improvement. But they are not the ëcore-businessí. In our approach the visual elements are separated from the actual exercises, to create an equal and quiet background and a clear layout. The student can focus on the exercise.

What comes before

†

The student must type the letter that comes before (alphabetically) the two letters given (alphabetically).

The letters on the original are bigger. Children who need this size will use magnification. On the right, even with magnified both original task and answer remain visible on screen.

†

What comes in between

†

The student must type the letter that comes between the two letters given.

On the left: the fortune-tellers' crystals have letters in them. There are hands over them that are not very recognizable. When you press the button on the left in the button-triangle letters start rolling in the outer crystals. You have to press the upper button to stop. Then you can type the letter that comes in between.

On the right you see exactly the same layout as in the former exercise, yet with no need to find out what is where and what is required.
†

†Which letter disappeared?

†

†This is a real picture puzzle for partially sighted and dyslexic children: it can cost them a lot of energy to find the red question mark in the picture frame around the cat. Mark how the feedback picture has changed position. On the right: the familiar layout. The exercise is simpler visually but didactically equivalent (the child has to type the missing letter in a random part of the alphabet).

†

Which letter doesnít belong here?

The child must read the given letters and decide which is the wrong one in the line.

In both cases (old and new version), when the child has to type that letter, there is one position for input. After an answer is given, the right answer is displayed. On the left there is yet a new way of displaying this, on the right we find the by now very familiar method.

Put the letters in the right place

The child has to drag and drop the letters below the ladybird to the right spot. A nice exercise, but very problematic for children who do not see well, and for children with a motor impairment that use assistive technology requiring keyboard accessibility.† By putting the letters into two rows we have a didactical equivalent again. A child can do this exercise using the mouse or using the keyboard.

Finish this row

Only the first letter is given when the exercise starts. The child has to type the following 4 letters. The input is put on the kettles. A child that works with magnification factor 1,5 or higher will not be able to see all letters at the same time on the screen. The letter jumping away might distress or confuse certain students. Other students do not miss this feature when itís not there.

†

Did we manage to make the exercises accessible for all? Yes, we think so, but still, there are a few exercises that are very difficult to do when you do not see the screen at all. As in ëPut the letters in the right placeí.

In the present version the letters in the upper row that are selected (and are grey on the screen) are not disappearing from the Braille display. So the exercise is much more complex for a blind child.
†

†It can be difficult for some students to ëkeep trackí; where am I? You can also find out by pressing F5 which will read the present order of the words. Then you tab and hear what word has the focus. If you hear ìjournalistî you know you are in the last position. Suppose you want to move it up, you press Enter to select the word, press the up arrow twice and the word is now moved into the first position. You press F5 again to check if all went well. In fact, it is simple and logical. But there may be students (young children) who will find this fairly complex. That is why we add two new exercises, especially for children who can use only audio. (There is a category of students that cannot use the Braille display because of motor impairment or because they are not able to learn Braille).

The first new exercise gives only two alternatives: which word comes first.

The student just has to press (Tab + spacebar) the right answer.

†

The screen design shows the situation after a wrong answer has been given and the right answer is displayed.

For 'put the letters in the right place', we provided a multiple choice alternative. The child has to type 1, 2 or 3. After a wrong answer is given, the right answer sounds and will be indicated.

(The screen design below ñ as with the above one ñ is a ërough sketchí in paint; the red numbers in the design will disappear; they are just there to indicate the focus-order).
†

†

†

In January 2006 we will test the programs with children. The results (findings and changes) will be added here in due time.

This software is easily translatable into other languages. If you are interested, please contact us.