A Browser Scanning Add-on for Users with Motor ...

4 downloads 291 Views 173KB Size Report
is currently under development, future work issues and evaluation plans are also discussed. ... compatible with Mac Operating Systems and none with Linux. Rationale for an ..... Mozilla Developer Center: WAI ARIA Live Regions/API Support.
FireScanner: A Browser Scanning Add-on for Users with Motor Impairments

Stavroula Ntoa1, George Margetis1, Constantine Stephanidis1,2 1

Foundation for Research and Technology – Hellas (FORTH) Institute of Computer Science N. Plastira 100, Vassilika Vouton, GR-700 13 Heraklion, Crete, Greece {stant, gmarget, cs}@ics.forth.gr 2

University of Crete, Department of Computer Science P.O.Box 2208, GR-714 09, Heraklion, Crete, Greece

Abstract. The web has become the most commonly used gateway to information, commerce and entertainment. As a result, accessing online resources without any barriers has turned to be of utmost importance for all the citizens of the Information Society. One common obstacle faced by users with motor impairments of the upper limbs is their difficulty to interact with a computer application using standard input devices, such as the keyboard and the mouse. This paper presents a browser add-on, named FireScanner, providing access to the web for people with hand motor impairments, through the scanning technique.

Keywords. Firefox, add-on, extension, scanning, motor impairments, accessibility, web.

Introduction Recently, the web has become very popular and constitutes a key resource to information, commerce, education, entertainment, and government services, displacing other traditional resources of information and interaction. Therefore, the need for accessible web resources has become fundamental for all users, including the elderly, children and users with disabilities. This paper presents a browser add-on, named FireScanner, aiming to provide access to the web for people with severe motor impairments of the upper limbs. The main barrier that these users face in their interaction with computer applications is the demand to use traditional input devices, such as the keyboard or the mouse. One approach aiming to alleviate these interaction difficulties is scanning, a method that

enables motor-impaired users to work with an application by using only appropriate assistive technology (such as binary switches), overcoming in this way any problems related to the inability to use traditional input devices. In the following sections, the architecture of FireScanner, as well as its functionality, are presented. As the add-on is currently under development, future work issues and evaluation plans are also discussed.

The Scanning Technique Scanning [15] provides access to all the interactive objects composing a graphical user interface, which are sequentially focused and highlighted by a focus marker in a predefined order (e.g., from left to right and from top to bottom). Users can select to interact with the object currently having the focus by just activating a switch. Furthermore, an on-screen keyboard supporting scanning is usually provided in order to eliminate the requirement of typing text via the traditional keyboard. Activation switches can vary from hand, finger, foot, tongue or head switches to breathe-controlled switches or eye-tracking switches [1], [6], which are connected to the users’ pc through an interface. Switch interfaces are used to connect switches to users’ computers and emulate certain mouse or keyboard functions [4], [5], [17], such as pressing the space, enter and tab keys, or clicking the mouse. Scanning has been a popular technique during the last decades, due to both its accuracy and relatively low cost for the end user, and as a result a plethora of scanning approaches have been developed. These scanning approaches can be in general classified in two major categories: applications with embedded scanning and generic scanning tools. Scanning applications are designed and developed to embed scanning techniques inherently. Their main drawback is that due to their limited scope users with motor impairments need to employ different scanning applications for each interactive task they wish to carry out with their computer (e.g., browse the web, read and send emails, compose and edit documents, etc.). Scanning tools, on the other hand, enable users to operate the entire environment of the operating system and interact with any application [2], [7], [18], [16], [3]. One important concern regarding scanning tools is the interoperability issues they face. For example, most of the scanning tools referred above have been developed to operate only with Microsoft Windows operating systems, while just one of them is compatible with Mac Operating Systems and none with Linux.

Rationale for an add-on approach The scanning browser add-on (aka extension) presented in this paper aims to provide easy and free access to web resources, lifting the need to use specialised software and devices or specific operating systems. Having this requirement in mind, the add-on has been developed for the Mozilla Firefox web browser [11], which is a popular browser running in the majority of operating systems employed by users

