Whether you are well-versed in UX Design or new to the field, you have likely heard the term “wireframe.” A wireframe is a low-fidelity visual representation of a website, application, or product that allows us to define the structure of the page, hierarchy, and placement of elements, and ultimately helps us plan the layout and interactions without the visual distractions of a high fidelity mockup.
Wireframes are a great way of gathering feedback from colleagues and stakeholders to help us iterate quickly without worrying too much about the color scheme and overall look. Critique sessions are often the medium with which we collect this feedback, but not all colleagues or stakeholders can attend meetings, so it’s a good practice to share our design process in wireframe form on a platform like inVision or Github where we can also collect asynchronous feedback from others.
The problem: The process for collecting feedback on wireframes is not inclusive nor accessible for people who are visually impaired. It’s impossible for them to participate in this process because wireframes are a visual asset.
I believe the best solutions are the result of a thoughtful process that centers the discussion not only on users, but also on those who have been historically marginalized, excluded, and discriminated against because they are a minority.
A little background
In 2020, we began working with the Facebook Accessibility team and the W3C’s ARIA-AT community group. Our goal was to design an app to test how reliably ARIA patterns are rendered by specific screen reader and browser combinations.
We conducted user and stakeholder interviews to gather requirements, defined use cases, and designed wireframes for an application that would allow manual testers to run tests for how well-supported ARIA patterns are by certain browsers using a number of different Assistive Technologies. Many of the people involved in the project are blind, including one of our key stakeholders, and getting their input on these wireframes was crucial to me before I could implement any solution. So I set myself to design wireframes that could be inclusive and accessible.
Making the Design Process Inclusive
To create inclusive and accessible wireframes, one first needs to understand how people who are blind use assistive technologies.
Blind users use screen readers to hear the contents of the page and navigate through using their keyboard. That’s how they “see” the Web. They can simply let the screen reader read the page from top to bottom, or they can navigate using the tab key or different shortcut combinations (depending on the screen reader they are using) to navigate freely between areas, components, or links.
Just like sighted users, “scanning” the page’s content first is a pretty common behavior. Screen reader users usually navigate through the major landmarks first, such as the Header, Nav, and Main, and through the Headings. This allows them to gain an understanding of the page’s structure and its content before diving into a specific area or component of the page to learn more.
Text-Based Wireframes
Inspired by how screen reader users navigate through websites and applications, I developed a way to present inclusive and accessible wireframes by documenting the components and interactions of a visual wireframe in such a way that it would be organized and structured similarly to how a person who is visually impaired would consume a page. I called this “Text-Based Wireframes,” and have divided the process into three steps.
Step 1: High-level overview
It is important to lay the groundwork first.
I begin by briefly describing the purpose of the page, how the user gets there, and what are the major areas of the page. This helps give the audience a high-level overview of the content and its structure. It is important to describe where the areas of the page are located, the approximate amount of space they would take, and how they are co-related.
Step 2: Main areas
Once an overview of the whole page has been provided, and the areas defined, I move on to describing each area in detail, and list the UI components they have in an intro paragraph for each area. Just like in the application itself, it is important to make proper use of headings when organizing our sections because this will help screen reader users navigate better.
Step 3: UI Components, states, and interactions
After describing the areas and listing their components, it is time to describe the purpose of the latter. I usually do this by using ordered lists and specifying the purpose of each. Part of this description should include the result of the user interaction with them and, if it applies, the different states.
Let’s say we are describing rows and columns in a table. This might be the deepest level we need to describe in our wireframe, but if we are doing the same for buttons, oftentimes there are several states in which a button could be presented. I then go one level deeper to go through each of the different states using nested lists.
Final Words
As designers, we are taught that users should be the center of our design process, but there are few to no methodologies out there to conduct research centered on people who are visually impaired in some of the design processes we use.
Creating accessible wireframes requires effort, but is essential to build into our practice. To truly design the best experiences, we need to not only think about designing for everyone, but also with everyone.
You can learn more about the ARIA AT project and the ARIA AT App from their GitHub repositories and find a few text-based wireframe examples there as well.
