A biblical short story from Adam Roberts.
Nolan writes up what he learned making accessibiity improvements to a single page app. The two big takeways involve letting the browser do the work for you:
Here’s the best piece of accessibility advice for newbies: if something is a button, make it a
<button>. If something is an input, make it an
<input>. Don’t try to reinvent everything from scratch using
And then there are all the issues that crop up when you take over the task of handling navigations:
- You need to manage focus yourself.
- You need to manage scroll position yourself.
For classic server-rendered pages, most browser engines give you this functionality for free. You don’t have to code anything. But in an SPA, since you’re overriding the normal navigation behavior, you have to handle the focus yourself.
Testing on a <$100 Android device on a 3G network should be an integral part of testing your website. Not everyone is on a brand-new device or upgrades often, especially with the price point of a high-end phones these days.
When we design and build our websites with the outliers in mind, whether it’s for performance or even user experience, we build an experience that can be easy for all to access and use — and that’s what the web is about, access and information for all.
Beyond automatic accessibility testing: 6 things I check on every website I build - Manuel Matuzović
Six steps that everyone can do to catch accessibility gotchas:
- Check image descriptions
- Disable all styles
- Validate HTML
- Check the document outline
- Grayscale mode
- Use the keyboard
When I liveblogged Jason’s talk at An Event Apart in Chicago, I included this bit of reporting:
Jason proceeds to relate a long and involved story about buying burritos online from Chipotle.
Well, here is that story. It’s a good one, with some practical takeaways (if you’ll pardon the pun):
- Use HTML5 input features
- Support autofill
- Make autofill part of your test plans
Maciej goes marching.
The protests are intentionally decentralized, using a jury-rigged combination of a popular message board, the group chat app Telegram, and in-person huddles at the protests.
This sounds like it shouldn’t possibly work, but the protesters are too young to know that it can’t work, so it works.
Harry enumerates the reasons why client-side A/B testing is terrible:
- It typically blocks rendering.
- Providers are almost always off-site.
- It happens on every page load.
- No user-benefitting reuse.
- They likely skip any governance process.
While your engineers are subject to linting, code-reviews, tests, auditors, and more, your marketing team have free rein of the front-end.
The test results are in:
During our testing “Install App” banners were the direct and sole cause of several abandonments of some of the world’s largest e-commerce websites.
Read on for details…
I was chatting with Rachel at work the other day about conversational forms, and I mentioned that I kicked that whole thing off with the mad libs style form on Huffduffer. Here’s the research that Luke later did on whether this style of form could increase conversion.
Did you know about
console.timeEnd()? I did not.
Greg has done a lot of research into developer frustrations with customising form controls.
My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.
Spoiler: it’s plain text. Every time.
Nothing boosts opens and clicks as well as an old school, plain-text email.
I feel vindicated.
People say they prefer HTML emails ..but they actually prefer plain-text.
This seems like a plausable explanation:
Think about how you email colleagues and friends: Do you usually add images or use well-designed templates? Probably not, and neither does your audience. They’re used to using email to communicate in a personal way, so emails from companies that look more personal will resonate more.
Now get off my lawn, you pesky HTML-email lovin’ kids.
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
I think I physically winced on more than one occassion as I read through Jake’s report here.
He makes an interesting observation at the end:
However, none of the teams used any of the big modern frameworks. They’re mostly Wordpress & Drupal, with a lot of jQuery. It makes me feel like I’ve been in a bubble in terms of the technologies that make up the bulk of the web.
Yes! This! Contrary to what you might think reading through the latest and greatest tips and tricks from the front-end community, the vast majority of sites out there on the web are not being built with React, Vue, webpack or any other “modern” tools.
A handy accessibility tool. The browser plug-in is only for Chrome right now (I use Firefox as my main browser) but it’s pretty nifty—the tool for visualising tabbing is really useful.
When one company decides which ideas are worth supporting and which aren’t, which access problems matter and which don’t, it stifles innovation, crushes competition, and opens the door to excluding people from digital experiences.
So how do we fight this? We, who are not powerful? We do it by doubling down on cross-browser testing. By baking it into the requirements on every project, large or small. By making sure our colleagues, bosses, and clients know what we’re doing and why.
Some tips for getting responsive images to work well on the Apple Watch:
- test your layouts down to 136-
300w-ish resources in your full-width
- art direct to keep image subjects legible
- say the magic