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

5 comments

  1. John Foliot

    Hi Duane,

    I think you hit on 2 important topics here. The first is that all developers need to keep accessibility in mind from the onset (as opposed to what you called Bolt-On), and you are absolutely correct.

    The other thing is, while you didn’t specify “what” accessibility ‘tags’ you added I will presume that some of it (all of it?) was likely ARIA based, which is pretty important when it comes to communicating web-based content to Assistive Technology such as screen readers, via the OS’es Accessibility APIs. One thing to consider however is that it’s not “just” blind users – there are many low-vision users who can see, but who may also be using AT such as screen readers to supplement that vision, and ensuring that your application works for them is a big deal (so thanks to you and your employer).

    I am also heartened to hear that your employer wanted to do this for the right reasons, but I will also suggest that it makes smart business sense too, especially if he is eying governmental contracts: those folks are legally mandated to purchase tools that meet accessibility requirements, so whether because it was right, or profitable, I’m glad to hear it was done.

    Kudos all way ’round

    • Duane

      John, thanks for your comments. You’re correct, I’m primarily talking about adding ARIA based attributes to the relevant entities in this case.

  2. Bryan

    Duane,
    This is a big deal and please do not ever feel like it was not or is not. Weather or not blind people jump right in and purchase software, or use software right away the fact that it is usable for them will be important soon enough. Accessibility is a big word for blind or low vision people to say they can do some of the things their sighted peers can do without thinking. Really all accessibility is to us is being able to interact with some thing on some level. It does not mean we have access to everything, it does not mean we can use it the same as our counter parts, and it does not mean we will work any less to do the same job as our peers. In short making your tools accessible is kind of like an emergency exit or a automatic door opener. You might never use it for normal day to day access, but that does not mean it should not be there for those who do need it and to be compliant to our moral and leagle obligation. One day it is my hope that access to developer tools will come usable as a standard rather than as an after the fact or “bolt on” option. So often we are forced to figure out other ways to do what we do that when a developer makes this decision we appreciate it and will do what we can to show our appreciation. THank you and your employer for thinking out of the box!

  3. Pingback: Accessibility Related Reading List – January 29 2013 | Recreate Web
  4. Vince Thacker

    I’m very glad to see this subject being discussed. I can say as a registerd blind/legally blind person that ideally I want access to everything that fully sighted people have.

    Accessibility in design tools is one way of future-proofing the software, especially as even totally blind people are now starting to use haptics as well as text-to-speech aids. it has taken a while to get touch screens to become tactile, ironically, but now this is becoming a reality, and at present it seems that mobile phones and tablets are leading the way in this field – and, of course, Windows 8 can be used via a touch screen.

    It is good to know that blind and other disabled people can be enabled to use more and more technology for work opportunities as well as leisure time pursuits.

    With any luck, accessibility will not be a last-minute bolt-on, but be incorporated by default in the DNA of software. People with dyslexia, dexterity problems, deaf people and those with cognitive challenges can all benefit, not just blind people.

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>