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.
Thursday, April 11th, 2019
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.
Thursday, February 21st, 2019
A tiny lesson in query selection
We have a saying at Clearleft:
Everything is a tiny lesson.
I bet you learn something new every day, even if it’s something small. These small tips and techniques can easily get lost. They seem almost not worth sharing. But it’s the small stuff that takes the least effort to share, and often provides the most reward for someone else out there. Take for example, this great tip for getting assets out of Sketch that Cassie shared with me.
querySelector to get a reference to an element in the DOM:
var someElement = document.querySelector('.someClass');
Before going any further, check to make sure that the reference isn’t falsey (in other words, make sure that DOM node actually exists):
if (!someElement) return;
That will exit the script if there’s no element with a class of
someClass on the page.
The situation that tripped us up was like this:
var myLinks = document.querySelectorAll('a.someClass'); if (!myLinks) return;
That should exit the script if there are no
A elements with a class of
As it turns out,
querySelectorAll is subtly different to
querySelector. If you give
querySelector a reference to non-existent element, it will return a value of
null (I think). But
querySelectorAll always returns an array (well, technically it’s a NodeList but same difference mostly). So if the selector you pass to
querySelectorAll doesn’t match anything, it still returns an array, but the array is empty. That means instead of just testing for its existence, you need to test that it’s not empty by checking its
if (!myLinks.length) return;
That’s a tiny lesson.
Sunday, January 29th, 2017
The text detection API is still in its experimental stage, but it opens up a lot of really interesting possibilities for the web: assistive technology to read out text, archiving tools for digitising text …it’s all part of the nascent shape detection API.
Friday, January 15th, 2016
A lightweight alternative to Modernizr. It doesn’t add classes to your markup so it’s up to what you do with the results of any test.
It’s perfect for cutting the mustard on a case-by-case basis.
Tuesday, December 8th, 2015
Personally though, I’m still uncomfortable with the assumptions baked into equating particular features with particular browsers …maybe I’ve known PPK too long.
I much prefer to cut the mustard on a case-by-case basis by feature testing the actual APIs I’m about to use in a script. I realise that might be harder to scale, and it’s more verbose, but it’s the only way to be absolutely sure.
Monday, August 4th, 2014
One more reason why you should never sniff user-agent strings: Internet Explorer is going to lie some more. Can’t really blame them though—if developers didn’t insist on making spurious conclusions based on information in the user-agent string, then browsers wouldn’t have to lie.
Oh, and Internet Explorer is going to parse -webkit prefixed styles. Again, if developers hadn’t abused vendor prefixes, we wouldn’t be in this mess.
Thursday, November 7th, 2013
Good luck getting that script updated for the thousands of sites and applications, you say to yourself, where it’s laying dormant just waiting to send devices the wrong content based on a UA substring.
Monday, March 25th, 2013
I think it’s a bit of a shame that Brett is canning his mobile-first device-detection library, but I totally understand (and agree with) his reasons.
There is a consensual hallucination in the market, that we can silo devices into set categories like mobile, tablet, and desktop, yet the reality is drawing these lines in the sand is not an easy task.
Monday, February 25th, 2013
And this is why user-agent sniffing not a future-friendly technique. A new mobile browser comes along, and it has to spoof a fake UA string to all of these sites.
It’s a Red Queen arms race.
Monday, February 11th, 2013
This is a pretty wacky experiment in altering font size based on the user’s distance from the screen (allow the page to access your camera and enable the “realtime” option for some real fun). I don’t know how much real-world application this has, but it’s a cute’n’fun exercise.
Wednesday, February 29th, 2012
Luke outlines three different solutions to delivering a site to multiple devices.
Monday, January 30th, 2012
When I wrote about responsible responsive images a few months back, I outlined my two golden rules when evaluating the various techniques out there:
- The small image should be default.
- Don’t load images twice (in other words, don’t load the small images and the larger images).
I also described why that led to my dissatisfaction with most server-side device libraries for user-agent sniffing:
When you consider the way that I’m approaching responsive images, those libraries are over-engineered. They contain a massive list of mobile user-agent strings that I’ll never need. Remember, I’m taking a mobile-first approach and assuming a mobile browser by default. So if I’m going to overturn that assumption, all I need is a list of desktop user-agent strings.
I finished by asking:
Anybody fancy putting it together?
Instead of assuming the device is a desktop, and detecting mobile and tablet device user agents, Categorizr is a mobile first based device detection. It assumes the device is mobile and sets up checks to see if it’s a desktop or tablet. Desktops are fairly easy to detect, the user agents are known, and are not changing anytime soon.
It isn’t ready for public consumption yet and there are plenty of known issues to iron out first, but I think the fundamental approach is spot-on:
By assuming devices are mobile from the beginning, Categorizr aims to be more future friendly. When new phones come out, you don’t need to worry if their new user agent is in your device detection script since devices are assumed mobile from the start.
Monday, September 19th, 2011
One of the recurring themes at the Mobilism conference earlier this year—and more recently at the Breaking Development conference—was the subject of server-side user-agent detection. I posed the question in absurdum on the Mobilism browser panel:
A useful tool for developers or spawn of Satan: which is it?
It’s a contentious issue, as Alex’s strident defence illustrates. Personally, I’ve never been a fan but that’s mostly because of the long history of really, really bad UA-detection in the past. When I discussed this issue with Lyza we came to a détente, agreeing that there is nothing inherently wrong with server-side UA-detection: it’s what you do with it that counts.
In their presentation at Breaking Development Bryan and Stephanie outlined the kind of detection that they have used. Crucially, it assumes a very basic small-screen default—rather than assuming a desktop browser—and later double-checks the profile on the client-side using feature detection.
Luke recently outlined another kind of cautious device detection that he’s calling RESS: Responsive Design + Server Side Components, sending subtly-different DOMs to different classes of device. He also recently wrote about why Bagcheck has a separate mobile site and it strikes me that RESS could alleviate the concerns he mentioned regarding responsive design for Bagcheck.
I think that RESS could be a very useful technique as long as it assumes a safe default: a small-screen, low-bandwidth default. That way, any UA detection would be done against a fairly limited set of user agents: desktop browsers and maybe tablets. To me, that seems far more reasonable than trying to pattern-match against the sprawling jungle of mobile devices in the wild …not to mention the swampy morass of licensing issues with Device Atlas (and now WURFL too).
A thornier problem with server-side UA-sniffing is that, regardless of whether you’re testing against a list of mobile devices or you’re testing against a list of desktop devices, you’re still committing yourself to an arms race. You are now obligated to keep your list of browsers up to date.
Still, the rate of desktop browser releases is a lot slower than the rate of mobile browser releases. So if a new desktop browser is released and it ends up being served a mobile-optimised DOM, I think that’s better than inadvertently serving a desktop-optimised DOM to a whole bunch of mobile devices.
That’s just my opinion of course. As ever, the standard disclaimer applies.
Friday, May 14th, 2010
Saturday, December 16th, 2006
A microformat detection extension for Firefox 2. This looks more human-friendly than the existing Tails extensions.