Accessibility and Interviewing

Gretchen is curious what your experiences have been like, either as the interviewer or interviewee.  It makes me wonder how I would give a coding problem to someone who is blind, because I’m extremely visual and like looking at code on the whiteboard.  I’m not the best at recording everything down verbatim as I hear it, mostly because of my learning style.  Don’t get me started about the time I attempted to take drive-food orders at the Taco Bell in my youth.  I was talking to someone the other day about coding problems given over the phone in a phone screen, and we discussed how difficult that would be for both the interviewer and interviewee.  This phone screen example reminds me of how I think of accessibility and usability as two sides of the same coin.

Anyone have any experiences along these lines, blind or not?  I’m sure Gretchen would love to hear.

Comments (6)

  1. Travis Roth says:

    Hi Sara, I agree with you accessibility and usability are related closely. Part of my job is to check our clients’ applications for accessibility as it pertains to Section 508, the Federal government’s guidelines for what makes accessible software and websites. I often run into scenarios where a specific item falls into the category of complying with the guidelines but yet not being usable. Clients get upset when I tell them this; and they want to let it pass because "it complies". How much of usability do you think is clear-cut versus an individual experience and opinion? I know you worked in accessibility a lot at one time, did you ever encounter issues where it was more a usability issue than pure accessibility in regards to any specific guidelines? And if so do you have any strategies for getting the usability point across that usability and accessibility "are on the same side of the coin"? Thanks.

  2. saraford says:

    Hey Travis,

    Check out this post of mine –

    In my opinion, the answer is a yes, accessibility and usability are the same thing. I have seen *so many times* issues that if you solve the usability issue, you solve the accessibility issue, many of which involved simplifing the design. I helped drive the UI Consistency effort for Visual Studio alongside my Accessibility effort, so i’m speaking from experience from both sides.

    I "measure" usability in a couple of ways (and this is just my opinion, the usability team has lots more data than i do)

    1. how fast does the user learn how to complete the task?

    2. how fast can the user complete the task after ‘n’ interations?

    #1 is can i figure it out, or do i need to go to the Help System. #2 is how productive can i be once i figure it out.

    Simplicity is always the best approach for both usability and accessibility, because with it you can accomplish both #1 and #2.

    I honestly don’t recall a case where improving the accessibility of a feature didn’t improve the usability of the feature. Okay, MSAA implemetnation isues don’t count – we’re talking pure UI design here. It’s harder to make the same claim going the other way (but, hey, maybe i’m wrong), because adding mouse wheel support will definitely help the mouse user, but it won’t help the keyboard user. However, it’s still safe to say improve usability <=> improve accessibility.

    If you need a good Usability = Accessibility argument, ask whomever to think about how they would give a coding question to a blind person sitting in their office. Let them think about it for a few minutes. Then ask them (maybe a few questions later – not to let the cat out of the bag) if they ever given a coding question or talked about code over the phone with someone. Then ask them how is that different than asking the blind person a coding question. Yes, sure, it isn’t 100% the same, but it requires you to use the same sort of "usability" tools. QED.

    And lastly, my greatest strategy for getting accessibility across – have the people on your team, clients, etc, watch someone who is blind or uses whatever accessibility tools use (or attempt to use) their products. Nothing drives the point home faster and better than that.


  3. Ian Ringrose says:

    I would tent to want to do two interviews, in the first interview ask the blink person how THEY design software and have communicates designs in the past. In the second interview make use of what you learnt in the first interview to set the coding test.

  4. Travis Roth says:

    Hi Sara, Thanks for the link. I would agree with your earlier article that it is likely improved usability would imrpove accessibility. HOwever, this is only true if the improved usability is factoring in all users. Just adding more whim-bang features for a mouse user will not improve the experience for a keyboard-only user for example.

    I find it interesting that the main accessibility concern seems to go to the blind community. I am greatful we get some attention as we do need it 🙂 but it also amuses me how much other things are overlooked. I.e., blind users are not the only users who may need to use the keyboard exclusively.

  5. saraford says:

    My main accessibility concern over the past 3 years has been the blind community because visual studio doesn’t rely only on sound anywhere to convey information or meaning. So I focused on the blind community. If only we did have places where we relied on sound, i could have had a business justification to ask my manager to pay for Sign Language courses =) I’ve always wanted to learn sign language and apply it to something someday.


  6. saraford says:

    wow, time flies. I should have said for the past 4 minus 1 years. <grins>


Skip to main content