Getting accessibility right from the start
It’s a sad state of affairs but as society’s demand on the web becomes more intense, our rate of demand for content and web services increases alongside it. With any uptick in demand, something has to give, and more often than not it’s considering accessibility in our web platforms; either cutting corners or ignoring it completely and that’s costing them, and their clients, in more ways than one.
But why is this such a big deal? Why can’t we just update our site post-launch with accessible features? Yes, it’s true that that is an option, but including these considerations from the wire-framing stage can save you considerable reverse engineering, refactors and changes.
Take the bare bones HTML for example – if wire-framing is done properly, adding aria labels to the code at the time of writing will take no time at all, because you’re building the features up iteratively, and so at the time of writing the purpose of each section will be more obvious, and so it can be named more easily, rather than having to trawl back through mountains of code and re-understand it. These nifty tags will allow your code to be read natively by screen readers, which will enable people with visual impairments to navigate your site with ease.
Technical processes aside; there are obvious moral and reputational reasons for designing web applications that are accessible to all people, regardless of any additional needs that they might have. If you have a good experience, statistics show you’ll tell 5 people. If you have a bad experience, you’ll likely tell closer to 20. The same goes for UX and UI; you don’t want to become a beacon of bad practice, a half-baked site that doesn’t cater to its customers’ needs. Your customers will ask, “what other corners have they cut?” and think twice about buying your product or hiring your service.
Quite simply, thinking about the extended needs of your customers is crucial at the wire-framing and conceptual design phase, because doing it retroactively might be too little too late, and will cost you more time (and therefore money) in the long run. You wouldn’t send an application into the world that didn’t make use of responsive technology or one that wasn’t mobile compatible – so why would you build one that people couldn’t use?