Website accessibility is about inclusion
Nathan Barry, full stack developer here at Symbiote, describes why designing and coding websites to make them accessible improves them for everyone.
Developers are missing a huge opportunity if they view accessibility as being about adding a few tags. Well-designed sites enable people with full vision and those with low- or no vision to quickly get the information they need. They also enable technology such as voice-controlled personal assistants to rapidly find and read out information from the web.
Everything changed for me once I understood how different users relied on web-reading technologies
Before working at Symbiote my only experience with accessibility-related tasks ended with adding tags and alt text. I didn’t understand the importance of developing a site that was, for example, used exclusively by people with different assistive technologies.
It was something I didn’t know I didn’t know.
When I started work on the Public Transport Victoria (PTV) Website Continuous Improvements project and saw the detailed accessibility requirements that are baked in to all of Symbiote’s projects I realised that good software development practice involves making sites that are useful for a whole range of people to use in different ways.
We don’t assume that everyone will be using a site by reading it, or that they’re easily able to scroll or click through to find the information they need.
I learned a lot by using PTV’s guidelines and recommendations and Web Content Accessibility Guidelines (WCAG).
Understanding the ways people use different kinds of web-reading methods and technologies underscores how important it is, as a developer, to stick with correct and consistent usage of structure, tags and labels.
The correct tag can make the difference between annoying a customer and them missing something completely.
Think about how irritating it would be to try to pay a bill online on a page without seeing the error message that says the form failed to submit. This happens routinely to people using screen readers to read webpages aloud to them when error messages aren’t coded properly by developers.
It’s not enough to throw a description on an image and think you’ve done your bit for accessibility
Everyone sets up all their devices with different settings and preferences. People using screen readers are no different – they set and use screen reader technology in different ways to scroll through pages. They might tab through to find links and buttons to click, or scroll using the keyboard arrows to go through each piece of content on the page. It can take a very long time and be frustrating or even dangerous for someone if webpages aren’t set up with appropriate tags or structures for a screen reader to prioritise them or show them at all.
To use the myki website as an example, we need everyone using that site to immediately get alerts about system delays or safety information. Screen readers will only read out those alerts as a priority if they’re coded correctly, otherwise they’ll be there on a webpage, but might not be read out until a lot later – which might be too late for the commuter who’s affected by that information.
We carefully consider the colours and contrasts we use on text, buttons and backgrounds. This ensures that people with different kinds of colour blindness or low vision can see all the important parts of the page clearly.
User testing and feedback is essential
The importance of user feedback was brought home to me just the other day when someone who routinely views websites at 200% zoom told us that they couldn’t use one of the features on the page we were developing at this zoom size.
We have all our webpages for this project audited by Vision Australia. They give us a list of findings and recommendations to make improvements. This is particularly valuable because it picks up changes or updates that might render pages hard or impossible for people to use if they have low vision or no vision, or need captions on videos.
I learn a lot from watching our testers using screen readers to read through pages I’ve created.
For example, on myki webpages when we display card numbers for a user’s myki card, these are usually masked so sightetd users see the last five digits of the card. A screen reader wouldn’t know how to tell the reader there was a masked section, so we added text to say “MYKI card ending in –” and then the digits.
What if we viewed coding for accessibility as just ‘good coding’?
I think that the care taken to code for accessibility is the care we should take anyway, to make great websites that are useful to a range of people and tech.
We all increasingly rely on hands-free technology that searches sites and reads information aloud to us – think Google Home, Siri and Alexa.
If your site isn’t structured with the right tags, elements and roles it could be overlooked or of limited use to these kinds of technologies. It makes sense to make websites work for everyone, whatever kind of technology they use to read them.
Doing this work has changed the way I see the world
I definitely take more notice in my day-to-day activities, thinking about how people get around and find the information they need to do things I take for granted as a person who doesn’t currently rely on assistive technologies.