Conceptual Model
An application's conceptual model is the "mental map" that the designers build into it in order to present information logically. In regards to study participants, the conceptual model represents how they expect and believe the information they are encountering should, and does, fit together. A hallmark of usable design is when both the designer's conceptual model, and the users' conceptual models are in alignment.
As mentioned in the Executive Summary section of this report, this series of usability tests illuminated a disparity between the participants' expectations concerning the Web site's guideline recommendations, and those of the Web site designers. In addition, participants were unable to make sense of the relationships between checklists, checkpoints, guidelines, and techniques.
In addition to those significant findings, the following conceptual model discrepancies came to light.
Finding 7: Participants frequently sought out or stated the importance of a "good, solid overview" of Web accessibility.
In keeping with Finding 4, participants stated that they expected to find a highly visible option on the WAI Web site homepage that would provide them with overviews, tutorials, scope of effort indicators, and a series of Frequently Asked Questions about Web accessibility techniques that would lead them to specific information about how to implement those techniques. A few participants located a "slide" presentation within the WAI Web site that they considered "perfect" and "very helpful" at conveying just this sort of information.
However, as discussed later in Finding 24, we observed that participants rarely noticed when they had navigated into a slide presentation, and we observed confusion as they attempted to ascertain "where the menus had gone" and find their way "back" to the WAI Web site proper.
Finding 8: Participants struggled to understand the text they were reading- both the sheer amount of it, and the language itself.
Throughout the study, the WAI Web site content was described as "impenetrable," "overly complex," and "supremely difficult" to understand. In one especially memorable moment, a participant who had earned an advanced degree in mechanical engineering from MIT, stated: "Oh yeah. This is written by engineers, for engineers . . . We have to take this out of the hands of the engineers." The highly technical language used to describe accessibility issues and procedures, coupled with the physical presentation of complex procedural information (document draft histories, for example) alongside content, appeared to be very much at odds with the needs of the Web developers for straightforward, unadorned information that would provide clear advice in an efficient manner.
Moreover, the participants frequently stated that these factors contributed to a feeling of alienation from the material they were reading. The deeper they dove into documents, the more they felt the information wasn't intended for them. One participant referred to the WAI Web site as giving her the feeling that it was "an exclusive club."
Finding 9: Participants stated that the WAI Web site focused too heavily on WAI and not enough on Web accessibility.
As they moved about the WAI Web site, attempting to complete the tasks we had given them, participants stated that they felt the Web site was striking an improper balance between information from WAI and information about WAI. In previous findings we shared that we observed the participants responding to WAI documents by asserting that the information was "all about WAI and how they came up with the document, and not about the content." This opinion was consistent across other areas of the WAI Web site as well.
Participants suggested that the WAI Web site should be "far more" focused on presenting relevant accessibility information to Web developers, and "far less" focused on presenting information about WAI. There was, as they put it: "Too much WAI."
One example that the study participants pointed to when we asked them to clarify what "too much WAI" meant, was the homepage of WAI Web site. One participant said: "It's all about WAI. Their meetings, their groups. The second section on the page is 'about.'"
The Participation section of the WAI homepage was also singled out, perhaps because the WAI Web site failed to communicate the value proposition of participation to the participants. In the words of one participant, "They want you to join them here, and the language is all about working groups. What's a working group? Why doesn't it say 'join' or 'volunteer?'"
Other participants expressed confusion with the organization of the WCAG Working Group page itself, saying: "'How to Join' is the very last section. They must not want you to join." We observed participants both struggling to move past the information pertaining to WAI's makeup and practices, and to understand how that information might pertain to them.