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.
Accessibility is an aspect of web development that is often overlooked. I would argue that it is as vital as overall performance and code reusability. We justify our endless pursuit of better performance and responsive design by citing the users, but ultimately these pursuits are done with the user's device in mind, not the user themselves and their potential disabilities or restrictions.
A responsive app should be one that delivers its content based on the needs of the user, not only their device.
Luckily, there are tools to help alleviate the learning curve of accessibility-minded development. For example, GitHub recently released their accessibility error scanner, AccessibilityJS and Deque has aXe. This article will focus on a different one: Ally.js, a library simplifying certain accessibility features, functions, and behaviors.
Much like their physical counterparts, the materials we use to build websites have purpose. To use them without understanding their strengths and limitations is irresponsible. Nobody wants to live in an poorly-built house. So why are poorly-built websites acceptable?
In this post, I'm going to address WAI-ARIA, and how misusing it can do more harm than good.
Website accessibility has always been important, but nowadays, when we have clear standards and regulations from governments in most countries, it's become even more crucial to support those standards and make our projects as accessible as they can be.
The W3C recommendation provides 3 level of conformance:
AAA. To be at the
AA level, among other requirements, we have to provide a way to increase the site's font size:
Let's look at solutions for this and try to find the best one we can.
Update(09/25/17): It turns out that WCAG doesn't require a text resizing custom solution in addition to what user-agents provide. We just have to make sure a website looks OK as a result of resizing. Yet if we still want to scale elements for any reason, below is a thorough analysis of different methods for doing that.
Removing the focus outline is like removing the wheelchair ramp from a school because it doesn't fit in with the aesthetic.
So David shows how you can remove it unless you detect that the user is tabbing, then show it. Essentially you add "user-is-tabbing" class to the body when you detect the tabbing, and use that class to remove the focus styles if it's not there (plus handle the edge cases).
Activities to help you develop empathy for the variety of people that use your thing. Eric Bailey:
This project is geared towards anyone involved with making digital products. It is my hope that this reaches both:
- People who are not necessarily involved in the day-to-day part of the process, but who help shape things like budget, timeline, and scope, and
- People who work every day to help to give these products shape and form
These prompts are intended to help build empathy, not describe any one person's experience. These prompts are not intended to tokenize the experience of the individuals experiencing these conditions.
I love the "share" link on the page. It's basically
Here's a question I got the other day?
Would you suggest icon fonts or inline SVGs for a complex single page application? And are there specific accessibility concerns for either? Accessibility is especially important for us because schools use our products. I ask because we are currently in the process of unifying and setting up an icon system.
Still here? Cool. Let's do this.