You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ultimately we want folks to be honest and not feel like they have to worry about disclosing that their ICT isn't 100% accessible. The most important thing is that we can see that vendors are properly investing in accessibility and that their products and services are improving over time. This requires a big shift in the industry, and isn't something that will happen over night.
Some firms presently put this in the comments, but we could add some default boilerplate language that we recommend.
Users would need to override this to make sure to include their own disclaimer.
I'm not sure how to best avoid the ambulance chasers here, but a disclaimer might help. People are afraid of admitting any accessibility errors, and so some folks hide errors because of fear of litigation. Errors are becoming easier and easier to find with automated tools, so hiding really isn't an option any more.
It could be also useful to highlight things that are outside the scope of your control, for example, Chrome introduces an accessibility bug that shows up in your product.
As a possible draft, I suggest:
"This document is an assertion of [vendor x]'s understanding of accessibility at the time of publishing. This is primarily a technical document to help measure continual improvement."
But this should be considered by the GSA and Access Board. I don't know how often government sues industry for accessibility violations, but I suspect not very often. There is uncertainty and risk in all of this.
The text was updated successfully, but these errors were encountered:
Ultimately we want folks to be honest and not feel like they have to worry about disclosing that their ICT isn't 100% accessible. The most important thing is that we can see that vendors are properly investing in accessibility and that their products and services are improving over time. This requires a big shift in the industry, and isn't something that will happen over night.
Some firms presently put this in the comments, but we could add some default boilerplate language that we recommend.
Users would need to override this to make sure to include their own disclaimer.
I'm not sure how to best avoid the ambulance chasers here, but a disclaimer might help. People are afraid of admitting any accessibility errors, and so some folks hide errors because of fear of litigation. Errors are becoming easier and easier to find with automated tools, so hiding really isn't an option any more.
It could be also useful to highlight things that are outside the scope of your control, for example, Chrome introduces an accessibility bug that shows up in your product.
As a possible draft, I suggest:
"This document is an assertion of [vendor x]'s understanding of accessibility at the time of publishing. This is primarily a technical document to help measure continual improvement."
But this should be considered by the GSA and Access Board. I don't know how often government sues industry for accessibility violations, but I suspect not very often. There is uncertainty and risk in all of this.
The text was updated successfully, but these errors were encountered: