Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I am not sure if there is a definite answer to this but I thought I'll just throw it out....

I am working on re-designing a site for an federal organization who also require their site to be accessible as per 508 section guidelines. One of the recommendations that I got was that I should look at incorporating accessibility guidelines while designing the wireframes itself so that we dont run into issues later.

What I like to know is if there are any recommended guidelines on how to incorporate accessibility principles into wireframes ( I have read as much as I can on how to incorporate accessibility during the actual visual and html design phase) but I have drawn a blank with regards to what should be done for wireframe design and what should be the checkpoints.

I did find this interesting article which talks about some guidelines but they are pretty generic. To quote the article:

Intuitive Hierarchy: A web page with over 150 links will take a very long time to tab through, whether a user is listening to link names or reading them visually. This makes intuitive hierarchy all the more important. A good hierarchical structure will mean that fewer links are presented on each page of the site and that only relevant links are presented on the page at the next level down. As long as the links are meaningful and relevant, the hierarchy or structure will mean that overall, a user has fewer tab key presses to make, because fewer and more relevant links are made available.

Navigational aides: Users with visual impairments are often helped enormously by an A to Z index or a site map. These navigational aids present content in a long list that can be viewed easily with screen magnification or a large text size.

Use Meaningful links : By embedding links in the overview copy, content planners can support users' journeys towards key information. Embedded links are great because they enable readers to understand more about a page than an isolated navigation link in a menu. Embedded links can give users direct access to buried content, at a deeper level in the logical hierarchy.

I was wondering if anyone has come across specific guidelines in research or from their own experience.

share|improve this question
add comment

2 Answers

In terms of making wireframes accessibility documents, this is not what wireframes are for!

Other things that wireframes are not designed to be:

  • content repositories
  • interaction design specification
  • visual design specifications
  • a permanent record
  • etc.

:)

My point merely being that it's important for UX teams to push back on the desire for wireframes to be the document of record. Wireframes are a way to visually sketch out ideas. That's their intent. Asking them to do more than that, while common, is also fraught with inefficiencies.

As for accessibility specifically, they're already documented. As you point out, the 508 or WCAG guidelines are examples of that.

The key for accessibility is that everyone should understand it and be aware of it. The UX team should have knowledge of it so they aren't purposefully designing solutions that are difficult to make accessible. The developers should understand it so the presentation layer markup and javascript they are using is accessible to begin with.

Asking a wireframe to communicate accessibility requirements is akin to a wireframe being asked to communicate HTML best practices. That's just a skill set the builders of the site should possess. If they don't possess that skill, then that's a training/education problem--not a UX Wireframe problem.

So based on all of that, in terms of answering your specific question:

how to incorporate accessibility principles into wireframes

It comes down to the UX designers working on wireframes need to have knowledge of accessibility best practices. There's no master list of things to look out for, as it's always going to be highly context-centric. And there's always room for debate as well. So I'd suggest the best solution is to make sure your UX team has some amount of accessibility training. Ideally, bring in a UX staffer that's an expert on accessibility issues.

share|improve this answer
add comment

I'm not aware of anyone having compiled a list of 508 or WCAG guidelines that are specifically worth focusing on during wireframe stage. Some visual aspects such as colour contrast and text size, and technical details of implementation such as HTML markup are almost certainly out of scope at the wireframing stage. That said, there certainly are still lots of things that you should consider. The decisions you make in wireframes with regard to functionality and structure will almost certainly have accessibility implications.

In addition to the three areas quoted in the question (intuitive hierarchy, navigational aides and meaningful links) the following spring to mind:

  • Think about keyboard (and touch) accessibility when wireframing complex controls or unusual interfaces. Don't assume you can rely on the mouse.
  • How will users know where they are? Do you need to include, for example, a breadcrumb?
  • For automatically moving and updating content, consider how the user will be able pause/stop;
  • For audio and video content, consider how your interface will provide access to a text transcript;
  • Don't rely on shape, size, or visual location to provide instructions or to provide important information;
  • Allow for suitable line length (not too short, not too long);
  • Form validation - How will you indicate mandatory fields and how will you present error messages?
  • How will the interface respond to different user inputs? Will, for example, typing in a field change the page automatically? How will you communicate those changes to your users?

It is worth noting that these considerations will vary depending on who is producing and consuming the wireframes, and for what purpose. If you are producing wireframes in order to give direction to designers and developers, you should probably give more thought to the details of accessibility, more so than if they were being used to give a high-level overview (for a client, perhaps).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.