You know that joke, “Two front-end developers walk into a bar and find they have nothing in common”? It’s funny, yet frustrating, because it’s true.
This article will present three different perspectives on accessibility in web design and development. Three perspectives that could help us bridge the great divide between users and designers/developers. It might help us find the common ground to building a better web and a better future.
![The corner of a white and blue building in focus, with white on the left and blue on the right representing the divide between developers when it comes to accessibility practices.](https://i0.wp.com/css-tricks.com/wp-content/uploads/2022/01/divide-corner-building.webp?resize=1200%2C600&ssl=1)
Act 1
“I just don’t know how developers don’t think about accessibility.”
Someone once said that to me. Let’s stop and think about it for a minute. Maybe there’s a perspective to be had.
Think about how many things you have to know as a developer to successfully build a website. In any given day, for any given job position in web development, there are the other details of web development that come up. Meaning, it’s more than “just” knowing HTML, CSS, ARIA, and JavaScript. Developers will also learn other things over the course of their careers, based on what they need to do.
This could be package management, workspaces, code generators, collaboration tools, asset loading, asset management, CDN optimizations, bundle optimizations, unit tests, integration tests, visual regression tests, browser integration tests, code reviews, linting, formatting, communication through examples, changelogs, documentation, semantic versioning, security, app deployment, package releases, rollbacks, incremental improvements, incremental testing, continuous deployments, merge management, user experience, user interaction design, typography scales, aspect ratios for responsive design, data management, and… well, the list could go on, but you get the idea.
As a developer, I consider myself to be pretty gosh darn smart for knowing how to do most these things! Stop and consider this: if you think about how many people are in the world, and compare that to how many people in the world can build websites, it’s proportionally a very small percentage. That’s kind of… cool. Incredible, even. On top of that, think about the last time you shipped code and how good that felt. “I figured out a hard thing and made it work! Ahhhhh! I feel amazing!”
That kind of emotional high is pretty great, isn’t it? It makes me smile just to think about it.
Now, imagine that an accessibility subject-matter expert comes along and essentially tells you that not only are you not particularly smart, but you have been doing things wrong for a long time.
Ouch. Suddenly you don’t feel very good. Wrong? Me?? What??? Your adrenaline can even kick in and you start to feel defensive. Time to stick up for yourself… right? Time to dig those heels.
The cognitive dissonance can even be really overwhelming. It feels bad to find out that not only are you not good at the thing you thought you were really good at doing, but you’ve also been saying, “Screw you, who cares about you anyway,” to a whole bunch of people who can’t use the websites you’ve helped build because you (accidentally or otherwise) ignored that they even existed, that you ignored users who needed something more than the cleverness you were delivering for all these years. Ow.
All things considered, it is quite understandable to me that a developer would want to put their fingers in their ears and pretend that none of this has happened at all, that they are still very clever and awesome. That the one “expert” telling you that you did it wrong is just one person. And one person is easy to ignore.
— end scene.
Act 2
“I feel like I don’t matter at all.”
This is a common refrain I hear from people who need assistive technology to use websites, but often find them unusable for any number of reasons. Maybe they can’t read the text because the website’s design has ignored color contrast. Maybe there are nested interactive elements, so they can’t even log in to do things like pay a utility bill or buy essential items on their own. Maybe their favorite singer has finally set up an online shop but the user with assistive technology cannot even navigate the site because, while it might look interactive from a sighted-user’s perspective, all the buttons are divs and are not interactive with a keyboard… at all.
This frustration can boil over and spill out; the brunt of this frustration is often borne by the folks who are trying to deliver more inclusive products. The result is a negative feedback cycle; some tech folks opt out of listening because “it’s rude” (and completely missing the irony of that statement). Other tech folks struggle with the emotional weight that so often accompanies working in accessibility-focused design and development.
The thing is, these users have been ignored for so long that it can feel like they are screaming into a void. Isn’t anyone listening? Doesn’t anyone care? It seems like the only way to even be acknowledged is to demand the treatment that the law affords them! Even then, they often feel ignored and forgotten. Are lawsuits the only recourse?
It increasingly seems that being loud and militant is the only way to be heard, and even then it might be a long time before anything happens.
— end scene.
Act 3
“I know it doesn’t pass color contrast, but I feel like it’s just so restrictive on my creativity as a designer. I don’t like the way this looks, at all.”
I’ve heard this a lot across the span of my career. To some, inclusive design is not the necessary guardrail to ensure that our websites can be used by all, but rather a dampener on their creative freedom.
If you are a designer who thinks this way, please consider this: you’re not designing for yourself. This is not like physical art; while your visual design can be artistic, it’s still on the web. It’s still for the web. Web designers have a higher challenge—their artistic vision needs to be usable by everyone. Challenge yourself to move the conversation into a different space: you just haven’t found the right design yet. It’s a false choice to think that a design can either be beautiful or accessible; don’t fall into that trap.
— end scene.
Let’s re-frame the conversation
These are just three of the perspectives we could consider when it comes to digital accessibility.
We could talk about the project manager that “just wants to ship features” and says that “we can come back to accessibility later.” We could talk about the developer who jokes that “they wouldn’t use the internet if they were blind anyway,” or the one that says they will only pay attention to accessibility “once browsers make them do it.”
We could, but we don’t really need to. We know how these these conversations go, because many of us have lived these experiences. The project never gets retrofitted. The company pays once to develop the product, then pays for an accessibility audit, then pays for the re-write after the audit shows that a retrofit is going to be more costly than building something new. We know the developer who insists they should only be forced to do something if the browser otherwise disallows it, and that they are unlikely to be convinced that the inclusive architecture of their code is not only beneficial, but necessary.
So what should we be talking about, then?
We need to acknowledge that designers and developers need to be learning about accessibility much sooner in their careers. I think of it with this analogy: Imagine you’ve learned a foreign language, but you only learned that language’s slang. Your words are technically correct, but there are a lot of native speakers of that language who will never be able to understand you. JavaScript-first web developers are often technically correct from a JavaScript perspective, but they also frequently create solutions that leave out a whole lotta people in the end.
How do we correct for this? I’m going to be resolute here, as we all must be. We need to make sure that any documentation we produce includes accessible code samples. Designs must contain accessible annotations. Our conference talks must include accessibility. The cool fun toys we make to make our lives easier? They must be accessible, and there must be no excuse for anything less This becomes our new minimum-viable product for anything related to the web.
But what about the code that already exists? What about the thousands of articles already written, talks already given, libraries already produced? How do we get past that? Even as I write this article for CSS-Tricks, I think about all of the articles I’ve read and the disappointment I’ve felt when I knew the end result was inaccessible. Or the really fun code-generating tools that don’t produce accessible code. Or the popular CSS frameworks that fail to consider tab order or color contrast. Do I want all of those people to feel bad, or be punished somehow?
Nope. Not even remotely. Nothing good comes from that kind of thinking. The good comes from the places we already know—compassion and curiosity.
We approach this with compassion and curiosity, because these are sustainable ways to improve. We will never improve if we wallow in the guilt of past actions, berating ourselves or others for ignoring accessibility for all these years. Frankly, we wouldn’t get anything done if we had to somehow pay for past ignorant actions; because yes, we did ignore it. In many ways, we still do ignore it.
Real examples: the Google Developer training teaches a lot of things, but it doesn’t teach anything more than the super basic parts of accessibility. JavaScript frameworks get so caught up in the cleverness and complexity of JavaScript that they completely forget that HTML already exists. Even then, accessibility can still take a back seat. Ember existed for about eight years before adding an accessibility-focused community group (even if they have made a lot of progress since then). React had to have a completely different router solution created. Vue hasn’t even begun to publicly address accessibility in the core framework (although there are community efforts). Accessibility engineers have been begging for inert
to be implemented in browsers natively, but it often is underfunded and de-prioritized.
But we are technologists and artists, so our curiosity wins when we read interesting articles about how the accessibility object model and how our code can be translated by operating systems and fed into assistive technology. That’s pretty cool. After all, writing machine code so it can talk to another machine is probably more of what we imagined we’d be doing, right?
The thing is, we can only start to be compassionate toward other people once we are able to be compassionate toward ourselves. Sure, we messed up—but we don’t have to stay ignorant. Think about that time you debugged your code for hours and hours and it ended up being a typo or a missing semicolon. Do you still beat yourself up over that? No, you developed compassion through logical thinking. Think about the junior developer that started to be discouraged, and how you motivated them to keep trying and that we all have good days and bad. That’s compassion.
Here’s the cool part: not only do we have the technology, we are literally the ones that can fix it. We can get up and try to do better tomorrow. We can make some time to read about accessibility, and keep reading about it every day until we know it just as well as we do other things. It will be hard at first, just like the first time we tried… writing tests. Writing CSS. Working with that one API that is forever burned in our memory. But with repetition and practice, we got better. It got easier.
Logically, we know we can learn hard things; we have already learned hard things, time and time again. This is the life and the career we signed up for. This is what gets us out of bed every morning. We love challenges and we love figuring them out. We are totally here for this.
What can we do? Here are some action steps.
Perhaps I have lost some readers by this point. But, if you’ve gotten this far, maybe you’re asking, “Melanie, you’ve convinced me, but what can I do right now?” I will give you two lists to empower you to take action by giving you a place to start.
Compassionately improve yourself:
- Start following some folks with disabilities who are on social media with the goal of learning from their experiences. Listen to what they have to say. Don’t argue with them. Don’t tone police them. Listen to what they are trying to tell you. Maybe it won’t always come out in the way you’d prefer, but listen anyway.
- Retro-fit your knowledge. Try to start writing your next component with HTML first, then add functionality with JavaScript. Learn what you get for free from HTML and the browser. Take some courses that are focused on accessibility for engineers. Invest in your own improvement for the sake of improving your craft.
- Turn on a screen reader. Learn how it works. Figure out the settings—how do you turn on a text-only version? How do you change the voice? How do you make it stop talking, or make it talk faster? How do you browse by headings? How do you get a list of links? What are the keyboard shortcuts?
Bonus Challenge: Try your hand at building some accessibility-related tooling. Check out A11y Automation Tracker, an open source project that intends to track what automation could exist, but just hasn’t been created yet.
Incrementally improve your code
There are critical blockers that stop people from using your website. Don’t stop and feel bad about them; propel yourself into action and make your code even better than it was before.
Here are some of the worst ones:
- Nested interactive elements. Like putting a button inside of a link. Or another button inside of a button.
- Missing labels on input fields (or non-associated labels)
- Keyboard traps stop your users in their tracks. Learn what they are and how to avoid them.
- Are the images on your site important for users? Do they have the
alt
attribute with a meaningful value? - Are there empty links on your site? Did you use a link when you should have used a button?
Suggestion: Read through the checklist on The A11y Project. It’s by no means exhaustive, but it will get you started.
And you know what? A good place to start is exactly where you are. A good time to start? Today.
Featured header photo by Scott Rodgerson on Unsplash
The same reason people don’t install wheelchair accessible ramps to their homes.
It’s more like installing accessible ramps to your business. And businesses do that, as long as the cost is proportional to the business’ size.
Regarding the “same reason people don’t install wheelchair accessible ramps in their homes” I’m not understanding the comparison or exactly how it pertains to the article? I immediately thought about how businesses “used to” not provide access such as this but have been compelled by the law and because enough citizens feel that they must despite the costs incurred. Still inadequate but I think a much fairer comparison.
I don’t know th ins and outs of 508, exactly who’s been sued of late, but I’m going to continue to take it upon myself to double check my use of HTML and aria and learn and hopefully improve my code and make it more accessible. I will make some mistakes and I think it’s fine if I’m willing to iterate and improve and learn.
Another comparison might be asking a PM for time to add tests or do QA. Depending on the organization you can get very different responses. At a certain point you have to give yourself the grace and self respect to decide you know what is best as the expert in the topic. Just add tests. Just audit your own code for a11y as you see fit. It’s part of being a pro yah?!
Regarding the article I enjoyed the persuasiveness even if we had to belabor the point a bit I guess it’s aligned with the point that folks are militant because the community has failed them for so long! Agreed.
It’s also interesting to consider which of the popular FE frameworks is making it easier or harder to properly implement an accessible component? How come I have to keep implementing keyboard navigation for the gazillionth time frameworks? Or find a third party hook or module, audit it, figure out how to make it work?
Unless they had routine visits from people who need wheelchair ramps to get around. The difference is most homes are privately accessible and for those with access, a wheelchair ramp may not be necessary. However, nearly all websites are, to some degree, publicly accessible. Even those with a public facing authentication page and everything else locked away behind it. There is no reason to not make things that are publicly accessible as truly publicly accessible as possible even if it is only to tell someone that they aren’t supposed to be here without proper credentials, provide them with a useful means to request assistance, point them in a different direction, etc.
not the same. Websites are a publicly accessible service and therefore should be accessible to everyone on equal basis. By choosing to ignore accessibility, you’re saying that disabled people don’t matter.
BTW, installing wheelchair ramps at home is a thing. Every person I’ve known in a wheelchair has had a ramp added onto their house. They are most commonly made out of aluminum and are quite noticeable when you drive by the property.
The title of this article, “Why Don’t Developers Take Accessibility Seriously?” is a blanket assumption in the form of a negative accusation.
I think this kind of toxicity perfectly illustrates why developers aren’t more welcoming of the accessibility movement. Imagine how popular other technologies and paradigms would be if they promoted themselves through emotional hostility: “You don’t use Rust because you don’t care about disabled people and you’re egotistical. Here’s why you should care about Rust and why it’s faster it’s faster than PHP.”
Every serious front-end developer cares about accessibility, it’s the U (User) in UI. Many of those tools that the author mentions in the beginning exist for the purpose of supporting older browsers and keeping the code payload small. (They work for CSS, HTML and images too. Not everything is about JavaScript.) We use these in conjunction with newer language specifications and other tooling because they increase the robustness of our code, leading to more stable and scalable user interfaces, which is more beneficial for everyone.
If there is disparity over accessibility in the industry, I think it’s based around HOW to make UIs more accessible, not IF they should be. Minimalism isn’t always the best approach, even if it’s the easiest for beginners to master. A static HTML file might seem more accessible from a bird’s eye view, but if it fails to communicate the intended concept to the user or if the user fails to retain that concept for future use, then the page has failed from a human centric standpoint. Engaging interfaces have their purpose.
There’s some good advice at the end of this article, but I think it would have been more productive to frame it from a technical standpoint than an emotional one.
Yes, I was thinking the same thing. I’m a developer myself, wrote lots of code for decades, but the last 15 years I’ve been focused 100% on accessibility and helping other developers, designers, and testers understand what it is and how to design and implement it. The key is how accessibility is presented. Unfortunately, there are lots of a11y people that approach it with the “you’re doing it wrong” attitude. That’s vinegar, not honey. Perhaps because I’m a developer myself, I have great success with other devs learning about a11y. All developers want their code to be used – that’s the point of writing it. So all developers I’ve come across are very appreciated of accessibility tips that helps their code to be used by more people.
These are all awesome suggestions, but I think it’s missing 1 critical part to the equation.
What’s missing in all this is the browsers role.
If you take a snapshot of the current situation, you’ll realize that easily 90% of the basic accessibility problems are entirely the browsers fault.
We, as developers, are forced to build our own solutions for things like
<select>
,, etc. Why? Because they can't be styled entirely the way we need them to. You also have new stuff like
that should have solved many problems, but has so many accessibility problems and coherence between browsers that we simply can't use them. We'd also like a workable
` please…As long as those trillion(s) market cap companies like Apple, Google and Microsoft don’t do the bare minimum to solve those issues, you won’t make a dent in accessibility on the web.
Apple is willingly dragging their feet and pulling everyone down because their business model encourage the use of apps over using the browser.
Google, while trying its best to educate developers about accessibility, is shoveling the whole mountain of responsibilities down on our backs… And most of their business products are atrocious UX wise and accessibility wise…
The war starts at the very root. Once these issues are fixed, it will trickle down to libraries. Once it’s solved there too, you can bet most of the accessibility problems on the web will already have been taken care of.
And when all of that is done, the burden on developers should be magnitudes lighter. We won’t approach accessibility with a “yet another mountain of responsibilities on our backs” attitude, but with a “sure thing, I can fix this easily for you”.
as user with a disability and uses speech recognition, I can tell you it’s not the browser. It’s all the blankety-blank blank JavaScript magic that gets in the way.
Nuance has a plug-in for all browsers that speech enables many things about a webpage. Personally, I mostly focused on dictating into an editing text in a text box. If there is no JavaScript getting in the way, it works just fine. But add JavaScript to change how text is entered into the text area, speech recognition fails.
hotkeys are another failure mode. If you can press a key which initiates an action, you can totally screw up your environment by dictating when focuses on the application and not in a field. You can simulate this by closing your eyes and hitting random keys. Extra points if you can figure out what happened to your data.
Leading up to the 2000 Olympics in Sydney a vision impaired bloke sued the Olympics Committee (and won) for not being able to access the website to buy tickets. The website was not rebuilt but from then on Australian Government websites all had mandatory requirements for web accessibility that has continued to this day.
It’s a real shame that over two decades later we’re still having this same conversation for the ‘commercial’ internet, that for all the advancements in internet technology developers are still neglecting the very simple guidelines of web accessibility.
The WAVE Web Accessibility Evaulation Tool (https://wave.webaim.org/extension/) is a great tool because it tells you what you’re doing right as well as what you’re doing wrong. This helps because it’s encouraging you rather than just telling you what you’re doing wrong. You can also turn off styles on the fly to see how your content is presented without layouts, which can be a great help in helping people understanding the value of using semantic HTML elements for content presentation.
Anyway, great article. I reckon the web development community needs one like it every three days until web accessibility is just second nature to developers. It really should be the first thing taught to anyone getting into the industry because the reality is it’s probably the simplest thing they’ll ever have to learn.
This is a great article but isn’t the title a bit counter-productive? If I’m a developer and I see this, it just reinforces the idea that not caring about accessibility is the norm, so there’s not a ton of pressure on me to change my practices.
I think I would’ve phrased it as “Why Not Enough Developers Take Accessibility Seriously” personally.
Fwiw, the original title was “perspectives on accessibility”
I hope folks don’t get too distracted by the title, which was crafted to get people to read it.
Dear Melanie,
I don’t think that the first act is necessarily true. Have you considered the accessibility of learning about accessibility?
I do the best I can with what I know: semantic html, React Aria, headlessui, etc.
But this stuff is hard:
– the information isn’t always up to date
– patterns are not consistent across devices
– the aria docs are dense
– many of the validators are paid, not open-source
– there are no in-depth courses I can buy to teach me everything I need to know (there are many on react, js, ts, css, and more)
Just look at all the stuff that goes into a simple card component! https://inclusive-components.design/cards/
I wish one of the many accessibility evangelists would write a definitive guide. I’d follow it religiously. So many of them are just saying how much it matters and giving little breadcrumbs of intro tips. Speaking of, I do appreciate your checklist link https://www.a11yproject.com/checklist/ I will add that to my toolbox. You say “Take some courses that are focused on accessibility for engineers”—Please, don’t tell me to do something without actually telling me how. Which courses? I want to take them.
Accessibility is important. Accessibility should be by default. When it’s hard to learn accessibility, even harder to tell if you’re doing it right and automatically test for it, and the client wants it shipped yesterday, what options do I really have?
Anyway, thank you for writing this post. This comment is intended as constructive criticism. Please send me your suggestions.
P.S.
I used to do design too. I’ve never met anyone who intentionally makes anything inaccessible. I do use plugins to check those values, but even those don’t catch everything. It’s just another design constraint of the web medium.
One of the things I discovered very quickly was that every screen reader works a little differently. They’re like pre-HTML5 browsers; each has its own interpretation of the standard. As a free app developer I couldn’t afford to test on every one of them, and they’re also intentionally designed so you can’t tell which is in use (or even IF one is in use.) This makes for a pretty tough challenge for small-time devs.
One difficulty developers face are Clients that do not like the way some site elements, that are designed to be accessibility friendly, are interacted with. One wanted a dropdown menu to open submenus on hover only, and for the opening link to have a destination page rather than act as a button that toggles the submenu visibility. The rationale took 2 parts: 1, that this was how it was done (in his opinion) and 2, that his view of the users of the website was that no one that visited the website would need to use a click-actuated sticky dropdown menu. Another issue was he didn’t want to see keyboard focus indicators anywhere.
It’s a shame, really.
So, as a developer who needs to work to make money, who is doing work for a paying Client who pays 100% of the time, and on-time, what can I do when every request to work from the start with an eye for accessibility is ignored or rebuffed?
I do as much as I can for accessibility that doesn’t interfere with the Client’s “vision” of the way the website is supposed to be.
And this is a shame, too.
Completely agree! How often I am told that colors with sufficient contrast “do not match the brand”
That’s terrible. I don’t have a serious disability, but as someone with an essential tremor hover-only nested menus are my nemesis.
Speaking specifically of the hover to expand the sub-menu, this very challenge is actually able to be accomplished. It does however take some prudent understanding and thinking outside the box. The end result is more code to ensure everything works.
I would simply suggest to the client that you can meet their needs, however do to the nature of those same changes, some extra hours will be needed to ensure accessibility remains working as expected. This also leads into the focus related request, which I would clearly indicate that I will not remove this as it is a standard requirement. At this point you will need to negotiate a suitable solution but ensuring they understand the importance of the focus role becomes how to go about solving the issue.
Mostly the more we understand what changes and work needs to happen to meet various requirements, the better we can manage a client’s expectations. Until you make this clear in simple language your client can understand, you should assume they have no working knowledge. If they do know, then at the least they are taking accountability for the end results and you made it clear, in the even it was an oversight.
One advantage of good accessibility is that it can easily be demonstrated to reveal the importance of certain types of changes. Focus is one such element.
Encouraging article, thanks for writing in such a constructive way! In particular I’ll be taking away the idea of the minimum-viable product being accessible.
I’m a developer and I take accessibility seriously and I was in no way offended by the title :D …
… because it’s true. I worked for years in a company where it was a constant fight to get ANYONE to take accessibility seriously. We need to find constructive ways to address the situation. Thanks again.
Real World example:
When my Projectmanagers see the finished website it is done. Move on to the next project. There is no time allocated for accessibility because it doesn’t exist visualy to project managers. In my experience accessibility doubles dev time. No manager is waving this trough. It comes down to money, sorry thats jsut how managers think.
So yeah, I pass the blame partially along to clients and managers.
Plus learning about accessibility is brutally hard. The information is scatered accross the web and everybody is saying you should do accessibility but nobody is talking about where to learn this stuff. There are diffrent pretty incomplete standards which counteract each other at times.
I’m sorry but it really starts to piss me of how everybody is virtue-signaling accessibility but then follow up with nothing. It’s easy to write such hit pieces. Better invest your time in documentation about accesibility, but that would mean hard work.
Sorry to vent here, but articles like that contribute nothing.
In my experience, the only reason accessibility would double dev time is because a company hired too many “full stack” devs to do front-end jobs. While HTML is the core foundation of the web, most developers are JavaScript-first who consider HTML not real coding. If you want to blame managers, blame them for their inability to hire the right talents, not that they only care about money.
If you want to debate about money, lawsuits and losing out on good clients are more costly than hiring a team of real front-end devs to write good code to begin with.
Here are some resources, I personally find helpful:
Written Guides:
– https://web.dev/accessible/
– https://developer.mozilla.org/en-US/docs/Web/Accessibility
– https://developers.google.com/web/fundamentals/accessibility/
– https://www.accessibility-developer-guide.com/
– https://www.smashingmagazine.com/2021/03/complete-guide-accessible-front-end-components/
Videos and Online Workshops:
– https://www.udacity.com/course/web-accessibility–ud891
– https://youtube.com/playlist?list=PLNYkxOF6rcICWx0C9LVWWVqvHlYJyqw7g
– https://smashingconf.com/online-workshops/
Other suggestions:
– https://www.a11yproject.com/resources/#courses
Of course it’s hard, as is almost everything you have to learn in frontend development. But as the author already said:
“It will be hard at first, just like the first time we tried… writing tests. Writing CSS. Working with that one API that is forever burned in our memory. But with repetition and practice, we got better. It got easier.
Logically, we know we can learn hard things; we have already learned hard things, time and time again. This is the life and the career we signed up for. This is what gets us out of bed every morning. We love challenges and we love figuring them out. We are totally here for this.”
Hope this helps, happy learning! :)
This is such a wonderfully written article!
Great post! I especially like how you acknowledge that for developers, accessibility is just one area of knowledge they’re expected to have, and that it isn’t taught well (or at all) at most of the places teaching people front-end web development. We do need to start at the source of the problem by making it a proper subject taught comprehensively.
That said, in the comments some people are saying that accessibility is hard to learn. I’ve got to push back on that – it’s not hard or time consuming compared to learning React, or how to balance performance with features, or keeping up with the newest browser changes. Developers learn difficult things on the job all the time. We have a responsibility to do the right thing, the same way we do with privacy and security.
Great article, and I agree with the several comments that learning how to make a site accessible isn’t very accessible.
As a retired full stack developer, I wrestled with accessibility a lot and never felt I was very good at it. But a lot of the time my feeling was “why are screen readers so stupid, and why do they need so much help and hand holding in order to work?”
I still wonder this, so I’d add that in addition to browsers needing to be better at standardizing accessibility support, maybe screen readers that don’t read the DOM so much as interpret its display would help.
The article and the comments have to narrow focus on what what accessibility means. There are more disabilities than visual ones. Mobility problems alone range from the profoundly disabled quadriplegic to chronic pain and loss of fine motor control in the hands like I have. People like us use speech recognition as our accessibility tool.
A11y says nothing about speech enabling an application. Nuance is fighting a losing battle because of all the fine JavaScript magic toolkits used to modify the appearance and action of text areas. Electron is one of the worst offenders in this area.
The three main problems speech recognition users encounter is JavaScript interference with text input, hotkeys and use of GUI toolkits that bypass built-in speech accessibility hooks.
JavaScript interference frequently breaks text input by not allowing it at all, dropping characters, doubling characters, entering characters but not displaying them, breaking cut-and-paste. Hotkeys break because unfocused dictation triggers commands as you speak. Think cat walking on keyboard. Nonstandard GUI toolkits frequently don’t accept input from speech recognition or, worse yet, lockup when using speech recognition so that you can no longer use the application and need to reboot your machine.
How do we fix this?
Live the life of the disabled person. Wear a blindfold and try to work and play online. Feel that frustration and urge to take off the blindfold and imagine living with that every single day and you can’t take off the blindfold.
Put your keyboard in a desk drawer or cover with a book. Use speech recognition and feel the frustrations of applications that should be accessible at least for basic dictation but aren’t.
That sense of relief when you take off the blindfold or bring your keyboard back onto the desktop, is something disabled people never feel.
Live the life and see how the world is through our experience
We always try to follow best practices. That being said using our accessibility partner adds (on average) around 80 hours to a full site build. So that is an additional $12k in build fees. And that isn’t even including the accessibility partners fees (which are substantial).
Building an accessible website isn’t just a matter of using best practices. You have to have auditors with actual disabilities. It’s expensive. And if the client isn’t paying for it, we aren’t either.
We present it to the client as an option, and if they opt-out we make them sign a waiver taking full legal responsibility if any lawsuits arise.