I recently asked a friend who happens to be blind if he’d share some sites that were built really well—sites that were beautifully accessible. You know what he said? “I don’t use the web. Everything is broken.”
Everything is broken. And it’s broken because we broke it.
But we can do better.
Monday, October 15th, 2018
Monday, October 8th, 2018
A profile of Mark Graham and the team at the Internet Archive.
Saturday, October 6th, 2018
An nth-letter selector in CSS
Variable fonts are a very exciting and powerful new addition to the toolbox of web design. They was very much at the centre of discussion at this year’s Ampersand conference.
A lot of the demonstrations of the power of variable fonts are showing how it can be used to make letter-by-letter adjustments. The Ampersand website itself does this with the logo. See also: the brilliant demos by Mandy. It’s getting to the point where logotypes can be sculpted and adjusted just-so using CSS and raw text—no images required.
I find this to be thrilling, but there’s a fly in the ointment. In order to style something in CSS, you need a selector to target it. If you’re going to style individual letters, you need to wrap each one in an HTML element so that you can then select it in CSS.
For the Ampersand logo, we had to wrap each letter in a
But if the whole point of using HTML is that the content is accessible, copyable, and pastable, isn’t a bit of a shame that we then compromise the markup—and the accessibility—by wrapping individual letters in presentational tags?
What if there were an
::nth-letter selector in CSS?
There’s some prior art here. We’ve already got
::first-letter (and now the
initial-letter property or whatever it ends up being called). If we can target the first letter in a piece of text, why not the second, or third, or nth?
It raises some questions. What constitutes a letter? Would it be better if we talked about
::nth-character, and so on?
Even then, there are some tricksy things to figure out. What’s the third character in this piece of markup?
Is it “C”, becuase that’s the third character regardless of nesting? Or is it “E”, becuase techically that’s the third character token that’s a direct child of the parent element?
I imagine that implementing
::nth-character) would be quite complex so there would probably be very little appetite for it from browser makers. But it doesn’t seem as problematic as some selectors we’ve already got.
Think about it. The browser has to first calculate how many characters are in the first line of an element (like, say, a paragraph). Having figured that out, the browser can then apply the styles declared in the
::first-line selector. But those styles may involve font sizing updates that changes the number of characters in the first line. Paradox!
(Technically, only a subset of CSS of properties can be applied to
::first-line, but that subset includes
font-size so the paradox remains.)
I checked to see if
::first-line was included in one of my favourite documents: Incomplete List of Mistakes in the Design of CSS. It isn’t.
So compared to the logic-bending paradoxes of
::nth-letter selector would be relatively straightforward. But that in itself isn’t a good enough reason for it to exist. As the CSS Working Group FAQs say:
The fact that we’ve made one mistake isn’t an argument for repeating the mistake.
Now, I know that browser makers would like us to figure out how proposed CSS features should work by polyfilling a solution with Houdini. But would that work for a selector? I don’t know much about Houdini so I asked Una. She pointed me to a proposal by Greg and Tab for a full-on parser in Houdini. But that’s a loooong way off. Until then, we must petition our case to the browser gods.
This is not a new suggestion.
While I’m talking about CSS, I would also like to have
::nth-word(n), any thoughts?
Of all of these “new” selectors,
::nth-letteris likely the most useful.
In 2012, Bram linked to a blog post (now unavailable) from Adobe indicating that they were working on
::nth-letter for Webkit. That was the last anyone’s seen of this elusive pseudo-element.
In 2013, Chris (again) included
::nth-letter in his wishlist for CSS. So say we all.
Thursday, October 4th, 2018
It’ll never catch on.
Thursday, September 27th, 2018
“What if someone doesn’t browse the web like I do?”
Tuesday, September 25th, 2018
The long-standing difficulties of styling
legend are finally getting addressed …although I’m a little shocked that the solution involves extending
-webkit-appearance. I think that, at this point, we should be trying to get rid of vendor prefixes from the web once and for all, not adding to them. Still, needs must, I suppose.
Thursday, September 13th, 2018
This is very timely. I’ve been doing some consulting at a company where they are perhaps a little over-reliant on automated accessibility tests.
Automated accessibility tests are a great resource to have, but they can’t automatically make your site accessible. Use them as one step of a larger testing process.
Tuesday, September 11th, 2018
Damn, that’s a fine opening! And the rest of this post by Alex is pretty darn great too. He’s absolutely right in calling out the fetishisation of developer experience at the expense of user needs:
The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.
I have a feeling that this will be a very bitter pill for many developers to swallow:
If one views the web as a way to address a fixed market of existing, wealthy web users, then it’s reasonable to bias towards richness and lower production costs. If, on the other hand, our primary challenge is in growing the web along with the growth of computing overall, the ability to reasonably access content bumps up in priority. If you believe the web’s future to be at risk due to the unusability of most web experiences for most users, then discussion of developer comfort that isn’t tied to demonstrable gains for marginalized users is at best misguided.
Oh,captain, my captain!
Tools that cost the poorest users to pay wealthy developers are bunk.
Wednesday, September 5th, 2018
I love this deep dive that Sara takes into the question of marking up content for progressive disclosure. It reminds me Dan’s SimpleQuiz from back in the day.
Then there’s this gem, which I think is a terrificly succinct explanation of the importance of meaningful markup:
It’s always necessary, in my opinion, to consider what content would render and look like in foreign environments, or in environments that are not controlled by our own styles and scripts. Writing semantic HTML is the first step in achieving truly resilient Web sites and applications.
Saturday, September 1st, 2018
Just last week I came across an example of what Ethan describes here: accessibility (in a pattern library) left to automatic checks rather than human experience.
Thursday, August 16th, 2018
A great post by Tim following on from the post by Eric I linked to last week.
Is a secure site you can’t access better than an insecure one you can?
He rightly points out that security without performance is exlusionary.
…we’ve made a move to increase the security of the web by doing everything we can to get everything running over HTTPS. It’s undeniably a vital move to make. However this combination—poor performance but good security—now ends up making the web inaccessible to many.
Security. Performance. Accessibility. All three matter.
A web of anxiety: accessibility for people with anxiety and panic disorders [Part 1] | The Paciello Group – Your Accessibility Partner (WCAG 2.0/508 audits, VPAT, usability and accessible user experience)
Enumerating the anti-patterns that cause serious user experience issues that don’t get nearly enough attention:
While such intrusions can be a source of irritation or even stress for many people, they may be complete showstoppers for people with anxiety or panic disorders.
I’m looking forward to reading the follow-up post.
(I was going to say I was anxiously awaiting the follow-up post but …never mind.)
Friday, August 10th, 2018
Overwhelmingly, our software is built by well-paid teams with huge monitors and incredibly fast computers running on a high-bandwidth internet connection. We run MacBook Pros, we have cinema displays, we carry iPhones.
That’s not what the rest of the world looks like.
Tuesday, August 7th, 2018
This is a heartbreaking observation by Eric. He’s not anti-HTTPS by any stretch, but he is pointing out that caching servers become a thing of the past on a more secure web.
Can we do anything? For users of up-to-date browsers, yes: service workers create a “good” man in the middle that sidesteps the HTTPS problem, so far as I understand. So if you’re serving content over HTTPS, creating a service worker should be one of your top priorities right now, even if it’s just to do straightforward local caching and nothing fancier.
Inclusive design is also future-proofing technology for everyone. Swan noted that many more developers and designers are considering accessibility issues as they age and encounter poor eyesight or other impairments.
Oh, this is magnificent! A rallying call for everyone designing and developing on the web to avoid making any assumptions about the people we’re building for:
People will use your site how they want, and according to their means. That is wonderful, and why the Web was built.
I would even say that the % of people viewing your site the way you do rapidly approaches zilch.
Thursday, August 2nd, 2018
A handy bunch of checklists from Dave for creating accessible components. Each component gets a card that lists the expectations for interaction.
I encourage you to think about and make sure you are using the right elements at the right time. Sometimes I overthink this, but that’s because it’s that important to me - I want to make sure that the markup I use helps people understand the content, and doesn’t hinder them.
Tuesday, July 31st, 2018
A great collection of styled and accessible form elements:
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.