Data Me This, Data Me That
Robin: This week, I’ve been mulling over Mat Marquis’s fantastic post about Apple’s mysterious Accessibility Events feature:
In iOS 12.2 and MacOS 10.14.4, a toggle switch has appeared in Apple’s VoiceOver preferences, innocuously labeled “accessibility events.” It was rolled out to no fanfare—short of a brief mention in Apple’s iPhone User Guide—and we’re still not sure how it’s meant to be used. The most generous interpretation of the intention behind this feature is that it was developed with the same intention as a “UA string”-style identifier for users browsing via VoiceOver.
We do know this much: when this setting is enabled—and it is, by default—your browser will identify you as using VoiceOver to help you browse the web. If you’re using Apple’s VoiceOver, both your phone and your computer will broadcast your assumed disability to the entire internet, unless and until you specifically tell it to stop.
Mat goes on to explain why this is such a bad idea:
If you’re not furious at this change, you should be—not just for what it means for users, but what it foists upon you. Apple has burdened you with the knowledge that, now, yes, you can know whether a user has a disability. We can use this information to serve up a limited alternative version of a website, into which we can very easily opt people of a protected class. And once we choose to start listening for “accessibility events,” well, we can capture that information, as anything else broadcast to the web.
Mat’s piece complements something I’ve been thinking a lot about lately: the need many folks have to quantify everything in the entire universe with data. For example, why do we need to collect data about what viewport width and devices our users have? Why do I need analytics on my blog? Why do we need to A/B test two shades of one color?
What value does this data provide us all with? Is it really helping or is it all getting in the way?
In my experience, data is often used to exclude making good experiences in different browsers and different screen sizes. “Oh, we only have 4% of our users with [insert browser here]” is a common reply I hear when I make a pitch to support more browsers.
And I have this gut feeling that has sort of left me in a weird place in the web design community where I feel like collecting all this data just… doesn’t help. If anything, it prevents us from iterating and confidently making changes. It makes us think twice before we do things and it slows us down immensely from improving an interface.
Data alone won’t make better websites.
I’ve been referring to this as data fetishism. Maybe someone has used that term before in a different context, but I think that it accurately describes the industry today. Dave Rupert wrote along the same lines recently when he mentioned that he was switching from Google Analytics to using a self-hosted setup instead. The logic of collecting all that data often goes like this: “if only we could detect everything, we could make more informed decisions.”
But no, I really don’t think that’s the case most of the time. And Mat’s post argues that very well. By being able to identify “disabled” users we now can use this data to ignore them. To build interfaces around them. To break the web in service of some half-hearted business ideal.
There’s this concept called the Coastline Paradox. You might be familiar with the idea but here’s the gist: the coastline of a landmass, say England, doesn’t have an easily definable length. The more you try to measure it, the harder it becomes to measure. There’s not a single value that will pop out the other end of that question and eventually, you’re left with more questions than you do answers. What sized rocks be included? What about coral reefs? What about what about what about…
And even though Chris doesn’t really mention this in his series about thinking like a front-end developer, I believe that this is one of the qualities that sets a good front-end developer apart from the rest. They won’t fetishize the data to compare two alternatives; nor will they use data as an excuse not to do the hard work to make a website accessible or fast. They just do the work to make a quality website without trying to justify the time and care it takes.
Being a good front-end developer means recognizing that some things are measurable and some things aren’t — and even the things that are measurable may not mean all that much. As front-enders, we have to actively question the purpose of data and recognize that our own experiences in web development are often more important than whatever can be read in the tea leave. Remember, data can be misconstrued and can be both managed and designed poorly and used to obfuscate facts and tell lies.
I think the way we start building a better web (for everyone, and not just numbers) is to think more carefully about data and why we need it.
Because most of the time? We just don’t.
? From the Blog
Using the Web Speech API for Multilingual Translations: Steven Estrella looks at an API that allows us to incorporate speech into our interfaces. In his demo, Steven shows us how to create a web page that will speak the same text in multiple languages which is pretty nifty because I didn’t even know this API existed in the first place.
Edge Goes Chromium: What Does it Mean for Front-End Developers?: In this post, Ollie Williams has a lot more optimistic take on what it means for the Edge browser to switch to the Chromium rendering engine:
Not so long ago, I penned an article titled “The Long Slow Death of Internet Explorer.” Some of us are lucky enough have abandoned that browser already. But it wasn’t the only thing holding us back. Internet Explorer was the browser we all hated and Edge was meant to be its much-improved replacement. Unfortunately, Edge itself was quite the laggard. EdgeHTML is a fork of Trident, the engine that powered Internet Explorer. Microsoft significantly under-invested in Edge. The apple didn’t fall far from the tree. Edge’s User Voice website was a nice idea, allowing developers to vote for which features they wanted to be implemented. Unfortunately, as Dave Rupert put it, voting on the site was “like throwing coins in a wishing well.” The most requested features were left unimplemented for years.
Ollie looks at how custom elements and shadow DOM, font loading, new HTML elements, and the background blend property are just a couple of the improvements these users are likely to see when Edge makes the switch.
Using “box shadows” and clip-path together: I think I’ve bumped into this issue a few times when I’ve been working on projects and kinda shrugged my shoulders, but in this article, Chris looks at making a clip-path element like this:
…and why adding a box-shadow to that shape will result in…nothing. Unfortunately it’s because the clip-path is cutting off the box-shadow. The workaround Chris iuses in this post is pretty neat and worth checking out.
Netlify
Here’s how quick, powerful, and flexible hosting a site on Netlify can be: 1) Connect your repository (like GitHub, GitLab, Bitbucket) 2) Tell it which branch, which directory, and what build command to run 3) That’s it! Netlify will deploy your site live in seconds.