I work on a product for higher-ed clients, and this has deeply impacted my team over the last two years. The process has been really tedious and painful for everyone involved: developers, product folks, management, and the users.
University admins send us automated third party a11y reports constantly, demanding that we make all of the recommended fixes immediately. We learned really quickly that several of these reports are very opinionated about how to implement ARIA tags, sometimes in ways that contradict the documentation. It can be hard to explain this to a customer trying to protect themselves legally.
In addition, screenreader apps are implemented inconsistently, and reproducing/debugging the screenreader bug in your app can be really infuriating. I felt truly horrible for people who use them on a daily basis because it's an utterly prehistoric experience compared to using the web normally.
The last thing is that we've had issues with getting a11y right with our front end frameworks at times to address these screenreader bugs.
Ultimately, a11y is so painful and costly for us to get right that it takes up a major chunk of our development efforts these days, and we all hate working on them.
The state of developing and maintaining accessible web applications feels like a sad joke given the industry's mantra to make the world a better, more connected place.
I empathize. My last job was with a university that got tagged with a lawsuit threat around the time I started. Accessibility stories eventually dominated our backlog. I appreciated being able to improve accessibility. But the lack of consistent standards and the legal department's lazy and inflexible response to the issue were demoralizing.
One of the first things I did in my next position was to bring on a Site Accessibility Engineer (I think I made that term up) to get out in front of issues like this. She was a graduate of a developer bootcamp with past experience assisting people with real-world accessibility issues. She's been invaluable.
"She was a graduate of a developer bootcamp with past experience assisting people with real-world accessibility issues."
That's one of the best "boot camp" use cases I've ever heard. An accessibility engineer like that doesn't necessarily need to be able to actually code up a backend with a database, etc, but is going to be greatly handicapped if they literally know nothing about the web and can't even show off a prototyped-up page with the new markup they are proposing. They don't need a full "computer science" education, a boot camp is a perfect bootstrap. (I'd still say there's things yet to learn, but when isn't that true?)
Sure, but where do they get their second tech job? Site accessibility engineer is not a common job title/position that I know of. Without some of those skills you mention, if not the corresponding formal education, that seems like this person is set up to fail soon, unless companies really start taking accessibility seriously in the next few years.
I dunno; if they're like most developers I know, they'll end up picking up a hodgepodge of skills that they missed in the bootcamp, which will let them plump out their resume.
If they can't figure out how to write their resume after they've had the experience, I don't feel too bad for them.
Accessibility consulting pays bonkers money these days due to the demand; even the a11y places like Deque and Usablenet are being asked for on-site a11y practitioners and they can’t find enough of them to refer companies to.
From reading the other comments in this thread, it seems that companies are starting to take accessibility seriously, and an experienced site accessibility engineer will not have any issues getting another job.
You might want to put her on a certification track (of which there are legit and respected certs out there now). Gomez v GNC highlighted the need for someone that could be pointed to as an actual expert on Accessibility on staff.
I don't see how implementing accessibility isn't a nuance. Not only do most people, including engineers, not even notice accessibility features, but they're a minor detail in how a web application functions. What do you think a "nuance" is?
Besides, it doesn't matter whether it's a nuance, because apparently most engineers aren't competent in implementing accessibility. I'd rather that people who specialize in it can get paid to do it right instead of believe in a fantasy that engineers are going to going to care enough to do it themselves.
IMO the problem is that web development education is often very informal, if not just straight up on the job. A lot of accessibility is to make links <a>, buttons <button>, tables <table>, lists <ul> or <ol>, etc. Append alt text as needed.
The problems come up when people see default <button> styling and then go off and make it a <div> instead. Nobody really teaches why this is a bad thing, you certainly won't find it in some random web tutorial on a blog from Google search. But if enough kludges like this happens in a code base it becomes pervasive tech debt in lots of tiny places, which is possibly the worst kind of tech debt.
I don't think it's impossible to educate engineers to do this, the problem is that we don't really educate about web development in the first place.
This is technically correct, but developers often code websites and applications facing the public, at which point you do come under the auspices of US case law (since websites are not explicitly covered by ADA), and UK legislation, to start with a few jurisdictions.
Does every developer face the law? Or just the companies putting material out there?
This really isn't a matter for developers to take on themselves. It is a matter of product development and feature selection.
So many people on here talking like they just "just do it right" and it's no more difficult to make the site accessible than it is to make the site at all. It is something which needs to planned an budgeted for.
It can get expensive. Especially when the development of the site is speculative and you don't know beforehand what it is going to look like in. Iterating over works in progress and maintaining accessibility along the way can be a real pain.
If it was as easy as everyone says, then most websites wouldn't be downright crap when it comes to accessibility. Most engineers are either too incompetent to implement it or it's too hard, or both. It's probably a mix of both. Either way, just wishing that people just do a better job just isn't going to happen. Paying people to do one job really well is probably a better way forward.
Hell, I can take the argument against this and apply it to things like QA. Why exactly can't engineers just do what QA would do themselves? Why not make all engineers devops? After all, shouldn't they understand the entire system from end to end? The answer is they can't, because the more skills you expect an individual to have, the more likely they're going to suck at everything they do.
It's easy to do when you implement. Links should be links. Buttons should be buttons. Lists should be lists. And so forth.
The problem IMO is that a lot of people see the default styling of, say, a button, and go 'screw that' and make a div do the work of a button instead of trying to override browser button styling. A fair amount of people learn web development very informally, and in my experience very few tutorials or education sources actually talk about accessibility other than as something that sounds like something nice to have. So they don't know why doing this is bad, or they don't think it's a huge problem.
And it's very easy to do these small little accessibility kludges instead of modifying default behavior, and you don't realize what the cost of that is until lots of kludges later you get slapped with a lawsuit. If you're on a team prioritizing composability, this isn't necessarily very difficult to fix, but for websites that exist pre-composable frameworks and use a hodgepodge of older technologically, this is actually very difficult, especially since many of the people who wrote the original logic are probably gone and the code probably isn't commented sufficiently.
Accessibility is just another form of tech debt. I don't know of any places that would hire a tech debt specialist.
I spent a while working at an accessibility company, and while I was there, worked on two separate things:
1. Remediating customers' sites that were inaccessible. (Which, btw, for all the "ambulance chaser" comments: Something like 100% of our customers were working with us because they had been sued; none of them were doing so because they had a sincere commitment to accessibility, so there's a reason these lawsuits happen.)
2. Developing our own web-based software, which obviously had to be fully-accessible from minute one, both because a large fraction of the people using it would be blind, and because obviously it had to be, come on.
Making changes to customers' sites was deeply, deeply painful, as we tried to work around fundamentally inaccessible designs and make things as close to acceptable as we could, given the reality of what we had to work with. Everything that the parent comment says here was 100% true.
Building our own software to be fully accessible, on the other hand, added some extra effort (largely around manual testing, since automated testing can only take you so far), but we're talking about like... 10%? If you have a dev team that's been trained on a11y and is committed to producing an accessible product, it's not super-hard to make that happen. That basically no dev teams work this way says nothing good about our industry.
IMO, if you start off with sane good practices, it's really not that difficult to work for a11y in web. Just adhering to good markup and keyboard-first navigation will get you most of the way "there", especially if the designers are aware of their constraints and designing with a11y in mind.
But reworking stuff that isn't already working around a11y is a massive pain in the ass.
So I "get" it, and I've built a lot of stuff that doens't serve every population as well as it could have if I had been more informed. But at this point, for new work it doesn't feel like much of a burden at all, any more than using git or linters or whatever other stuff we do because it's a helpful practice.
I'm in the same boat, but I'm just a contract web developer for a college within a public university. Turns out the university now requires outside "vendors" to provide a Voluntary Product Accessibility Template [0] and they're not allowed to purchase any "products" that aren't WCAG 2.0 AA. The VPAT essentially lists every individual WCAG guideline and asks to what level your "product" is compliant. This came up because my client within the college is trying to get approval for me to make some updates to the site (which I built for them 4 years ago, taking pains for accessibility before they even had a policy about it) to align with new branding guidelines which are also being imposed from above by the university.
I've tried to argue that the VPAT doesn't make any sense because they're not buying a "product" from me, they're paying me to do original work, so if anything they should provide me a VPAT as a form of specification. But the feedback I'm getting is that I should essentially pretend that the "product" is the entire website (including all the content added by college staff over the years), which means I'm supposed to essentially audit every page against the VPAT, or lie and say I did (which I would never do).
My only remaining tack is to appeal to the undue burden they're imposing on my small business.
Never mind that the website I built for the college is demonstrably more accessible than that of the university itself.
If they could ask anyone to update the site because they host it and it belongs to them, you're right, you shouldn't have to provide a VPAT.
However, they should include in any new contract for contract work that the end result be accessible according to their standards (WCAG 2.0 AA). A VPAT could be used as a template for documenting the accessibility of the newly completed work but there are better options. If they wanted documentation of the accessibility of the existing site, before you make any changes, and they wanted it in VPAT format, again, there are better tools but that should be considered separate, additional work.
> The state of developing and maintaining accessible web applications feels like a sad joke given the industry's mantra to make the world a better, more connected place.
this also feels true of most of the industry's business models.
but yeah, the mantra's just a mantra. i think lots of people repeat that and think it sounds like a good goal, but they never really examine whether they're contributing to it. people can bullshit themselves pretty easily. and a lot of other folks just pay lip service to that mantra so they can make money.
> Ultimately, a11y is so painful and costly for us to get right that it takes up a major chunk of our development efforts these days, and we all hate working on them.
Honestly, I expect this question would be difficult to answer in short time or without context. I think it'd be good discussion subject for a blog post. But: what are some examples of the pain and what would you change to simplify?
Not OP, but have done two large site UX overhauls in recent history, and my team/company takes accessibility _very_ seriously.
The biggest pain point for me has been the lack of a "Ground Truth" static-analysis-esque tool. We're provided some accessibility-issue-highlighting tooling, and there are some open source as well, but it's very common to get a11y tickets where the tool won't pick up the underlying issue, or will say "there's an issue" but not what the correct threshold is for fixing it (e.g. border contrast/density) so there's a bit of trial and error in there too.
If we had something similar to the "green squiggles" in IDEs, with, in my perfect world, the "right click->see suggestions ->auto-fix" flow that I can now get in code, addressing these issues would be SIGNIFICANTLY similar.
This is only one facet however, although it brushes against other issues in this space (inconsistent behavior of screen readers, occasionally not having sufficient specialized hardware to even test the scenario fully, often having to "negotiate" accessibility fixes with the designers who gave the original layouts, etc.)
Also, a final thing that I'm always curious is "just me" or not, but tab-ordering-fixes have seemed far more painful to handle (in dynamic/scalable layout scenarios) than I would have thought going in. The two options I know of for dealing with it are "assign the order" and "adjust your HTML/Z" layout, and the former is a very blunt hammer while the latter sometimes seems to be at odds with other requirements of the layout. (but this could very well be my naivete in frontend, thus this ramble)
Agreed. I've been happy to see aXe getting more visibility so it's easy to do at least the basic smoke testing similarly to other kinds of static analysis but it's definitely an area which is open for much greater improvement.
Getting things to be accessible (in practice: not just what some tool spits out in a report, but making the app/site useful to a real user with disabilities using a real browser of some sort) is not that bad as long as everyone's on board (if the designer wants everything drag & drop in red and green tones, you're kind of screwed).
Catering to screen readers is hard for the same reason supporting any non-60%+ user base browser is (uncommon mobile browsers, IE, whatever). All browsers have bugs and quirks, and having less eyes on things makes finding bugs hard. Debugging in a browser you don't use as frequently is always going to be significantly more challenging. When its not a "standard" one, it can be hell.
As another poster mentioned, a lot of the automated tools spit out a lot of false positives, and that adds to the burden.
I went to the A11y page to see what it was. Ironically, the single largest answer on their Learn More[1] page is them explaining what "A11y" even means. I'm trying not to draw sweeping conclusions about the project from this, but damn that's a bad start.
I'm not who you replied to, but as someone unfamiliar with the term "a11y", I googled it while reading these comments and the very first hit is https://a11yproject.com/ which I, too, assumed was "the a11y page" -- and after briefly looking at that page again just now, I'm still not convinced that it shouldn't be considered the canonical "a11y page". I now get that "a11y" is a numeronym for "accessibility", but considering I haven't heard it called "a11y" before today, a page calling itself The A11Y Project sounds both fairly authoritative and like it potentially could have been the source of the a11y numeronym. If it's not, it really could use some more explanation on that page.
> The A11Y Project sounds both fairly authoritative and like it potentially could have been the source of the a11y numeronym. If it's not, it really could use some more explanation on that page.
I've now read that entire page several times, and I don't believe that the explanation is truly there. The about page does a good job of explaining why accessibility is important, what "A11Y" means, and states that The Accessibility Project's goal is essentially to further accessibility on the web. It's very easy to interpret that page as meaning/implying they originated the term "A11Y" and/or that "A11Y" is specifically related to The A11Y Project, and therefore that The A11Y Project page is the defacto "A11Y page", for someone who has not come across the numeronym "a11y" before.
But whatever... This is rather off-topic to the main point of this HN post.
Lot's of love for accessibility folks in education. Maybe a small consolation, but we just made AccessLint, our GitHub code review application free for edu's, inspired by this thread.
With that much work being required, could the case be made that goes beyond a "reasonable accommodation"? Maybe that would mean that some of the less-trafficked pages would not need tagging, though maybe the more major and commonly-accessed ones represent a reasonable accommodation.
Indeed. My business is currently being targeted by these ambulance-chasers, but we are not a college with a well-staffed IT department; we are an ecommerce business with a single front-end developer on staff.
First off, his eCommerce business might be some custom software app, not an online store or informational website. So being "knee deep in frameworks" might be necessary for his business.
That said, the ADA is all about accommodating disabled persons within reason. Depending on the scope and functionality of his software, fully supporting such with a single developer on staff MIGHT be an undue burden - it all depends on the specifics of the situation and we don't know his.
Notice the usage of "Undue Burden" from the official ADA documentation below.
"The rules are also flexible for communicating effectively with customers who are blind or have low vision. For example, a restaurant can put its menu on an audio cassette or a waiter can read it to a patron. A sales clerk can find items and read their labels. In more complex transactions where a significant amount of printed information is involved, providing alternate formats will be necessary, unless doing so is an undue burden."
"It is a business's responsibility to provide a sign language, oral interpreter, or VRI service unless doing so in a particular situation would result in an undue burden, which means significant difficulty or expense. A business's overall resources determine (rather than a comparison to the fees paid by the customer needing the interpreter) what constitutes an undue burden."
I would say it's more similar to distributing menus without braille translations.
It's also very possibly their developer is woefully overworked, and what may amount to 'minimal effort' for you, could be outside the scope of what they have the time to accomplish.
> It’s no different than a restaurant server delivering shitty service to a black family because they stereotyped that people with kids and black people tip less.
Come on now. Stereotyping is an affirmative action, failing to consider accessibility is passive / apathy. It's comparable to not installing a handicap ramp for your restaurant.
As a contractor I used to construct special websites for both universities and government agencies. I would bring up in meetings "this site is required by law to be accessible" and invariably I was told "accessibility's not in the list of requirements". So in my opinion, they've had this coming for a long time.
While it's easy to say the site must legally be 'accessible', the problem I've encountered is that there is apparently no legal standard for 'accessible'. Section 508, WCAG, etc. do not have US caselaw behind them that actually identifies them as such.
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.
In general courts look at standards IF you point the judge to it. The judge will look at the standard, and if it looks reasonable will accept it, thus creating precedent. If your website obeys a standard the other side needs to prove the standard isn't enough to meet the law. That is if you meet WCAG the judge will probably default to considering it a bug in the screen reader - putting the burden the screen reader to show that the standard is not enough for ADA, not only is this a higher bar, but the judge will generally cut you some slack for trying.
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.
In general US civil court judges will cut you some slack if you can demonstrate that you acted in good faith and made reasonable efforts to comply with the law, even if you are technically violating some rules. This applies to most sections of civil law, not just web accessibility.
A few years ago I wrote out the specs for the vendors who do our ebook conversions. This is a somewhat more limited domain than most web sites, but still, from the beginning I insisted on proper semantic markup, aria tags, etc. It was clear then that the reckoning would be coming. In fact, our vendor recently added DAISY validation, and we were the only client who didn't have to change specs. Now the university is handing down mandates, and how much do I have to do now? Nothing.
Any way to contact you? It sounds like you work in an a11y-friendly university, and I'd love to pick your brain about how you handle ebook accessibility in particular.
Numerous times in my career things have come to a boil because management refused to let me and my team spend any time on accessibility. Trying to convince middle/upper management to have compassion for the visually disabled is like pulling teeth. Which I think is particularly nuts since advances in TTS have made it generally useful to the visually capable as well (acclimatizing to the TTS voice has become easier, and so casual usage of TTS has become more feasible.)
Accessible websites are higher quality websites. The article mentions SiteImprove, a commercial service that can be used to assess website accessibility. But that's not appropriate for everyone. Want to improve yours but don't know where to start? Here are a few options:
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.
Note: It's entirely possible to build a site that scores a 100 on Lighthouse, but be an abject failure in Accessibility compliance. We've done it ourselves on my team inadvertently (combo-box failure), so never forget that actual, manual testing with screen readers is 100% necessary. Automation often works against you when it comes to achieving compliance.
I used lighthouse to look at a prototype that used an iOS look framework.
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?
Just had a play, that wave extension for firefox is really good - I'm going to use it to fix my blog theme (low contrast issues and a missing language declaration but otherwise not to bad - it is just plain html with no JS).
Does anyone know of a site for fixing low contrast. My blog has v.pale grey (like #EEE), on a dark-green background. To me - normal vision - it looks high contrast.
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.
You can try to look at your site on your phone out in bright sunlight, but the thing about contrast is... you don't have to trust your eyes.
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.
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.
Does anyone know of a site for fixing low contrast. My blog has v.pale grey (like #EEE), on a dark-green background. To me - normal vision - it looks high contrast
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.
Why are accessible websites higher quality? If someone spends a good portion of their time making their site more usable for non-blind users, wouldn’t it be more likely that the less accessible site would be higher quality?
Because they can work better for users on small screens, low bandwidth connections, who just want to find some information they need, etc.
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.)
I’d go a step further and say confidently that there are strong and mutually beneficial interrelationships between Accessibility, Technical SEO, Site Performance, and General Front-End Best Practices.
Yes, that's a great example. It turns out having ramps widely available is really handy even if someone is just temporarily incapacitated--or is pushing a stroller or a shopping basket. Captions is another.
W3.org has a good article on the business case for accessibility:
> 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.
The expected steady-state outcome of this situation is that all website-owning educational companies will be targeted for lawsuits, many of which are valid, and many of which are not. The net effect of these lawsuits will primarily be a massive loss of productivity. It is very technically challenging and labor intensive to make websites accessible to the blind or otherly disabled, and doing so is to the benefit of a very small population, who will continue to primarily use other communication platforms anyway. Net effect: For every hour of time saved for the blind or otherly disabled, dozens of hours of time spent by others. A saner society would choose a different path.
I wish I could see actual statistics on this, I admit this is wild speculation on my part.
You're thinking short term. And you're probably right, short term. But we had the same set of concerns raised about many other ADA issues in the past, such as wheelchair-accessible ramps and doors. Over time, the standard practices (and what we'd think of as tooling and common design patterns) for new construction evolved. ADA lawsuits about websites create a similar incentive for long-term change.
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.
There are bad actors in every domain, but cherrypicking one doesn't tell us much about the overall balance. (Heck, for every scummy lawyer who uses the ADA as their club of choice, there are probably 100 who specialize in extracting money using questionable torts claims. Prenda Law was infamous for being a pile of snakes, enough so that they justify their own wikipedia article [0]).
Countering anecdote with anecdote, here's an example of the importance of ADA lawsuits:
I think that even long-term the approach as described in TFA will always require many hours of work for an hour of time saved. The saner way to do it is probably have direct personal assistance for the blind. Phone call systems for the deaf and hard of hearing have been in place for decades, and many of these systems rely on direct personal assistance.
These laws definitely increase expense though, wheel chair ramps aren’t free in material and space. We do have to pay for it in the form of increased real estate costs.
For websites, either they will have to spend more money making them or make fewer of them using existing budgets.
Accessibility is much more of a design (to design accessible experiences) and legal challenge (to defend your experiences as compliant in the face of malicious litigation and vague laws) than it is an engineering one. Yes, we can solve the technical problem fairly easy, but that won’t reduce compliance costs very much, if at all.
Why would compliance costs differ greatly once the technical problem of tools that build for accessibility by default are commonplace? Maybe some minimal oversight to verify accessibility, but no much else. Or am I missing something?
Probably very little, and a fraction that goes down over time. The cost of making new construction ADA-compliant is very small [0]. Retrofits are more expensive, but there are thresholds to try to reduce the pain. As we move to more and more post-ADA construction, the overall share of construction costs becomes fairly trivial.
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.
You can make the same argument about many things in the ADA. It's not supposed to be "worth it", and I don't think it's insane to spend a disproportionate amount of time/money catering to a small minority of the population. We, as a society, decided not to be economically optimal on this issue, and I think that's a sensible choice to make.
> For every hour of time saved for the blind or otherly disabled, dozens of hours of time spent by others. A saner society would choose a different path.
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.
I expect the universities will outsource more and more of their IT departments, and write in 'accessibility' into the contract. This way, they can continue not care, while also pointing the finger. Inevitably, costs for IT will go through the roof for these universities.
Nope, really not that complicated. Where I work, they just hired on a specialist contractor for a year. That person assisted with the audit of sites at the same time they trained web developers in remediation for existing sites and methods for building new content.
My suspicion is that a major aspect of this is the proliferation of SPAs built with tools that make accessibility seriously difficult. If you have an old-fashioned web application that spits out HTML only, congratulations, your site is already 90% of the way to compliance! Most of the a11y issues arise not from omitting some special step, but from breaking behaviour the browser already provides by default.
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.
Much of the discussion here is about commercially viable sites. Some budget and staffing exists to make progress, and some chunk of that will be redirected to a11y.
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?
I work in government and this is a major issue right now. We've basically pulled any and all content that wasn't required to be online from our website until it has been "certified accessible" by a third party.
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.
No. You don't make a building accessible by putting a sign on the front saying "wheelchairs not welcome", and you shouldn't make a web site "accessible" by gutting it of all content and functionality that isn't already accidentally accessible. This is at best a case of malicious compliance.
I never said it was accessible. I said it was a text based site, which it is. I feel like you're misunderstanding on purpose just to argue.
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 rather uselessly pedantic to claim that a single page placeholder qualifies as a simple text-based web site for the purposes of a discussion like this.
They're complying with the letter of the law. They don't have the resources to do it right, and if they don't, they get sued. I don't see how you can be pro-ADA and not ok with this outcome.
Web Developers need to start designing accessibility in from the start. Adding WCAG compliance after the fact is much more difficult.
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.
In my experience, too many websites are created design-first, content later. When your first consideration is visual appeal, it's much harder to go back and add meaning to the content that was never really intended to stand by itself without its surrounding visual context.
Design drives sales online. Entirely. If brick and mortar stores had to design their entire storefront and display area around wheelchair accessibility first to the detriment of 5-10% or more of recurring revenue we'd instantly have a small city worth of lobbyists to reverse it.
In the US, the ADA does indeed mandate many things (reserved parking spaces, door widths, ramps/elevators, etc.). Though to continue the analogy, I think we'd need to extend it to how the merchandise itself is displayed/marketed—for example, requiring all products to be accessible by someone in a wheelchair, braille on all packaging, etc.
Notice the usage of "Undue Burden" from the official ADA documentation: "The rules are also flexible for communicating effectively with customers who are blind or have low vision. A sales clerk can find items and read their labels..."
I've done WCAG / ADA work over the last two years and it's been a wake up call for government funded organizations and even small businesses, not to mention designers, developers and staff who manage content.
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.
I care about WCAG, PCI, GDPR and things like privacy policies, security and accessibility. However, I work for clients who simply want an inexpensive (as possible) website that they like the looks of. My competitors sell increasingly inexpensive solutions that lack these considerations, further driving down the expectations of price by the client (race to the bottom). Convincing them to care AND pay more is difficult. The lawsuits have made them afraid, and in some cases frantic. I don't believe FUD is the most effective way to improving accessibility. Maybe the ends justifies the means, but I cringe thinking we're lining the pockets of law firms for only marginal improvement.
If you want to make a website accessible without much effort then don't add shitty animations that hide content, don't use divs for buttons and links, don't use modals for everything, don't make text that's barely readable, etc, keep it simple and stick to semantic HTML. I made a checklist years ago https://github.com/miguelmota/web-accessibility
My university went through an accessibility remediation process recently, and it was a rather nightmarish undertaking. Many universities have multiple (thousands) of individual microsites that are largely untouched for years at a time, and I've always wondered if these would be targeted by people looking to bring a complaint.
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.
> Many universities have multiple (thousands) of individual microsites that are largely untouched for years at a time
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.
And I'll bet the vast majority of those PDFs were bitmaps made by somebody printing them on paper and then scanning them in because they didn't know how to make a text-based PDF directly from Word, or why doing so was a better idea.
One news story [1] has a copy of the suit within the article. Suit [2]
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
While I want the web to be maximally accessible to all individuals it seems like these lawsuit have had a chilling effect on things like opencourseware and open access to university courses.
College IT department managers aren't financially sophisticated enough to calculate explicit trade offs between accessibility compliance versus lawsuit costs.
Surely if they don't have the data then their set up is, by definition, not sophisticated enough to address the balance point for payoff in costs of non-mandated accessibility work?
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.
Mods, can you update this article to have (2018) in the title? The original article [1] was published on December 4, 2018, nearly 6 months ago. The lawsuit was filed on November 17, 2018 [2].
Would the plaintiff still have a case if the defendants staffed a phone line with someone available to navigate the websites by verbal instruction and made the availability of that service obvious? (I believe phone companies already provide speech <-> text services for people who can't speak and/or hear.) Seems like a decent compromise.
I've seen some web sites recently that have small text at the bottom reading something like, "Need help reading this web site? Call 800-xxx-xxx for assistance."
I don't know if that stands up in a court of law, but it's an interesting way to handle the problem.
I used to do Help Desk while attending University and often times people would have trouble using JAWS (screen reader) on Blackboard/Canvas pages. Almost made finishing school work impossible and those companies didn't seem to be putting in any effort accessibility wise.
Accessibility is hard. It's not just a technical problem. It informs every stage of conceptualizing, designing, and implementing a web site. Accessibility is end-to-end.
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.
Why aren't we designing the web to be "accessible first" instead of "mobile first". It's gotta be exponentially more difficult to retrofit accessibility on top of a site designed for sighted users instead of vice-versa.
Isn't that the same premise behind why the web started designing "mobile first"?
This was a priority at Cornell until the Peoplesoft/Duffield Hall disaster happened and at that point anybody in IT had a target on their back.
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.
Your post assumes readers have a significant amount of knowledge about Cornell. Most of us have no idea what the "Peoplesoft/Duffield Hall disaster" was, what CIT stands for, or who Lehman is.
CIT == Cornell Information Technology, the central IT organization.
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.
Cornell has an endowment in excess of $7 billion dollars, why wouldn't some of that have been used to ensure the "unique & special" didn't die? Politics?
The developers of screen reader apps are responsible for presenting the information to the user, just like a browser is. It is a mystery to me that they've managed to shove that burden onto every single developer who builds a website. The data is already there and Google manages to extract what's relevant, why can't the screen readers?
To me that argument doesn't make sense... It seems like arguing that because there are wheelchairs that can climb staircases, there's no need to make buildings wheelchair accessible.
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.
No, it's like if we had wheelchairs that were so broken and unstable, everybody had to build ramps with very special and hard to maintain padding on it, which varied between wheelchairs.
It's the responsibility of the wheelchair makers to at least build a reasonably stable product that everybody can support.
Web frameworks are already quite far from any "normal" use of HTML and Web technologies, TBH. They are the problem. Build your website using semantic HTML, test it in a text-mode, JS-free browser, and 90% of common accessibility issues are going to be solved for you, with the remaining 10% still being quite easy to address.
This. I have a strong suspicion that the web was inherently more accessible 10 years ago when it was written in -- you know -- HTML. But now it's not written in HTML as much as in Javascript frameworks, most of which are necessary only to add "flash" (no pun intended) to modern websites but which also hinder accessibility.
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.
Alternatively, there is the approach taken by segments of the US government: choose (and buy) an accessibility test system, point it at the apps, and fix what it reports. Pro tip: single-page apps will routinely pass with no changes.
When I bring up that some accessibility improvement to support the blind doesn't help the deaf-blind (who have much reduced screen readers), the people pushing for accessibility brings up that it would be too costly to support everyone. The irony seems lost on them.
Oops, should be deaf-blind. But you're right: I may have accidentally stumbled upon a market that, apart from cryogenics, has nearly zero products marketed toward them. And what of the living? Why can't they get the whole "dead" experience without the full commitment? I see DaaS (death as a service) with monthly subscription as a completely untapped pool of demand.
My question is why use the web at all? Surely there's an easier way for a blind person to access an information or send data to an API than through an HTML web page.
HTML was that way! "Hey, look, it's a spec where any computer can send a request, and you get a nice, structured text document back that's machine-parseable. It even words for the blind, who can just plug their own preferred reader into the doc! Problem solved."
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.
>and starts using clients that can do ever-zanier things with the UI.
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.
Yes, please. Accessibility requirements that push developers toward static or mostly-static pages tend to also help usability in general even for non-disabled users.
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.
Or to follow progressive enhancement: serve the core content quickly and accessibly and let JavaScript provide improvements. This usually provides significant performance and reliability benefits, too, because your visitors get the core page even if the more complicated code breaks.
That used to be the attitude for a number of sites. There was some form of accessibility mode. Also sometimes a separate mode for printing. The obvious downside is now you maintain multiple UIs.
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.
That's effectively closing off a growing percentage of modern life from people with visual impairments unless you think that places which chose not to follow good web practice would be much better at publishing data to an API they use even less (Googlebot at least used to help accessibility because sites which were all Flash/images/JavaScript wanted to get indexed even if they didn't care about being accessible).
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.
I've been curious about this too. Instead of hacking around HTML to make it accessible, why not just have a completely separate page which is explicitly designed for low vision/screenreader users? Is this a 'separate is not equal' problem?
As an aside, I do not think Apple gets nearly enough credit for designing iOS, WatchOS and MacOS with the needs of the blind and disabled in mind. It's truly a beautiful thing.
Like cars, soon all the websites will look nearly identical. Building your own, your choice will be the background color to use and one of a number of approved fonts you can select from.
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.
I'm not sure if you've ever been in a building, but in case you haven't, I can assure you there's a lot that goes into their design and identity beyond the presence of a wheelchair ramp. Cars look identical because of consumer expectations, not because of the ozone resistance of their brake hoses.
Websites, however, can experience drastic swings in recurring revenue, brand loyalty, all from the addition or removal of a seemingly minor visual interface element. Design = Sales online. If compliance for brick and mortar stores moved out of the entryway and into the mandated height of display cases, counters, signage for colorblind patrons, and mandatory gluten free options there would be a deluge of lobbyists to stop it.
Building onto the other reply to your comment, I think you'd be surprised just how much accessibility regulation already exists that's just invisible to you. You also use highly accessible websites every day, you just don't notice.
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...
To some degree, where its followed at all, where its enforced at all, and when its not convenient exceptions get made. That's kind of my point... If this becomes a crackdown there will be an equally large backlash.
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.