Resultados del tratamiento y análisis de la información 1 Variables

Although the attitudes and perceptions of stakeholders undoubtedly impact upon the accessibility of websites, both Lazar et al. (2004) and Farrelly (2011), in their respective models, consider web development tools, guidelines and resources to have an even greater influence. According to Lazar et al., “good, well-written guidelines and powerful software tools” are likely to improve levels of accessibility, whereas “poorly-written, confusing guidelines, and hard to use or unclear software tools” are likely to reduce them (p. 4). Numerous studies, both of web developers and of the tools and guidelines they use, support these assertions. These studies not only question the validity and reliability of tools and guidelines but also demonstrate how web developers find them confusing and difficult to use.

Reflecting on an accessibility evaluation of 50 homepages in the mid-Atlantic United States, Lazar, Beere, Greenidge and Nagappa (2003) describe the tools used in the evaluation as “flawed, inconsistent and requir[ing] large numbers of additional manual checks” (p. 1). However automated the tools may be, the authors observe, they still rely on the subjective (and potentially flawed) judgement of human expert evaluators (see Section 2.1.1). Lazar et al. criticise the tools’ lack of transparency (with regards to how they evaluate webpages against each accessibility guideline), which leads to

inconsistencies in their output. They also highlight the tools’ slavish adherence to certain guidelines (such as the presence of alternative text on images, which many tools pass regardless of its accuracy), which prevents them from truly reflecting the user experience of people with disabilities.

Many of the surveys discussed in Section 2.4 examined respondents’ attitudes towards accessibility tool and guidelines. The webmasters surveyed by Lazar et al. (2004) reportedly found existing accessibility tools to be flawed and argued that tool improvements would motivate them to create accessible websites. Web developers surveyed by Rosson et al. (2005) admitted omitting accessibility checks due to relatively tedious and time-consuming tool support. Existing accessibility evaluation tools, the authors claim, were too verbose, prone to reporting false positives, and lacked

also cited the difficulties they encountered with tools and guidelines as a major barrier to web accessibility.

The difficult and time-consuming nature of accessibility evaluation tools was raised by the web developers surveyed by Trewin et al. (2010). They described existing tools as being unclear, cumbersome, and incomplete, with respect to the standards that must be met. Confidence in the tools’ output was also a big issue for respondents, with many reporting to have struggled with tools that generate many false positives. Surprisingly few of the web practitioners interviewed by Farrelly (2011) claimed to have used accessibility evaluation tools but those that had raised similar concerns over false positives, false negatives and insufficient support to remediate problems.

The study of accessibility evaluation tools by Petrie et al. (2007) considered whether, irrespective of the tools’ performance (about which the authors agree they have “serious questions” (p. 2)), the usability of the tools presented a further barrier to accessible web development. The authors point out that web developers should be able to concentrate on web developments tasks and not be distracted by tools that are difficult to use or interpret.

Petrie et al. conducted a group expert evaluation of five popular accessibility evaluation tools (Bobby, Cynthia Says, Deque Ramp, Site Valet, and WAVE), in which they collectively noted and rated usability problems. The evaluators discovered what they considered to be very obvious, serious and easily avoidable usability problems in each of the five tools. The majority of problems related to how the tools reported accessibility issues, which the authors note was “almost always unclear” (p. 9). The tools were also reportedly unclear about the scope of evaluation, both in terms of the number of webpages being evaluated, and the guidelines/level of conformance being adhered to. According to Petrie et al., entry-level accessibility evaluation tools were not making the vital task of web accessibility evaluation easy for web developers. Furthermore, the tools were doing very little to enhance web developers’ knowledge and understanding of accessibility issues. Trewin et al. (2010) also concluded that web developers need tools that enhance their understanding of accessibility through detailed explanations of problems.

A novel attempt to overcome problems with existing tools was devised by Bigham and Ladner (2007). They developed a scripting framework called Accessmonkey that allows web users, web researchers and web developers to collaboratively improve accessibility. It uses JavaScript scripts to dynamically reconfigure webpages to automatically address accessibility problems, for example, by generating text alternatives for images or making components keyboard accessible. Bigham and Ladner note that existing tools “rarely offer specific suggestions that developers can implement” (p. 1) and that web

developers struggle to integrate them into their existing workflows. Accessmonkey can be integrated into existing tools and browsers and provides a means of gaining specific feedback and workable solutions to accessibility problems directly from web users. However, while Accessmonkey is a pragmatic and empowering solution for disabled web users, it cannot guarantee that web developers will adopt or understand the proposed website adaptations. Reducing web developers’ responsibility to an approval and editing process may have efficiency benefits but at the cost of failing to advance their understanding of the problems that users encounter.