today, such as Microsoft Windows, Linux distributions, Mac OS, etc. The main benefit of this interoperability feature is that it allows testing the behaviour of the addon over different computer architectures and operating systems, and as a result addressing the needs of a wide-ranging target computer user group and finally providing a useful assistive technology, which can operate, without any modification, in popular computer architectures. Add-ons are a powerful feature of Mozilla applications (i.e., Firefox, Thunderbird and SeaMonkey) that add new functionality without any limitation, regarding access to applications’ resources, such as toolbars, graphics, rendering, etc. Mozilla extensions can be easily installed and then homogeneously incorporated into the application, unlike other approaches such as plug-ins, which are used in order to render content that the Mozilla application itself can't display inherently. A major drawback of plug-ins, compared to extensions, is that they are not interoperable components, and therefore a different plug-in library has to be implemented from scratch for every supported computer architecture. Furthermore, it should be mentioned that plug-ins face limitations concerning their access to applications’ resources. Moreover, it should be mentioned that add-ons are the most popular approach adopted by end users themselves in order to enhance their browsers’ functionality. Recently, the official Mozilla download site announced [9] that one billion add-on downloads had been accomplished since 2005, and that the daily download counter had reached 1.5 million. Considering that users download add-ons not only from the official site, it is certain that the popularity of add-ons is even higher. Furthermore, it is interesting that several browser features were initially developed as add-ons. For example, tabbed browsing, that first appeared in Mozilla and was later adapted by other browsers as well, has its ground roots in an add-on. In conclusion, it is clear that the end users community is eager to welcome features that enhance browsers’ usability and make their interaction with the web an easy and pleasant experience. Finally, it should be noted that the Mozilla developers’ community has not disregarded the issue of accessibility. In fact, some efforts addressing accessibility issues in the Mozilla Browser (e.g., [12], [10]), as well as some add-ons regarding accessibility have been made available, such as the ones mentioned in [8], [19], [20]. However, all the aforementioned efforts are addressed only to web developers in order to assist them in producing accessible web content, and not to target users themselves.

The FireScanner Add-on FireScanner was developed for hand motor impaired end users in order to facilitate their access to web resources. In the following sections the functionality of the add-on and its architecture are explained, a number of interesting development issues are discussed, some current limitations of the add-on are pointed out and future development and evaluation plans are indicated.

FireScanner at a glance When FireScanner is activated, all the interactive html elements of the displayed web page are sequentially scanned from top to bottom and from left to right. The currently developed prototype of FireScanner supports automatic scanning, while user input is provided through the right arrow key of the keyboard or through any switch connected with a switch interface device, supporting the right arrow key emulation. As a result, the scanning focus marker moves automatically from the one interactive web page element to the other, identifying thus the currently active element. Users can either select to interact with the currently active element or remain inactive for a predefined time interval. When the time interval elapses, the focus marker automatically moves to the next interactive element and highlights it. It should be noted that the inactivity time interval, as well as the activation key, are customisable parameters of the add-on, allowing users to modify them according to their needs and preferences. Architecture and Technical Issues When FireScanner is activated, each web page that is loaded in the user’s browser is processed and an enhanced page version is delivered to the user, as shown in Fig. 1.

Fig. 1. FireScanner architecture

In more detail, once a web page is loaded the hierarchical structure of the HTML elements composing the page is acquired as a Document Object Model (DOM) structure [21]. Then a filtering and tree reconstruction process takes place resulting in the creation of the scanning objects tree of the web page, in order to allow users to navigate from one element to another effectively through scanning. If the user interaction with the page results in loading a new web page in the browser, then the

processing takes place all over and a new scanning tree is constructed. It should be mentioned that processing takes place transparently and that users do not perceive any delays at all. During the filtering process the initially retrieved DOM is traversed in depth and active scanning objects are selected and placed in the scanning tree, according to the decision making algorithm. Before describing the decision making algorithm, it should be mentioned that all elements of the HTML 4.1 specification [22] have been classified into three categories in FireScanner: • Text input. Text input elements refer to all the html elements used for receiving text from users, such as text fields and text areas. In order to address the needs of motor-impaired users an on-screen keyboard [13] supporting scanning is used. • Container. The role of container elements is to group other interactive elements. An example of container elements in html is the forms fieldset. When using the traditional input devices, these objects do not entail any user interaction at all. However, in scanning they constitute significant interactive elements, as they allow users to easily skip large groups of objects that they do not wish to interact with and therefore achieve better performance. • Simple interactive elements. Simple interactive elements, such as checkboxes, radio buttons, or links, are directly associated with a single user action. When using the traditional input devices, interaction with these objects is achieved with a single mouse click or key press. In scanning when the marker has focused on a simple interaction object and users press the activation switch, the single click is emulated and the same result as using the mouse is achieved. User interaction with each category of elements and the according FireScanner behaviour is depicted concisely in Fig. 2.

Fig. 2. Scanning dialogue modeling per object category

It is worth mentioning that when a container object is encountered during the filtering process, additional actions are required according to the number of contained

