Accessibility Evaluation of an Alternative and ... - Springer Link

Accessibility Evaluation of an Alternative and Augmentative Communication (AAC) Tool Sandra Baldassarri1, Javier Marco1, Eva Cerezo1, and Lourdes Moreno2 1

GIGA AffectiveLab, Universidad de Zaragoza, Zaragoza, Spain {sandra,javi.marco,ecerezo}@unizar.es 2 Computer Science Department, Universidad Carlos III de Madrid, Spain [email protected]

Abstract. People with communication needs use Assistive Technology (AT) to participate in society, be at the family, school among others. There is a variety of different Alternative and Augmentative Communication (AAC) devices due to end-users have different communication needs. AraBoard is an AAC tool developed with the aim to facilitate the functional communication to people with complex communication needs. In this paper, AraBoard tool is presented. In order to ensure the quality of the tool, an accessibility evaluation has been carried out. Following a methodical approach, two main steps have been followed in the evaluation process: (1) Two lists of checkpoints have been developed based on the study and analysis of accessibility standards and related work in the domain of AAC; (2) An evaluation using these resources has been conducted by accessibility experts. The results from the study indicate a high level of accessibility in AraBoard tool, besides some suggestions about new requirements to integrate in the tool have been obtained. Keywords: Alternative and Augmentative Communication (AAC), accessibility, expert evaluation.

1

Introduction and Background

Many people with communication needs face challenges when trying to communicate with others persons. In order to solve this situation, Alternative and Augmentative Communication (AAC) is a set of strategies and techniques that can be used to support communication for individuals with Complex Communication Needs (CCN) who have little or no functional speech. People who use AAC are a diverse group, as communication disorders can result from physical and/or intellectual disabilities, congenital disability, acquired disability, progressive disorders, and also temporary voice loss [1]. The majority of AAC interventions use unaided techniques (e.g., gesture and sign language) and low-technology devices (e.g., communication-symbol books and letter/word boards). High-technology AACSs are technological aides formed by peripherals, digital ramps and AAC software designed for people with CCNs. They are conceived as support tools for the development of communicational competencies C. Stephanidis and M. Antona (Eds.): UAHCI/HCII 2014, Part IV, LNCS 8516, pp. 529–540, 2014. © Springer International Publishing Switzerland 2014

530

S. Baldassarri et al.

and/or as “communicational prostheses” that help the individual relate to his/her environment. Recent advancements in technology have expanded the customizability, portability and convenience of AAC devices. The field has witnessed the explosion of mobile technologies (e.g., touch screen smartphones and tablets) with a wide range of apps, including those intended to support communication, extending AAC beyond low-tech systems including new symbol sets, layouts, organizations, selection techniques, and output [2,3,4,5,6,7,8,9]. The advent of digital technologies has resulted in enhanced potential to meet the increased scope of communication needs for a wider range of communication needs [10]. Besides users with cognitive disabilities affecting communication development, these apps can also be used as communication assistants by users with temporal communication difficulties, such us users in a foreign country without knowledge of the local language. Thanks to mobile technologies, the AAC field is crossing over into the mainstream [11]. The reduced cost and ready availability of AAC apps and mobile technologies has meant that many individuals and their families are becoming active consumers, making their own decisions as they purchase the widely available mobile technologies and apps. But also this “democratization” is expanding to AAC system development, as well [12]. The creation of AAC software applications no longer rests solely in the hands of the traditional assistive technology manufacturers; rather apps are being developed by a wide range of stakeholders, from mainstream programmers to family members requiring AAC tools for their relatives. This model of development differs dramatically from the traditional models of AAC research and development. It supports the rapid development of AAC apps by providing direct links between end consumers and software developers. Unfortunately, this model also has some liabilities. The development of mainstream technologies is largely driven by the needs and preferences of the masses; as a result, these technologies may not meet the needs and skills of individuals with complex communication needs [13], since they are not easily customized, and/or they are not accessible. The limitations are not just restricted to the AAC apps; they also extend to the mobile technologies as well, which use may be difficult or impossible for young children or individuals with motor impairments. Research is urgently needed to tackle these problems to ensure that “democratization” AAC brings benefits for individuals with complex communication needs. We must ensure that communication technology mitigates, and does not exacerbate, disability. This paper focuses in the study of the accessibility requirements of AraBoard, a shareware application aimed to facilitate the functional communication to people with communication needs. AraBoard allows the creation, edition and use of communication boards especially suited for people with motor disabilities and very basic communication needs. The structure of the paper is: Section 2 is devoted to present AraBoard tool, formed by two applications: Constructor and Player. Section 3 shows the accessibility evaluation process of AraBoard tool, which includes the development of a checklist and the experts’ application of the checklist. In Section 4 conclusions and future work are presented.

