I think the people who you perceive as "overestimating/overcomplicating" have first-hand understanding of what it truly takes to execute formal process and verification which unambiguously demonstrates compliance, given:
1.) the courts are now involved...this in itself introduces an unprecedented level of complication;
2.) product and workflow are already established;
3.) legal mandate requires compliance with qualitative guidelines[1], as opposed to hard specification;
4.) scope of applicability and impact to existing product/workflow have yet to be determined...requirements traceability based on interpretted guidelines will almost certainly be a cluster fuck;
5.) a level of uncertainty from guideline disclaimers, e.g., even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability.
6.) use of non-standard, 3rd-party tools (e.g. screen readers) clearly had an impact on legal decision, which suggests additional impact to compliance verification;
Keeping your quote in context, where did it come from and when did this become a requirement? As far as I can tell, this only became scope when a legal decision was made that classified Winn-Dixie's website as heavily integrated, rendering ADA compliance applicable.
I think we are, in the context of what I was responding to there. It means changing the workflow of the team, such that accessibility constraints are taken into account. Teams already operate with constraints like that; I don't see it as a remarkable change of workflow.
We're talking about wholesale refactoring of an existing product/workflow, if not a complete redesign depending on scope of impact.
No, you're not. Unless you have produced an already catastrophically ill-designed product, your accessibility adaptations will not involve substantial redesigns.
I respectfully beg to differ. At best, you've made quite gratuitous assumptions on impact to workflow realignment, which assumes requirements traceability and formal verification was even a thing this team was already familiar with. Sure, some teams may already operate with constraints like that, but we're talking about this team, which may or may not conform to your standards definition; all other teams are irrelevant.
> No, you're not. Unless you have produced an already catastrophically ill-designed product...
The phrase ill-designed product is objectively meaningful in the context of hard requirements. Until this legal judgement, ADA compliance simply wasn't a requirement...hindsight is 20/20.
Suffice it to say we know nothing of their team's competency, existing architecture, scale of product, workflow complexity, verification process, level of impact, funding availability, etc. In other words, we know absolutely nothing, so it's unsurprising that you're struggling to see where the cost is. From a risk management perspective, you've taken an optimistic hand-waving stance in the face of so many uncertainties. With the courts involved and legal mandate on the table, do you really think the game being played hasn't changed? For the sake of this web dev team, I hope you're correct.
Getting on the wrong side of simple guidelines like WCAG really does require actively user-hostile processes from the dev team, and if that can be shut down via lawsuit, then hooray.
How you've twisted the facts...judgement was based on the determination that Winn-Dixie’s website is heavily integrated with the company’s physical store locations, making it subject to the ADA...key phrase: heavily integrated...which was the point of contention. Judgement was based on the applicability of ADA to a company's website, not the scope of how badly inaccessible the website was.
> ...requires you to be expending effort and time and money to screw up. It's not something that you just accidentally do out of ignorance.
Because web design is a static practice that never changes, right? With as much dynamic crap associated with the latest UX trend these days, it's surprising that anything modern conforms to a generalized definition of accessible.
And yes, you really do have to go out of your way to build something a modern screen reader can't handle.
Only from this determination does everything else follow.
Citing the list of issues remaining to be determined from opinion, verdict and order[2]: (2) and (3) are contextually relevant questions iff (1) was judged in the affirmative.
> And yes, you really do have to go out of your way to build something a modern screen reader can't handle.
On this note, I suppose we simply agree to disagree.
[1] http://www.adatitleiii.com/wp-content/uploads/sites/121/2016...
[2] https://www.plainsite.org/dockets/3067htvmz/florida-southern...
And the only way there's a violation for the court to deal with is if the site is inaccessible.