In assessing a Web application for accessibility, there are two approaches: a technical evaluation or a functional evaluation. A technical evaluation examines the code used in an application and the interactions between the application and the end user to ensure it is implemented according to standards like the Web Content Accessibility Guidelines. It determines if the application is behaving in ways that allow assistive technologies to effectively interact with the system. An example of this type of evaluation is, “Does a particular button in the user interface present itself in a way so that it can be understood by, and interacted using both visual and non-visual means?” The limitation of a technical evaluation is that it does not take a holistic view of asking if the individual pieces of an application work together correctly and if the end user can actually perform the necessary functions with it.
Alternatively, functional evaluations ask if the end user can accomplish the necessary tasks to effectively use an application, regardless of how a particular feature is coded. An example of this type of evaluation is, “Can the user create a new document?” This question is then tested using various modes of interacting with the application, such as using a mouse, a keyboard, or an assistive technology. If the user can accomplish the task through all of those methods, the application is considered functionally accessible for that task.
Functional and technical evaluations are not mutually exclusive. In fact, they help inform each other and both aspects are necessary in developing an accessible application. The individual components of an application have to be implemented to meet a technical standard in order for the functional tasks to even be possible for users of assistive technologies. As the functional tasks are performed and evaluated, a skilled evaluator will be able to readily identify the technical issues behind problems that are discovered.
The analysis in this report concentrates on the functional analysis of Documents for two reasons. First, Documents and the rest of the Google Apps suite are pushing the boundaries of what is possible in a Web browser. Given that reality, Google will need to be creative in how it implements its accessibility solutions and there are multiple technical implementations that can achieve that goal. By concentrating on what can and cannot be accomplished functionally, Google can be made aware of the issues and decide best how to implement that technically. Second, the main goal for the end user is to be able to actually use the application. Instead of getting mired in the details of which technical implementation to use for the solution, ATHEN can concentrate on the main goal of allowing all users to fully use Google Apps and let Google determine which solution works technically best in its application.
Although there might be multiple possible technical implementations for a solution to an accessibility problem, it does not mean all technical implementations are equally effective. A particular technical implementation might benefit a certain set of disabilities and assistive technologies but might also make it more difficult to find solutions for other types of disabilities. The Interest Group is keenly aware of and concerned about this issue because of Google’s concentration on screen reader solutions. The group recognizes the advanced nature of what Google is implementing in its accessibility solution, but by revealing the functional limitations of Google Apps for various types of disabilities, the group wants Google to ask some fundamental questions about its implementation in order to ensure the widest possible number of users can use the Google Apps suite, not just screen reader users.