This last feature makes Farfalla read aloud the contents of web pages. When the project will be stable, all this tools will be selectable in accordance with the specific needs of every user. Vocal browsing can be useful to people with visual impairments.

I prepared another video to show these features, it can be viewed at the demo page again.

I plan to publish the code before the end of June, I need to clean it from some rubbish… Then I will go on developing the base features, starting from a user authentication and preferences module.

The video is available at the demo page.

For example, parsing the DOM tree of a document we can find every common inappropriate usage of some HTML tags and correct it, making the page ready for further processing. We can also change the CSS properties for each tag, so we can evidentiate some parts of the documents we are browsing. There is a lot more things we could do working on the DOM tree through Javascript, but there is a big problem, too: for security reasons, it is only possible to access documents which reside on the same domain where our Javascript does.

A PHP wrapper was built to overcome this issue: it uses the function file_get_contents() pointing to an external URL to read the HTML included into any webpage. This means that getting contents from external URLs must be allowed by the webserver we are working on. Through this method we can receive the whole content of a web page and put it into a variable. If we simply try to print it on the screen, we receive a page with the whole text but without (almost) any images and, probably, without any css formatting. This is because getting the file content we actually copied the HTML inside one of the documents of our webserver, but the relative path of every link, and also the “src” of every image still searches inside a relative path.

Luckily, HTML has an instrument for this kind of problems: it is the <base> tag. It has to be put in the header of the file we are rendering, and that is very simple using PHP and some regexp replacement. This tag takes an url as an “href” attribute, making every relative link in the page use that url as a base for its path.

We also have to extract the path to the page we are currently browsing. This can be done using the parse_url() PHP function, cutting off the unneeded parts of the url (mainly the filename and its get options) via regexp replacement again.

There are only three active pages besides the home page, but others are coming with docs, pictures and other downloads.

In the demo section you can now try a couple of working demos of the original project, but I will (hopefully) publish the rest of my work very soon. I am still working on the functionality which allows Farfalla to render web pages correctly and I will only release a new demo when this is fixed.

Any comment on these articles will be appreciated!

At the bottom level there is a database, which will be used to store the user settings and the vocabulary. Then, linked to the database by an abstraction layer, there is the core application, which consists of a virtual browser inside a common web browser.
On an upper level there will be some modular instruments. Thanks to them, users will be enabled to choose between different writing tools and output channels. Browsing the web and filling forms will be accessible after choosing the appropriate modules.

Recently I have been thinking about how a new user can configure his new account on an ipothetical Farfalla server.The best introduction to an accessibility program would be an accessible registration form, where the first login and configuration procedure should be simple and effective. I think the best interface for this would be a “multisensorial” one. A list of questions, both displayed on the screen and read by a synthetic voice, should be readily accessible for the major part of users.These questions should ask about the needs and the preferences of the new user, proposing useful combos of instruments: if someone chooses a scanning writing system, it would be useful for him to also have a word prediction system up and running. It would be useful, even if not mandatory: it only depends on one’s actual ability to move on the keyboard.This user configuration procedure should also be flexible: as Farfalla is meant to become a modular instrument, with the possibility offered to other developers to add new features, the configuration has also to be modular and it has to provide the developers with the possibility to simply add their options in a standardized way.

An abstraction layer is “a way of hiding the implementation details of a particular set of functionality” [Wikipedia]. To give an example from everyday life, we could say that when we drive a car we use an interface (the steering wheel) to command the hardware (the wheels): the wheels don’t turn directly at our command, but there is some mechanism (probably power steering) which helps us and makes the steering easier. That mechanism acts in a very similar way as an abstraction layer does.

Now imagine a car where you can choose between using a steering wheel and some other gadget, as a handlebar or a joystick. It would be very useful if the power steering could receive its inputs and translate them into a standardized output for the wheels. In that case, it would probably be the best abstraction layer you could imagine.

Since farfalla is web based, the abstraction layer will be between the user interface(s) and the web-browser. It will consist in a intermediary program which can receive input directly from the keyboard or from another program, translating it directly into something that the web browser can easily understand.

It should also provide a way to receive data from the web browser and translate it into a more accessible way, for example in plain text.

This whole work will be done using Javascript and probably AJAX methods.

There are some well known issues in cross-browser compatibility, so the project will initially only support the Mozilla Firefox web browser: it is free and open source, cross-platform and also installable on a pendrive.

The main resources for this project are:

1. the precedent research experience with a disabled person, who has already contributed to the project in its earlier phase;
2. some experience in web application development, with a special interest in accessibility and usability.

The main objective is to create a versatile instrument, so the “problem” will be seized in smaller parts. This will help to maintain it as flexible as possible. It would be useful to build a sort of abstraction layer between the hardware and the common software, for example between the keyboard and the web browser. This layer could act as an interpreter, translating inputs received from almost every source, which could be hardware or software as well. Some modular software aids could then be written, to emulate already-existing aids or to make new ones available.

Now the most important thing to do is to gather information from companies, research centers, associations and firms which already have experience in this topic.

Every point of this post will be discussed more in depth in the following posts.