Defining accessible experiences with linear wireframes

October, 2016: Update! I used to encourage experience designers to capture annotations for accessible keyboard functionality separately in "linear wireframes." The reason for that was that it was new to them, and it felt like a very separate exercise. More recently I have recommended that keyboard events be captured in the same wireframes that capture all other interactions as a more holistic experience. I have edited the article below to refer to linear interactions as opposed to linear wireframes.

Traditional wireframes describe page functionality in a web browser for the desktop, tablet, and mobile breakpoints, typically for people who use a mouse to navigate. However, when considering accessibility guideline compliance, there are many additional considerations and interactions required that are specific to the more linear screen reader experience that should be clearly defined and reviewed/approved by your client, the web site owner, as part of the design phase, especially for complex interfaces.

This is because many users of assistive devices are forced by their device to navigate experiences in a linear way. Sighted users who use a mouse pointing device can navigate to any part of a page at any time. Users of assistive devices like screen readers are forced to start at the top of a page and navigate through the content in a linear order.

Examples of linear interactions that should specifically be defined for the screen reader experience include:

  • All skip navigation links and link copy (it may make sense to have more than one)
  • Any hidden headings for screen readers only and heading copy (to orient the non-sighted user to sections that may be obvious to sighted users)
  • The required focus order of content for a screen reader to parse through (this will determine the actual content order in the markup compared to the visual content order on the screen)

How is the screen reader experience usually defined?

Short answer: It is not usually defined.

TL/DR: The way I see this handled on many projects is by leaving decisions like the placement of the skip navigation link and the alternate headings to front end developers who build the site. However, it is not a front end developer's role to define this content, and it is risky for a developer to attempt this without having a mechanism to obtain client approval for the direction taken. This should be defined as part of the overall experience, like everything else.

Who should define linear user experience?

It is the role of an information architect to define this content, and I was pleased when my team took the step last fall of creating our first linear experience annotations for the complex flight search flow for a Canadian airline company.

Linear interaction definition considerations

Capturing linear experience annotations will initially take additional time to create, maintain, and get approved. It can take up to 15-20% additional effort to deliver linear versions of wireframes for experience designers who are not experienced at providing these. These rules are not difficult to learn, and that 15-20% of time will quickly be reduced.

For more information on linear interactions, see my other blog post, How to make your wireframes more accessible in five easy steps.

Leave a Reply

Your email address will not be published. Required fields are marked *