Gijo Varghese Depends on the client and how big the site is. Ranges from "just me" to the largest I've dealt with the past eight years or so since I started accessibility consulting being two dozen. (A far cry from roughly two and a half decades ago where the insurance software I was in charge of running on Netware of a single 486DX-50 had a team of 60 maintainers under me. I can hear it now "How could you keep track of millions of clients on a single 486?!? Well, it used to be done on a PDP-11.)
Sadly the more people involved, the longer I have to sit there educating them since that too is part of the job. They get into these messes because they don't know or understand HTML/CSS/JavaScript or even design within the scope and limitations of accessibility norms, so I have to try and teach them those limitations and hope they stay between the lines when I'm done.
Which isn't always the case. Usually it's not the line dev's that are the problem, many of them are jonesing for the chance to do things "right" and had the same worries I was brought in to address, it's the people in charge of their departments who "failed upwards" through brown-nosing and paying their way to the top by going ivy league that fight the changes because it disagrees with the marketing and propaganda, and their general incompetence at development. The larger the company, the worse this usually is in those industries -- the opposite of general development where startups are the worst offenders in the rampant fanboyism of bad technologies.
But when they embrace the changes I suggest and understand what I'm teaching, it's a night and day transformation where they genuinely wonder what the blazes they've been wasting their time on for however long they were making the bad choices.
Simply put, less code is easier to understand. Less code is easier to maintain. In situations where micromanagement of the code for accessibility reasons (aka a website front end) is essential learning the semantics so you can use less code is the be-all end-all of development; as is kicking 90%+ of what people do with JavaScript client-side to the curb.
I'm trying to pinpoint exactly when it was over the past decade or so that HTML went from being scoffed at as being not even a real programming language and the separation offered by CSS was the savior of development, to both being "so hard" people started using these HTML/CSS/JS frameworks with their false claims.
It seems to be related to the uptick in bad website development practices much akin to the garbage we saw during the first browser wars and the corresponding dotcom bubble. Makes me think that Musk and Shuttleworth are right, the web is in fact in a second bubble.
Since pretty much the majority of cookie cutter goofy scripted train wrecks out there built with these "frameworks" might as well be -- from a user perspective -- the equivalent of an old Geocities or myspace page riddled with animated GIF's and flash files. I oft wonder if people forgot that the technology of flash being a plugin was only half the problem on websites, and that what people were doing with it was a disaster in terms of both speed and accessibility. The end result is that what a lot of people are doing with SVG, Canvas, and ECMAScript right now ends up akin to the people who used JavaScript to replicate target="_blank" because it was deprecated in 4 strict -- completely missing the bloody point!
Lands sake, over this past summer I did a job for a public utility where I kind you not, what they'd done with bootcrap and vue might as well have been this classic gem from the '90's:
theworldsworstwebsiteever.com
