> ARIA, the language created to help make interfaces more accessible, was found on more than sixty percent of the home pages surveyed. Unfortunately, those home pages were more likely to have detectable accessibility errors.
> Pages containing popular JavaScript frameworks were more likely to have accessibility errors than those that didn’t use those frameworks.
This was obvious to me all along, but it's nice to have official statistics on this.
I would like to use this opportunity to point out the astounding hypocrisy of front-end developers who claim to be in favor of better accessibility, but then vehemently oppose the idea that HTML should have built-in component that cover basic web use cases without the need for scripting.
Sure, getting controls "right" in browsers is hard. But hoping that all web developers get them right when choosing/writing their own implementations of everything is absolutely hopeless. Accessibility should be the reasonable default you get "out of the box" when not doing something overly fancy or stupid.
> front-end developers who claim to be in favor of better accessibility, but then vehemently oppose the idea that HTML should have built-in component that cover basic web use cases without the need for scripting.
Is this a thing? (specifically that the front-end devs are the problem) I'm a dev with plenty of front-end experience, but back in the day I was sad when login pages became a thing (as opposed to built-in browser authentication), and frankly if Apple would stop being a problem I still retain hope that HTML5 form validation could actually be common.
The problem has always been (in my experience) - when browsers provide an insufficient/notably unfriendly experience (no means of managing forgotten passwords or registering logins, for example), when browser vendors refuse to play ball (IIS/IE only supported BASIC authentication, for example. Today Apple is the hold out on HTML5 validation), and/or when designers want to be "different" or have a brand that is consistent across platforms (despite those platforms having their own conventions).
Usually the front-end _devs_ want things to work with minimal effort. It's only when they are asked to do things the browsers won't do that they/we waste time rolling our own reinvented solutions.
When you run into yet-another-page that screws with how scrolling works - do you think the front-end _dev_ wanted to work on that bug-ridden task?
The amount of work Apple has put into making iOS accessible astounds me. Apple are not the bad guys here from what I can tell... (Disclaimer: I usually go Android, but iOS kicks Android's arse on more than one feature IMHO)
Wow! I haven't checked in about 3 years - last I heard they had basically shrugged it off and weren't intending to change. I'll have to check this out - if correct, I'm that much happier.
If I go through this post https://news.ycombinator.com/item?id=19367149 (A JavaScript free front end, which was on the front page a couple days ago) it seems to me about half of the comments are devs arguing that JavaScript is a better solution for page interactivity than HTML and CSS.
The 'better' varied between arguments that it was easier to debug JS, easier to maintain, and when I just looked at it now it seemed someone thought that a JS solution would be more accessible (although the argument seemed to acknowledge people needed to do work to make it accessible)
Anyway, if we agree that JS is more difficult than the other technologies named it sort of follows that more money will be earned by solving things with it, and someone once said something about the difficulty of changing someone's mind when their livelihood depends on maintaining the opinion.
Note - I make most of my money solving things with JavaScript nowadays.
If you know what you are doing it isn't needed. You can solve nearly 60-70% of accessibility issues by writing good HTML. For most of the rest having a simple understanding of CSS and JavaScript events with concern what constitutes a disability you are probably ok.
Personally I often try to avoid ARIA. ARIA is generally there to complicate for problems in the interface. If you solve for those problems directly you don't need ARIA. The role attribute is an exception though, because its always helpful.
There are always edge cases, but if you avoid stupid marketing trickery and understand the web standards you are probably safer than that supposed JS ninja spinning their favorite framework bullshit.
The Microsoft world has always had some pretty advanced yet somewhat obscure stuff --- a shame that they're not more well-known. Other examples include MSRPC (through which you can do SSH-ish things), WMI, everything Active Directory, etc.
As a front-end dev, I'm trying to bake this into my process as much as possible. I am only around 20% of the way to that. Last year I focused on baking in testing into my process, now I'd like to do the same for accessibility. Big ups to Google for making Lighthouse an easy to use tool.
A business will likely never give explicit permission or budget for A11y work. Just like unit tests or e2e tests are rarely line items too. At my midsize consultancy we don't even mention it, we just bake it into the work we do. We find the time-- we make it work. It's our job. Writing inaccessible sites is kind of like building a car but ignore all environmental regulations. Your bosses boss might be ok with it, but should you be ok with it?
Think about all the work you do as a front-end dev that is not explicitly writing production code. You research libraries. You learn from screencasts. You read blog posts. You form complicated opinions about Redux. You have long code reviews. You agonize over naming. You can take similar care with accessibility. And lastly, it's not only important to be 100% accessible, it's also important to care and constantly improve. This a reminder to myself more than anyone else.
A tip: the most important step you can take is to do a short tutorial on how to navigate the web using a screen reader ([1] covers the basics - it's video though, and focused on OS X, but helped as a starting point for me to do the same on Ubuntu), then use that to navigate through your own app. You just need to do that once to already have a far better feeling of where common pain points are.
This is sad, but in no way surprising.
It has the same root cause as many websites misusing javascript to a point where they become unusable, and that is people not really knowing how to use the tools they are given.
One not so dirty secret of accessibility has always been that it is not something you do afterwards, but that you have already done 80% of what needed to be done by just writing valid, standard compliant, semantic HTML.
So I would argue, if you really want to do something to make the web more accessible, usable and a generally nicer place, learn the tools of your trade. No, HTML and CSS are not so simple that they are not worth your time. They are easy to learn, true, but put in the time to get them right. Headings are an H tag, Navs are lists of links, paragraphs are p, not div. Easy stuff like that. And of course, CSS goes hand in hand with that.
You know display: none on a dropdown menu breaks accessibility, right? Of course it does, you tell the browser to not show the content. So use position: absolute; left: -999em or something. These are simple things you could and probably should know and if you do them, you already eliminated most of the problems.
Alt Tag on Images? Yeah, they are easy to forget, but they are also mandatory! So if you tend to be forgetful, use something like pink css borders around images that don't have them, so you won't in the future.
And for using tables for layout: There was a time, way back when, when css 2 was sparkling new and the young guys in the office bought a copy of Zeldmans "Designing with web standards" so the old farts would learn that the world was better now and we didn't need old crutches. If you are still using tables for layout today, you are not a web developer. Harsh but true. They got obsolete with float and position and you also have flexbox or css-grids today. I think you still actually don't need these for 95% of designs, but if you find them easier to use, please do!
And those aria tags or skip to content links? They are actually not the problem. They are icing on the cake. Include them if you like, people might thank you for them, but they also have had tools to compensate for these shortcomings for years, so they are not the real problem. Not displaying content properly or not at all without 500K of JS is, though.
So do something for accessibility and the web and learn the basics, it goes a long way to making you a better and more efficient developer and making the web more pleasant to use for all of us!
Well, tables for layout are necessarily in one very specific case. Namely, coding HTML emails, where CSS support is pretty horrible and (for some reason only known to them), Microsoft decided that they'd use Microsoft Word's rendering engine for Outlook.
Yeah, it's screwed up, and god knows what the accessibility of these things is like because of it. Someone needs to start a Zeldman esque web standards push for that media too.
Yeah, HTML emails are really a sad state of affairs. So many basic CSS things wont work there consistently. You don't need to even think about position or float when you got trouble setting colors.
I actually felt HTML mails were finally coming along and getting better standard support until Microsoft decided to use Words engine instead of IE/Edge. Since then, all is lost on that front.
Drew is one of our users: Drew is 70, with poor but functional eyesight, and they have shaky hands. I try to ensure our product works for Drew because many other users are on a spectrum with similar problems.
Chris is one of our users. Chris has a unique disability within our clientbase, and they work for a government department. There are two developers working on UI, and it would take me 3 man months to write code to make our product work for Chris. I am a founder so I have the authority to make our product work for Chris, but there is no external pressure on us to do so (not even by the government department).
The fundamental question that occurs is: should we invest 3 months working on functionality specific to a single person (Chris) or should we invest 3 months working on a feature that benefits all our users a small amount?
Developers spend far too much time thinking up justifications not to build accessible software. 99.9999% of the time no such user as Chris exists, so the argument is nonsense - if you build an accessible app and you don't put things in the way of users modifying it using their accessibility software, then it will work better for everyone. Users with accessibility needs don't want special, complex additions. They want software that works, just like everyone else.
If you really can point to a specific user and define 3 months of work for that person to use the app then you're lucky. You really know your users, and you can determine exactly how much of a problem not supporting that user is. That's very unusual.
The point here isn't that people have unique disabilities though, it's the assertion that people have unique disabilities that require unique solutions. That is entirely false. If you have a single blind user you don't have to code "special stuff for blind people"; you just have to make an accessible app and their screenreader will do all the "special stuff for blind people" work. The same is true for pretty much every disability. Just write code that has the necessary accessible structure and tags and let the user do turn it in to an app that works for them.
A key thing to consider is that a user with accessibility issues wants a solution that works on every website and every app. If you're thinking you need to spend months of time coding accessibility features just for your app, and expand that out to every other app, then clearly something is very wrong. That's why we have standards and best practises; if you follow them then your app will 'just work' with accessibility software.
And, as a very useful bonus feature, if you've written your app with semantic markup, a good information hierarchy, a contrast-y color scheme, and and a bit of thought then it'll also work better for every single other user regardless of their accessibility needs. It'll simply be a better app.
One thing I try to remember that puts the fundamental question in perspective is this: at some time scales, the portion of users who will lose some portion of their full ability is a majority (in fact, the minority that doesn't figure in here will lose all of their ability to use the software).
That doesn't eliminate the tradeoff, but it changes user stories. Maybe Amy is 25 in full health and not only that but pretty bright and a well-compensated developer at a FAANG company... but is going to suffer severe carpal tunnel and tendonitis before she turns 28. Maybe Brad is a 50 year old long time power user but macular degeneration is going to hit him hard in the next 5 years.
Maybe the group of people who will benefit from an accessibility feature is less narrow than it might seem at any given point in time.
at least make sure your buttons have a slight border and that u re not rendering #eee text over #fff background. usability issues are usually just small changes to the UI, not something that will disadvantage all users a small amount.
Totally agree. And a non-human issue with your example:
We had #EEF as a subtle light-blue 5px resizer handle on a #FFF background. However the resizer handle was invisible on a newly unboxed monitor the other day (benq 32 inch 4k monitor) - because it was showing up as white on white.
It was fixed by replacing the HDMI cable.
I think the HDMI connection was dropping back to a lower bitrate. Screenshot, and displaying the screenshot on another monitor, showed that the blue resizer line was there but it was not being displayed correctly.
Yes. 'Pure' colors tend to be bright, so white text doesn't contrast well enough. As a rule, designers don't use the pure color. I suspect lots of sites get accessibility wrong because developers prioritize using nice round numbers (eg F00 rather than D00) instead of accessible colors.
Well if accessibility a right then you don't have a choice - which is why accessibility isn't a right.
Accessibility as a right requires actions on the part of others - which means it comes at the expense of another's rights. Real Rights require inaction from others not action.
Government websites are required to be accessible for employees in many scenarios. Depending on what Chris’s temperament is, he could grieve or sue for some reasonable accommodation, and win.
Once I suggested we get a partially sighted person help with recommendations for clients, the goal was to get more business in as a client might need a site rebuild if it is deemed bad on the accessibility front.
I explained how Google rank according to accessibility and how GoogleBot is the biggest 'screen reader' there is, so accessibility should be part of the SEO sales pitch.
The men in white coats from the local mental health hospital did not come and collect me but I did feel that this was the expectation, particularly for suggesting we bring a partially sighted person into the process.
The web is hampered by a visual design process that was necessary a decade ago when you did need to know what you were doing with non-standards-compliant browsers. However, a whole industry has built up around this process and mockups are never made from simple HTML documents structured with semantic HTML elements such as 'aside', 'section', 'article', 'nav' and so forth. What emerges from a visual design process always gets coded up with some allegedly 'agile' process with many 'div' elements and maybe a 'header' element thrown into the mix because someone on the SEO team has demanded it for SEO.
Fundamentally it is this visual led design process rather than mocking up the content with semantic HTML that is getting the div soup industry into this accessibility problem. If you mark up a document with the proper HTML tags and put it through the WAVE tool then it comes up good.
For instance, rather than using 'div' containers for images, if you use 'figure' then you can add a 'figcaption' in there. The 'figcaption' can describe the picture, e.g. 'my cats dinner' and the 'alt' tag on the img can be 'messy bowl with prawns in it'. In this way you can have 'what it is' and 'what it looks like'. What is there not to like from a SEO perspective? Never mind accessibility!
I hope that the work Google are doing with Lighthouse that flags accessibility can be brought in to actively down-rank websites that fail on this metric, with an upranking for HTML5 semantic usage where there is document structure instead of divs bloated with class tags from lame frameworks.
One of the strategies that I'm thinking of to advance accessibility is to tout it as a way of cost-cutting. Blasphemy! How? Well because the major pain point I see in a11y is over-designing. Managers are being a control freak on the UX and designers are already overwhelmed by the newer features and ever-changing requirements and standards. Just give it up! Go back to a website with simple features and focus on what actually matters - clarity, relevance and easy workflow. I don't know if this works for other people but this is my take on a11y issues.
Often, HTML is not hand-crafted by developers but created by content authors in WYSIWYGs or generated from markdown. Of course developers could find ways to force content authors to write accessible content, but most content needs to be cheap, so people will always find ways to take shortcuts.
I don't want to say that modern JS frameworks aren't problematic, but I think they might only account for a small part of these bad numbers.
Around last christmas there was this long discussion on a mailing list I followed about people being unable to access websites because their computers were too old to reasonably run modern encryption algorithms in browsers. Much of the internet is pushing for https-only access, which, it would appear, locks out an entire bunch of end devices of perfectly healthy, yet not very wealthy people.
The guy defending unencrypted traffic got bullied and called names, and I stepped in but not to the amount of success that would have anyone from the opposing side acknowledge that there is indeed a case to be made for it. I ultimately cancelled my subscription, because I realized all the arguments had been repeated several times over to no effect.
Having worked for GOV.UK I’m painfully aware of the realities of supporting everyone’s devices and browsers, but it’s not quite that simple. The opposing factor is protecting people’s right to a secure experience.
Or, to put it another way, which is more important: letting a user who currently only has access to extremely old technology access any page on the site, or protecting (for example) someone suffering from domestic abuse when they access a page with details on how to get help?
In the end it’s a judgement call, but if you can argue your case both approaches are valid.
> their computers were too old to reasonably run modern encryption algorithms in browsers.
Do your remember any of the examples of such computers given?
I'm aware of the problem of no-longer-supported software too old to have added support for modern encryption, but I'm unfamiliar with this being a hardware problem.
Yeah, exactly. These are software limitations in Android.
The above comment seemed to be referring to older hardware so I was wondering if they were simply conflating bundled software (like pre-installed OS) or actually talking about hardware limitations.
While there is of course plenty of hardware that would be too limited for modern encryption, but I would seriously doubt anyone would be using it due to budget constraints (as in, these would more likely be specialised hw for niche embedded applications).
I would partly blame the web browsers. They should have better dev tools to check that pages are accessible.
I know that Firefox has its accessibility dev tool tab, but I don't really understand it. It looks very technical.
Chrome has Audit tab which checks that the web page is accessible. Fixing the errors helps, but I still have no idea how screen readers or other assisting technologies show the page.
Why web browsers can't have accessibility mode which changes the web page to show only data that screen readers and other accessibility tools see. Replace images with alt texts, remove css layout and colors, etc.
Browsers have a mode to check responsive layouts for mobiles. They should have a similar mode for accessibility.
> Why web browsers can't have accessibility mode which changes the web page to show only data that screen readers and other accessibility tools see. Replace images with alt texts, remove css layout and colors, etc.
if they did, they wouldn't be able to shove advertisements in your face. What you're talking about sounds like Reader view, which Firefox and Safari sure support, but often times popovers and "You've read 3 of your 5 free articles.." garbage blocks you and prevents Reader view from working. I've had visually impaired users complain about this very thing.
this looks like something that a trained AI can solve: recognize the meaningful parts of a page and adapt it to the user's needs. just like with every web standard, technology and hype made those accessibility tags obsolete very soon.
This would be a good use case for AI. Unfortunately the implementation right now is pretty poor, at least when it comes to MS PowerPoint. When I add an image to a slide deck, PPT automatically attempts to add a caption with its best guess of what the image is. 90% of the time it says "An image of a cell phone", and I have never once added that image.
1. Even if accessibility is somehow done, it's often for marketing reasons and just for the most visible part. A perfect example is Netflix. They make special movie description tracks for the blind, but they only do that because of public outrage[0]. Their website in general is usable but it could be way better. The only big company that used to be different was Apple, but then Jobs died and they've gotten much worse. Still the best of the FAANG companies but much worse than before. For example, the accessibility of the coding app for kids is apparently amazing because they can use it to show off, but Xcode is apparently still very, very bad.
2. Accessibility is not just about disability. Denying access to people under a certain age, living in a certain location or even using a certain (non JS) browser is inaccessibility too. This is something the law actively encourages (particularly when age and location come into play). I don't think it should be the developer's job to decide such things. A perfect example here is BBC. They do a really amazing job at the "classic" accessibility, but their geo restrictions are horrendous.
3. If you really can't do the accessibility, fine, but don't actively try to make the job harder for others. Don't be Twitter, don't break your API for special clients for the blind that are much easier to use.[1] Don't be the polish railroad company and don't actively change your API in such a way that the accessibility-focused third party app stops functioning.[2] Don't be Amazon, don't lock screen readers out with all the piracy apps when designing your DRM solution.[3] Not being able to do anything is acceptable. Being dicks is not.
No no no. Public pressure doesn't work that way. If you make public pressure, Apple will fix the few isues the public was outraged about and leave the invisible rest untouched. That's "marketing accessibility". The impressive, very visible and not that useful stuff is usually accessible, the invisible nitty gritty details of some settings dialog burried deep in the application that you suddenly need aren't. Even if it is accessible, this kind of accessibility done because of regulation or marketing can be horrible, see Google Docs. Is it useful? yes. Is it extremely verbose, speaking too much when the user does not need or want it? Yes. Is it completely unlike what blind people are used to? Also yes. I can elaborate more and provide examples if interested.
Firstly, I'm suspicious of "big data" in general and any emotional interpretation of machine-driven analysis of that data. But who cares, let's look at the findings..
> 2,099,665 layout tables were detected compared to only 113,737 data tables
I'm calling bullshit.
First of all, they found 2 million tables in 1 million websites? That's ridiculous. But not as ridiculous as the claim that all those 2 million tables were layout tables. Come on guys, think about it. That's not happening unless the samples included "way back machine" versions of those sites.
Find me ONE website in the list with a layout table. I challenge you. There's no way that any site in the top 1000 is going to have layout tables or "abysmal"
accessibility.
This is "million-something" clickbait. Any time someone does something involving a "million" somethings, everyone stops what they're doing and looks.
They are and there have been many rather bullshit drive-by lawsuits in regards to them too. With no leeway to give you time to fix the problem either.
Compliance is almost impossible for small teams. You can't rely on a lot of 3rd party code/widgets since many of them are non-compliant so now you require an in-house development team to recode a 3rd party widget to follow WCAG guidelines. Don't forget that you can't post any videos without transcripts! Transcripts cost money and time to create. So now people are simply denied videos altogether. [0]
These lawsuits have done far more harm to the public than good. Because they aren't focused on actually helping users, but turning a profit for some lawyer instead.
I'm the "go to" person regarding WCAG 2.0 / ADA within my company. I actually despise my job because I don't get to spend time making our websites more accessible to users but instead spend most of my time appeasing lawyers with too much time on their hands.
> You can't rely on a lot of 3rd party code/widgets since many of them are non-compliant so now you require an in-house development team to recode a 3rd party widget to follow WCAG guidelines.
We've gotten a lot of mileage out of going nuts with "UX" and styling on the web. Maybe it's time to stop thinking about whether or not we could, and start thinking about whether or not we should.
Of course you gotta get the money folks and the designers on board or you're out of luck. A lawsuit or ten should do the trick. Though, yes, "this is bad give us money" is a place these complaints probably shouldn't be able to start.
The end result of that is an internet ran by businesses and large corps capable of affording to be on the internet. Ma & Pa shops and small restaurants may not be able to afford to have a website, which could be enough to put them out of business.
Additionally I believe that if something can benefit people by simply existing it is better to have that thing than not have it at all if some small percentage of users aren't able to use that thing. For example, the Suicide Prevention Hotline website is not fully adhering to WCAG 2.0. I'd much rather that resource exist at all for those who may need it than to not let it exist because it doesn't adhere to WCAG 2.0
It's also very much accessible enough for actual people - but not quite "free from drive-by lawsuits" territory because it doesn't fully adhere to the guidelines.
> They are and there have been many rather bullshit drive-by lawsuits in regards to them too. With no leeway to give you time to fix the problem either.
Its clear these are not just "accidental" mistakes but people ignoring the problem wholesale. Commercial entities have responsibilities under the ADA. Yes it takes extra time and money to do it - so does designing in that ramp next to the stairs.
A little goes a long way here. It would be great if even just the alt text fields were filled out. Much easier than property developers have it.
The end result is appeasing 3rd party scanners like Powermapper without actually making the site any more accessible and in some cases making it less accessible. I've had to remove ARIA labels because Powermapper flags it as a problem for some screen readers. That's right. The markup we added to make the site as accessible as we could for screen readers was flagged as an issue and we had to remove it.
My job isn't to make websites more accessible because of these lawsuits, it's to put a stop to the lawsuits by any means necessary to the detriment of everyone. To quote my earlier post, I actually despise my job because I don't get to spend time making our websites more accessible to users but instead spend most of my time appeasing lawyers with too much time on their hands.
Probably a good reason for the industry to come together and make a tool that does work then. I can see how a magic number of errors is more convincing to the average person (and court) then a bunch of expert testimony saying otherwise. The industry should control the narrative.
You can bet the construction industry has people in the room when standards are set on what sort of elevators and ramps are required.
They are a major thing. There are a small number of law firms.... "heavily" invested in suing ADA non-compliant websites. The run it through a online tool and if there are a certain number of errors, an intern prints out a nasty gram demanding $xx,xxx or see them in court.
These guys recently went through all the art galleries in New York City... Alphabetically. [1]
Without regulatory action this will never happen. There isn't any money in it and so the laws of capitalism more or less push towards ignoring the issue until it can't be ignored any longer because there is a price attached to that.
The annoying thing is that the web was made with accessibility and screenreaders in mind, your typical javascript powered piece of shit one-page application is a nightmare for screenreaders and other kinds of accessibility aids. And this is getting worse over time, when form trumps function and pixel perfect placement of text is more important than the text itself there is not much hope for self-governance.
Part of it's the platform's defaults, part of it's every product owner and designer thinking every part of their "experience" needs to be some special snowflake crap.
PO - "We need an alert dialog, just some text." Dev - "Cool, gimme a few seconds... and there you go, window.alert()" PO - "No it needs to match our styling and look exactly the same no matter where it's running." Dev — "sigh."
Meanwhile, a bunch of the most successful sites are ugly as sin. But whatever. I'm sure it's worth thousands of extra dollars (though not enough thousands to also match all the built-in functionality of the feature you're replacing!) to make the datepicker pretty, but break a11y and keyboard shortcuts.
The base platform is pretty ugly and feature-starved, though. Like, date/time formatting and conversion to the user's preferred TZ should be a built in to HTML rather than re-invented a thousand times in JS or server-side. Some basic table sorting feature that'd serve 90% of all needs ought to be built in. Maybe alerts could allow more styling while still being accessible and safe. The datepicker widget should be good enough that no-one feels the need to make their own—though to be fair I've still seen that crap happen on mobile, where the platform widgets are basically fine, though part of that was Android's fault for sometimes having god-awful datepickers depending on version and vendor. The default styling mostly is bad (alerts actually aren't too shabby these days, at least in some browsers, though). It's a crappy state of affairs.
There is a bit of a chicken and egg problem here. As long as most of the popular websites are styled to extremis so that the users think they look nice, then there is no "market" for browsers and/or plugins that have features like sorting tables and "nicer" default styling in general.
If only a few big sites went "vanilla" then you can bet a browser that could "make them look nice" would become popular very quickly.
Depends: for a company operating purely in the US/outside Europe, an ADA lawsuit, or customers from fields that have a11y requirements not buying their product, seems more likely than GDPR fines. At least for now, there's little indication of GDPR tools being even attempted against companies not explicitly doing business here.
Everywhere I have ever worked, accessibility is 100% an afterthought if it ever even came up at all. In the places where people tried to do something about it, it was never a business priority or explicitly given resources; just something people did out of the kindness of their hearts. And I think that's the whole story. If you want this to change, press on companies to build this in as a concern, the way they should do with performance, security, localization, and whatever else.
12 years in industry across stacks b2b dev experience here. The word "accessibility" or
"disability" never even uttered out loud by developers, stakeholders or otherwise during every single project.
Maybe in like 50 more years it will be more common?
It's not just deadlines that gets a11y chopped off. It's not even remotely considered to begin with, unless a client demanded it specifically. Which never happened. Closest thing I've seen is internationalisation demands.
I've read sentiments and articles indicating that if you DO include good a11y support - these users love you. It garners massive loyalty, as one could imagine.
If you're a grunt serving in the lines? Good luck filling out a comment card after your desk-eaten 23 minute brown bag lunch and maybe the CEO won't fire you for the insubordination of suggesting work off of the most minimal track to $$$. I actually get anxiety sitting here thinking of how much trouble and internal political strife that would have caused in some places.
Businesses in the software industry care 0%. Negative zero.
> Pages containing popular JavaScript frameworks were more likely to have accessibility errors than those that didn’t use those frameworks.
This was obvious to me all along, but it's nice to have official statistics on this.
I would like to use this opportunity to point out the astounding hypocrisy of front-end developers who claim to be in favor of better accessibility, but then vehemently oppose the idea that HTML should have built-in component that cover basic web use cases without the need for scripting.
Sure, getting controls "right" in browsers is hard. But hoping that all web developers get them right when choosing/writing their own implementations of everything is absolutely hopeless. Accessibility should be the reasonable default you get "out of the box" when not doing something overly fancy or stupid.