Accessibility Evaluation of an AAC Tool

2

531

Alternative and Augmentative Communication (AAC) Tool: AraBoard

AraBoard1 is a public domain tool developed to facilitate functional communication to people with CCN due to different causes: autism, aphasia, cerebral palsy, etc. The tool has been designed following an Inclusive Design [14] and User Centered Design (UCD) approach [15] in the specific context of users who need AAC technology to communicate. The tool is available for different devices (PC, mobile, tablets) and operating systems (MS-Windows and Android Operating Systems). AraBoard is formed by two different applications: AraBoard Constructor, for the creation and edition of communication boards and AraBoard Player, for the visualization of the boards previously generated. Each application has a different end user profile. AraBoard Constructor is used by relatives, tutors, educators and therapists; while AraBoard Player is used by the final users (usually children) that have any kind of communicative limitation. Both share the same interface and are used in the same way independently of the device. Moreover, the boards created with the Constructor in one device can be moved, edited and played with the Player in any other device that has AraBoard installed. Each communication board is stored in their own folder in the internal memory of the device, containing the images and audios of each pictogram and an XML file with the board’s specification. In the next sections AraBoard applications are presented as well as the results of a survey completed via web by their users. More detailed information about AraBoard can be found in [16]. 2.1

AraBoard Constructor

The AraBoard Constructor application allows tutors and relatives to create and edit communication boards adapted to the particular needs of each user. AraBoard Constructor is characterized by its ease of use in all aspects, since it has a graphical interface designed to make possible anyone to create and edit boards intuitively in a few minutes. Its interface lets to define the number of rows, columns, arrangement of cells, and also to create and configure all elements-visual, auditory, textual, appearance, etc. - that compose the communication board. The possibility to create boards from one to thirty-two cells extends the range of users, from people with severe motor disabilities and very basic communication needs (see Fig. 1.a), offering boards with few cells but with large dimensions, to users with advanced communication needs up to boards with 32 cells (see Fig. 1.b). In order to customize the elements composing the board, the application allows the user to enter resources from the ARASAAC pictograms collection [17] and also personal resources like images, photographs, sounds and voice.

1

http://giga.cps.unizar.es/affectivelab/araboard.html

532


Fig. 1. (a): Simple board for people with severe motor disabilities; (b) Board for people with advanced communication needs

Once the board has been built, the application allows: to export the board in PDF format ready to be printed and used as a communication board in paper, or to save the communication board project, creating a directory in the internal memory of the device for editing or for being used in AraBoard Player. 2.2

AraBoard Player

AraBoard Player is an application that allows users with communication needs to use communication boards previously generated with the Constructor. AraBoard Player shows the board in the full screen, and the user interacts with it by pressing the different cells that compose it. Once a cell has been marked, it plays the audio associated with it (see Fig. 2). In order to be accessible to users with physical disabilities, the audio playback mechanism is designed so that although not stating exactly the desired cell, it always runs the audio associated with the cell closer to the area that has been pressed.

Fig. 2. AraBoard Player

2.3

AraBoard Seen by Its Users

According to the results of a survey carried out to users which have been freely downloaded and used this tool, the users claim to have a high tool’s acceptance [16]. During the first year of publication, 295 completed questionnaires have been collected. Users distinguish as main features that the tool is multiplatform and adaptable to a wide range of users’ needs by modifying different parameters like language,


533

number and size of the cells, inclusion or not of audio, selection of colors (background and text), etc. Furthermore, the results reflect that AraBoard Player was mainly used by autistic people. The rest of users presented different types of impairment, which affect their verbal and written expression ability and, the combination of cognitive and motor impairments. The application is aimed to be used by a higher number and a broad range of final users with communication needs, in an accessible way. In order to ensure this accessibility, a specific accessibility evaluation has been carried out on the AraBoad tool, as it is explained in detail in next section.

3

Accessibility Evaluation of AraBoard Player Tool

