Hacker News Reader

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.

In the worst case the same place other bootcamp graduates get their jobs.

"a boot camp is a perfect bootstrap. (I'd still say there's things yet to learn, but when isn't that true?)"

Shouldn't those skills generalize to UX/QA?

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.

IAAP Certification Tracks: https://www.accessibilityassociation.org/certification

Gomez v. GNC: https://www.levelaccess.com/federal-court-decision-gomez-v-g...

Hiring specialists should be more of a thing, rather than expecting engineers to be competent at every nuance of building web applications.

Complying with laws that have been around about as long as the web isn't some nuance.

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.

There is no law requiring anything of the sort by an individual developer.

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.

Your experience resonates with mine.

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.

What percentage of products, in general, do you believe are “accessible”?

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.

[0] https://www.itic.org/policy/accessibility/vpat

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.

Also not OP, but...

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.

1: https://a11yproject.com/about/#what-does-the-term-a11y-mean

> I went to the A11y page

that's like saying "i went to the mathematics page". there's not an a11y page.

> I'm trying not to draw sweeping conclusions about the project from this...

you went to the page of some small community effort.

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.

The explanation is on the about 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.

Ha, I know what you mean. I’ve been designing building accessible websites for over a decade and only ran into the A11y acronym fairly recently.

I had to look it up.

So stupid the ‘official’ name for accessibility completely obfuscates what it is.

> [using the web with a screen reader is] an utterly prehistoric experience compared to using the web normally.

I think that's too harsh a criticism of screen readers. Can you give more details about why you think it's that bad?

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.

Annoying, to say the least.