Sara runs through the many ways of providing an accessible name to an icon button, backed up with Scott’s testing.
Wednesday, May 22nd, 2019
Monday, May 20th, 2019
This looks like a really useful tool for generating accessibile colour combinations from a starting colour.
Thursday, May 16th, 2019
What if accessibility were a ranking signal for Google search results?
Here’s a thought: what if Google put its thumb on the scale again, only this time for accessibility? What if it treated the Lighthouse accessibility score as a first-class ranking metric?
A very welcome project from Marcus Herrmann, documenting how to make common interaction patterns accessible in popular frameworks: Vue, React, and Angular.
Wednesday, May 15th, 2019
Coffee talk with Ethan Marcotte. Today’s special: inclusivity.
I want to get there: to have nuanced discussions about text descriptions; I want to read poetry in alt text; to have our work’s success measured by how broadly it can be accessed; to create moving, beautiful experiences for people who may not use the web like I do.
Monday, April 29th, 2019
Thursday, April 11th, 2019
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.
Wednesday, April 10th, 2019
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
Tuesday, April 9th, 2019
We have a tendency in our line of work to assume that what benefits us as developers translates to a benefit for those who use what we make. This is an unsafe assumption.
- Morality is not always relative.
- You’re a web professional.
- The web is accessible out-of-the-box. We break it.
- It’s not on people with disabilities to tell you how you screwed up.
- It should be easier. This is our job.
Sunday, April 7th, 2019
I got a message from a screen-reader user of The Session recently, letting me know of a problem they were having. I love getting any kind of feedback around accessibility, so this was like gold dust to me.
They pointed out that the drag’n’drop interface for rearranging the order of tunes in a set was inaccessible.
Of course! I slapped my forehead. How could I have missed this?
It had been a while since I had implemented that functionality, so before even looking at the existing code, I started to think about how I could improve the situation. Maybe I could capture keystroke events from the arrow keys and announce changes via ARIA values? That sounded a bit heavy-handed though: mess with people’s native keyboard functionality at your peril.
Then I looked at the code. That was when I realised that the fix was going to be much, much easier than I thought.
I documented my process of adding the drag’n’drop functionality back in 2016. Past me had his progressive enhancement hat on:
One of the interfaces needed for this feature was a form to re-order items in a list. So I thought to myself, “what’s the simplest technology to enable this functionality?” I came up with a series of
selectelements within a form.
The problem was in my feature detection:
There’s a little bit of mustard-cutting going on: does the
dragulaobject exist, and does the browser understand
querySelector? If so, the
selectelements are hidden and the drag’n’drop is enabled.
The logic was fine, but the execution was flawed. I was being lazy and hiding the
select elements with
display: none. That hides them visually, but it also hides them from screen readers. I swapped out that style declaration for one that visually hides the elements, but keeps them accessible and focusable.
It was a very quick fix. I had the odd sensation of wanting to thank Past Me for making things easy for Present Me. But I don’t want to talk about time travel because if we start talking about it then we’re going to be here all day talking about it, making diagrams with straws.
I pushed the fix, told the screen-reader user who originally contacted me, and got a reply back saying that everything was working great now. Success!
Saturday, April 6th, 2019
Accessibility for Vestibular Disorders: How My Temporary Disability Changed My Perspective · An A List Apart Article
This is a fascinating insight into what it’s like to use the web if you’ve got vertigo (which is way more common than you might think):
Really, there are no words to describe just how bad a simple parallax effect, scrolljacking, or even
background-attachment: fixedwould make me feel. I would rather jump on one of those 20-G centrifuges astronauts use than look at a website with parallax scrolling.
Every time I encountered it, I would put the bucket beside me to good use and be forced to lie in bed for hours as I felt the room spinning around me, and no meds could get me out of it. It was THAT bad.
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.
This is a really nice write-up of creating an accessible progressive disclosure widget (a show/hide toggle).
Where it gets really interesting is when Andy shows how it could all be encapsulated into a web component with a progressive enhancement mindset
Friday, March 29th, 2019
Not only does the differentiation of terms create a divide within the industry, the term ‘web app’ regularly acts as an excuse for corner cutting and the exclusion of users.
We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.
Wednesday, March 13th, 2019
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.
Eric is down about the current dismal state of accessibility on the web. Understandably so. It’s particularly worrying that the problem might be embedded into hiring practices:
But it’s not all doom and gloom. Eric also points to initiatives that could really help.
Still, this is a tough question to ask out loud:
What if we’re losing?
Monday, February 25th, 2019
Accessibility on The Session
These forms have been enhanced with some Ajax to add some motion design: instead of refreshing the whole page, the next form is grabbed from the server while the previous one swooshes off the screen.
You can see similar functionality—without the animation—wherever there’s pagination on the site.
The pagination is using Ajax to enhance regular prev/next links—here’s the code.
The multi-step forms are using Ajax to enhance regular form submissions—here’s the code for that.
Both of those are using a wrapper I wrote for XMLHttpRequest.
That wrapper also adds some ARIA attributes. The region of the page that will be updated gets an
aria-live value of
polite. Then, whenever new content is being injected, the same region gets an
aria-busy value of
true. Once the update is done, the
aria-busy value gets changed back to
That all seems to work fine, but I was also giving the same region of the page an
aria-atomic value of
true. My thinking was that, because the whole region was going to be updated with new content from the server, it was safe to treat it as one self-contained unit. But it looks like this is what was causing the problem, especially when I was also adding and removing
class values on the region in order to trigger animations. VoiceOver seemed to be getting a bit confused and overly verbose.
I’ve removed the
aria-atomic attribute now. True to its name, I’m guessing it’s better suited to small areas of a document rather than big chunks. (If anyone has a good primer on when to use and when to avoid
aria-atomic, I’m all ears).
I was glad I was able to find a fix—hopefully one that doesn’t negatively impact the experience in other screen readers. As is so often the case, the issue was with me trying to be too clever with ARIA, and the solution was to ease up on adding so many ARIA attributes.
For me, all of this really highlights the beauty of the web, when everyone is able to contribute to a community like The Session, regardless of what kind of software they may be using. In the tunes section, that’s really helped by the use of ABC notation, as I wrote five years ago:
One of those screen-reader users got in touch with me shortly after joining to ask me to explain what ABC was all about. I pointed them at some explanatory links. Once the format “clicked” with them, they got quite enthused. They pointed out that if the sheet music were only available as an image, it would mean very little to them. But by providing the ABC notation alongside the sheet music, they could read the music note-for-note.
That’s when it struck me that ABC notation is effectively alt text for sheet music!
Then, for those of use who can read sheet music, the text of the ABC notation is automatically turned into an SVG image using the brilliant abcjs. It’s like an enhancement that’s applied, I dunno, what’s the word …progressively.
Monday, February 11th, 2019
A nice counterpoint to the last time I linked to Paul’s weeknotes:
However, there’s another portion of the industry, primarily but not exclusively within the public sector, where traditional development approaches (progressive enhancement, server-side rendering) remain prevalent, or less likely to be dismissed, at least. Because accessibility isn’t optional when your audience is everyone, these organisations tend to attract those with a pragmatic outlook who like to work more diligently and deliberately.