An accessibility evaluation done by experts is presented in this section. The evaluation is mainly focused on the AraBoard Player because it is the software which is facing end-users with CCN, although many accessibility requirements are provided by the AraBoard Constructor. An accessibility evaluation of the AAC tool should be carried out together with its interrelated factors in the AAC environment. For example, communication software is very important, as well as the device the user is employing to access. A variety of AAC device designs and configurations currently exist, because no single device can offer efficient and effective communication to all people with severe communication impairments. The end users of AAC devices are very heterogeneous and with different communication needs access to ICT. Thus, there are a variety of different AAC devices. In this way, AraBoard expands functional communication to a varied range of viable environments due to its compatibility with mobile devices and because of the possibility of directly printing the created communication boards, so that they can be used without any technological device. This feature of AraBoard provides accessibility to the tool. Therefore, the accessibility of the AraBoard Player interface should be evaluated in the different environments in which it is used. In this work, desktop environment is studied. The evaluation process consists of two steps which are shown below: the generation of a checklist of accessibility requirements and an expert evaluation using the checklist. 3.1

Checklist of Accessibility Requirements for AAC Tools

With the aim of developing a checklist to validate the accessibility in the specific domain of the systems AAC, different works and standards have been distinguished, studied and analyzed to capture the requirements. On the one hand these requirements should help to comply with the characteristics of the AAC tools which should provide support for people with special communication needs; on the other hand, the requirements for access to the software tool must be conformed. In order to obtain these requirements, the following analysis has been made: 1. An analysis of the AAC tool audience was conducted. The data of the user needs were obtained from the results of the end-users survey (see section 2.3).

534


Resulting of this analysis, needs and users’ feedback have been identified. With regard to the suggestions of the users, the level of satisfaction reflected in the results is very high. Their comments show great enthusiasm for the usefulness of the tool. When they were asked about the improvements to incorporate in AraBoard tool, they have coincided on the following improvements: ─ Dynamic communication boards that allow linked boards, with the aim of increasing communication needs of users with CCN. ─ Functionalities to construct sentences by enabling the accumulation of words and displaying them on screen. ─ To provide tutorials, manuals, help guides on characteristics and uses of the tool. ─ To allow configuration settings for some features such as speed of response of the auditory messages, ... ─ Functionalities for scanning and sweeping through a pushbutton. 2. Following an UCD approach in the specific context of AAC systems, an analysis of related work from the literature and best practices based on formal and experimental studies with real users has been carried out. Works that include characteristics and guidelines for AAC systems [24] [25], and resources of Users Associations [23] [26] among others, have been studied to capture guidelines and requirements that provide the support to the accessibility validation. Resulting of this analysis, the Checklist (1) shown in Table 1 has been obtained. Each checkpoint of this list should be evaluated by an expert and he/she assigns a value from the following: "No" it is not satisfied, "Yes" if it is satisfied, "Partial" which means it fulfills the checkpoint only in part, and "NA" if it is Not Applied. Not Applied is considered in the case of some accessibility requirements of AAC systems that were decided not to be included in AraBoard because of taking into account the needs of real end-users (following the UCD approach). Table 1. CHECKLIST (1): Requirements in the specific context of AAC systems Cod

1 2 3

4

Requirements for the Player tools

AraBoard Player

Complemented by AraBoard Constructor

Theme communication boards and configuration settings The Player tool has levels No (dynamic boards) Enable to change the boxes No It is possible with the Constructor size No The Constructor can create temEnable to change the boxes plates with different layouts and layout, position and orientaorientations tion No It is possible with the Construc-tor Provide a different background colour for each semantic category

Yes, No NA, Par No Yes Partial

Yes


535

Table 1. (continued) Content: Pictographic symbols and configuration settings

5

Allow to introduce external pictures

No

The Constructor allows it

Yes

6

If it allows external pictures, users are informed about which sizes and formats can be used. Allow to include: a picture along with a word|literal?, the pictures are distinguished from the literals?, only a picture?, only a literal?

No

The Constructor notifies only formats

Partial

7

8 9

10 11

12

Partial

