Designing wireframes keeping accessibility guidelines in mind

Question

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.

Answer 1

I've been working with UX teams to help establish good practices with regards to including accessibility early on as well as documenting some issues in wireframes and designs.

Matt Obee covered keys issues above. To his list I would also add:

• Structure: understand how the heading structure works on the page, where lists are, WAI ARIA Landmarks and data tables. Simply indicating what the main heading is, sub headings and so on will ensure that the design does support a logical heading structure when coding starts.
• Colour and meaning: using colour to reinforce meaning is good, just make sure there is another way of defining colour for users that can not perceive colour. It's the same principle with shape and size.
• Colour contrast: this should meet the colour contrast minimum from WCAG and foreground and background colours defined in style guides.
• Focus states: hover and focus states should be defined for all focusable elements (the same styling works well and is preferable to browser defaults). Also ensure the selected states are unique to the hover/focus states.
• Content/focus order: If it is not immediately obvious it is work stating the content order in the wires so that groups of related information don;t get split up. This is essential for screen reader users.

All of the above can be annotated into wireframes and style guides. Looking at the bigger picture I would also say that it is the role of UX to think about the following accessible UX design principles:

• Choice: offering two ways to complete complex or non-standard interactions

• Control: not suppressing system accessibility settings or forcing content on the user when not requested. For example suppressing pinch zoom or forcing autoplay for multimedia.

• Familiarity: using standard design patterns, consistent labeling and alternatives across devices - both visually and in alternative text.

• Value: when prioritising features to include ask what the beneifit is to disabled users. What might be a nice to have for all users could be of huge benefit for disabled users. For example adding in a sort mechanism to a listings page so users can sort by most recent, popular etc. This saves wading though content to get to what you want - useful for all but essential for some.

I have written about some of this in Smashing Mag in a case study of how we integrated accessibility into UX on BBC iPlayer.

Answer 2

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.

Answer 3

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).