Not everyone uses a mouse to browse the internet. If you’re reading this post on a smartphone, this is obvious! What’s also worth pointing out is that there are other forms of input that people use to get things done. With these forms of input comes the need for focus styles.
Have you ever lost your voice? How did you handle that? Perhaps you carried a notebook and pen to scribble notes. Or jotted quick texts on your phone.
Have you ever traveled somewhere that you didn't speak or understand the language everyone around you was speaking? How did you order food, or buy a train ticket? Perhaps you used a translation phrasebook, or Google translate. Perhaps you relied mostly on physical gestures.
All of these solutions are examples of communication methods — tools and strategies — that you may have used before to solve everyday communicative challenges. The preceding examples are temporary solutions to temporary challenges. Your laryngitis cleared up. You returned home, where accomplishing daily tasks in your native tongue is almost effortless. Now imagine that these situational obstacles were somehow permanent.
I remember seeing these accessibility guidelines from Vox a while ago but it’s still interesting to go over them again today and see if there’s anything missing from my own process when it comes to improving accessibility.
And there’s an awful lot to remember! Color contrast, alt-text, keyboard navigation, focus states, and ARIA attributes are only a small snippet of the total number of things we ought to be mindful of when designing websites and so this checklist is certainly helpful for giving us all a good nudge from time to time.
Plus, it's worth remembering that there are small tweaks we can make and ways to advocate for improved accessibility in our projects.
I'm sure you know about alt text. It's the attribute on the image tag that has the important task of describing what that image is for someone who can't see it for any reason. Please use them.
I don't want to dimish the please use them message, but some interesting alt-text-related things have come up in my day-to-day lately that are related.
There is a sentiment that accessibility isn't a checklist, meaning that if you're really trying to make a site accessible, you don't just get to check some things off a list and call it perfect. The list may be imperfect and worse, it takes the user out of the equation, so it is said.
Karl Groves once argued against this:
I’d argue that a well-documented process which includes checklist-based evaluations are better at ensuring that all users’ needs are met, not just some users.
I mention this because you might consider an automated accessibility testing tool another form of a checklist. They have rules built into them, and they test your site against that list of rules.
I'm pretty new to the idea of these things, so no expert here, but there appears to be quite a few options! Let's take a look at some of them.
Say we have a <div></div>.
We only want this div to be visible when it's hovered, so:
div:hover {
opacity: 1;
}We need focus styles as well, for accessibility, so:
div:hover,
div:focus {
opacity: 1;
}But div's can't be focused on their own, so we'll need:
<div tabindex="0">
</div>There is content in this div. Not just text, but links as well.
<div tabindex="0">
<p>This little piggy went to market.</p>
<a href="#market">Go to market</a>
</div>This is where it gets tricky.
You love HTML emails, don't you?
As a developer, probably not... but subscribers absolutely do. They devour them, consume them on every device known to man, and drive a hell of a lot of revenue for companies that take their email marketing seriously.
But most web developers tasked with building HTML emails merely want to get them out the door as quickly as possible and move on to more interesting assignments. Despite email's perennial value for subscribers, tight timelines, and a general loathing of the work result in things falling by the wayside; and, just like in the web world, one of the first things to be set aside in email is accessibility.
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.
Color is pretty good for separating things. That's what your basic pie chart is, isn't it? You tell the slices apart by color. With enough color contrast, you might be OK, but you might be even better off (particularly where accessibility is concerned) using patterns, or a combination.
The topic of disabling links popped up at my work the other day. Somehow, a "disabled" anchor style was added to our typography styles last year when I wasn't looking. There is a problem though: there is no real way to disable an <a></a> link (with a valid href attribute) in HTML. Not to mention, why would you even want to? Links are the basis of the web.
At a certain point, it looked like my co-workers were not going to accept this fact, so I started thinking of how this could be accomplished. Knowing that it would take a lot, I wanted to prove that it was not worth the effort and code to support such an unconventional interaction, but I feared that by showing it could be done they would ignore all my warnings and just use my example as proof that it was OK. This hasn't quite shaken out for me yet, but I figured we could go through my research.