The Constructor allows the option of a picture along with a word/literal. Yes, they are distinguishable. However, if the number of rows and columns increases, it becomes more difficult distinguish the text. Output: Messages and configuration settings Provide flexibility about the No The number of messages is fixed number of messages by the Constructor. Yes The Constructor allows recording Provide speech output speech and loading audio (digidigitized speech output or tized speech output) synthetic speech output Provide flexibility in size and Partial The Constructor allows change edit of messages? the message associated to symbol. NA Allow independence between (lack of the output messages and hearing scanning scan technology) Allow volume selection and NA volume adjustments Input: Access and configuration settings

13

Allow direct access

NA

14

Allow to access with a pointer: Spaciousness to provide enough movement to reach all boxes, Accuracy (boxes with size enough to press comfortably) and strength (it is possible to press the boxes with an average force) Allow to access through eye tracking Allow to access using AT

Yes (desktop environments)

Allow to use assisted scanning technology (and setting configuration)

No

15 16

17

Yes Yes

Partial No

NA

NA It is dependent on the number of rows and columns of the communication board. It is interdependent of the device and platform. It is possible to design boards to ensure spaciousness and accuracy with the Constructor.

NA No, NA

Yes

Yes

NA No, It does not. In addition, it does not provide information about it, because this tool is an Assistive tool

No

No

536


3. An analysis of the software accessibility standards and related work about how to develop a user agent (such as a player) have been distinguished and analyzed. These standards have been: the standard ISO 9241-171:2008 - Guidance on software accessibility [21] and standard User Agent Accessibility Guidelines (UAAG) 2.0 [22] of the WAI [18], highlighting the UAAG 2.0 includes comply with the Web Content Accessibility Guidelines (WCAG) 2.0 [20]. With the knowledge gained from this study, a Checklist (2) (see Table 2) has been made. The procedure to assign values to each checkpoint is the same that the one described for the checklist (1). Table 2. CHECKLIST (2): Requirements based on Software Accessibility Standards Cod

8.1

8.2

8.3

Requirement ISO 9241 -171

NA/ Yes/ No/Par.

Suggestion/Comments 8 GENERAL GUIDELINES NA Names and labels for user Guideline 4.1. – UAAG 2.0 interface elements Provide a name for each user interface This requirement would be a recommendation if element, meaningful names. the tool had as an aim to provide support to the AT Make names available to AT NA User preference settings Guideline 2.7 –UAAG 2.0 Enable easy individualisation of user If new features are incorporated in tool as: scan, preferences. Enable adjustment of sizes languages, etc., it is recommended to incorporate and colours of common user interface user preference settings elements. Enable user control of timed responses NA Special considerations for Several guidelines - UAAG 2.0 accessibility adjustments Make controls for accessibility features discoverable and operable. Avoid interference with accessibility features. Inform user of accessibility feature activation

8.4

8.5

8.6

Mapping with other standards

No General control and operation guidelines Optimise the number of steps required for any task. Provide “Undo” and/or “Confirm” functionalities. Allow warning or error messages to persist No Compatibility with AT Enable communication between software and AT. Allow AT to change focus and selection. Allow AT to access resources. Accept the installation of keyboard and/or pointing device emulators. NA Closed systems Read content on closed systems. Announce changes on closed systems

In current version, there are not adjustments because the possible accesses are always available (enabled) and are intuitive to use. But if they are incorporating new features that require configuration settings, it would be recommended to design and integrate mechanisms to keep the simplicity and operability of the interface components Guidelines 3.1., 3.2 y 3.4- UAAG 2.0 These requirements should be integrated in future versions.

Guidelines 4.1, 5.1- UAAG 2.0 AraBoard tool could be considered a closed system such that the installation of additional technology assistive (it itself is a support product) is not allowed, however: access through Assisted Scan should be provided.

If it is considered as a closed system, these requirements should be included


537

Table 9. (continued) No

9 INPUTS Guidelines 2.1, 5.1- UAAG 2.0

9.1

Alternative input options

9.2

Provide keyboard input from all standard input mechanisms. Provide pointer control of keyboard functions. Provide speech recognition services Partial Keyboard focus Provide focus cursor. Provide high visibility focus cursor. Restore state when regaining focus No

9.3

Keyboard input

9.4

Enable full use via keyboard. Provide adjustment of delay before key acceptance. Provide accelerator keys. Reserve accessibility shortcut key assignments. Partial Pointing devices

The access through screen reader should be provided.

Guidelines 1.3, 5.1 -UAAG 2.0 Access via keyboard is provided only for menu elements. It is not provided for the board boxes (mouse only). The visibility of keyboard focus should be provided Guidelines 2.1, 5.1- UAAG 2.0 Keyboard shortcuts, time setting, allowing configuration settings ... should be provided

