A11YLint Brackets Extension – My Attempt At Realtime Accessibility Improvement

I do all my coding in Brackets – the open source HTML, CSS and JavaScript editor project started by Adobe.

One of the things I really like about Brackets is this integration they’ve done with JSLint – a tool that looks at your JavaScript while you’re writing it and tells you when you’re doing something you probably shouldn’t. JSLint can be a little over-strict sometimes, but using it has had the real benefit of forcing me to write cleaner and more consistent code.

I’ve had an idea kicking around for a little bit that plugging a linter for accessibility into Brackets might help me do the same thing when I’m writing HTML (which I don’t do that often). So this past weekend I sat down after talking the idea through with a couple people and banged something out.

The A11YLint Brackets Extension is available on Github, is MIT licensed, and may or may not be doing all the right things. I’d love it if you checked it out and gave me some feedback. I know it’s incomplete, but it’s a start.

Want to help, but don’t know where to start? Write me some failing tests – create an HTML page that fails a rule not currently covered by the A11YLint Brackets Extension and submit it. Or open a bug and describe the test.

Also – I don’t know what your development process is like, but while I was working on this project I decided to shoot some video along the way, and what came out the other end is this.

Questions, comments, etc – I’d love feedback on this.

Are you a non-profit? Do you need help with mobile? Come see me.

Last night I followed a link to a non-profit on my phone, and it kinda made me sad. No, I won’t name names or anything, but my guess is that if you were to pick 3-4 of your favorite not-huge non-profits, and you went to their website on your phone, you’d probably see what I mean. A lot of non-profits could use a little help making their content easier consume on mobile devices (or easier to consume in general).

And I’m already doing this thing with Red Rover Open Device Lab where I’m working from locally owned bay area cafes on Wednesdays. It seems like it would be a good opportunity provide a little assistance for non-profits in this area.

So, I announce a little thing today to basically say “Come out wherever Red Rover ODL is, I’ll help you if I can.” I don’t know if it’s useful or not, but I know if I don’t make the offer, there’s know way to know who would accept.

So, here it is bay area non-profits: if it’s Wednesday I’m probably sitting in a cafe, and I’m willing to help you crack this particular nut.

Writing Accessibility Into A Design Application

Note: This might be an especially good post to remind people that I’m blogging on my own, and anything I say here isn’t on behalf of my employer.

I pushed out an update today to the Edge Inspect Chrome Extension that mainly included a couple of localization tweaks and adding accessibility tags to the extension.  Given that Edge Inspect is primarily a tool for designers, we had some discussion about if this was even necessary.  I don’t know if I have anything new to say on the subject, but I thought it was worth writing about.

I’ll preface by saying that I’m not the guy to talk to about accessibility and your content.  I’ve never given it much thought before, and I’m pretty sure what you’re reading right now doesn’t give you much in the way of accessibility features unless it came baked into the theme already.  In fact when I typed that I had to go back and set the title of that link I posted earlier because I skipped that bit.  In short, I’m probably part of the problem in the first place.  I know that accessibility doesn’t mean “usable by the blind” but I’m probably not getting even that right.

So when the question of adding accessibility tags to Edge Inspect came up, I was one of the first to say “It’s a visual design tool.  It’s not something you can use if you’re blind.”  The discussion went back and forth, and ultimately we decided to go ahead and do the work.  Partially on the strength of our product owner, who felt strongly that we should do it as a matter of principle, and partially because the company has a dedicated team of people willing to do a lot of the work for us.  Most of the updates to the extension weren’t done by anyone on the team.  It’s hard to say no to free work, especially when it’s really well done.

But the conversation in general forced me to challenge a fundamental assumption I’d made about the product, and in a way that really clicked with changes I’ve been trying to make in how I approach everything.  Like most of us I guess, I used to think I could get to the right solution if I thought things through hard enough.  I’ve come around to the notion that really the only way to get to a good solution is to test an assumption.  In other words there is either stuff I’ve validated, or stuff I haven’t finished testing yet.

And in this context, I’d assumed that Edge Inspect wouldn’t be used by the blind, and never bothered to test that assumption. Further, we’d kinda made it impossible to test the assumption by not including accessibility in “those things we do along the way rather than bolting them on at the end.”

