This post was originally published on CSS-Tricks on November 21, 2017.
Accessibility is a hot topic these days, and the older we web-makers get, the hotter it’s going to become! That might be a snarky outlook, but what I’m trying to say is that it’s about time we start designing the web for everyone because the web was meant to be for everyone, and less and less are we able to predict where, when, and how our work will be consumed.
Accessibility is not just up to developers
As developers, we often encounter accessibility post-design, when we do things like implementating the correct role and aria attributes, ensuring navigation is keyboard friendly, and responsibly hiding elements. In general, our accessibility efforts go towards thinking about how to make specific components and features accessible, such as an SVG icon system or helpful tool-tips.
Given our roles as developers, this makes sense. Accessibility flaws, however, often originate in the UI design itself, and depending on our work environment, we developers don’t necessarily have the authority or bandwidth to advocate for accessibility in the designs we are handed.
#For example, let’s say you are tasked with turning a Sketch file into a one-page WordPress site.
The design has finally been approved by the client, and now you have a weekend to build the thing, plus another two days to work with QA to perfect it. As you take a look at the design for the first time, you notice that, on small devices, the dainty serif typeface overlaid on a background image would be difficult for low-sighted visitors to read.
You, the accessibility-minded developer, could proceed in a few ways:
- Remain silent and sate your accessibility conscience by making accessible choices in the code where you can
- Go ahead and make accessibility improvements to the UI as you develop, present them in the finished product, and explain yourself after
- Compile a list of suggested changes to send to the designer and request they be implemented in the mockups so you can then develop them
I was in a situation like this recently and, judge me if you will, I chose number one.
If I’d had the time and the guts, number 2 would’ve gotten me the furthest, but given the nature of my role as a first-time contractor at this high-speed agency I was hoping to develop a working relationship with, I felt I’d be overstepping my bounds and wasn’t ready to take the risk of being too vocal out of the gate. I chose not to do number 3 for similar reasons, mainly for fear of causing more work and stress for the already extremely busy designer.
Now that I have the benefit of hindsight, however, might I add a fourth item to the list?
- Send a succinct list of non-technical accessibility tips for UI design to everyone on the team so they make more accessible design choices in future
Where to find such a list? Well, you are in luck! Read on!
#Non-technical Accessibility Tips for UI Design
What follows is a list of plain language, no-jargon, “Accessibility Tips for UI Design” you, developer, can share with everyone at work: UI designers, content providers, project managers, and clients alike. The more we can spread awareness about accessibility and think critically about the mockups we are handed to implement, the more accessible the web will be!
I have chosen the examples below from various trendy website feeds, and I used the fantastic Funkify Chrome Extension to simulate the viewing experience of site visitors with varying abilities and disabilities.
First up:
#Easy on the animations.
With great power comes great responsibility. The modern web affords us the power to bounce-in, fly-in, or drop-in any content we please, but besides the wow factor, how are these animations contributing to a reader’s experience on your site? How are the animations triggered? Can they be mistakenly triggered, causing a confusing jolt in the flow of your site visitor’s experience?
Take this example of a car repair company’s website. I’ve applied the “Elderly Ellen” filter from Funkify to simulate slightly blurred vision and shaky hands: Elderly Ellen’s trembling hands cause a jarring experience with bold animations.
If I were Ellen, this experience would likely steer me away from Service King’s services! Someone like Elderly Ellen is constantly frustrated with technology. It’s unnecessary to cause her that stress when she’s trying to read about a service for repairing her car after an already traumatizing fender bender.
#Make sure background and text colors have enough contrast.
Although that medium grey text looks just right on that light grey background, it’s hard to read…and impossible to read if you are working out in the sunshine (not a common occurance, but I’ve done it before). Here’s an example of the aforementioned grey-on-grey scenario:
And now, the same example affected by the “Sunshine Sue” filter from Funkify deems our low contrast captions simply invisible!
The solution? Run your color choices through the WebAIM contrast checker to see if they meet standards for readability and color contrast, and if they don’t, adjust the color values until they do.
The Funkify extension can be used to test anything that is visible in a browser. Even if a design mock isn’t yet implemented in code, an image or PDF can be opened in the browser and the extension will still work!
#Be very careful when overlaying text on images, or don’t.
It might look just right to have that dainty serif overlaid on the big header image, but can you read it if you slightly blur your vision? If not, up the contrast between the text and image, perhaps by brightening the text color and increasing the transparency of the image on a dark background.
On Burberry’s website, for example, the user must select from a drop-down in order to enter the site, but the text identifying the drop-down is barely readable over top the background image. There are many ways to solve this from a design standpoint, but for a quick example, we could add a dark background beneath the light text to provide a bit more contrast:
Similarly, while the delicate descriptive text below the image on Tesla’s new Semi website is delicate and beautiful, it is barely legiible when simulating slightly blurred vision with “Blurry Bianca”:
#Double-check the readability of font weights and sizes.
The thinner the font weight and the smaller the size, the harder it is to read. Even I, as a hearing, well-sighted individual, find myself zooming in on body text at times because it is so darn lightweight and small, even if the color contrast is up to speed. If you must stick with the lightweight font, increasing the sizes and line height can do wonders as well.
I like to ask myself, does it pass the slightly-cross-eye test? That is when I slightly cross my eyes, can I still make out the text?
#Indicate external links.
If it is a requirement for a link to open in a new tab, first question whether it should be a requirement, then indicate it visually with a small icon or note in the UI.
Additionally, designers can make a note in their designs where there should be screen-reader-only text indicating the link will navigate the user away from their current viewing portal. This was brought to mind by way of some excellent replies to a Twitter conversation; read through that here.
#Differentiate between action-oriented social media links vs. profile links.
When we see small social media icons, I think the general assumption is that they link to the relevant social media profiles. Sometimes, however, these icons are actually actions that, rather than linking to a profile, open a “New Tweet” dialog or similar. These actions should be marked as such.
#Don’t rely 100% on icons and colors to communicate.
It’s easy to assume everyone knows that a hamburger icon indicates a menu or that everyone is familiar with the various versions of LinkedIn’s icon. However, this is not the case, and it causes a moment of confusion and insult that isn’t necessary to site visitors that are less in-the-know than we are. Especially if your audience tends to be older and/or less tech-savvy, make sure you aren’t relying on what you think is common knowledge.
Reliance on colors for meaning causes a similar issue, and more-so for any users that deal with color blindness. A recent Smashing Magazine article covers this problem in detail and uses the example of a color picker on shoe sales website that, for color-blind users, results in an entirely different palette.
#What would the design look like without interactivity?
If all a user could do was scroll, does the content still make sense? Are there areas where, rather than hiding the thumbnail caption under a fancy hover event, the caption could be plainly visible instead? What about on a touch screen, where hover events are treated quite differently?
#What else?
Have you encountered issues with accessibility in designs you’ve implemented? How did you handle it? What other tips can we give designers and producers for creating more accessible UI designs?
The first step to advocating for accessible UI design is to simply think twice about what you, the developer, are told to implement. While coding up a design, try applying a few of these Funkify filters and see what results they yield. Think critically about the designs you are handed, and start a conversation with your coworkers.