Guideline 1.3, 2.12- UAAG 2.0

Provide direct control of pointer position from external devices. Provide easilyselectable pointing device targets. Provide adjustment of pointer speed. Provide adjustment of pointer movement direction

Some of these requirements are fulfilled: the mouse-pointing is easy to use but has a strong interdependence of the number of rows / columns, cell/box size and board layout type. Besides, an assistance take the direction to when the user is pointing one box would be recommended. 10 OUTPUTS Partial Guideline 1.3-- UAAG 2.0

10.2

Visual output (displays)

10.3

Provide a visual information mode usable by users with low visual acuity. Provide keyboard access to information displayed outside the physical screen No Text/Fonts Enable users to set minimum font size. Adjust the scale and layout of user interface elements as font-size changes Yes Colour

10.4

10.6

11.1

It is recommended to allow to change colours to highlight the focus of the cursor. The access through screen reader should be provided. Guideline 1.4 UAAG 2.0 It is recommended to allow to change settings such as the font size. Guideline 5.1 UAAG 2.0 ( comply with WCAG 2.0) The constructor allows it, however, we would recommend that these requirements may be included in the Player

Provide individualisation of colour schemes. Allow users to individualise colour coding. Provide contrast between foreground and background Partial Audio output Guideline 1.5, 1.6, 2.9, 2.11. ..UAAG 2.0 Enable control of audio volume. Enable The volume control is through the device (PC, adjustment of audio output. Use specific Mobile, Tablet ...) but the volume of the AAC frequency components for audio warnshould be independent of the device. ings and alerts. Synchronise audio equivalents for visual events 11 ONLINE DOCUMENTATION, HELP AND SUPPORT SERVICES. Partial Documentation and Help Guideline 3.3 UAAG 2.0 Provide understandable documentation. Provide user documentation in accessible electronic form. Ensure help is available in accessible forms

Although there is documentation, this information and help should be extended and provided for the AAC and not in an external web page.

538

3.2


Expert Evaluation with the Use of Checklists

Two human experts on accessibility have evaluated AraBoard. Both experts are professionals with the training required and a high degree of Software Accessibility knowledge, besides skills in the use of assistive technologies among others topics, with more than five years of experience in software accessibility evaluations according to standards. The experts have revised manually accessibility issues with the use of the checklists created. The steps followed are: 1. Each expert studied the checklists for the evaluation of the accessibility of the tool. 2. Each expert simulated specific accesses and features. 3. Each expert elaborated a preliminary evaluation report 4. Both reports were compared and a discussion of the results was carried out to confirm the level of conformance the final accessibility. The results of expert evaluation ({NA, Yes, No, Partial} for each checkpoint) are shown in the fourth column of Table 1: “Checklist (1): Requirements in the specific context of AAC systems”, in the third column of Table 2: “Checklist (2): Requirements based on Software Accessibility Standards”. Additionally in Table 2 some suggestions are provided. A discussion of the data and conclusions are shown in the next section. 3.3

Discussion of the Data

The AraBoard tool was designed involving users, and this is perceived in the endusers survey (see section 2.3). The purpose of the tool is to provide flexibility in the creation of boards with different layout and sizes, providing external resources as ARASAAC symbols/pictograms, different languages, etc. and all these features integrated into an easy interface. They have a very positive perception of the tool. Users suggested essentially the integration of scan technology. There are some checkpoints of the checklists which have not been considered (they have been assigned by "Not applied" (NA)) because they are not required by the tool since they come into conflict with user reviews collected in the design phase of the system. Of the remainder, it is noticeable that the evaluation of the AraBoard tools achieves a high level of accessibility, because the most of the checkpoints have achieved rating of "Yes" and others “Partial”, except checkpoints related to accessibility requirements such as: provide scan system and configuration settings and provide Documentation and Help.

4

Conclusions and Future Work

In this paper, an overview to the AAC tools has been introduced and the AraBoard tool is described. A user survey was conducted as previous work. To complete this evaluation, an assessment of the accessibility has been carried out and presented in this work. The evaluation process has included two parts: first, the development of


539

