What are some lessons you have learned from either implementing a11y or fixing a11y issues? I would love to hear about unexpected and unintuitive a11y problems that you may have come across when developing.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (2)
I started building a design system for a large, enterprise company ~2.5 years ago. Accessibility is part of the foundation of all of our work. Before I started here I'd done some a11y work but didn't really understand it all that well... I thought it was just about adding aria-labels and alt tags to elements that were purely visual. Since then I've learned a lot of things, some obvious and some surprising:
Consider each a11y user type
When you approach a problem, think hard about the different kinds of a11y users you are targeting. The big breakdown here is between non-visual users who interact via screen readers (SR) and visually impaired or motor-impaired users who interact via keyboard. Take truncated text as an example. Users should be able to see the full text in some way. You could add a tooltip that appears on mouseover for mouse users and an aria-label with the full text for SR users. But you'll still need to add the text or something to the tab order for keyboard users to reach it and show the tooltip.
Don't confuse a11y with i18n
Internationalization (i18n) has some overlap with a11y, but lumping these problems together isn't helpful most of the time. And its usually a sign of an engineering or product strategy that respects English-speaking, visual/motor-abled users while lumping everyone else into the group "shrug, I guess we have to support them too".
a11y should drive visual/UX, not the other way around
Sometimes solutions from visual or UX designers that don't consider a11y during the beginning of their process just can't be made accessible. Or doing so would be so cost prohibitive that it doesn't make sense. That's not an "a11y problem" or an "a11y users are hard to support" problem. That's a problem with the design and the process that created it. Consider that there are many complex applications in the real world that are accessible and likely do some equally difficult things compared to your application. If Microsoft, Salesforce, Apple, and Adobe can make accessible applications on web/desktop/mobile you can too.
Don't design a totally different experience for the SR
SR users often want to talk to visual users of the same product to give and get advice. They want to read support documentation and tutorials. They want to call into support to get help. When you create a totally different experience for them vs. visual users you'll make it harder for them to do all these things. For example, if you have complex interactive widgets, don't just use aria tags or other solutions to replace them for non-visual users with hidden tables or paragraphs of descriptive text. Make the widgets work for visual and SR users.
Don't help the SR too much
Don't add additional aria-labels or other ".screen-reader-only" text all over the place unless you have a good reason to do so. Being overly helpful and adding tons of extra descriptive text can lead to the SR announcing an endless stream of introductory information, often over and over, before the user gets to the task or content they care about. Write semantic HTML (or JSX) — that's your main course. Only sprinkle on additional SR targeted content as a light seasoning.
Don't invent new SR/keyboard patterns
Imagine if every app or site you used had a set of hidden keyboard shortcuts that provided the only way to navigate through pages. Even if those were documented somewhere obvious, it'd still be really annoying to read the docs every time you changed apps, or even changed pages in the app. We have common metaphors in web design for navigation like hamburger buttons and tabbed menus that aren't perfect but at least create some consistency and allow users to apply what they've learned elsewhere to new apps. When you invent cool new shortcuts for keyboard users that they must learn to interact with your app (rather than just making tab/enter/space/arrow work as expected) or cool new patterns for SR users that you don't think anyone else has done before — stop. Those aren't good things. Don't innovate. Just make it work the way WAI-ARIA or WCAG examples do. Or the way other popular apps work.
Good luck!
Making apps accessible — not just legally accessible, but actually accessible in a way users can succeed at all tasks — isn't easy. It isn't cheap. But it is important. A lot of it is learning browser quirks, showing things to users and feeling their frustrations, and taking the time to get it right even if it pushes the feature out a bit. You'll get there though. Just keep at it.
Thank you for this awesome, comprehensive reply! I agree with you that a11y should drive the design of a new feature or app. It helps with creating less tech debt if your site gets audited and you have a bunch of a11y violations.