The Approachable Guide to Prototyping for Accessibility with Axure RP
About this guide
This guide pulls together a number of accessibility issues worthy of your consideration as you develop your next Axure RP prototype, along with some simple steps you can take in the tool to pilot your project toward an outcome that’s more friendly for all types of people to consume.
In assembling this guide, we’ve gathered advice from the following web accessibility specialists:
Aidan Tierney, Manager of Digital Accessibility at TD Bank. Aidan was interviewed in 2015 by Access iQ about accessibility and prototyping.
Alison Walden, Director of Experience Technology at SapientRazorfish and proprietor of the accessib.ly blog. Alison has written broadly on accessibility, but her 2016 presentation “Creating accessible experiences starts with experience design” is particularly relevant here.
Terrill Thompson, Technology Accessibility Specialist with the University of Washington and accessibility blogger. Terrill’s personal blog is both a wealth of information on best practices and also itself an instructive example of accessible web design.
Ann Chadwick-Dias and Marguerite Bergel, Directors of UX Research at Fidelity Investments. Ann and Margy are distinguished researchers, trainers, and presenters in the accessibility space, whose work has been cited by several of the experts we consulted for this guide.
Sarah Horton and Whitney Quesenbery, authors of A Web for Everyone. Sarah and Whitney’s highly influential book is required reading for the accessibility-enlightened Axure designer.
The reasoning behind this guide’s recommendations is thoroughly explored in the above links, so please click through if you have the time and inclination to self-educate. For practical tips on how to implement our experts’ suggestions when working in Axure RP—the “how” as opposed to the “why“—read on.
The official guidelines (aren’t these)
If conformance to an official set of accessibility guidelines is an explicit goal of your project—or if you’d like it to be—the guidelines you want are the Web Content Accessibility Guidelines (WCAG), current version 2.0. The WCAG are intended to be precise and thorough. If your web content conforms to all of the WCAG 2.0’s level AA standards, you’ll get two things: you’ll very likely be in full compliance with any applicable laws, and you’ll also very likely have a site with much better usability for people with disabilities than 99% of what’s out there.
The Axure guide, by contrast, is meant to be informal—we won’t be citing WCAG criteria here. Instead, we’re going for approachability. It takes just a couple of minutes to dip into this guide for a quick, actionable tip or two about how to make your content better for accessibility than it otherwise would have been. Think of it as a collection of modest first steps.
Here we go!
– – –
One nice thing about doing your design in Axure RP is that it outputs HTML, which can then be fed into any of a number of HTML accessibility checkers available online. (WAVE is a pretty good one.) Publish your prototype to Axure Share, paste the URL into your checking tool of choice, and then pick a couple of the reported problem areas to punch up a bit.
If you’re looking for buy-in from project stakeholders on the issue of contrast, try the sunlight test, recommended to us by Jennifer Sutton. Take your most skeptical stakeholder out for coffee on a sunny day, and on the way, pull out your phone and load up your design. Even with the brightness on your device turned all the way up, chances are that a design with inadequate contrast will be darned hard to read in full sun.
Tab order / focus order
The tab order of keyboard-navigable elements, such as form elements, in your Axure RP diagram is determined by the order of elements in the Outline pane. (Check out the “Layer Order” section of our “Organizing Widgets” training page for more details.) If you’re designing a page with keyboard navigation in mind, consider temporarily switching the Outline’s sort order to “Back to Front” via the “Sort and Filter” button in the pane’s local toolbar.
If you’d like a normally non-keyboard-navigable element, such as an image, to become navigable in your prototype, simply add interactivity to it. Even just an empty OnClick case will do!
Modern browsers are pretty good about visually indicating focus as you’re tabbing through a page, but if you’d like more control over this, you can add special focus effects to your elements. To do this, first configure a Selected interaction style for your widget. (Here’s the section of our training dealing with interaction styles, and here’s our interactive button tutorial, which is a good practical demonstration of how interaction styles work.) Then, add OnFocus and OnLostFocus cases, like so:
Set is selected of This equal to “true”
Set is selected of This equal to “false”
Because the actions here refer to “this” widget, meaning the widget on which the case is set up, you can create these cases just one time and then quickly copy-paste them to as many other widgets as you need to.
Error presentment / error recovery / form validation
Axure RP’s powerful interactivity features can be used to build forms that look and feel like the real thing, right down to the complex validation behaviors. (Here’s an Axure blog post about building a form with dynamic validation and inline errors.)
When deciding how your form will handle error presentment, consider choosing from one the following three accessibility-friendly approaches: error alert, then focus; errors on top; or inline errors. (Here’s an article from WebAIM going into detail about each error presentment option.) If you’d like to go with the first option, you’ll want to build your modal dialog in Axure RP using a dynamic panel widget. (For an example of how to do a modal-type window with a lightbox effect, check out our lightbox tutorial.)
Your content deserves a thoughtful, consistent heading strategy—that’s just a general usability best practice (that also happens to be an accessibility best practice). Once you’ve ironed that out, implementation is a cinch with Axure RP’s widget styles. (Here’s our training page on widget and page styles.) Simply make styles corresponding to each of your heading levels—or use the presets in any new Axure RP file—and then let your developer know to match those levels to their corresponding HTML heading levels in your production content.
If you want to have a carousel or image slider in your Axure prototype, you can certainly do that. (Here’s our image carousel tutorial.) And if you want to have an element of your Axure RP design start going by itself, you can easily do that too, using the OnLoad or OnPageLoad events. (Here’s a full list of Axure RP events from our documentation.)
But if you build a carousel and also make it auto-rotate, for accessibility reasons it’s a good idea to provide a control that will stop the auto-rotation if wanted. Fortunately, there’s an Axure RP feature for that too! Set up a case on the OnClick event of your pause button, add a “Set Panel State” action, specify your carousel dynamic panel, and then choose the “Stop Repeating” option from the “Select state” dropdown.
Link text and link labels
Here are some traits of accessible text links:
- They make sense out of context—so no “link”, “info”, “read more”, or “click here” text links.
- They’re as long as necessary to describe the linked content, but no longer. In some contexts, one-word links are ideal; in others, five or six or more words will be necessary to adequately describe the target content.
- Put another way: accessible links answer the question, “would I want to click this?” For example, if you’re creating a set of links for adding parameters to a search filter, a text link reading “add color” is better than one that simply says “color”.
If it makes sense for your link to have text that’s different visually from what would be read out by a screen reader, no problem—create a widget note field to document your preferred link label. You can let your developer know to append the text in your “link label” note field to each link in such a way that it’s hidden from sighted users but available to screen readers. (Here’s our training page about widget and page notes.)
Form control labels
Form controls need good labels too. Make another widget note field called “form label” which you can use to indicate to your dev team what the appropriate descriptive text would be for each of your form elements.
This is another situation for widget notes. Create a note field called “alt attribute” to provide your developer with the alt text they’ll use for any relevant images.
Keep in mind that not all images need an alt attribute, particularly if they’re decorative or if the content of the image is already described by surrounding text. If you’re not sure whether your image needs alt text, or if so, what kind, refer to this handy and approachable decision chart from 4 Syllables.
Review pages / confirmation pages
If you’d like to pull user-entered data from page to page in your Axure RP prototype for display on a review or confirmation page, the Axure RP feature to reach for is variables. Here’s our variables page over on the Axure support site, and here’s our “pass text to next page” tutorial.
Timed responses / “need more time” dialogs
Axure RP provides for the use of a bunch of different time and date variables, which you can use to build real, dynamic count-up or countdown timers into your design. Here’s a reasonably complete list of available time and date functions in a post on the Axure forum, and here’s an .rp file example of a working countdown timer.
Just remember to build in a feature allowing the user to request more time to complete their task! A modal dialog with a couple of buttons usually does nicely.
– – –
Is our guide missing an Axure RP technique that has made prototyping for accessibility easier for you on a past project? Let us know by emailing us at firstname.lastname@example.org, and we may add your suggestion to this guide (along with a credit!).