Programmer-focused website accessibility evaluations

Abstract

Suggested methods for conducting website accessibility evaluations have typically focused on the needs of end-users who have disabilities. However, programmers, not people with disabilities, are the end-users of evaluations reports generated by accessibility specialists. Programmers' capacity and resource needs are seldom met by the voluminous reports and long lists of individual website fixes commonly produced using earlier methods. The rationale for the need to consider the whole website development process, and the social characteristics of programmers and project managers is presented. A new programmer-centric Streamlined Evaluation and Reporting Process for Accessibility (SERPA) is described in detail.

Exploring perceptions of web accessibility: a survey approach

“…However, it seems that there is a disconnect between what people believe and do, similar to what Lazar et al (2004) found: webmasters are aware of Downloaded by [University of Arizona] at 06:21 05 February 2015 web accessibility practices, while the evidence supports that the web is non-accessible. The fact that conformance badges are displayed on non-conformant websites (Gilbertson and Machin 2012) may indicate an overreliance on tools and might be a symptom of communication problems between the HCI specialist and programmers (Law et al 2005). This means that if one is educated in web accessibility, it should be strongly emphasised that using only automated tools to assess accessibility might not be enough to identify all the accessibility problems in a web page.…”

User-centered design in universal design resources?

“…In another example, Law et al [12] have developed a method for reporting the results of website accessibility evaluations that modifies suggested processes (e.g., [29]) to make it programmer-centric. The automated accessibility evaluation tools of the time produced voluminous stacks of paper, which essentially were lists detailing where in the code and on what pages of the site the violations occurred [12].…”

“…The automated accessibility evaluation tools of the time produced voluminous stacks of paper, which essentially were lists detailing where in the code and on what pages of the site the violations occurred [12]. These lists were often appended to lengthy evaluation reports and handed to programmers with the expectation that all they had to do was fix everything in the report.…”

“…Recalling Cooper's [4] observation, the programmers had not had their ''minds changed''. The method from Law et al [12] was called the Streamlined Evaluation Process for Reporting Accessibility (SERPA). The SERPA process was a direct response to the acknowledgment that (generally speaking) people producing the reports could quite easily evaluate a website for accessibility, but that did not necessarily mean that they would know how effectively convey their results to programming teams.…”

Assessing the Effort of Repairing the Accessibility of Web Sites

“…As such, it is important to evaluate accessibility as close as possible to what is delivered to the user [2]. The drawback of this Web site evaluation procedure is the possibility of guiding to misleading accessibility results, for the point of view of the developer [3] or of the team manager that tries to assess the effort of repairing a web site. For example, if a template intrinsically contains an accessibility problem, that problem is reported as often as the template is used within the page/site.…”