So I guess there were two lessons really.  The first is that we were a little backwards on our thinking.  We were saying “It’s a visual design tool, therefore no blind users” when we probably should have been saying “Users could be blind, how can we make this design tool useful to them.”  And the second is if we’d been thinking that way all along, we wouldn’t have needed to try and bolt the work on at the end.

Will it make any difference to our users, downloads, market impact, adoption rate or revenue?  I dunno.  But I’m pretty sure if we don’t test things like this, we’d never really know for sure.

Note: Edited to add a link to the accessibility team who did the work for us. If you’d like to learn more about the company’s accessibility team, you can read more about them at http://www.adobe.com/accessibility

How Not To Do A Blog

Three posts last year, right? That was a record for me!  And one of them was a shill for an article I wrote.

This year should be better.  I’m not going to put stuff up here just to put stuff up here, but I expect to be more active.  Maybe one a week.  Ish.  We’ll see.

I’m totally not just putting this post in here so that it looks like I’m more active than last year though.  That’s just the impression you’re getting because I didn’t actually say anything meaningful in this post.

World Class Writing Right Here Folks.

Belated SXSW Wrapup

In all the madness surrounding my venture out to SXSW, I didn’t really get a chance to post second impressions or a wrapup.  Better late than never, right?

All in all, the Adobe Shadow launch went great.  I was able to follow along on Twitter while the main presentation was going on, and reactions were very positive.  The same has been true since then.  Not that there aren’t detractors or people who want it to work differently.  But overall, people have been really happy with the product.  I can’t wait until we drop our first update.

SXSW as a whole has left a big blur in my memory.  There was so much to see that a lot of it ran together.  And I’m pretty sure that didn’t have so much to do with free drinks.  Having had some time to reflect, I think the main couple of things I took away from it were these two things:

1 – Have Some Semblance Of A Plan.

I should have scoped out the sessions a little better.  There were a couple I’m bummed that I missed, and a couple that I could have skipped.  If I’d done my homework, my session experience would have been a little better.

2 – Expect To Throw Out The Plan.

Rigid schedule?  Not so much.  If I hadn’t rolled with it, I wouldn’t have met some of the awesome people that I did.  So while I’d like to know ahead of time what my options are, I’m not going to break brain trying to come up with the perfect plan.  I’ll just throw it out when I meet interesting people anyway.

Overall, I really walked away with the feeling that there’s no reason I couldn’t be on a stage instead of in the audience at least once next year.  I’ll have to start honing my pitches for the frenzy come June.

All in all, you should go.  At least once, if you can.  See what people are talking about.  It might not be for you, but I think of it like most large events: you can have as good or as miserable of a time as you want to.  And me, I had an AWESOME time.

First Impressions of #SxSW, Austin and the Adobe Shadow launch.

I got the opportunity to go to SxSW for the launch of Adobe Shadow this year.  This was a whole bunch of first-times for me – the first time I’ve been to Austin, to SxSW, the first time I’ve been present for a big launch, the first time I’ve been involved in such a high profile way in a new product.  I wanted to write a blog post every day about how it was going, but it’s been pretty crazy.  Here’s a bunch of my early thoughts, in no particular order.

Austin looks much more like Ohio than I expected it to.

As crazy as I knew SxSW would be, it’s s much crazier.  In every sense of the word.

When they talk about Austin being theLive Music Capital of the World, they aren’t messing around.

There are some amazing things to be heard at this conference.  And there is a great deal of snake oil.

I would not want to come here to launch an indie game.

I have walked far more in the last few days than I expected to.

This is a cool town to run in.  But it is not flat.

There is such a thing as eating too much delicious meat in one day.

There are so many parties, and so many places to have parties.

Signal to noise is an issue.

Getting here early to pick up my pass saved me half a day of waiting in line.

I want to present here.  Next year.

I’ve heard at least two people mention in a talk concepts that I’m actively researching.

Everyone here wants something.  Coming in knowing what you want is important.

Texas Chili Parlor

Javascript has made a crazy comeback.  Everyone knows it, but it’s still a bit surprising.

Getting noticed here isn’t hard.  Getting noticed on a big scale must be.

SxSW is not a good venue to meet people in the morning.

Really nice boots are expensive.

It’s not always hot here.

Pack extra socks when it’s raining.

There are some amazing people here to be met.  You won’t meet them if you don’t say hi.

Don’t burn out too quickly.

Don’t count on free time.

I’ll post more when I can.  It’s been pretty busy here.