Since 1999, when the W3C1-WAI2 introduced the “Web Content Accessibility Guidelines 1.0” (WCAG 1.0) as a set of guiding principles, the fact that Accessibility is a main topic in Web design upon which the success of a Web application depends, has become a landmark statement. However, developing accessible Web applications is usually hard for several reasons.

Firstly, there is a significant knowledge gap between developers and Accessibility specialists. Most developers do not have the necessary skills or training in designing and coding for Accessibility, and most Accessibility specialists have, in turn, limited developing practice. Thus, although there are many available tools and published sources of information on Web Application Accessibility, existing Web Accessibility guidelines and principles (and therefore, experts on these guidelines) do not address additional design issues that may typically arise when developing complex Web applications. To make matters worse, there is little evidence of design approaches dealing with Accessibility from the beginning of the design process. In most cases, Accessibility is regarded as a programming issue or even dealt with when the Web application is already fully developed and, consequently, the process of making this application accessible involves significant redesign and recoding, which might be out of the scope of the project and/or hardly affordable. As we will show next, the main problem with Accessibility is that it is a non-functional software concern, which affects (crosscuts) other application concerns. Generally speaking, a non-functional requirement is a software requirement which does not describe what the system will do (functional requirement), but how the system will do it; for example, performance requirements, modularity requirements, or quality attributes, which represent constraints on the services or functions offered by a system.