Dispatches From The Internets

A (not so) short note on ARIA to the rescue

Accessibility is hard. It’s a broad term encompassing a variety of special needs ranging from low vision and color blindness to motor impairment and language barriers (to name but a few) which means guaranteeing our projects are “100% accessible” is a significant challenge.

Accessibility becomes even more of a challenge when you begin to factor in the dependency chain. Blind and low-vision users, for example, often use screen readers in order to access the Web. With screen readers, we need to consider the capabilities of both the browser and the screen reader being used. If either piece of software isn’t up to the task or contains a bug our users suffer for it.

Getting multiple inter-dependent programs on the same page sometimes requires that we do things we’d rather not do. This post from Steve Faulkner chronicles one such case where the particular versions of Chrome and JAWS required for a project didn’t see eye-to-eye on the semantics of heading levels. He talks about the issue and the less-than-optimal fix he had to put in place to ensure users got the experience they were meant to.

Flex-grow 9999 Hack

Very clever bit of flexbox here for laying out text optimally when you don’t know its length.

I don’t know that I would consider it a hack so much as pushing flexbox beyond what most people would even consider doing.

Refreshing The Verge

I love how Mandy deftly wove progressive enhancement into her content strategy and publishing discussion:

Perhaps ironically, we’ve found that the best way to create that resiliency is by harking back to the web principle of progressive enhancement: each story created in Chorus begins as a platform-neutral collection of text, images, and video. That foundation ensures that we can publish that story as easily to our own platform as to, say, AMP or Apple News, and be confident that our audience will experience that story in a way that fits whichever platform they are using. On our own platform, we’re then free to enhance up, adding stylistic or experiential flairs that elevate the experience of the story. This practice — which I refer to unoriginally as progressively enhanced storytelling — also has the added benefit of helping us make our content more accessible to more kinds of users, especially those with disabilities. (It wouldn’t be inaccurate to consider speaking browsers one among the many platforms we must publish to.)

crossfit.js

A hilarious and completely accurate reflection on the cultural similarities shared by JavaScript and crossfire enthusiasts.

Progressive Misconceptions

Last week, my colleague Nolan Lawson wrote a lengthy post about his struggles with progressive enhancement. In it, he identified a key tension between the JavaScript community and the progressive enhancement community that has, frankly, existed since the term “progressive enhancement” was coined some 13 years ago. I wanted to take a few minutes to tuck into that tension and assure Nolan and other folks within the JS community that neither progressive enhancement nor the folks who advocate it (like me) is at odds with them or their work.

I’m voting for Oscar

![]({{ site.url }}/i/posts/2016-10-11/oscar.jpg)
This is my son Oscar. In case you can’t see the picture, he looks nothing like me because he’s adopted. He’s also friggin’ adorable, but that’s not why I’m writing this. I’m writing this because my son is Black and despite the fact that he will grow up in a family that has the means to provide him with a good education and far more opportunity than a lot of children in America—including me—the sheer fact that his skin is dark means he will grow up in a far different America than I did.

What Would You Do With 10kB?

Sixteen years ago, Stewart Butterfield conceived of a contest that would test the mettle of any web designer: The 5k. The idea was that entrants would build an entire site in 5kB of code or less. Its aim was to force us to get creative by putting a bounding box on what we could do: > Between servers and bandwidth, clients and users, HTML and the DOM, browsers and platforms, our conscience and our ego, we’re left in a very small space to find highly optimal solutions. Since the space we have to explore is so small, we have to look harder, get more creative; and that’s what makes it all interesting.

Test on the right mobile devices

This is a nice overview of where you should be spending your mobile device testing time if you’re clueless about where to begin. Obviously it skews toward BrowserStack’s offerings, but it’s a pretty solid list of devices. It doesn’t touch on browsers though, which means Opera is a glaring omission.