Monday, June 17th, 2019
Tuesday, June 11th, 2019
A very thoughtful post by Hidde that draws a useful distinction between the “internals” of a component (the inner workings of a React component, Vue component, or web component) and the code that wires those components together (the business logic):
I really like working on the detailed stuff that affects users: useful keyboard navigation, sensible focus management, good semantics. But I appreciate not every developer does. I have started to think this may be a helpful separation: some people work on good internals and user experience, others on code that just uses those components and deals with data and caching and solid architecture. Both are valid things, both need love. Maybe we can use the divide for good?
Friday, June 7th, 2019
A very useful explanation of the ARIA attributes relating to state:
Wednesday, May 29th, 2019
Here’s a clever tiny lesson from Dave and Brad: you can use
prefers-reduced-motion in the
media attribute of the
source element inside
Wednesday, May 22nd, 2019
Sara runs through the many ways of providing an accessible name to an icon button, backed up with Scott’s testing.
Monday, May 20th, 2019
This looks like a really useful tool for generating accessibile colour combinations from a starting colour.
Thursday, May 16th, 2019
What if accessibility were a ranking signal for Google search results?
Here’s a thought: what if Google put its thumb on the scale again, only this time for accessibility? What if it treated the Lighthouse accessibility score as a first-class ranking metric?
A very welcome project from Marcus Herrmann, documenting how to make common interaction patterns accessible in popular frameworks: Vue, React, and Angular.
Wednesday, May 15th, 2019
I completely agree with every single one of Terence’s recommendations here. The difference is that, in my case, they’re just hot takes, whereas he has actually joined the AMP Advisory Committee, joined their meetings, and listened to the concerns of actual publishers.
- AMP isn’t loved by publishers
- AMP is not accessible
- No user research
- AMP spreads fake news
- Signed Exchanges are not the answer
There’s also a very worrying anti-competitive move by Google Search in only showing AMP results to users of Google Chrome.
I’ve been emailing with Paul from the AMP team and I’ve told him that I honestly think that AMP’s goal should be to make itself redundant …the opposite of the direction it’s going in.
As I said in the meeting - if it were up to me, I’d go “Well, AMP was an interesting experiment. Now it is time to shut it down and take the lessons learned back through a proper standards process.”
I suspect that is unlikely to happen. Google shows no sign of dropping AMP. Mind you, I thought that about Google+ and Inbox, so who knows!
Coffee talk with Ethan Marcotte. Today’s special: inclusivity.
I want to get there: to have nuanced discussions about text descriptions; I want to read poetry in alt text; to have our work’s success measured by how broadly it can be accessed; to create moving, beautiful experiences for people who may not use the web like I do.
Monday, April 29th, 2019
Thursday, April 11th, 2019
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.
Wednesday, April 10th, 2019
When I talk about evaluating technology for front-end development, I like to draw a distinction between two categories of technology.
Personally, I’m much more interested and excited by the materials than I am by the tools. But I think it’s right and proper that other developers are excited by the tools. A good balance of both is probably the healthiest mix.
I’m never sure what to call these two categories. Maybe the materials are the “external” technologies, because they’re what users will interact with. Whereas all the other technologies—that mosty live on a developer’s machine—are the “internal” technologies.
Another nice phrase is something I heard during Chris’s talk at An Event Apart in Seattle, when he quoted Brad, who talked about the front of the front end and the back of the front end.
I’m definitely more of a front-of-the-front-end kind of developer. I have opinions on the quality of the materials that get served up to users; the output should be accessible and performant. But I don’t particularly care about the tools that produced those materials on the back of the front end. Use whatever works for you (or whatever works for your team).
As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time. Like I said, from a user’s point of view, it’s irrelevant what text editor or version control system you use.
Now, you could make the argument that anything that is good for developer convenience is automatically good for user experience because faster, more efficient development should result in better output. While that’s true in theory, I highly recommend Alex’s post, The “Developer Experience” Bait-and-Switch.
Where it gets interesting is when a technology that’s designed for developer convenience is made out of the very materials being delivered to users. For example, a CSS framework like Bootstrap is made of CSS. That’s different to a tool like Sass which outputs CSS. Whether or not a developer chooses to use Sass is irrelevant to the user—the final output will be CSS either way. But if a developer chooses to use a CSS framework, that decision has a direct impact on the user experience. The user must download the framework in order for the developer to get the benefit.
So whereas Sass sits at the back of the front end—where I don’t care what you use—Bootstrap sits at the front of the front end. For tools like that, I don’t think saying “use whatever works for you” is good enough. It’s got to be weighed against the cost to the user.
We’ve certainly seen that at Clearleft. We’ve worked on multiple React projects, but in every case, the output was server-rendered. Developers get the benefit of working with a tool that helps them. Users don’t pay the price.
For me, this question of whether a framework will be used on the client side or the server side is crucial.
That was a few years ago. I think that these days it has become a lot easier to make the decision to use a framework on the back of the front end. Like I said, that’s certainly been the case on recent Clearleft projects that involved React or Vue.
It surprises me, then, when I see the question of server rendering or client rendering treated almost like an implementation detail. It might be an implementation detail from a developer’s perspective, but it’s a key decision for the user experience. The performance cost of putting your entire tech stack into the browser can be enormous.
Alex Sanders from the development team at The Guardian published a post recently called Revisiting the rendering tier . In it, he describes how they’re moving to React. Now, if this were a move to client-rendered React, that would make a big impact on the user experience. The thing is, I couldn’t tell from the article whether React was going to be used in the browser or on the server. The article talks about “rendering”—which is something that browsers do—and “the DOM”—which is something that only exists in browsers.
So I asked. It turns out that this plan is very much about generating HTML and CSS on the server before sending it to the browser. Excellent!
I have misgivings. But just to be clear, these misgivings have nothing to do with users. My misgivings are entirely to do with another group of people: the people who make websites.
It wasn’t that long ago that devs coming from a Computer Science background were deriding CSS for its simplicity, complaining that “it’s broken” and turning their noses up at it. That rhetoric, thankfully, is waning. Nowadays they’re far more likely to acknowledge that CSS might be simple, but it isn’t easy. Concepts like the cascade and specificity are real head-scratchers, and any prior knowledge from imperative programming languages won’t help you in this declarative world—all your hard-won experience and know-how isn’t fungible. Instead, it seems as though all this cascading and specificity is butchering the modularity of your nicely isolated components.
It’s no surprise that programmers with this kind of background would treat CSS as damage and find ways to route around it. The many flavours of CSS-in-JS are testament to this. From a programmer’s point of view, this solution has made things easier. Best of all, as long as it’s being done on the server, there’s no penalty for end users. But now the price is paid in the diversity of your team. In order to participate, a Computer Science programming mindset is now pretty much a requirement. For someone coming from a more declarative background—with really good HTML and CSS skills—everything suddenly seems needlessly complex. And as Tantek observed:
Complexity reinforces privilege.
The result is a form of gatekeeping. I don’t think it’s intentional. I don’t think it’s malicious. It’s being done with the best of intentions, in pursuit of efficiency and productivity. But these code decisions are reflected in hiring practices that exclude people with different but equally valuable skills and perspectives.
Rachel describes HTML, CSS and our vanishing industry entry points:
If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged.
I think there’s a comparison here with toxic masculinity. Toxic masculinity is obviously terrible for women, but it’s also really shitty for men in the way it stigmatises any male behaviour that doesn’t fit its worldview. Likewise, if the only people your team is interested in hiring are traditional programmers, then those programmers are going to resent having to spend their time dealing with semantic markup, accessibility, styling, and other disciplines that they never trained in. Heydon correctly identifies this as reluctant gatekeeping:
By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.
This hurts everyone. It’s bad for your team. It’s even worse for the wider development community.
Last year, I was asked “Is there a fear or professional challenge that keeps you up at night?” I responded:
My greatest fear for the web is that it becomes the domain of an elite priesthood of developers. I firmly believe that, as Tim Berners-Lee put it, “this is for everyone.” And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.
I’ve described a number of dichotomies here:
- Materials vs. tools,
- Front of the front end vs. back of the front end,
- User experience vs. developer experience,
- Client-side rendering vs. server-side rendering,
- Declarative languages vs. imperative languages.
But the split that worries the most is this:
- The people who make the web vs. the people who are excluded from making the web.
Wouldn’t it be great if every component in your design system had accessibility acceptance criteria? Paul has some good advice for putting those together:
- Start with accessibility needs
- Don’t be too generic
- Don’t define the solution
- Iterate criteria
Tuesday, April 9th, 2019
We have a tendency in our line of work to assume that what benefits us as developers translates to a benefit for those who use what we make. This is an unsafe assumption.
- Morality is not always relative.
- You’re a web professional.
- The web is accessible out-of-the-box. We break it.
- It’s not on people with disabilities to tell you how you screwed up.
- It should be easier. This is our job.
Sunday, April 7th, 2019
I got a message from a screen-reader user of The Session recently, letting me know of a problem they were having. I love getting any kind of feedback around accessibility, so this was like gold dust to me.
They pointed out that the drag’n’drop interface for rearranging the order of tunes in a set was inaccessible.
Of course! I slapped my forehead. How could I have missed this?
It had been a while since I had implemented that functionality, so before even looking at the existing code, I started to think about how I could improve the situation. Maybe I could capture keystroke events from the arrow keys and announce changes via ARIA values? That sounded a bit heavy-handed though: mess with people’s native keyboard functionality at your peril.
Then I looked at the code. That was when I realised that the fix was going to be much, much easier than I thought.
I documented my process of adding the drag’n’drop functionality back in 2016. Past me had his progressive enhancement hat on:
One of the interfaces needed for this feature was a form to re-order items in a list. So I thought to myself, “what’s the simplest technology to enable this functionality?” I came up with a series of
selectelements within a form.
The problem was in my feature detection:
There’s a little bit of mustard-cutting going on: does the
dragulaobject exist, and does the browser understand
querySelector? If so, the
selectelements are hidden and the drag’n’drop is enabled.
The logic was fine, but the execution was flawed. I was being lazy and hiding the
select elements with
display: none. That hides them visually, but it also hides them from screen readers. I swapped out that style declaration for one that visually hides the elements, but keeps them accessible and focusable.
It was a very quick fix. I had the odd sensation of wanting to thank Past Me for making things easy for Present Me. But I don’t want to talk about time travel because if we start talking about it then we’re going to be here all day talking about it, making diagrams with straws.
I pushed the fix, told the screen-reader user who originally contacted me, and got a reply back saying that everything was working great now. Success!
Saturday, April 6th, 2019
Accessibility for Vestibular Disorders: How My Temporary Disability Changed My Perspective · An A List Apart Article
This is a fascinating insight into what it’s like to use the web if you’ve got vertigo (which is way more common than you might think):
Really, there are no words to describe just how bad a simple parallax effect, scrolljacking, or even
background-attachment: fixedwould make me feel. I would rather jump on one of those 20-G centrifuges astronauts use than look at a website with parallax scrolling.
Every time I encountered it, I would put the bucket beside me to good use and be forced to lie in bed for hours as I felt the room spinning around me, and no meds could get me out of it. It was THAT bad.
Thursday, April 4th, 2019
I also discussed this accessibility events feature with my friend who is a screen reader user herself. She said it feels like it’s a first step towards a well-meant digital apartheid.
This is a really nice write-up of creating an accessible progressive disclosure widget (a show/hide toggle).
Where it gets really interesting is when Andy shows how it could all be encapsulated into a web component with a progressive enhancement mindset