I work on a product for higher-ed clients, and this has deeply impacted my team over the last two years. The process has been really tedious and painful for everyone involved: developers, product folks, management, and the users.
University admins send us automated third party a11y reports constantly, demanding that we make all of the recommended fixes immediately. We learned really quickly that several of these reports are very opinionated about how to implement ARIA tags, sometimes in ways that contradict the documentation. It can be hard to explain this to a customer trying to protect themselves legally.
In addition, screenreader apps are implemented inconsistently, and reproducing/debugging the screenreader bug in your app can be really infuriating. I felt truly horrible for people who use them on a daily basis because it's an utterly prehistoric experience compared to using the web normally.
The last thing is that we've had issues with getting a11y right with our front end frameworks at times to address these screenreader bugs.
Ultimately, a11y is so painful and costly for us to get right that it takes up a major chunk of our development efforts these days, and we all hate working on them.
The state of developing and maintaining accessible web applications feels like a sad joke given the industry's mantra to make the world a better, more connected place.
I empathize. My last job was with a university that got tagged with a lawsuit threat around the time I started. Accessibility stories eventually dominated our backlog. I appreciated being able to improve accessibility. But the lack of consistent standards and the legal department's lazy and inflexible response to the issue were demoralizing.
One of the first things I did in my next position was to bring on a Site Accessibility Engineer (I think I made that term up) to get out in front of issues like this. She was a graduate of a developer bootcamp with past experience assisting people with real-world accessibility issues. She's been invaluable.
"She was a graduate of a developer bootcamp with past experience assisting people with real-world accessibility issues."
That's one of the best "boot camp" use cases I've ever heard. An accessibility engineer like that doesn't necessarily need to be able to actually code up a backend with a database, etc, but is going to be greatly handicapped if they literally know nothing about the web and can't even show off a prototyped-up page with the new markup they are proposing. They don't need a full "computer science" education, a boot camp is a perfect bootstrap. (I'd still say there's things yet to learn, but when isn't that true?)
Sure, but where do they get their second tech job? Site accessibility engineer is not a common job title/position that I know of. Without some of those skills you mention, if not the corresponding formal education, that seems like this person is set up to fail soon, unless companies really start taking accessibility seriously in the next few years.
I dunno; if they're like most developers I know, they'll end up picking up a hodgepodge of skills that they missed in the bootcamp, which will let them plump out their resume.
If they can't figure out how to write their resume after they've had the experience, I don't feel too bad for them.
Accessibility consulting pays bonkers money these days due to the demand; even the a11y places like Deque and Usablenet are being asked for on-site a11y practitioners and they can’t find enough of them to refer companies to.
From reading the other comments in this thread, it seems that companies are starting to take accessibility seriously, and an experienced site accessibility engineer will not have any issues getting another job.
You might want to put her on a certification track (of which there are legit and respected certs out there now). Gomez v GNC highlighted the need for someone that could be pointed to as an actual expert on Accessibility on staff.
I don't see how implementing accessibility isn't a nuance. Not only do most people, including engineers, not even notice accessibility features, but they're a minor detail in how a web application functions. What do you think a "nuance" is?
Besides, it doesn't matter whether it's a nuance, because apparently most engineers aren't competent in implementing accessibility. I'd rather that people who specialize in it can get paid to do it right instead of believe in a fantasy that engineers are going to going to care enough to do it themselves.
IMO the problem is that web development education is often very informal, if not just straight up on the job. A lot of accessibility is to make links <a>, buttons <button>, tables <table>, lists <ul> or <ol>, etc. Append alt text as needed.
The problems come up when people see default <button> styling and then go off and make it a <div> instead. Nobody really teaches why this is a bad thing, you certainly won't find it in some random web tutorial on a blog from Google search. But if enough kludges like this happens in a code base it becomes pervasive tech debt in lots of tiny places, which is possibly the worst kind of tech debt.
I don't think it's impossible to educate engineers to do this, the problem is that we don't really educate about web development in the first place.
This is technically correct, but developers often code websites and applications facing the public, at which point you do come under the auspices of US case law (since websites are not explicitly covered by ADA), and UK legislation, to start with a few jurisdictions.
Does every developer face the law? Or just the companies putting material out there?
This really isn't a matter for developers to take on themselves. It is a matter of product development and feature selection.
So many people on here talking like they just "just do it right" and it's no more difficult to make the site accessible than it is to make the site at all. It is something which needs to planned an budgeted for.
It can get expensive. Especially when the development of the site is speculative and you don't know beforehand what it is going to look like in. Iterating over works in progress and maintaining accessibility along the way can be a real pain.
If it was as easy as everyone says, then most websites wouldn't be downright crap when it comes to accessibility. Most engineers are either too incompetent to implement it or it's too hard, or both. It's probably a mix of both. Either way, just wishing that people just do a better job just isn't going to happen. Paying people to do one job really well is probably a better way forward.
Hell, I can take the argument against this and apply it to things like QA. Why exactly can't engineers just do what QA would do themselves? Why not make all engineers devops? After all, shouldn't they understand the entire system from end to end? The answer is they can't, because the more skills you expect an individual to have, the more likely they're going to suck at everything they do.
It's easy to do when you implement. Links should be links. Buttons should be buttons. Lists should be lists. And so forth.
The problem IMO is that a lot of people see the default styling of, say, a button, and go 'screw that' and make a div do the work of a button instead of trying to override browser button styling. A fair amount of people learn web development very informally, and in my experience very few tutorials or education sources actually talk about accessibility other than as something that sounds like something nice to have. So they don't know why doing this is bad, or they don't think it's a huge problem.
And it's very easy to do these small little accessibility kludges instead of modifying default behavior, and you don't realize what the cost of that is until lots of kludges later you get slapped with a lawsuit. If you're on a team prioritizing composability, this isn't necessarily very difficult to fix, but for websites that exist pre-composable frameworks and use a hodgepodge of older technologically, this is actually very difficult, especially since many of the people who wrote the original logic are probably gone and the code probably isn't commented sufficiently.
Accessibility is just another form of tech debt. I don't know of any places that would hire a tech debt specialist.
I spent a while working at an accessibility company, and while I was there, worked on two separate things:
1. Remediating customers' sites that were inaccessible. (Which, btw, for all the "ambulance chaser" comments: Something like 100% of our customers were working with us because they had been sued; none of them were doing so because they had a sincere commitment to accessibility, so there's a reason these lawsuits happen.)
2. Developing our own web-based software, which obviously had to be fully-accessible from minute one, both because a large fraction of the people using it would be blind, and because obviously it had to be, come on.
Making changes to customers' sites was deeply, deeply painful, as we tried to work around fundamentally inaccessible designs and make things as close to acceptable as we could, given the reality of what we had to work with. Everything that the parent comment says here was 100% true.
Building our own software to be fully accessible, on the other hand, added some extra effort (largely around manual testing, since automated testing can only take you so far), but we're talking about like... 10%? If you have a dev team that's been trained on a11y and is committed to producing an accessible product, it's not super-hard to make that happen. That basically no dev teams work this way says nothing good about our industry.
IMO, if you start off with sane good practices, it's really not that difficult to work for a11y in web. Just adhering to good markup and keyboard-first navigation will get you most of the way "there", especially if the designers are aware of their constraints and designing with a11y in mind.
But reworking stuff that isn't already working around a11y is a massive pain in the ass.
So I "get" it, and I've built a lot of stuff that doens't serve every population as well as it could have if I had been more informed. But at this point, for new work it doesn't feel like much of a burden at all, any more than using git or linters or whatever other stuff we do because it's a helpful practice.
I'm in the same boat, but I'm just a contract web developer for a college within a public university. Turns out the university now requires outside "vendors" to provide a Voluntary Product Accessibility Template [0] and they're not allowed to purchase any "products" that aren't WCAG 2.0 AA. The VPAT essentially lists every individual WCAG guideline and asks to what level your "product" is compliant. This came up because my client within the college is trying to get approval for me to make some updates to the site (which I built for them 4 years ago, taking pains for accessibility before they even had a policy about it) to align with new branding guidelines which are also being imposed from above by the university.
I've tried to argue that the VPAT doesn't make any sense because they're not buying a "product" from me, they're paying me to do original work, so if anything they should provide me a VPAT as a form of specification. But the feedback I'm getting is that I should essentially pretend that the "product" is the entire website (including all the content added by college staff over the years), which means I'm supposed to essentially audit every page against the VPAT, or lie and say I did (which I would never do).
My only remaining tack is to appeal to the undue burden they're imposing on my small business.
Never mind that the website I built for the college is demonstrably more accessible than that of the university itself.
If they could ask anyone to update the site because they host it and it belongs to them, you're right, you shouldn't have to provide a VPAT.
However, they should include in any new contract for contract work that the end result be accessible according to their standards (WCAG 2.0 AA). A VPAT could be used as a template for documenting the accessibility of the newly completed work but there are better options. If they wanted documentation of the accessibility of the existing site, before you make any changes, and they wanted it in VPAT format, again, there are better tools but that should be considered separate, additional work.
> The state of developing and maintaining accessible web applications feels like a sad joke given the industry's mantra to make the world a better, more connected place.
this also feels true of most of the industry's business models.
but yeah, the mantra's just a mantra. i think lots of people repeat that and think it sounds like a good goal, but they never really examine whether they're contributing to it. people can bullshit themselves pretty easily. and a lot of other folks just pay lip service to that mantra so they can make money.
> Ultimately, a11y is so painful and costly for us to get right that it takes up a major chunk of our development efforts these days, and we all hate working on them.
Honestly, I expect this question would be difficult to answer in short time or without context. I think it'd be good discussion subject for a blog post. But: what are some examples of the pain and what would you change to simplify?
Not OP, but have done two large site UX overhauls in recent history, and my team/company takes accessibility _very_ seriously.
The biggest pain point for me has been the lack of a "Ground Truth" static-analysis-esque tool. We're provided some accessibility-issue-highlighting tooling, and there are some open source as well, but it's very common to get a11y tickets where the tool won't pick up the underlying issue, or will say "there's an issue" but not what the correct threshold is for fixing it (e.g. border contrast/density) so there's a bit of trial and error in there too.
If we had something similar to the "green squiggles" in IDEs, with, in my perfect world, the "right click->see suggestions ->auto-fix" flow that I can now get in code, addressing these issues would be SIGNIFICANTLY similar.
This is only one facet however, although it brushes against other issues in this space (inconsistent behavior of screen readers, occasionally not having sufficient specialized hardware to even test the scenario fully, often having to "negotiate" accessibility fixes with the designers who gave the original layouts, etc.)
Also, a final thing that I'm always curious is "just me" or not, but tab-ordering-fixes have seemed far more painful to handle (in dynamic/scalable layout scenarios) than I would have thought going in. The two options I know of for dealing with it are "assign the order" and "adjust your HTML/Z" layout, and the former is a very blunt hammer while the latter sometimes seems to be at odds with other requirements of the layout. (but this could very well be my naivete in frontend, thus this ramble)
Agreed. I've been happy to see aXe getting more visibility so it's easy to do at least the basic smoke testing similarly to other kinds of static analysis but it's definitely an area which is open for much greater improvement.
Getting things to be accessible (in practice: not just what some tool spits out in a report, but making the app/site useful to a real user with disabilities using a real browser of some sort) is not that bad as long as everyone's on board (if the designer wants everything drag & drop in red and green tones, you're kind of screwed).
Catering to screen readers is hard for the same reason supporting any non-60%+ user base browser is (uncommon mobile browsers, IE, whatever). All browsers have bugs and quirks, and having less eyes on things makes finding bugs hard. Debugging in a browser you don't use as frequently is always going to be significantly more challenging. When its not a "standard" one, it can be hell.
As another poster mentioned, a lot of the automated tools spit out a lot of false positives, and that adds to the burden.
I went to the A11y page to see what it was. Ironically, the single largest answer on their Learn More[1] page is them explaining what "A11y" even means. I'm trying not to draw sweeping conclusions about the project from this, but damn that's a bad start.
I'm not who you replied to, but as someone unfamiliar with the term "a11y", I googled it while reading these comments and the very first hit is https://a11yproject.com/ which I, too, assumed was "the a11y page" -- and after briefly looking at that page again just now, I'm still not convinced that it shouldn't be considered the canonical "a11y page". I now get that "a11y" is a numeronym for "accessibility", but considering I haven't heard it called "a11y" before today, a page calling itself The A11Y Project sounds both fairly authoritative and like it potentially could have been the source of the a11y numeronym. If it's not, it really could use some more explanation on that page.
> The A11Y Project sounds both fairly authoritative and like it potentially could have been the source of the a11y numeronym. If it's not, it really could use some more explanation on that page.
I've now read that entire page several times, and I don't believe that the explanation is truly there. The about page does a good job of explaining why accessibility is important, what "A11Y" means, and states that The Accessibility Project's goal is essentially to further accessibility on the web. It's very easy to interpret that page as meaning/implying they originated the term "A11Y" and/or that "A11Y" is specifically related to The A11Y Project, and therefore that The A11Y Project page is the defacto "A11Y page", for someone who has not come across the numeronym "a11y" before.
But whatever... This is rather off-topic to the main point of this HN post.
Lot's of love for accessibility folks in education. Maybe a small consolation, but we just made AccessLint, our GitHub code review application free for edu's, inspired by this thread.
With that much work being required, could the case be made that goes beyond a "reasonable accommodation"? Maybe that would mean that some of the less-trafficked pages would not need tagging, though maybe the more major and commonly-accessed ones represent a reasonable accommodation.
Indeed. My business is currently being targeted by these ambulance-chasers, but we are not a college with a well-staffed IT department; we are an ecommerce business with a single front-end developer on staff.
First off, his eCommerce business might be some custom software app, not an online store or informational website. So being "knee deep in frameworks" might be necessary for his business.
That said, the ADA is all about accommodating disabled persons within reason. Depending on the scope and functionality of his software, fully supporting such with a single developer on staff MIGHT be an undue burden - it all depends on the specifics of the situation and we don't know his.
Notice the usage of "Undue Burden" from the official ADA documentation below.
"The rules are also flexible for communicating effectively with customers who are blind or have low vision. For example, a restaurant can put its menu on an audio cassette or a waiter can read it to a patron. A sales clerk can find items and read their labels. In more complex transactions where a significant amount of printed information is involved, providing alternate formats will be necessary, unless doing so is an undue burden."
"It is a business's responsibility to provide a sign language, oral interpreter, or VRI service unless doing so in a particular situation would result in an undue burden, which means significant difficulty or expense. A business's overall resources determine (rather than a comparison to the fees paid by the customer needing the interpreter) what constitutes an undue burden."
I would say it's more similar to distributing menus without braille translations.
It's also very possibly their developer is woefully overworked, and what may amount to 'minimal effort' for you, could be outside the scope of what they have the time to accomplish.
> It’s no different than a restaurant server delivering shitty service to a black family because they stereotyped that people with kids and black people tip less.
Come on now. Stereotyping is an affirmative action, failing to consider accessibility is passive / apathy. It's comparable to not installing a handicap ramp for your restaurant.
University admins send us automated third party a11y reports constantly, demanding that we make all of the recommended fixes immediately. We learned really quickly that several of these reports are very opinionated about how to implement ARIA tags, sometimes in ways that contradict the documentation. It can be hard to explain this to a customer trying to protect themselves legally.
In addition, screenreader apps are implemented inconsistently, and reproducing/debugging the screenreader bug in your app can be really infuriating. I felt truly horrible for people who use them on a daily basis because it's an utterly prehistoric experience compared to using the web normally.
The last thing is that we've had issues with getting a11y right with our front end frameworks at times to address these screenreader bugs.
Ultimately, a11y is so painful and costly for us to get right that it takes up a major chunk of our development efforts these days, and we all hate working on them.
The state of developing and maintaining accessible web applications feels like a sad joke given the industry's mantra to make the world a better, more connected place.