Nothing makes us happier than knowing there are people out there just as eager as we are when it comes to making the digital world better for everyone.
Last week, we received this question through our website:
Hello, I’m a front-end web developer in charge of accessibility in my company. I say that, but there’s never really any time for R&D, user testing is non-existent, and I basically try to bake it into my work following WAI-ARIA recommendations whenever I’m developing something not new (as opposed to retrofitting accessibility after an “audit”). Having seen some articles here, it has proven my concern that my guesswork does indeed have its limitations.
If I cannot do user testing and if I have limited time to “make” our UIs accessible, what can I do to do this better? Are there tools I can use? Experiences I can simulate?
Usually when we get emails at Simply Accessible, they are from companies looking to partner with us to help them make their digital products or services more accessible. Once in a while, though, we get questions and comments from individuals. Recently, we received the above question from a developer who is the sole person in their organization responsible for accessibility, with no budget or support for usability testing or research, and really no infrastructure for evaluating how effective their work on accessibility is. Outside the specifics of their situation, the question was one we’ve heard many times: “How can I do this better?”
Our hearts swelled. We put our heads together and wrote this response to the person we’ve affectionately come to call the Lonely Developer. It might help you, too.
Hi Lonely Developer,
First of all, kudos to you for thinking about accessibility as you do your development work! That’s a huge step in the right direction, and always smoother sailing than retrofitting.
Simply Accessible testers and developers came up with some ideas that might help you move things forward with your team. The biggest takeaway here is that there are many things you can do as a developer to make your product more accessible. There are also things you can do to help your team, and things your team can do to support you and each other, while you support your users.
As a developer, you can:
- Embrace web standards and progressive enhancement. See what you can do with HTML/CSS/JS alone before relying on ARIA. There are often a few (or a dozen!) ways to implement the same content these days, but there’s still usually only a handful of methods that will work for literally everyone. Examine your features and go with the lowest common denominator option first (Is that element a decorative image? Then an old fashioned <img> is probably the way to go, versus a CSS content image that displays exactly the same way but doesn’t mean the same thing.).
- Prioritize a few areas as you build for maximum impact on users. These are things you can test as you build and collaborate closely with design or UX to verify, and that will have a huge impact on the user experience for people that may have dexterity and mobility issues, low-vision, and cognitive-related disabilities. These things build on that HTML/CSS/JS/ARIA pyramid mentioned previously:
- Test everything with the keyboard as you’re building, so you know it will be usable by sighted and non-sighted keyboard users.
- Include text equivalents for all informative media (images, icons, charts, videos, audio, etc.). Also, make sure you’re implementing media in ways that won’t cause unexpected feedback for non-visual users. Remember that for many users the best way to convey information is in text, so they can process it in the way that works best for them, whether it’s through just skimming and reading with their eyes, through a screen reader, a text to speech engine, refreshable braille, or through a translation service into a different language.
- Provide logical and clear forms with helpful labels, specific error messaging, and a clear path to correct problems. Forms can be challenging on a good day, so try to help your users have the best day when it comes to forms.
- Check for color contrast with an online tool like Snook’s Colour Contrast Check. Users with low vision (as well as those in bad light or with tired eyes!) appreciate being able to read content without strain.
- Turn on a screen reader, if you haven’t! We published a three-part series on integrating screen reader testing into the development process that might help integrate using a screen reader into your testing process.
- Look into automated solutions for low-hanging fruit. Offload validation and binary testing that’s easy to automate onto a tool so you can focus on testing the user experience. A computer is more efficient than you are at finding misspelled or incorrectly used attributes, and you’re better at problem solving than a validation engine.
- Check out pattern libraries like a11yproject.com. Integrate them into your own work and contribute. If your team has a pattern library, integrate shared patterns into your own library, development standards, and brand guidelines; if you don’t have a pattern library, standardizing your UI in the name of accessibility is a great reason to start one!
- Have discussions with designers when potential issues appear in handoff, before development and, even better, before client or stakeholder sign-off. Getting accessibility integrated as early in the agile process (if you’re on an agile team) makes for fewer headaches later on.
- Go to local developer or accessibility meetups and follow people in the industry on Twitter or other platforms. Even if you don’t have an accessibility meetup in your area, you can probably meet other developers interested in accessibility, who may be facing the same challenges you are. Together, you can create a support network.
As a member of your team, you can:
- Work to educate the team around you about accessibility, including the leadership team. Getting the people above you and beside you on board can help make user testing and time for R&D more of a reality.
- Encourage collaboration within your team so that accessibility is part of the entire process. Accessibility is not an engineering problem–it’s a human interaction problem. Making one person responsible for it doesn’t scale.
- Organize accessibility learning sessions with team members. These don’t have to be long or elaborate. For example, take an hour or so over lunch to talk about keyboard accessibility; go through one of your products with the keyboard alone, as a group. Seeing a potential problem firsthand goes a long way toward helping designers, product owners, and other stakeholders understand accessibility in context.
- Find allies in your organization. Use those learning sessions and collaborative exercises to find other people who are interested and invested in accessibility. Those allies may be in places you don’t expect, and may be on teams you don’t normally work with.
- Talk to your product owner or project manager about including people with disabilities in your QA cycle. Short, paid studies to look at specific, high-value activities with a handful of people with disabilities can go a long way toward gut-checking your work and making improvements that benefit everyone. Find local advocacy organizations for people with disabilities if you’re not sure how to contact potential participants.
- Consider ways to create a more inclusive work space and encourage hiring with diversity in mind. This isn’t something you can do alone, but taking inclusivity to heart helps organizations put accessibility work into context.
Don’t give up! It can feel frustrating at times and the accessibility learning curve has a lot of friction. You aren’t alone in this, even if it feels like you are sometimes. We hope some of these suggestions will help you feel like you’re a member of the accessibility family (because you are). Your users (and we!) thank you.
What tip do you find most helpful? Have you discovered any other ways to be successful within your organization? We’d love to hear about it in the comments below.