Tags: accessibility

237

sparkline

Sunday, January 15th, 2017

Using the aria-current attribute – Tink

The aria-current attribute is very handy and easy to implement. Léonie explains it really well here.

Monday, December 19th, 2016

Front-End Developers Are Information Architects Too ◆ 24 ways

Some great thoughts here from Francis on how crafting solid HTML is information architecture.

Saturday, December 10th, 2016

Accessibility Whack-A-Mole · An A List Apart Article

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

What the Heck Is Inclusive Design? ◆ 24 ways

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

FormLinter—Detect common issues that hurt conversions

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

Results of the 2016 GOV.UK assistive technology survey | Accessibility

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

Accessibility Meetup: role=drinks

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

bitsofcode | Tools for Developing Accessible Websites

Ire rounds up a bunch of tools you can use to test accessibility, from dev tools to Tenon.

Tuesday, November 1st, 2016

Mutating the active element - ally.js

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

Simple, semantic and responsive tables (part II) – Design Today – Wouter Hillen

This uses generated content in CSS to make the aria-label attributes visible on small screens—clever!

Friday, October 21st, 2016

How the Web Became Unreadable

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

Hiding inline SVG icons from screen readers | 456 Berea Street

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

Responses To The Screen Reader Strategy Survey | HeydonWorks

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

Aria-Controls is Poop | HeydonWorks

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:

‘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. you@example.com">
</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. you@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:

  1. Label text,
  2. Validation message,
  3. Form field.

And in the second example we get:

  1. Label text,
  2. Form field,
  3. 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

Writing Less Damn Code | HeydonWorks

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:

My favorite thing about aiming to have less stuff is this: you finish up with only the stuff you really need — only the stuff your user actually wants. Massive hero image of some dude drinking a latte? Lose it. Social media buttons which pull in a bunch of third-party code while simultaneously wrecking your page design? Give them the boot. That JavaScript thingy that hijacks the user’s right mouse button to reveal a custom modal? Ice moon prison.

Tuesday, August 9th, 2016

Start Building Accessible Web Applications Today - Course by @marcysutton @eggheadio

A great series of short videos from Marcy on web accessibility.

Monday, August 8th, 2016

Creating An Accessible Modal Dialog

In the same vein as Hugo’s script, Ire walks through the steps involved in making an accessible modal window. Seeing all the thinking and code required for this really highlights the need for a way of making the document in the background inert.

Tuesday, August 2nd, 2016

Hidden Expectations - daverupert.com

Over the years I’ve come to realize that most difficult part of making websites isn’t the code, it’s the “hidden expectations”, the unseen aspects I didn’t know were my responsibility when I started: Accessibility, Security, Performance, and Empathy.

Thursday, July 21st, 2016

Vox Product Accessibility Guidelines

I’m not a fan of the checklist approach to accessibility, but this checklist of checklists makes for a handy starting point and it’s segmented by job role. Tick all the ones that apply to you, and this page will generate a list for you to copy and paste.