Colleges improve website accessibility as they are defendants in lawsuits
ithacajournal.com
ithacajournal.com
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.
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.
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?
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)
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.
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.
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?)
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.
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.
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.
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.
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.
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.
IAAP Certification Tracks: https://www.accessibilityassociation.org/certification
Gomez v. GNC: https://www.levelaccess.com/federal-court-decision-gomez-v-g...
1: https://a11yproject.com/about/#what-does-the-term-a11y-mean
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.
The explanation is on the about page.
But whatever... This is rather off-topic to the main point of this HN post.
I had to look it up.
So stupid the ‘official’ name for accessibility completely obfuscates what it is.
Annoying, to say the least.
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'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.
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.
I think that's too harsh a criticism of screen readers. Can you give more details about why you think it's that bad?
From a practitioner's viewpoint, it might make perfect sense to target WCAG, and possibly consider anything less 'unaccessible'. However, from a legal viewpoint - which typically doesn't acknowledge any obligation or liability without precedent - it's a very different situation.
I'm curious if these tort cases can set that precedent, and clarify things for the lawyers.
The above assumes there is only one standard. Standards bodies (ANSI, ECMA, ISO) often accept multiple competing standards. This happens when they are not aware of the other standard, or when they believe the standards can compete (C++ doesn't prevent you from creating an ISO standard for a different programming language).
Companies will often try to get their internal process encoded into a standard for this reason: it documents something that can be brought to court with more weight than something they came up with: if you sue latter the judge will ask if you care so much why didn't you get involved with the standards process when the company created their standard. Since part of becoming a standard is you have to take input from others this is somewhat reasonable.
The above is a US perspective from not a lawyer. Other countries have different rules. Talk to a local lawyer if you need legal advice.
* WAVE add-on for Firefox (free): https://addons.mozilla.org/en-US/firefox/addon/wave-accessib...
* Google LightHouse (free, part of Chrome): Developer Tools -> Audits
* HTML Validator: https://html5.validator.nu/
The HTML validator isn't specifically aimed at accessibility issues but it does highlight some low-lying fruit. All 3 of these are free and easy to use. WAVE is the most helpful IMO.
To wit, you can create a really, really inaccessible site that scores 100 on Lighthouse: https://www.matuzo.at/blog/building-the-most-inaccessible-si...
I was at a conference that had a theme of accessibility about a year ago and one of the repeated points was that accessibility (not just visual) tends to improve access for people under lots of circumstances. (Think closed captioning in a noisy environment or for viewers who aren't fully fluent or have trouble with strong accents.)
> Businesses that integrate accessibility are more likely to be innovative, inclusive enterprises that reach more people with positive brand messaging that meets emerging global legal requirements.
Thanks.
What I'd like is to see what the Lighthouse tool considers fixed text (eg with either foreground or background adjusted, then with both) to help decide how to fix it. Probably showing images of the failing elements put through colour-blindness imitating filters would be useful too.
As it's just my blog I've left it ("works for me"!); but I try to always deliver 100% pass on mainstream automated tools as a first approximation of a working site.
Automated tools are a good start, but they're not the be-all and end-all. They aren't always right because they're mathematical approximations of reality.
For a site I'm working on the art department specified a set of colors that validate perfectly in the automated a11y tools, but are a visual disaster.
One thing that helps, though, is to make sure your computer and monitor(s) are all in the same color space. I discovered a few weeks ago that my main preview monitor wasn't set to the same space as my computer, and changing them to match made a world of difference.
You can mathematically know if something has enough contrast. The guidelines for AA contrast is 4.5:1 for most text and 3:1 for large text. But... it may be hard to understand what those ratios mean. Basically Lightest Color relative brightness:Darkest color relative brightness. https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-cont...
The US Web Design system shows one way to solve it (ie, use their css token system that labels colors to make contrast differences super clear) but they also link to several very good resources on contrast.
https://designsystem.digital.gov/design-tokens/color/overvie...
Things like the WAVE tool (https://wave.webaim.org/extension/) will also have places where you can see contrast errors. In the WAVE tool, it's the third button at the top of the results [styles][no styles][contrast].
You can then see the contrast errors and try out some different options right there in the tool, until the errors go away, and you know what you can replace in your code.
It showed that the standard blue on white used by iOS (approx #07F on #FFF) doesn't have enough contrast... Is Apple's dark-mode partly designed for accessibilility reasons?
I wish I could see actual statistics on this, I admit this is wild speculation on my part.
and, hopefully, just as we've realized that ADA compliance benefits all of us, whether it's in the form of getting old or pushing strollers or nursing a sprained ankle, we'll get to the point where the improved information availability from ADA compliance becomes an intrinsic part of the power of the web.
Countering anecdote with anecdote, here's an example of the importance of ADA lawsuits:
https://www.peds.org/campaigns/sidewalk-maintenance/curb-ram...
Atlanta has been awful about keeping their pedestrian infrastructure working. And this wasn't a profit-seeking lawsuit -- it was the DoJ.
[0]hypothetically
[1]hypothetically
[0] https://adata.org/publication/ADA-faq-booklet ("under 1%")
As to your student loan, again, probably very little. Let's say it cost a few hundred k spread over a few years -- at CMU, at least, adding 100k spread over 10k students is a molecule in the bucket.
For websites, either they will have to spend more money making them or make fewer of them using existing budgets.
Seems like a market ripe for disruption.
Championing the rights of the disabled despite it being a net loss of productivity for humanity (which is my reading of your comment, and could be inaccurate) may look insane to a logic-less machine, but less so when reasoned through for a bit.
If you're suggesting we change the laws to avoid this kind of productivity loss, it may be worth wondering why all these government websites only reacted to the stick, not the carrot.
Tabstops: browsers have these but if you mix up forms with crazy CSS they don't work well. Focus states: there by default, frequently removed by CSS. Font sizes & contrast: high contrast & adequately large (and scalable!) by default.
Semantic HTML, alt tags, and a "skip to content" link are up to you, combine those with not breaking the browser's behaviour and you're 90% there, maybe 100%.
In the process of reinventing the web UI wheel, a lot of the a11y features of the browser were forgotten.
I deal also with science research and education outreach content. There's often no budget. No staff. Crufty pages put up by graduate students. Or zombie sites left up long after their funding is gone. It's severely bottlenecked on overworked people finding a bit of time to volunteer on something that helps the world and largely doesn't help them. Even having a working web server is a challenge. It's profoundly marginal, and every tweak of barrier energy directly throttles how much of it occurs.
High-stakes a11y could be a disaster for this area. The liability exposure, associated administrative hassle, and simple bare technical cost, might have severe impact.
When Berkeley took down years of youtube lectures in response to DoJ ADA concerns, they had already stopped making new ones pubic. So while dramatic negative impact on the scale of large projects is a thing, I'm more worried about the smaller-scale but systemic stuff.
For marginal efforts, an "if it's public, there are requirements and risks" has a straightforward impact - it won't be public, it won't exist. At least not there.*
And if a11y requirements aren't grandfathered, then as standards rise, the long tail of pages that persist long after their authors have moved on, retired, or died, that persist until a host name changes or a disk dies, will likely be intentionally cut off. Like corporate email retention minimization, but for human knowledge on the web.
Having watched copyright compliance dramatically slow open education content creation at a range of scales, and HIPAA kill off promising work on patient-created orientation content, and now hearing of "high-stakes" a11y... I worry that we don't fully appreciate just how large a price in retarded progress we're choosing to pay, since it's hard-to-see "that which might now exist... doesn't; those we might have helped... weren't".
*Or... maybe small-scale content will simply be shifted off university sites, onto personal ones? And google and archive.org can fill in the gaps? There's already a trend of research groups having two sites; an institutional one, and a second more extensive one under the personal control of the professor who might move elsewhere. And graduate students having their own, describing their own work. So perhaps "high-stakes" a11y will merely accelerate this?
The default behaviours of HTML and default CSS are accessible to a reasonable degree. PDFs that aren't scans are accessible.
It tends to be when one overrides behaviour that you start to become inaccessible.
JS is awful for breaking a site for a screen reader as the purpose and contents can change after or during it being read.
Scientists and researchers, in my experience, don't tend to futz with the markup, because it's just the delivery tool, not their purpose.
It's not the government I work for, but a nearby sheriff's office took their website completely offline and replaced it with a simple text based site[1]. The cost to make their old site accessible and the liability of leaving it up was too high.
That said and as others have mentioned in their comments, all of these institutions know that accessibility is mandated by law and they've just kind of ignored it.
I also never said that it was okay for them to do that. But it meets the minimum requirements of the law and is legally compliant (or so their lawyer says).
In fact, my point was that they should not do that. They did it to avoid getting sued. Now any functionality they could have offered, such as online crime reporting or crime stat lookups, are not even options.
It's more like instead of adding ramps, just shutting down the actual building and conducting business in the parking lot.
That's a bad analogy. The linked website is equally usable for everyone.
I wonder if part of the problem is that we still don’t have an official way to develop “blueprints” for websites the way building designers do. As the industry matures, having inaccessible websites could be as taboo as having inaccessible buildings is today.
See joebubna's comment in this topic for more depth: https://news.ycombinator.com/item?id=20226398
code - blueprint
configuration, content - building
From my experience, most of these lawsuits are "predatory" in nature. Law firm finds a sympathetic case, sues as many orgs as they can, and collects massive fees along the way while the web developers get thrown under the bus, or also collect massive fees (yay?!?). The same can be said for "workshops" that teach people about compliance.
Passing automated WCAG tests, vs actually following the "spirit" of compliance are two completely different things. I've spent countless hours attempting to get my code to pass automated tests, just so when I pass back to the client they don't throw it back in my lap, despite my code being fully compliant and accessible.
We also do design work, and work with external designers with no concept of accessibility. Often (most) times, clients dictate the design and often make decisions that violate accessibility rules. Color contrast, "wiz bang" features are the two most common violators. Full accessibility limits design freedom considerably.
I met with a 100% government funded org just last week and told them their (hundred + page) site (no CMS) was not in any way compliant. You should have seen the look on their faces. They then proceeded to show me websites they like, to inspire a redesign project and NONE of them were even remotely compliant despite all the examples also being gov funded.
20-30% in the cost increase to make a new website project fully compliant. Retrofitting an old website? The cost could easily exceed the initial development.
To be clear, I'm not saying websites should not be compliant, just that ... it's messy and the guidelines aren't always clear. Aggressive law firms are only making things worse.
Final note: The accessibility capabilities of social networks are ... not good. Where do you post transcriptions of your Facebook video? Where do you specify alt tags, or "long descriptions"? The list is extensive.
Final final note: Once your web developer is "done". Your staff who blogs and the content creators that fuel this work can ruin everything. Staff training is often overlooked.
Are they? Would you, or the one writing the cheque, care without them?
Our HTML was more or less fine (though we found and fixed a few bugs), but the unbelievable number of PDFs and un-captioned videos nearly broke us. The culture shift has been difficult, particularly with people who want to post videos or PDFs but don't have the resources or training to make those pieces of content accessible.
Wholeheartedly agree with this. I once hosted a microsite on my personal server for a group at the university I was a web flunkey for as it needed to get up quickly, and well, corporate IT wasn't the fastest thing there, and it took them years to ask for changes after I'd left.
It's usually pretty easy for universities to update their main public facing pages, but as you mention, it's the thousands of other, quite often slightly bespoke (as this Professional or that Dr wants their own, custom slice) that's the breaker.
My understanding is that the ADA is enforced specifically by citizens filing complaints which turn into lawsuits.
It's great that these lawsuits actually carry enough weight to make the universities take action.
In other cases, companies repeatedly get fined for some violation (pollution comes to mind) and simply see it as a cost of doing business.
No word on exact amounts being sued for over and beyond compliance enforcement. I am all for compliance but there needs to be safeguards against excessive lawyer fees and actual damages at most could only be applicable to one defendant. It is clear from previous cases that they are claiming damages
The fact so many state colleges have not complied should be an embarrassment to the states which this is true and if wider spread should be an absolute requirement before federal funds are given to any state college to include providing backing to student loans.
Compensatory and damages in an amount to be determined by proof, including all applicable statutory and punitive damages and fines, to Plaintiff and the proposed class for violations of their civil rights under The Rehabilitation Act of 1973, New York State Human Rights Law and City Law; f.
Pre- and post-judgment interest; g.
An award of costs and expenses of this action together with reasonable attorneys’ and expert fees; and
-31- h.
Such other and further relief as this Court deems just and proper
[1] https://www.timesunion.com/news/article/Colleges-including-S...
[2] https://www.scribd.com/document/394914375/Camacho-v-St-Rose#...
1. Assess the cost of implementing proper security vs cost of doing damage control in the event of a breach
2. If former is less than latter, implement proper security. If not, ignore the problem until a breach happens
Just replace "security" with "accessibility" and "breach" with "lawsuit"
I mean if you use ad iv or img instead of a button how will the reader know that is a button?
Do you use the reader mode in Firefox or similar extensions? Have you seen webpages where it does not work or instead of grabbing only the content it grabs a lot of the advertising and other garbage? Accessible webpage would help people that use reader mode too.
https://www.rachelandrew.co.uk/archives/2019/06/04/grid-cont...
Section 508 has been around, for what, 20 years?
And using lynx to see how a document is rendered was used quite a bit, for both some accessibility assessment, and also SEO.
I can definitely see how difficult this can be as an after-thought, but higher-ed should know better.
This is not a new requirement.
[1]: https://www.timesunion.com/news/article/Colleges-including-S...
[2]:https://www.scribd.com/document/394914375/Camacho-v-St-Rose#...
I don't know if that stands up in a court of law, but it's an interesting way to handle the problem.
For instance WCAG 2.1 requires a minmum text color contrast ratio of 4.5:1. If a web designer and other stakeholders haven't taken this on board there's a risk they'll select an inaccessible color palette. And that's just one requirement.
Designs that appeal to management and other stakeholders are more often hostile to accessibility than not.
Isn't that the same premise behind why the web started designing "mobile first"?
The most used web page at Cornell has been the weather report for the longest time, but CIT didn't know and shut it off out of ignorance. Then all of a sudden they get hundreds of calls.
IT at Cornell was a center of excellence in the past, but since Lehman left, it as seem as a cost center that gets in the way of hiring more academics.
The Peoplesoft/Duffield Hall disaster was two connected scandals.
David Duffield (the Peoplesoft founder) donated money to build Duffield hall, which houses a national nanotechnology center. That nanotechnology also received startup funds from the NSF, which required that Cornell raise matching funds from some source that wasn't the NSF. When they demanded documentation, Cornell said that was impossible (paperwork is SNAFU), the NSF said "This is an eligibility requirement, not a reporting requirement". Cornell was informed it wouldn't be getting any more funding from the NSF if it didn't correct the situation.
Around the same time Cornell attempted a Peoplesoft implementation that went at least $50 million over budget while implementing only 20% of the original scope.
The first project manager they hired said there was no way they could do the project with the budget they wanted, they fired him and hired a Yes Man. The rest is history.
Jeff Lehman was president of Cornell for about a year. He announced his resignation at Alumni week, shocking people. The cause of his resignation was kept secret, but I can't help but believe that he took office when the above mentioned scandals hit. (These certainly were not his fault because the situations started before his watch)
What I do know is that there was a severe money pinch, which caused a series of cascading failures, and also that everything at Cornell that was unique and special had to fight for it's right to exist, while they kept chasing the same fads as all the other Ivys.
Was this why Lehman quit? I don't know. But I do know if he stayed he would have been cleaning up an awful mess instead of leading new initiatives.
Perhaps one way to approach the issue is for people who build web frameworks to reconsider their anchor of "normal."
Reading OP it seems like his team is shouldering a disproportionate amount of what should be a shared burden.
I thing the problem with this argument is that it shifts the burden of serving all people (including disabled people) from the company providing the service to a person who is disabled. That's exactly what the ADA was supposed to prevent.
It's the responsibility of the wheelchair makers to at least build a reasonably stable product that everybody can support.
Sigh.
Web developers need to decide if their job is to impress or to inform. Usually users want to be informed, while the VP of marketing (your client) wants to be impressed. The two goals do not have to be in conflict with each other but the blind use of frameworks and client-side rendering often puts them in conflict.
Using a framework that is designed for accessibility should be better than using plain HTML that is not designed for a11y.
React and declarative frameworks make it as easy as vanilla HTML to include ARIA compliant content.
I would also reconsider why that “API” would be better than the existing web APIs which the community has been working on for the last few decades. HTML is great for this purpose: you have a rich document markup language with a decent semantic model, separation of display styling from content, and the ability to add metadata to support different accessibility modes. Using it to build applications is problematic but still possible: the main problem being that many JavaScript tools are developed by teams which don't prioritize accessibility, which is really the same problem as the previous paragraph where things which the people building the site don't check tend not to work. That's getting better but it really needs a combination of awareness of the need and legal ramifications to get people to build it in from the beginning.
Oh wait, except most of the audience isn't blind, and starts using clients that can do ever-zanier things with the UI. Designers want to appeal to this market. The beautiful, parseable structure of HTML gets forgotten about, and it's no longer usable by the blind.
So you want content providers to support an api endpoint that works like HTML used to? Okay, but what stops that exact process from happening all over again?
Or, maybe you mean that every provider in existence will support two versions of every endpoint: the meth-addled zany design, and the standards-compliant, usable one. Okay, that could work, but it seems a lot harder than just having one version that makes a small effort to make itself more machine parseable.
But if you're doing anything that spits out HTML (flask, django, react, vue, whatever), you should be able to construct that HTML in an accessible way.
Too many web developers go for the full JS framework-heavy application architecture without stopping to consider if the project in question is trying to replace a native desktop app or if it's trying to replace a PDF document that could be printed on paper. The latter projects need to be pushed back toward simpler HTML.
From where I was sitting it seemed more like "brands demand 'consistent brand image', which they confuse with pixel perfect design because they don't really grok the new paradigm, and so any semblance of semantic web and accessibility dies".
And we've just now 15 or more years on clawed our way back to some semantics, and responsive design, and a legal framework that forces brands to accommodate those using different UA for accessibility reasons.
None at all, even though the dead-blind greatly outnumber the living-blind. This area is ripe for technological disruption.
Cars have regulations about the size, color, brightness of all the external lights, airbags, emissions, noise levels, etc., that when you put all these together, you get a Chevy Impala. Or a Toyota Camry.
Compare the SUVs, for example. I just bought one and I constantly turn my head when an SUV passes on the street thinking it's the same as mine. But turns out it's from a different maker altogether. Designed on a different continent by very different people.
You might also not be aware of how differently these regulations are applied depending on the type of product or service being offered and the nature of its provider. If you're hawking a web-app for designing charts, you will probably not be asked to stop supporting rainbow color-scales. Now, if you're an educational institution whose admissions tab is unnavigable to visually-impaired people...