This content originally appeared on Ethan Marcotte’s website and was authored by Ethan Marcotte
I care pretty deeply about accessible design. I wouldn’t call myself an accessibility specialist, mind you, but I’ve always felt that “designing for the web” means ensuring our work is accessible as broadly as possible. Not just accessible to differently-sized screens, but for people who might not browse the web like I do.
Lately, I’ve been reflecting on some of the language I use to talk about accessibility—or, more specifically, to talk about the people I’m designing for. Like, I’ve spoken in the past about “screen reader users” or “users who navigate primarily by keyboard.” (Heck, maybe you have too.) And I’ve been wondering if that language is problematic, since it implicitly treats those groups as monoliths: as though every single person using a given piece of assistive technology would browse, behave, and think exactly the same. In other words, if two different people visit your site with the same speaking browser, each of those people will have their own expectations of how a website should work, and how information will be arranged.
It’s important for me to remember the people using those technologies are infinitely more diverse, more complicated than the software they use to access my work. Each time I watch an accessibility consultant conduct a site audit, I’m amazed by how a well-built site can completely break a human’s expectation for how the page should be laid out. That’s why I’ve found it’s been really, really helpful to me to break the word “accessibility” down into two related sub-components: that is, there’s a distinction between making a site navigable by assistive technology, and making it usable to the people visiting it with that technology.
Part of the reason I’ve been thinking about this is because I’ve seen more frameworks and pattern libraries tout their focus on accessibility. And just to be clear, that is fantastic to see. But I’ve been part of a few conversations recently where something like this came up:
“We don’t have to worry about accessibility. The framework we’re using takes care of it for us.”
I think this is a fairly common sentiment. After all, designing an accessible experience is difficult, especially for folks not intimately familiar with certain users’ needs. And if a piece of software says it’s “solved” the accessibility piece for a team, that’s pretty appealing.
But at best, a design pattern or framework that’s built for broad access is going to get you to navigable; it’s incumbent on us to test the product with real content, with real users, and ensure we’re putting something usable in front of them. After all, I don’t think many of us would say something like this:
“We don’t have to worry about usability. The framework we’re using takes care of it for us.”
We should treat accessibility better than that. It’s more than just another software feature.
Note: My thanks to Andy Bell and Eric Bailey for providing some truly invaluable feedback on this entry. This post was prompted by a discussion with Filament Group’s John Bender, Todd Parker, and Scott Jehl, who have taught me so danged much about accessible design.
This content originally appeared on Ethan Marcotte’s website and was authored by Ethan Marcotte
Ethan Marcotte | Sciencx (2018-08-31T04:00:00+00:00) Accessibility is not a feature.. Retrieved from https://www.scien.cx/2018/08/31/accessibility-is-not-a-feature/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.