Topic: Reinventing the wheel - breaking design conventions

  • Our fifth open house already - record attendance of 17 people, and a more practical, training-like topic: the importance of adhering to established design patterns and conventions because violating them makes your application unpredictable: mportant elements are out of the expected places in the flow, and therefore not findable or actionable.
  • We started by analyzing the design patterns of a slideshow: it is important that it has stop and start controls, that the sighted user can jump to any slide at any time and that it stops automatically on hover. It is all about it behaving in a predictable and controllable manner. The same expectation applies to screen reader users - that the behavior is predictable and controllable.
  • We then looked at four examples of page mockups inspired by real world problems discovered by AUL over the years of testing.
  • Example 1: an iOS app where an additional panel has been added along the left side of the screen to accommodate a set of navigation buttons, pushing the standard window into the remaining portion of the screen in the middle and right, and moving the "Back" button with it from its default location in top left corner further to the right towards the middle. Users used to hitting the top left corner end up hitting the top option in the new navigation menu instead.
  • Example 2: a registration form where there is a sticky header with the controls to reset and to save the form. The header is above the form in the DOM; when the user gets to the bottom of the registration form, they don't find the expected buttons to reset and submit. This can be even more of a problem in Google Apps since the user may come to expect that all inputs autosave, and on reaching the bottom assume that the results are already saved.
  • Example 3: another registration form, this time with an error message that displays below the submit and reset buttons. To a screen reader user, those buttons signal the end of the form and users are highly unlikely to look for error messages (or any content that is part of the form semantically) below those buttons in the document flow.
  • Example 4: an autoupdating list of results that changes every time a new character is typed into the search box, and that has ARIA attributes to force the screenreader to start reading those results over and over from the beginning every time they update, making it impossible to hear anything else - a fine example of an application that is not predictable or user controllable.
  • See you next week, October 31, for part 2 of this session, when Amelia will talk about implementing new web design trends accessibly.