Accessibility Design Drive

Last week, for roughly one hour each day, I participated in the Accessibility Design Drive, organised by Stanford University and Mozilla to make Firefox more inclusive by collaborating in diverse teams. It was a fun thing to be part of, and great to learn from others!

The people who joined this were a very varied bunch, over 100 in total. There were lots of people from the States and India, but also a number from Europe and elsewhere. Some had impairments, some were accessibility practitioners and some were both. A lot of students joined, too!

They grouped us into teams by time zone, and during the week, some of us were moved around to other teams, so that we could meet and work with more different people. We were working in a decentralised design process, with as its goal the inclusion of more perspectives in the design process.

Time-wise it was challenging. Many of us, myself included, had to squeeze the time into our after work hours, and the one hour wasn’t always enough.

What did we do?

Identify roadblocks

On the first day, we got some links for reading and got to know our fellow team members. The first team exercise was to figure out what kind of roadblocks each of us (or people close to use) experienced when accessing the web.

I read How people with disabilities use the web for inspiration.

Find patterns

The day after, our team had become slightly bigger by this point, we were asked to identify patterns from our observations from the day before.

Think of solutions

The third day, I was moved to another team by now, was all about thinking what we could do about the problems we had identified. And mainly, how could something in Firefox help solve the problems. So the question, really, would be: ‘what can a browser to improve accessibility?’

I found it difficult to come up with many solutions and decided to ask some friends, as well as Twitter:

If you could add a feature to a browser to improve accessibility to the web for people, what would it be? #a11y

(Me, on Twitter)

Lots of great responses came in, a couple I liked in particular:

  • auto fix color accessibility issues (Bob)
  • allow for styling of form elements like radio buttons, checkboxes and selects (Karl and Anneke)
  • make it easy and obvious for users to change the appearance of a site to personal preferences (Alistair)


On the fourth day, we were asked to choose three ideas and turn them into a storyboard, which, I learned, is an unpolished visual representation of how an interface idea could work in the real world. We started by describing the approach in steps, as a sequence of actions.


The fifth and last day was all about testing. We were asked to communicate our thoughts to someone from their target audience, ask them about their thoughts, learn from this and then refine. In our team, this was the day we failed to do the main thing and did not test with users because we were time constrained. We did work on fine tuning the descriptions of our most important ideas.

Problems that browsers could solve

I’m a lazy front-end developer and happy with anything I don’t need to build myself. I’ll gladly leave things to the browser. Browsers are much better than I could ever be at interoperability, ensuring keyboard access and providing information to platform accessibility APIs. Over the past week, I realised there are even more things the browsers could improve for users regarding accessibility.

One thing I noticed in the discussions we had in our team, is that some accessibility issues follow from poor decision making by people who make websites. Browsers could theoretically resolve many of those. Examples: too little color contrast (browser could autocorrect), removal of focus outlines (browser could let the user override) and too much motion (the latter has been resolved with a media query for reduced motion).

Problems people have with forms could be solved by browsers, too. What if they provided native methods to style form elements like select and radio/checkbox inputs? Developers currently resort to non-native ways, which are not necessarily the most accessible, hence making forms harder to use for some users.

The above suggestions may be nothing more than public daydreaming, but I think it’s awesome that browser makers like Mozilla are so serious about accessibility. I am looking forward to seeing some feature ideas from this Accessibility Design Sprint make it into Firefox.

Comments, likes & shares

No webmentions about this post yet! (Or I've broken my implementation)