How to discuss accessibility during a design/UI/UX interview or portfolio review
Portfolio reviews are the penultimate step in the design/UI/UX interview process. It’s a chance to show your work, defend your decision-making, explain your creative process, and allow your work to speak for you.
Accessibility questions occasionally come up in this process, especially if you are interviewing at a company that *really* cares about accessibility. If you have practice with universal/inclusive/accessible design then the answers to the questions below should be easy. The questions and structure around accessibility aren’t that much different from a portfolio review in general. But what if you haven’t done an accessible design before? Is it going to be an automatic interview fail?
Not if you prepare: if you have designs with inaccessible layouts or color choices, you can demonstrate that you know and care about accessibility if you talk about what you would have liked to do instead of what you did. This option is all that is available to you when you have worked for companies or clients that didn’t care enough to include accessibility as part of the “definition of done.” Think about the answers to the following questions before you go into a portfolio review.
Who did you involve in making accessibility decisions?
Typically the interviewer wants to hear that you are involved (or would have been involved) in the accessibility team (if you have one), product owner(s), program manager(s), QA, usability, and UI development. More mature designers for existing products that are being updated should have also sought out input from existing customers. Interviewers always want to hear that people with disabilities were consulted (or would have been consulted) as part of the design process.
When did you start (and end) thinking about accessibility?
Are you a practitioner of proactive accessibility (thinking about accessibility from the beginning of the design process), or did the item(s) in your portfolio implement accessibility reactively (that is taking a “finished” design/product and then making it accessible?)
Do you view accessibility as a project or a continuous improvement program? Did you take steps to future-proof your accessibility decisions? Did you look at what others with similar products are doing? Did you review the latest accessibility features coming from iOS 14 to figure out how to take advantage of them?
The right time to execute accessibility is an interview question that does have right and wrong answers.
Accessibility is never best accomplished retrospectively.
Robust accessibility requires the continued ability to function even when underlying browsers and operating systems have been updated.
You never finish thinking about accessibility until a product has been officially declared end-of-life.
Did you design a product or create a product experience?
Making sure the documentation, support, training, and marketing materials are also accessible is an integral part of making sure the entire product experience is accessible, and not just the product. People with disabilities need equal access to the whole package, not only the product.
What challenges did you encounter, and how did you overcome them?
Sometimes, designers have to make accessibility trade-offs or deviate from standard recommendations to create the most usable experience. Some examples of this include:
A complicated grid with activatable components in the cells requires extra ARIA instructions or keyboard shortcuts.
Lack of a research group or funding constraints might make it challenging to execute research on people with disabilities.
All projects have challenges. How someone responds to the challenges tells the interviewer a lot about the candidate and whether or not their process is collaborative or executed in a silo.
How did you communicate desired accessibility behavior to developers?
There is a great deal of accessibility behavior that can’t be conveyed in design comps because the accessibility behavior itself is not visible — it is behavior mostly exposed (or important) to assistive technology users. A non-exhaustive common list of examples that fall into this category include:
Page/screen titles
Error messaging
Primary grid navigation that triggers detailed grid updates
Button activation that triggers visual changes elsewhere on the page
Modal dialogs
Toast messages
“Click Here” and “more” links.
Designers should communicate accessibility implementation instructions that address the invisible accessibility aspects of product behavior. If they don’t, there is a distinct possibility that unless the developers are very experienced at implementing accessible products, that the product (and thus, the product experience) will not be completely accessible. This can be done as part of the design brief.
How did you make sure that your accessibility research findings were coded into the final product?
There is no right answer to this question *other* than as a good accessibility designer, you don’t throw the instructions to the developer then move on to the next design and never look at the final implemented accessibility features in the first product. This is especially true in organizations where the designers know more about accessibility than the developers.
In order to review the final product, you need to be able to intelligently discuss the use of various types of assistive technology — keyboard and alternative input devices, magnification, switches, and screen readers just to name a few. Multiple iterations involving both automated and manual accessibility are always required.
What would you do differently next time?
Again, no right answer. The clearly wrong answer is, “I wouldn’t change a thing, everything was perfect.” It is incredibly rare to have zero accessibility regrets at the end of any project. If the product contains every accessibility feature you requested, you didn’t ask for enough. There should be things you wish you could have done better or best practices that you wished you could have convinced people to adopt. The mature answer is to say, “We did a retrospective, and decided next time we would blah blah blah.” Even if you didn’t do a retrospective, just saying that wish you could have done a retrospective shows some level of maturity.
Bonus question: what is your least favorite WCAG guideline?
WCAG 2.1 Level AA has 50 guidelines. If you have worked with them for any length of time, there is always at least one that isn’t your favorite, that you find difficult to implement, or that is counter to the way you originally learned to design. Of course, candidates are expected to be able to discuss what they like about WCAG and what is important about accessibility in a portfolio review. But being able to discuss what you don’t like, didn’t go far enough, or would do differently is an extra dimension that many people don’t have a good answer for.
It is possible to salvage the accessibility part of your portfolio review, even if you didn’t consider accessibility while developing your portfolio designs. To accomplish that, you need to be prepared to discuss what you would have done if accessibility had been part of the product design.
I wanted to do X
But my employer/client limited me to Y
goes a long way towards explaining that you know how to design accessible experiences even though you were not in a position to do so in earlier work.