elements. In particular, when the container object does not include any interactive elements, it is omitted from the final scanning tree. Furthermore, when the container includes only one interactive element, the container is excluded from the final tree structure and only the interactive element is added, ensuing less scanning steps to interact with the element. Finally, containers including other containers and no interactive elements are skipped. One additional step in the filtering process is the exclusion of hidden elements from the scanning tree (e.g., hidden input fields), since users should not interact with them, although they are included in the web page DOM. Furthermore, destination anchors tagged with are also considered invisible and are excluded from the scanning tree, since they just constitute the destination of other links and not links themselves, although they are marked with the html tag. Once the filtering and decision-making process is completed, users may interact through scanning and a switch with the web page. When users select to interact with a simple element, its default action should be carried out. Object interaction is accomplished in FireScanner by sending a click event to the object. This technique ensures that all actions (default or javascript events) which may be bounded with an element will be executed and as a result the web page functionality is retained. The only exception to the above emulation regards the activation of drop-down menus, tagged in HTML with the attribute. In particular, the Firefox add-on API doesn’t support click events for these elements, so a workaround was followed, in order to select an element of such a menu and open the drop-down box. Challenges Faced The main challenge faced during the development of the scanning add-on was the diversity of web content. Although web authoring recommendations have been developed by international organizations, such as W3C, web authors can create and publish content without necessarily following all the suggested guidelines. This results in a huge variety of web pages, some of which make arbitrary use of the HTML elements. If all HTML elements were appropriately used by web page authors, the decision-making process and the classification of elements would be simpler and the FireScanner performance would be equivalent for all web pages. Current Status and Future Work In the context of the presented work, a prototype version of the scanning add-on has been developed supporting several fundamental key features. However, it should be noted that this is an ongoing work and further plans for the development of additional features and facilities are under consideration, in order to enhance users’ effectiveness, efficiency and satisfaction. Limitations of the currently developed prototype include the lack of support for certain html elements, such as image maps, applets and objects (marked with the html tag) embedded in a page, frames, inline frames ( html

tag), and file select controls ( html tag). Furthermore, option groups ( html tag) are partially handled. Future versions of FireScanner will provide users the ability to define additional preferences, such as for example whether they prefer automatic or manual scanning, what colour they desire for the focus marker, or how many switches they are using. In the case of additional switches, reverse scanning and exit container options will be supported by the add-on. Furthermore, the add-on will allow users to scan not only the elements of the web page, but the browser window itself, providing thus a fully functional and usable working environment. As a result, users will be able to use all the browser facilities provided, e.g., add bookmarks, review their browsing history, define browser preferences, etc. Accessibility and Usability Evaluation Evaluation is a fundamental part of the development life cycle of an application, ensuring usability and user acceptance. There are several evaluation methods that can be employed, however user testing is the most preeminent one ensuring in-depth comprehension of the user needs and requirements. Studies [14] regarding the selection of the best evaluation method according to the development stage suggest that user testing should be combined with heuristic evaluation methods that should be applied when a functional prototype is available. Once the major usability problems have been eliminated with heuristic evaluation, user testing, which is more expensive in resources, can be applied. The usability and accessibility of FireScanner have been evaluated by three usability and accessibility experts. Initially, the FireScanner approach and its goal were explained to all the evaluators, who then examined the functionality and the interface of the add-on individually. All the evaluator remarks were gathered in one reporting document and were rated according to their importance. Results of the evaluation suggested the use of automatic scanning instead of the manual scanning that was initially applied, since it requires less user interaction and best suits users’ needs. Furthermore, it was suggested that FireScanner should also provide scanning access to the browser window itself and that users should be able to customize scanning according to their needs. Both features are very important in order to achieve high usability and will be implemented in future FireScanner versions. Future evaluation plans include user-based assessment both in the laboratory and remotely. In the first case, once the final prototype is developed the usability experiment will be planed carefully and several users will be brought to a usability evaluation lab in order to provide measurements regarding effectiveness, efficiency and satisfaction of browsing the web with the use of FireScanner. In addition to this, an online questionnaire will be made available for all the FireScanner users in order to express their opinion and provide requirements for potential improvements.

Summary and Conclusions This paper has presented a browser add-on, named FireScanner, aiming to provide access to the web for people with severe motor impairments of the upper limbs. Since the web is nowadays a daily used medium for information retrieval and interaction with several services, FireScanner is expected to address fundamental needs of motor impaired users by enhancing browser functionality. The add-on has been developed for the Mozilla Firefox browser, ensuring thus interoperability across the most commonly used platforms. Access to a web page is provided through the scanning technique and the only input device required is a binary switch, a commonly used assistive technology by the target user group. As a result, all the impediments imposed to users’ interaction by the required use of conventional input devices are eliminated. Scanning access to a web page is achieved through a transparent process, during which the initial web page DOM is inspected and processed according to the scanning needs and a new hierarchical objects’ tree is constructed. A major difficulty and at the same time the most challenging issue that arose in the development of FireScanner is the diversity of web content, which cannot be controlled in any way. The fact that anyone can author and publish web content and the flexibility of the HTML language result in several web pages which may misuse HTML and disregard any accessibility guidelines. Therefore, the behaviour of a web page is quite unpredictable and difficult to capture in an algorithm. In order to work this out, FireScanner applies generic rules in its decision-making component to filter the webpage DOM and construct a new scanning tree eliminating any unnecessary elements. The last step in the development of the current prototype was the accessibility, usability and performance evaluation by experts that was carried out and which led to useful results. Some of the evaluation outcomes were used to improve the current prototype, while some others will be addressed in future versions of FireScanner. Once the final prototype is deployed, user evaluation is planned both in the lab and remotely through online questionnaires. The latter is expected to lead to an iterative process of enhancements’ development and evaluation in an effort to accommodate users’ needs in the best way possible.