Another innovative approach by Bigham, Brudvik and Zang (2010) also shifts some of the responsibility for web accessibility onto web users. Accessibility by Demonstration (ABD) is an extension to the open source web-based screen reader WebAnywhere (Bigham, Prince & Ladner, 2008). ABD allows WebAnywhere users to retroactively record accessibility problems as soon as they occur as human-readable macros and to send the recordings to web developers. The recordings capture both the screen reader output and whatever keyboard commands the user has made. This is accompanied by visual highlighting to assist web developers in following along. ABD plays the user’s recorded actions over the current version of the page, allowing web developers to replay the recording while making iterative improvements to the webpage. While this approach does not furnish web developers with specific solutions to web accessibility problems, it gives them the opportunity to experience the problem from the user’s perspective: a vital step in developing their understanding of web accessibility and stimulating creativity in solving accessibility problems in future.

Criticism for failing to enhance web developers’ understanding has been levelled not only at tools but also at web accessibility guidelines. Not long after the publication of WCAG 1.0, Sloan, Gregor, Rowan and Booth (2000) highlighted the considerable amount of understanding required of web developers to use the guidelines effectively.

An evaluation of WCAG 1.0 by Colwell and Petrie (2001) found that the structure and tone of the document made it difficult for web developers to navigate and interpret. Furthermore, they found that, in some cases, adhering to the guidelines resulted in webpages being more inaccessible. Respondents to Knight’s (2003) survey of designers, information officers and accessibility advocates ranked the difficulty of navigating, interpreting and implementing WAI guidelines, as the third biggest barrier to web accessibility. One respondent described the guidelines as “opaque, very poorly organised, daunting, and in many cases unrealistic” (para. 15).

Web developers surveyed by the DRC (2004) reportedly found WCAG 1.0 useful but considered the lack of simple but authoritative guidance a barrier to web accessibility. Sloan, Kelly, Heath, Petrie, Hamilton, and Phipps (2006) collated the criticisms made of WCAG 1.0 by other authors, characterising the guidelines as subjective, ambiguous, unnecessarily complex, logically flawed, and difficult to understand. They also

highlighted the distinct lack of empirical evidence of the majority of recommendations made in WCAG 1.0. Despite acknowledging the WAI’s significant accomplishments in defining and promoting web accessibility, Farrelly (2011) considered the confusion and uncertainty caused by its guidelines to be a leading factor in halting the diffusion of web accessibility.

With the publication of WCAG 2.0 in 2008, the WAI sought to address many of the criticisms levelled at the previous version of the guidelines. In doing so, however, they appeared to create further difficulties for web developers. Tackling the technology- specific nature of WCAG 1.0, which had led to the guidelines becoming out-dated, WCAG 2.0 was designed to be technology-neutral by promoting general accessibility concepts over specific implementation details. Unfortunately, this resulted in the use of ambiguous notions such as “accessibility supported technologies”, which Alonso, Fuertes, González and Martínez (2010a) claim only caused further confusion.

Kapsi, Vlachogiannis, Darzentas and Spyrou (2009) evaluated the usability of WCAG 1.0 and 2.0. They considered the effectiveness of both versions of the guidelines to be impeded by the use of complex language, complex document structures, and lengthy documentation. While they acknowledged that WCAG 2.0 has overcome the

technology dependency of its predecessor, they claimed it was still “characterised by an exponential learning curve” (p. 4).

Although few of the web practitioners interviewed by Farrelly (2011) were sufficiently familiar with WCAG, of those that were, all of them found the guidelines difficult to use. They raised concerns over the length of WCAG 2.0, its lack of clarity, obtuse language, and convoluted organisation. Participants considered the guidelines difficult for even seasoned web developers to use effectively, let alone hobbyists or anyone new to the field.

A study by Alonso, Fuertes, González and Martínez (2010b) of 17 students taking part in a web accessibility course concluded that WCAG is “far from testable for beginners” (p. 8). The authors attributed this to: difficulties in comprehending the language used in the guidelines; a lack of knowledge that is required to correctly evaluate the guidelines; and a reluctance to spend a lot of effort evaluating the guidelines.

Criticisms over the subjective nature of WCAG 1.0 were addressed by attempting to make WCAG 2.0 more objectively testable. A study by Brajnik (2009) with 35 student web developers, however, found that, for many of the WCAG 2.0 guidelines, web developers were unable to come to an 80% level of agreement about whether a problem was present in a webpage. Agreement between evaluators of many WCAG 2.0 criteria was actually lower than the equivalent criteria in WCAG 1.0, suggesting the second version of the guidelines are more difficult to apply.

Like its predecessor, WCAG 2.0 also suffers from a lack of empirical evidence. Though Power, Petrie, Freire and Swallow (2011) propose an effective methodology for

remotely evaluating WCAG 2.0 implementation techniques, few members of the web accessibility community have continued this empirical, evidence-based approach. The validity of WCAG 2.0 is also questioned in an empirical study by Power et al. (2012) of the problems encountered by blind users on the web. This demonstrated that only 50.4% of the problems were covered by WCAG 2.0 success criteria.