This is handy—an up-to-date list of tests run on form fields with different combinations of screen readers and browsers.
Monday, March 1st, 2021
Monday, February 1st, 2021
Thursday, November 12th, 2020
- First impressions
- The Tab key
- Automated testing tools
- Screen reader testing
- Next steps
Thursday, October 8th, 2020
Considering how much accessibility work happens “under the hood”, it’s interesting that all five of these considerations are visibly testable.
- Think about accessible copy
- Don’t forget about the focus indicator
- Check your colour contrast
- Don’t just use colour to convey meaning
- Design in anticipation of text resizing
Thursday, October 1st, 2020
I’d like to see more of this thinking – maybe we could call it the future owners test – in contemporary responsible tech work. We mustn’t get so wrapped up in today that we overlook tomorrow.
Monday, September 14th, 2020
Trys ponders home repair projects and Postel’s Law.
As we build our pages, components, and business logic, establish where tolerance should be granted. Consider how flexible each entity should be, and on what axis. Determine which items need to be fixed and less tolerant. There will be areas where the data or presentation being accurate is more important than being flexible - document these decisions.
Tuesday, July 7th, 2020
Good point. When we talk about perceived performance, the perception in question is almost always visual. We should think more inclusively than that.
Thursday, June 25th, 2020
A score of 100 in Lighthouse or 0 errors in axe doesn’t mean that you’re done, it means that you’re ready to start manual testing and testing with real users, if possible.
Tuesday, June 23rd, 2020
This is a great short introduction to using VoiceOver with Safari by the one and only Ethan Marcotte.
Thursday, April 30th, 2020
This is a great case study of the excellent California COVID-19 response site. Accessibility and performance are the watchwords here.
Want to know their secret weapon?
A $20 device running Android 9, with no contract commitment has been one of the most useful and effective tools in our effort to be accessible.
Leaner, faster sites benefit everybody, but making sure your applications run smoothly on low-end hardware makes a massive difference for those users.
Friday, April 10th, 2020
Web Share API test
Remember a while back I wrote about some odd behaviour with the Web Share API in Safari on iOS?
share()method is triggered, iOS provides multiple ways of sharing: Messages, Airdrop, email, and so on. But the simplest option is the one labelled “copy”, which copies to the clipboard.
Here’s the thing: if you’ve provided a text parameter to the
share()method then that’s what’s going to get copied to the clipboard—not the URL.
That’s a shame. Personally, I think the
urlfield should take precedence.
Tess filed a bug soon after, which was very gratifying to see.
- Share URL, title, and text
- Share URL and title
- Share URL and text
Very handy! The results (using the “copy” to clipboard action) are somewhat like rock, paper, scissors:
- URL beats title,
- text beats URL,
- nothing beats text.
So it’s more like rock, paper, high explosives.
Tuesday, March 10th, 2020
I use Firefox. You should too. It’s fast, secure, and more privacy-focused than the leading browser from the big G.
Yesterday, I got the Calibre newsletter, which always has handy performance-related links from Karolina. She pointed to a Lighthouse extension for Firefox. “Excellent!”, I thought, and I immediately installed it. But I had some qualms about installing a plug-in from Google into a browser from Mozilla, particularly as the plug-in page says:
This is not a Recommended Extension. Make sure you trust it before installing
Well, I gave it a go. It turns out that all it actually does is redirect to the online version of Lighthouse. “Hang on”, I thought. “This could just be a bookmarklet!”
So I immediately uninstalled the browser extension and made this bookmarklet:
Drag that up to your desktop browser’s bookmarks toolbar. Press it whenever you’re on a site that you want to test.
Tuesday, March 3rd, 2020
Telling the story of performance
At Clearleft, we’ve worked with quite a few clients on site redesigns. It’s always a fascinating process, particularly in the discovery phase. There’s that excitement of figuring out what’s currently working, what’s not working, and what’s missing completely.
The bulk of this early research phase is spent diving into the current offering. But it’s also the perfect time to do some competitor analysis—especially if we want some answers to the “what’s missing?” question.
It’s not all about missing features though. Execution is equally important. Our clients want to know how their users’ experience shapes up compared to the competition. And when it comes to user experience, performance is a huge factor. As Andy says, performance is a UX problem.
There’s no shortage of great tools out there for measuring (and monitoring) performance metrics, but they’re mostly aimed at developers. Quite rightly. Developers are the ones who can solve most performance issues. But that does make the tools somewhat impenetrable if you don’t speak the language of “time to first byte” and “first contentful paint”.
When we’re trying to show our clients the performance of their site—or their competitors—we need to tell a story.
Web Page Test is a terrific tool for measuring performance. It can also be used as a story-telling tool.
You can go to webpagetest.org/easy if you don’t need to tweak settings much beyond the typical site visit (slow 3G on mobile). Pop in your client’s URL and, when the test is done, you get a valuable but impenetrable waterfall chart. It’s not exactly the kind of thing I’d want to present to a client.
Fortunately there’s an attention-grabbing output from each test: video. Download the video of your client’s site loading. Then repeat the test with the URL of a competitor. Download that video too. Repeat for as many competitor URLs as you think appropriate.
Now take those videos and play them side by side. Presentation software like Keynote is perfect for showing multiple videos like this.
This is so much more effective than showing a table of numbers! Clients get to really feel the performance difference between their site and their competitors.
Running all those tests can take time though. But there are some other tools out there that can give a quick dose of performance information.
SpeedCurve recently unveiled Page Speed Benchmarks. You can compare the performance of sites within a particualar sector like travel, retail, or finance. By default, you’ll get a filmstrip view of all the sites loading side by side. Click through on each one and you can get the video too. It might take a little while to gather all those videos, but it’s quicker than using Web Page Test directly. And it might be that the filmstrip view is impactful enough for telling your performance story.
If, during your discovery phase, you find that performance is being badly affected by third-party scripts, you’ll need some way to communicate that. Request Map Generator is fantastic for telling that story in a striking visual way. Pop the URL in there and then take a screenshot of the resulting visualisation.
The beginning of a redesign project is also the time to take stock of current performance metrics so that you can compare the numbers after your redesign launches. Crux.run is really great for tracking performance over time. You won’t get any videos but you will get some very appealing charts and graphs.
Web Page Test, Page Speed Benchmarks, and Request Map Generator are great for telling the story of what’s happening with performance right now—Crux.run balances that with the story of performance over time.
Measuring performance is important. Communicating the story of performance is equally important.
Well, this is a grim collection from Dave:
There are some cases where even using plain ol’ HTML causes accessibility problems. I get frustrated and want to quit web development whenever I read about these types of issues. Because if browsers can’t get this right, what hope is there for the rest of us.
It’s worth clicking through each link he lists—the situation is often much more nuanced than simply “Don’t use X.”
Friday, January 10th, 2020
We have to stop confusing the excesses of capitalism with the hallmarks of quality. Sometimes Google aren’t better, they’re just more pervasive.
cough AMP cough
Friday, November 22nd, 2019
Saturday, November 16th, 2019
A biblical short story from Adam Roberts.
Thursday, November 7th, 2019
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.
Friday, November 1st, 2019
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.
Wednesday, October 16th, 2019
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