Good software developers follow the guidelines set out by W3C to ensure accessibility is at the heart of their apps, though perhaps only meeting basic requirements. Great software developers go further by creating accessible apps that empower every user. Sadly, accessibility is often ignored, or the topic is too big to tackle for many organisations. Yet, it’s a fundamental requirement that shouldn’t be ignored if you’re creating software for everyone to use.
In financial services, accessibility is a cornerstone requirement (or at least it should be). With so much sensitive information to hand, and crucial tasks to manage, it’s a potential minefield. Imagine not being able to see your financial dashboard, or hear instructions properly, or have to resort to using ill thought-out, clunky navigation. Imagine clicking images that aren’t labelled properly and suddenly finding yourself in hot water because you’ve sent money to the wrong account.
There are so many examples of accessibility issues for people with disabilities, but this isn’t just about creating environments for specific needs. It’s about creating great journeys that everyone can easily navigate, across lots of devices and browser versions, and using technology that may not pack as powerful a punch as you can afford. Great design is one thing, but not at the expense of usability. There needs to be a balance of function and fashion!
Let’s talk about semantic HTML, baby
It’s not requisite for you as a decision maker to work your way through the W3C guidelines and recommendations yourself. However, your developers should, and the people you hire to build your software environments should. The idea is that good design and accessibility should be available to everyone, so it’s incumbent on your developer to at least know the guidelines and be able to advise you on an appropriate accessibility strategy.
And so to semantic HTML. I know, sounds really sexy doesn’t it? It may not be the most important thing on everyone’s lips when they’re coding, but it’s a starting block for getting everything right from day one. The quickest way to fix 90% of accessibility issues is to code valid, semantic HTML. Let’s take a look at what it is, how it works, and why it’s vital.
Semantic HTML is the use of tags to provide meaning to different parts of a website. For example, instead of laying out an address in a standard block level element like a <div>, we use an <address> tag. This improves intelligibility for screen readers. It has the added benefit of invoking cool functionality on mobile devices, such as opening up Google Maps, your email app, or direct calling with one tap. It’s simplicity like this that enhances a user journey, making tweaks to improve how people use a device. Semantic HTML is the invisible magic that enhances so much of the experience, whether you’re using assistive technologies or not.
Colour contrast checkers
Unlike HTML, something that companies can really help with is colour contrast ratios. Colour contrast ratios are the second most common issue I come up against after semantic HTML, but issues are easier to fix. It’s as simple as doing things like making sure your website doesn’t use difficult-to-read colours for the copy text. For example, yellow font on a white background is hard for anyone to read. Change the background to a dark grey or black, and the contrast quickly makes it easier to read.
There are lots of colour contrast checkers out there that you can run your brand through, but our developers and designers are also available to help with this. Need to check something quickly? Try the WebAIM Color Contrast Checker.
These are but two areas of focus when it comes to accessibility, and there are quite a few more to consider. However, none of them mean a thing if you’re not prepared to work and keep your knowledge up to date. At ieDigital, we run tutorials for developers to help them write accessible code. We stay up to scratch on accessibility guidelines, performing rigorous testing to ensure everything is 100%.
Accessibility isn’t something you should ignore. It’s a vital part of your developer toolkit, and will help you not only improve user journeys for those who need it most, you’ll be improving journeys for everyone.
