Sunday, February 12th, 2017
A new media query that will help prevent you making your users hurl.
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.
Thursday, January 19th, 2017
Some interesting insights from usability and accessibility testing at the Co-op.
We used ‘nesting’ to reduce the amount of information on the page when the user first reaches it. When the user chooses an option, we ask for any other details at that point rather than having all the questions on the page at once.
Sunday, January 15th, 2017
aria-current attribute is very handy and easy to implement. Léonie explains it really well here.
Monday, December 19th, 2016
Some great thoughts here from Francis on how crafting solid HTML is information architecture.
Saturday, December 10th, 2016
A fascinating piece by Eleanor on the typographic tweaking that the Wellcome team did to balance the competing needs of different users.
Thursday, December 8th, 2016
I really, really like Heydon’s framing of inclusive design: yes, it covers accessibility, but it’s more than that, and it’s subtly different to universal design.
He also includes some tips which read like design principles to me:
- Involve code early
- Respect conventions
- Don’t be exact
- Enforce simplicity
Come to think of it, they’re really good design principles in that they are all reversible i.e. you could imagine the polar opposites being design principles elsewhere.
Monday, November 21st, 2016
A little tool for testing common form issues.
- Did we remember to give every input a label? (No, placeholders are not an adequate replacement)?
- Do our labels’ for attributes match our inputs’ ids?
- Did we take advantage of the url, email, and password input types, or did we forget and just use text?
- Are our required fields marked as such?
Monday, November 14th, 2016
The Government Digital Service have published the results of their assistive technology survey, which makes a nice companion piece to Heydon’s survey. It’s worth noting that the most common assistive technology isn’t screen readers; it’s screen magnifiers. See also this Guardian article on the prevalence of partial blindness:
Of all those registered blind or partially sighted, 93% retain some useful vision – often enough to read a book or watch a film. But this can lead to misunderstanding and confusion
Tuesday, November 8th, 2016
This Saturday afternoon—the day after FFConf—there’s an accessibility meet-up in the Caxton Arms here in Brighton with lighting talks (I’m planning to give one). ‘Twould be lovely to see you there.
Sunday, November 6th, 2016
Ire rounds up a bunch of tools you can use to test accessibility, from dev tools to Tenon.
Tuesday, November 1st, 2016
Rodney has done some great research into how different browsers respond to a focusable element becoming inactive (by being made disabled, hidden, or removed).
Sunday, October 23rd, 2016
This uses generated content in CSS to make the
aria-label attributes visible on small screens—clever!
Friday, October 21st, 2016
Kevin writes a plea on Ev’s blog for better contrast in web typography:
When you build a site and ignore what happens afterwards — when the values entered in code are translated into brightness and contrast depending on the settings of a physical screen — you’re avoiding the experience that you create. And when you design in perfect settings, with big, contrast-rich monitors, you blind yourself to users. To arbitrarily throw away contrast based on a fashion that “looks good on my perfect screen in my perfectly lit office” is abdicating designers’ responsibilities to the very people for whom they are designing.
Thursday, October 6th, 2016
A good reminder from Roger on how to hide images from an SVG sprite from assistive technology (use
aria-hidden) and how to expose them (use
title elements within the sprite).
Sunday, September 25th, 2016
Heydon asked screen readers some questions about their everyday interactions with websites. The answers quite revealing: if you’re using headings and forms correctly, you’re already making life a lot easier for them.
Wednesday, August 31st, 2016
I wrote a while back about how I switched from using a button to using a link for progressive disclosure patterns. That looks like it was a good move—if I use a button, I’d need to use
aria-controls and, as Heydon outlines here, the screen reader support is pants.
Wednesday, August 24th, 2016
Marking up help text in forms
Zoe asked a question on Twitter recently:
#a11y folks: Is it still best to put form field instruction/help text inside the <label>, or is aria-describedby sufficient nowadays?— Zoe M. Gillenwater (@zomigi) August 18, 2016
‘Sfunny—I had been pondering this exact question. In fact, I threw a CodePen together a couple of weeks ago.
Visually, both examples look the same; there’s a label, then a form field, then some extra text (in this case, a validation message).
The first example puts the validation message in an
em element inside the
label text itself, so I know it won’t be missed by a screen reader—I think I first learned this technique from Derek many years ago.
<div class="first error example"> <label for="firstemail">Email <em class="message">must include the @ symbol</em> </label> <input type="email" id="firstemail" placeholder="e.g. firstname.lastname@example.org"> </div>
The second example puts the validation message after the form field, but uses
aria-describedby to explicitly associate that message with the form field—this means the message should be read after the form field.
<div class="second error example"> <label for="secondemail">Email</label> <input type="email" id="secondemail" placeholder="e.g. email@example.com" aria-describedby="seconderror"> <em class="message" id="seconderror">must include the @ symbol</em> </div>
In both cases, the validation message won’t be missed by screen readers, although there’s a slight difference in the order in which things get read out. In the first example we get:
- Label text,
- Validation message,
- Form field.
And in the second example we get:
- Label text,
- Form field,
- Validation message.
In this particular example, the ordering in the second example more closely matches the visual representation, although I’m not sure how much of a factor that should be in choosing between the options.
Anyway, I was wondering whether one of these two options is “better” or “worse” than the other. I suspect that there isn’t a hard and fast answer.
Tuesday, August 23rd, 2016
I’m in complete agreement with Heydon here:
But it turns out the only surefire way to make performant Web Stuff is also to just write less. Minify? Okay. Compress? Well, yeah. Cache? Sounds technical. Flat out refuse to code something or include someone else’s code in the first place? Now you’re talking.
Just like the “mobile first” mindset, if you demand that everything must justify its existence, you end up with a better experience for everyone: