4 ms·

You're not just changing the website as it stands today...you're changing the entire workflow of their dev team.

by metaphor 9y ago

madeofpalk 9y ago
im not too sure - I think people are vastly overestimating/overcomplicating what it takes to make a site WCAG-friendly.
- metaphor 9y ago
  Herein lies the fundamental problem: you're not too sure...except in a certain unwaivering resolve to trivialize the significance of impact to an existing product/workflow. Gratuitous handwaving is no longer the name of the game. 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; [1] https://www.w3.org/TR/WCAG20/ https://www.w3.org/TR/WCAG20/
matthewmacleod 9y ago
I'm struggling to see where the cost is. It amounts to 'when you develop a new feature you must make sure it meets WCAG guidelines'. You probably already have a process in place to make sure that it's (e.g.) valid HTML.
- metaphor 9y ago
  We're not talking about developing a new feature, are we? We're talking about wholesale refactoring of an existing product/workflow, if not a complete redesign depending on scope of impact. 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.
  - matthewmacleod 9y ago
    We're not talking about developing a new feature, are we? 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.
    - metaphor 9y ago
      > I think we are, in the context of what I was responding to there. 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.
ubernostrum 9y ago
I've said it elsewhere in the thread, but: being so badly inaccessible that you can get a court judgment over it 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. 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.
- metaphor 9y ago
  > being so badly inaccessible that you can get a court judgment over it 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.
  - ubernostrum 9y ago
    In order to get an ADA complaint to succeed, the website has to be inaccessible. Getting the "heavily integrated" ruling wouldn't get a judgment against an accessible site. And yes, you really do have to go out of your way to build something a modern screen reader can't handle.
    - metaphor 9y ago
      From the defendant's motion for judgement[1]: The viability of Gil's claim hangs on the single legal determination: whether Winn-Dixie's website is a place of public accommodation that is subject to the ADA. 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/12/Motion-for-Jugdment.pdf http://www.adatitleiii.com/wp-content/uploads/sites/121/2016... [2] https://www.plainsite.org/dockets/3067htvmz/florida-southern-district-court/gil-v-winn-dixie-stores-inc/ https://www.plainsite.org/dockets/3067htvmz/florida-southern...

You're not just changing the website as it stands today...you're changing the entire workflow of their dev team.

madeofpalk 9y ago

im not too sure - I think people are vastly overestimating/overcomplicating what it takes to make a site WCAG-friendly.

metaphor 9y ago
Herein lies the fundamental problem: you're not too sure...except in a certain unwaivering resolve to trivialize the significance of impact to an existing product/workflow. Gratuitous handwaving is no longer the name of the game. 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; [1] https://www.w3.org/TR/WCAG20/ https://www.w3.org/TR/WCAG20/

matthewmacleod 9y ago

I'm struggling to see where the cost is. It amounts to 'when you develop a new feature you must make sure it meets WCAG guidelines'. You probably already have a process in place to make sure that it's (e.g.) valid HTML.

metaphor 9y ago
We're not talking about developing a new feature, are we? We're talking about wholesale refactoring of an existing product/workflow, if not a complete redesign depending on scope of impact. 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.
- matthewmacleod 9y ago
  We're not talking about developing a new feature, are we? 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.
  - metaphor 9y ago
    > I think we are, in the context of what I was responding to there. 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.

ubernostrum 9y ago

I've said it elsewhere in the thread, but: being so badly inaccessible that you can get a court judgment over it 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. 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.

metaphor 9y ago
> being so badly inaccessible that you can get a court judgment over it 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.
- ubernostrum 9y ago
  In order to get an ADA complaint to succeed, the website has to be inaccessible. Getting the "heavily integrated" ruling wouldn't get a judgment against an accessible site. And yes, you really do have to go out of your way to build something a modern screen reader can't handle.
  - metaphor 9y ago
    From the defendant's motion for judgement[1]: The viability of Gil's claim hangs on the single legal determination: whether Winn-Dixie's website is a place of public accommodation that is subject to the ADA. 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/12/Motion-for-Jugdment.pdf http://www.adatitleiii.com/wp-content/uploads/sites/121/2016... [2] https://www.plainsite.org/dockets/3067htvmz/florida-southern-district-court/gil-v-winn-dixie-stores-inc/ https://www.plainsite.org/dockets/3067htvmz/florida-southern...