checklists applicable to AAC tools based on accessibility standards. These checklists provide evaluation resources for other works in the AAC domain; and second, the evaluation by experts with the use of the checklists. Taking into account the findings of the results achieved, some suggestions are provided for future releases of the tool. In addition, other requirements proposed by some users have been already included in the new version in process, such as: synthetic speech output, user preference settings and scan. Acknowledgements. This work has been partly financed by the Spanish Government through the DGICYT contract TIN2011-24660, by the CYTED project 512RT0461, by the Research Network MAVIR (S2009/TIC-1542 and the MULTIMEDICA project (TIN2010-20644-C03-01).

References 1. Waller, A.: Public Policy Issues in Augmentative and Alternative Communication Technologies A Comparison of the U.K. and the U.S., Interactions May-June 2013, pp. 68–75 (2013), doi:10.1145/2451856.2451872 2. Smalltalk, http://www.aphasia.com/products/apps/smalltalk 3. Sc@ut, http://asistic.ugr.es/scaut/index.php 4. Plaphoons, http://www.xtec.cat/~jlagares/f2kesp.htm 5. TalkTable, http://www.gusinc.com/2012/TalkTablet.html 6. TICO, http://www.proyectotico.com/wiki-en/index.php/Home 7. PictoDroid Lite, http://www.accegal.org/pictodroid-lite/ 8. Baluh, http://blog.baluh.org/ 9. CPA, http://www.comunicadorcpa.com/ 10. Light, J., McNaughton, D.: The changing face of augmentative and alternative communication: Past, present, and future Challenges. Augmentative and Alternative Communication 28(4), 197–204 (2012) 11. Rummel-Hudson, R.: A revolution at their fingertips. Perspectives on Augmentative and Alternative Communication 20(1), 19–23 (2011) 12. Menard, L.: A Review of Innovative Communication Apps for Students with Special Needs. In: Proceedings of Society for Information Technology & Teacher Education International Conference, pp. 3292–3298 (2011) 13. Beukelman, D.: AAC for the 21st century: Framing the future. Presentation at the State of the Science Conference for the RERC on Communication Enhancement, Baltimore (2012) 14. Newell, A.F., Gregor, P.: User sensitive inclusive design— in search of a new paradigm. In: Proceedings on the 2000 Conference on Universal Usability (CUU 2000), pp. 39–44. ACM, USA (2000) 15. ISO, ISO 9241-210:2010 Ergonomics of human-system interaction – Part 210: Humancentred design for interactive systems, http://www.iso.org/iso/catalogue_detail.htm?csnumber=52075 16. Baldassarri, S., Marco, J., García-Azpiroz, M., Cerezo, E.: AraBoard: A Multiplatform Alternative and Augmentative Communication Tool. In: 5th International Conference on Software Development and Technologies for Enhancing Accessibility and Fighting Infoexclusion, DSAI 2013 (2013) (in press in Procedia Computer Science - Journal – Elsevier)

540


17. ARASAAC pictographic symbols from Aragonese Portal of Augmentative and Alternative Communication, Spain, http://www.catedu.es/arasaac/index.php 18. W3C, Web Accessibility Initiative (WAI) (2011), http://www.w3.org/WAI/ 19. ISO, ISO/IEC 40500:2012. Information technology: W3C Web Content Accessibility Guidelines (WCAG) 2.0, http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=58625 20. W3C, WAI, Web Content Accessibility Guidelines (WCAG) 2.0, W3C Recommendation (December 11, 2008), http://www.w3.org/TR/WCAG20/ 21. W3C, User Agent Accessibility Guidelines (UAAG) 2.0, W3C Last Call Working Draft (November 7, 2013), http://www.w3.org/TR/UAAG20/ 22. ISO, ISO 9241-171:2008 - Ergonomics of human-system interaction – Part 171: Guidance on software accessibility, http://www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_detail.htm?csnumber=39080 23. American Speech-Language-Hearing Association (ASHA). Augmentative and Alternative Communication (AAC), http://www.asha.org/public/speech/disorders/AAC/ 24. Light & Drager, AAC technologies for young children with complex communication needs: State of the science and future research directions. Augmentative and Alternative Communication 23(3), 204–216 (2007) 25. Owens, J.S.: Accessible Information for People with Complex Communication Needs. Augmentative and Alternative Communication 22(3), 196–208 (2006) 26. Augmentative and Alternative Communication (AAC) Connecting Young Kids (YAACK), http://aac.unl.edu/yaack/index.html