References 1. ABLEDATA: Electro-mechanical Switches. Retrieved January 20, 2009, from: http://www.abledata.com/abledata.cfm?pageid=19327&top=11324&deep=2&trail=22,1131 6 2. Applied Human Factors: ScanBuddy Assistive Software. Retrieved January 13, 2009, from: http://www.ahf-net.com/Scanbuddy.htm 3. Biswas, P., Robinson, P.: A new screen scanning system based on clustering screen objects. Journal of Assistive Technologies, 2 (3), pp. 24--32, (2008) 4. Don Johnston Incorporated: Switch Interface Pro 5.0. Retrieved January 20, 2009, from: http://www.donjohnston.com/products/access_solutions/hardware/switch_interface_pro_5/in dex.html

5. EnableMart: USB Switch Interface. Retrieved January 20, 2009, from: http://www.enablemart.com/Catalog/Switch-Interfaces/USB-SwitchInterface2;jsessionid=0a0107431f435289697bed3b4cae9c88a3e8b27a8856.e3eTaxiPc3mTe 34Pa38Ta38Nchj0 6. Enabling Devices: Capability Switches. Retrieved January 20, 2009, from: http://enablingdevices.com/catalog/capability_switches 7. Gus Communications, Inc.: Gus! Scanning cursor. Retrieved January 13, 2009, from: http://www.gusinc.com/scancur.html 8. iCITA: Mozilla/Firefox Accessibility Extension: Overview and Installation. Retrieved January 21, 2009, from: http://firefox.cita.uiuc.edu/ 9. Mozilla Add-ons Blog : 1 Billion Add-on Downloads. Retrieved February 13, 2009, from: http://blog.mozilla.com/addons/2008/11/19/1-billion-add-on-downloads/ 10.Mozilla Developer Center: AT API Support. Retrieved January 24, 2009, from: https://developer.mozilla.org/en/Accessibility/AT-APIs 11.Mozilla Developer Center: Extensions. Retrieved January 20, 2009, from: https://developer.mozilla.org/en/Extensions 12.Mozilla Developer Center: WAI ARIA Live Regions/API Support. Retrieved January 24, 2009, from: https://developer.mozilla.org/index.php?title=En/AJAX/WAI_ARIA_Live_Regions%2F%2 FAPI_Support 13.Mourouzis, A., Boutsakis, E., Ntoa, S., Antona, M., & Stephanidis, C.: An Accessible and Usable Soft Keyboard. In: C. Stephanidis, (Ed.), Universal Access in Human-Computer Interaction: Ambient Interaction – Volume 6 of the Proceedings of the 12th International Conference on Human-Computer Interaction (HCI International 2007), pp. 961--970. Berlin Heidelberg: Lecture Notes in Computer Science Series of Springer (2007) 14.Nielsen, J.: Choosing Usability Methods. In: Usability Engineering, pp. 224--225. Academic Press, Inc., San Diego (1993) 15.Ntoa, S., Savidis, A., & Stephanidis, C.: Automatic Hierarchical Scanning for Windows Applications. In: C. Stephanidis (Ed.), The Universal Access Handbook. CRC Press (2009 to appear). 16.Ntoa, S., Savidis, A., & Stephanidis, C.: FastScanner: An accessibility tool for motor impaired users. In: Proceedings of the 9th International Conference on Computers Helping People with Special Needs (ICCHP 2004), pp. 796--804. Berlin Heidelberg: SpringerVerlag (2004) 17.Origin Instruments Corporation: Swifty, USB Switch Interface. Retrieved January 20, 2009, from: http://www.orin.com/access/swifty/ 18.RJ Cooper & Associates: CrossScanner Switch Method. Retrieved January 13, 2009, from: http://rjcooper.com/cross-scanner/index.html 19.Standards-Schmandards: Fangs – the screen reader emulator. Retrieved January 21, 2009, from: http://www.standards-schmandards.com/projects/fangs/ 20.Wave: Wave Toolbar. Retrieved January 21, 2009, from: http://wave.webaim.org/toolbar 21.W3C: Document Object Model (DOM). Retrieved January 24, 2009, from: http://www.w3.org/DOM/ 22.W3C: Index of the HTML 4 Elements. Retrieved January 23, 2009, from: http://www.w3.org/TR/REC-html40/index/elements.html

Suggest Documents