7 Things I Learned Creating an Accessibility Guide for Designers
A couple months ago, I was tasked with researching and documenting the Web Content Accessibility Guidelines (WCAG) for a group of user experience and graphic designers.
WCAG’s defines it’s purpose this way:
Web Content Accessibility Guidelines (WCAG) 2.0 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.
The current version is WCAG 2.0, which builds on WCAG 1.0. The document outlines the principles, guidelines, and success criteria that empowers technologists and stakeholders to employ best practices for creating accessible web interfaces.
With that context, I’ll dive into the seven things I learned.
7. Most designers have not read WCAG
Upon interviewing a particular designer, I asked the question — “Out of 100, what percentage of designers do you think have read WCAG?” Her genuine answer — “. . . 5%,” and that was “being optimistic.”
The fact that the majority of designers have not touched WCAG led me to a couple assumptions: (1) Designers are not aware that the document exists, (2) Beauty and ingenuity takes precedent over functionality and accessibility, and (3) If they are aware, the length of the document deters most from reading it, even making them feel they are “wasting time.”
For a document to attempt to bridge the gap in information about accessibility, it was shocking to know that it was underutilized and even unknown.
6. Accessibility != ‘color contrast,” even if it feels that way
When I inquired about easy wins for accessibility, color contrast came up every time. This in itself was positive, but in conjunction with online research I found that accessibility is minimized to a conversation of color contrast.
My assumptions in this point lie in scalability, gender balance, and subject matter. Companies (especially scaled ones and those that wish to scale), whether conscious of WCAG or not, know that users experience various states of vision and they want these users on their interfaces. If you develop an interface that cannot be conveyed to a particular set of users, you lose their business — point blank.
My second assumption is that because color blindness affects men greater than women, (1 in 12 men versus 1 in 200 women experience color blindness) in a field that is male dominant, it makes sense that men would design for something that affects a large number of them, creating a large conversation around it.
For designers, color is a large aspect of the work they oversee. In the various manifestations a choice of color arises, color-contrast exists within this wheelhouse. In addition, I found color contrast tools though simplistic in nature, can be easily utilized as plugins and online tools. I even found this cool Adobe feature that shows designers their work depending on various states of color-blindness.
Although this is a win for low vision and color-blind users, it minimizes the other aspects of WCAG. So say it with me — just because you are tagged for accessibility issues with color contrast, does not mean it is the sole aspect of accessibility that deserves your team’s attention.
5. Accessibility is not “sexy . . . it’s a trend that never happened”
At an UX event, I asked about accessibility and was told it was a “trend that never happened.” Is this Mean Girls? Are we Gretchen trying to make fetch happen?
The skill of designing for accessibility isn’t meant to be “sexy,” it’s an ethical principle of design. The things we find “sexy” across industries often reflect a privileged user, one with the right characteristics, class, opportunity, and ability. When we talk about users with disabilities, the conversation gets less “sexy” for most people. Why? We must decenter the normalized user, that has no mobility, visual, cognitive, or social impairments and think about those who would have trouble with our designs and interfaces for various reasons.
When we develop use cases for main features, we should be developing cases that solve problems for users experiencing accessibility issues. To adequately support our users, what appears “sexy” to us or our teams should not be a deciding factor.
4. Accessibility is seen as reworking, red tape, and restriction
When the word accessibility wafts into the ears of designers and developers, it is connected to backtracking, rework, and rolled eyes. Accessibility issues flagged at the end of a process when the design is living creates massive amounts of waste. Therefore anything to do with accessibility develops a negative perception and conversations about it is avoided at all costs or experienced in contempt.
Accessibility obtains the reputation of “red-tape” in industries that are mandated by the government to adhere to 508 IT accessibility regulations. Governmental agencies, educational institutions, and transportation companies are some examples of entities governed by 508. For designers in these industries, designing for accessibility is not an option it’s a requirement. Therefore, accessibility can become a checkbox, rather than a mindful consideration.
As restriction, designers are unable to utilize some color schemes, interactions, visuals, language, and reading orders simply because they are not accessible. As designers, here is where we choose sides — do we value visual appeal or accessibility? The answer to this question defines our trajectory and how we think about the impact of our designs on those who will interact with them.
3. ARIA labels create conversation and a robust experience
ARIA labels are an invisible coding element used to “define a string value that labels the current element.” In other words, it offers those using screen readers more context to labels that appear on the screen.
ARIA labels create conversations between UX designers and developers, two roles whose work has major implications for accessibility. When teams are large or departments rarely interact, ARIA labels can be used to express the intent of UX decisions to developers. With a better understanding of design decisions, developers are better supported to convey the intentions of UXers and can further refine ARIA labels to convey valuable information to users with screen readers.
This conversation empowers designers and developers to craft ARIA labels used in development in a way that offers low vision and blind readers with more context where necessary to provide an optimal experience. For instance, a graph would normally be read off in the order it appears on the screen. A screen reader’s functionality does not connect the graph with information in prior paragraphs or create a story for the user using the graph. An ARIA label can solve this problem offering these users a more holistic experience that considers how they will receive the information.
2. Accessibility is not always given visibility under the umbrella of inclusion
In a conversation about inclusion, we need to talk about accessibility. When inclusivity becomes a conversation solely about race and even gender identity and sexuality, we erase disabled designers, developers, and more who exist within the intersections of these identities.
In conferences and conversations where accessibility is the topic, we must train ourselves to step out of the code and design, ensuring there are representatives of disabled users on our teams, conferences, events, and usability tests.
Like anything, talking about the people we want in the room does only so much. Make moves and noise to ensure these people are beside us.
Don’t tack on disabled users as an after thought, create a space for them to be heard and create their narrative.
1. Accessibility-first is the best way to design for accessibility.
Hate having to re-do work? Want to be a good human and cater to a group of users often forgotten? Want to be ethically responsible as a technologist and designer?
Design accessibility-first. Doing so is beneficial to all users, ensuring a highly functional and accessible experience. You guarantee all users despite ability can access information effectively and efficiently.
When you put accessibility-first, you create a mindful and aware ethos on your team that dissolves the “design for designs sake” mindset and centers multifaceted users in the forefront of our minds.
