The ATbar works with any desktop browser. It is a toolbar that does not have to be downloaded but can be added as a favourite or bookmarklet and allows users to personalise the way they read accessible web pages. It was originally designed as a result of the comments made by students on the LexDis project at the University of Southampton, who found it difficult to read web pages without their assistive technologies. These were mainly dyslexic students who didn’t always have their text to speech software available on the network or in the library.
The plugins on the toolbar allow for the increase or decrease of font sizes, changes to text colour and font style, increased line spacing and different coloured backgrounds. The students didn’t wish to enlarge pictures at the same time as text so although it is possible to ‘zoom’ in any browser this additional support for the text was felt important. It is also possible to toggle a coloured overlay in pink, green, blue and green. The text to speech works when you highlight the text as does the dictionary with single words, which offers definitions from Wiktionary. There is also the ability to use word prediction if typing is slow and the spell checker for the forms that do not offer this feature.
Each of these features is a separate plugin and there is the facility for not only developing plugins and testing new plugins but also for linking to other plugins via the marketplace, so the complete toolbar can be changed or personalised to suit a user’s needs. This means that the toolbar is highly flexible and it also has its own version control system, and bug tracking and constant updates.
The development of the toolbar occurred over two years and was launched on to the University of Southampton website via the accessibility tools menu. The statistics for uses, as it is only possible to track the number of times the toolbar is downloaded or added to a web page as embedded code has now reached over six million.
The challenge of localisation came when the Mada Center in Doha asked for the toolbar to be developed in Arabic. This was a culture, language and environment with which none of us were accustomed. One of the most important things was to immediately set up a very clear tracking system (Github) and make use of a blog to communicate progress. This proved to be very helpful as it provided a diary of events linked to the development and the issues that arose over time. We have been able to use it for many of the links in this case study.
We also provided a wiki page with instructions for each plugin in Arabic. We found that Media Wiki and WordPress were not only accessible to most assistive technologies, including screen readers, but also easy to adapt to the Arabic language with its written form being bidirectional but mainly right to left (links to a useful article on the subject). One of the major issues was the fact that when using a language that goes in the opposite direction to the one you’re used to there is a tendency to forget which side of the menu system the language should appear from. It should also be noted that numbers in Arabic go from left to right and mixing Latin and Arabic alphabets is not conducive to easy spacing on a page. There were times when dialogue boxes were forgotten and text would appear from the incorrect side.
There was much discussion about coding and the issues with implementing certain cascading style sheets correctly. Using the correct language for Menu systems was a challenge in that the vocabulary used by software and web developers is often not recognised in another language and so there were some words that could not be directly translated. We had to choose the nearest option which at times did not appear to make sense to us. There was much dependency on those who spoke Arabic with a certain amount of trust as we were unable to understand what was being said on our own website. Don’t ever try to use Google translate to test out whether something makes sense if you want to know what is really there!
We were careful to use icons that where acceptable in both cultures and were wary of using some videos or certain images on our blog that might cause offence as this was a cross cultural project. One of our saddest moments was when we realized that the quality of the free text to speech voice in Arabic was so poor so for the time being we are unable to use it, although it is available. We hope in the future to amend the situation. We also discovered that Windows 8 does not offer the complete switch for everything from English to Arabic as they do not have an Arabic text to speech voice available at present.
Without the help of our Arabic postgraduate students we wouldn’t have been able to undertake this project as none of the developers spoke Arabic. We also had the support of the Mada Centre for testing, which was crucial for the further development of the toolbar. However, it was noted that the Acapela voice used by the toolbar for the text to speech did not have a Qatari accent and this remains an issue although it came out best in the user testing.
We also had to develop a completely new Arabic dictionary as the Arabic version of Wiktionary was so poor. The new online dictionary offers both definitions and stemming and is the first of its kind.
We were lucky enough to be able to integrate an Arabic word prediction program called AIType and have embellished the spell checking feature with the help of several free vocabulary lists and Maraim and Nawar’s support.
It is important to remember that text in Arabic tends to need more space, especially if diacritical marks are used as it is a cursive script and needs a very clear font. There were several other items of importance that we learnt from Fadwa’s work and these have been written up on the blog under the title “A framework that might help those developing Arabic software and websites”.