Think back to our second user experience in Section 1 grappling with the bus schedule. Now that we have learned the capabilities of screen readers and talking browsers and the elements and attributes that make them most effective, let's write out some design goals we'd want to achieve if we were to design a transportation site.
These points may seem to go without saying. But that's the problem: when design goals go without saying, they all too often go without getting accomplished, too. Nobody means for this to happen. But it's all too easy to let unstated goals slide when deadline pressures get too intense or to forget to pass them on when new developers join the project in midstream.
And in any case, the first goal is apparently not all that obvious; in fact, quite a few designers seem to be convinced that it's better to create different versions to meet different needs, as both Capital Metro and the Santa Clara Valley Transportation Authority did at first (see Chapter 5 for details).
It may not seem intuitively obvious, either, that the best way to achieve that first goal, of designing a schedule that can be used with equal effectiveness by people with and without disabilities, is to concentrate on creating a schedule that people who are visually or cognitively impaired can use quickly and easily. This is the AccessFirst principle: if we make it our first priority to meet the needs of people with disabilities, we'll also do a better job when serving other users.
Coming at it from the other direction that is, without taking the needs of people with disabilities explicitly into account in setting design goals clearly does not work well, as we learned from the examples cited earlier. AccessFirst design serves the needs of all users, in large part because, in order to meet the needs of users who have disabilities, we have to be much clearer about all the elements, constraints, and opportunities involved in the design, clear about structure as well as content and presentation.