I had the privilege of retrofitting accessibility into a fairly large application that had omitted accessibility for version 1, version 2, and version 3.
Version 4 had accessibility. But in order to put in accessibility, we pretty much had to rearchitect the entire application from stem-to-stern. It was a herculean effort.
The interesting thing, to me, was that the application would have been better architected -- better separation of concerns, better abstraction, better M-V-VM -- from the get-go had it had accessibility in version 1. Why? Because accessibility can be thought of as a second UI.
And if you have 2 UIs on the same engine, you will -- by necessity -- have better architecture. And that better architecture is basically free in version 1. Then version 2 will be based on a better foundation. And version 3 will be based on a better foundation. (There's more to clean code than merely adding in accessibility, but just having 2 UIs puts pressure to have a better architecture.)
And most importantly, you won't need to devote 20 developer years of effort to fix the mess for version 4.
(This was a C#/WPF/.NET application, so was using UIA, and had to be MSAA compatible. And as a free bonus, we got bona fide automation capability as well. Accessibility for websites is a different domain, and has its own conventions to address the accessibility needs. I got to work in that area too -- and for HTML/CSS/JS being mindful for accessibility isn't even hard.)
Thank you so much for sharing this anecdote! I agree, having a good focus on accessibility earlier on can create better and cleaner architecture throughout an application. And as you've shown, the effort to make something accessible multiples exponentially the longer you put it off.
When you start off early, accessibility isn't really that tough. It's just a different mindset and knowing what common mistakes to avoid :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I had the privilege of retrofitting accessibility into a fairly large application that had omitted accessibility for version 1, version 2, and version 3.
Version 4 had accessibility. But in order to put in accessibility, we pretty much had to rearchitect the entire application from stem-to-stern. It was a herculean effort.
The interesting thing, to me, was that the application would have been better architected -- better separation of concerns, better abstraction, better M-V-VM -- from the get-go had it had accessibility in version 1. Why? Because accessibility can be thought of as a second UI.
And if you have 2 UIs on the same engine, you will -- by necessity -- have better architecture. And that better architecture is basically free in version 1. Then version 2 will be based on a better foundation. And version 3 will be based on a better foundation. (There's more to clean code than merely adding in accessibility, but just having 2 UIs puts pressure to have a better architecture.)
And most importantly, you won't need to devote 20 developer years of effort to fix the mess for version 4.
(This was a C#/WPF/.NET application, so was using UIA, and had to be MSAA compatible. And as a free bonus, we got bona fide automation capability as well. Accessibility for websites is a different domain, and has its own conventions to address the accessibility needs. I got to work in that area too -- and for HTML/CSS/JS being mindful for accessibility isn't even hard.)
Thank you so much for sharing this anecdote! I agree, having a good focus on accessibility earlier on can create better and cleaner architecture throughout an application. And as you've shown, the effort to make something accessible multiples exponentially the longer you put it off.
When you start off early, accessibility isn't really that tough. It's just a different mindset and knowing what common mistakes to avoid :)