Accessibility – What is it and why should you care about it?

Samara Dionne

Samara Dionne

Developer at Cogent

(Featured photograph by Yomex Owo)

I’ve been developing web applications for a little over a decade, ranging from simple brochure sites, to highly interactive content management systems, to government compliance portals. At the end of these projects, I would measure success by the client’s happiness. However, I quickly realized success is not only achieved through what the client wants, but also through listening to the users. My focus changed from “Does it look pretty?” to “Can the user access the information they need?” There is so much more involved in creating a website than just making sure an application matches the designs.

Approximately 1 in 5 Australians have some form of disability. Disabilities can range from (but are not limited to) visual, auditory, physical, speech, cognitive, language, learning and neurological. Disabilities may be permanent or temporary, they may have been present from birth or happened later in life. You never know what life will throw at you, and your application needs to consider all users.

Generally, we build tools that are trying to solve a problem. We want the tool to be easy to use and able to help the largest number of people. To ensure this, we need to consider who we are building our application for. This is something you might think only applies to visual designs, but it actually cascades throughout the entire project. The user needs applications that are visually understandable and content that is digestible and accessible on all types of devices. By considering all three aspects, we expand the reach and improve the accessibility of our application.

(Screenshot from Guide Dogs Australia’s website)

So what is an accessible application? To determine this, we refer to a community maintained document called the Web Content Accessibility Guidelines (WCAG). Based on the criteria from WCAG, a website can be categorized as having A, AA or AAA levels of conformance.  AAA is the highest of conformance levels, which means that the requirements to achieve it are a lot more strict. An example of a AAA website is Guide Dogs Australia; they have large type, easy to understand content, controls (in the menu) that can increase font size or turn on high contrast, and the website can be entirely navigated via keyboard (try ‘tabbing’ through the site!). For AA examples you can refer to any Victorian Government website, as they are required to conform to a minimum of AA compliance.

You may be thinking, you don’t need your website to be accessible, your users do not require additional tools to use your app, or maybe a bigger font just doesn’t work with your brand guidelines. Well, there are other reasons you should consider making a website accessible. What if I told you that accessibility will help boost your search engine rankings? There is overlap between good SEO (Search Engine Optimization) and WCAG compliance. 

(Photograph by Daniel McCullough)

Making accessible applications doesn’t have to be hard. If you start off your project with a good base, everything will work out as long as you follow some guidelines. If you have an already established application, that’s okay too, it will take a little more work, but your users will thank you in the long run! 

It’s important to note that the WCAG provides a lot of guidelines, but it is not exhaustive. There may be scenarios where there is no specific rule on making something accessible. In these situations, you should apply the four principles of accessibility (POUR) to make the best decision for your users.

Principles of Accessibility


The application must be perceivable by at least one of a person’s senses. Perception can mean supplying text for those who cannot hear, providing audio for those who cannot see, applying enough contrast for people with color blindness, or making the application digestible by screen readers and other assistive devices. 


The interface must be operable, a user should be able to interact with every intended element. For example, someone with a broken hand may not be able to operate a mouse, and can only navigate a website using a keyboard. 


The content should be understandable and digestible. Examples of this are: having a logical flow of content (such as grouping content via headings), using simple language when possible (year 8 reading level is suggested), providing definitions for uncommon expressions or idioms, and making sure the content is easy to navigate.


The website should be accessible via as many browsers, devices or operating systems as possible. A user should not be required to have a certain version of a browser or have a particular plugin installed to use a website. For example, some users may be unable to update their software (possibly due to external factors), but they should still be able to use the website. 

With those overarching ideas in mind, let’s take a look at some tools that will help start you off in the right direction!

Testing for Accessibility

There are quite a few tools out there that will do most accessibility testing for you. If you are required to adhere to a minimum of AA conformance, I highly recommend using an agency or paid service. However, to get you started I’ve compiled a list of a few of the free tools that I like to use:

WAVE Evaluation Tool

(Screenshot of using the Wave Chrome Extension)

This is a Chrome Extension that will give you visual indications of what is being evaluated and how it can be improved. If it seems too visually cluttered, there is a </code> view you can use to see exactly what the tool is referencing. 


(Screenshot of the A11Y checklist)

The A11Y project has a lot of resources for accessibility. One of my favorites is a simple but fairly thorough checklist for building and designing your applications. This list is good for everyone including designers, developers and content writers.

Contrast Checkers

(Screenshot from

It’s important to consider color combinations and if they are contrasting enough to be easily read. This is something you should consider at the beginning of a project. For example, you should test if a shade of blue (#1e8dfc) will work against a black background. But you also need to test the color in relation to the size of the font, as the thickness of the type can affect legibility. 

There are quite a few tools that you can use test this, but these are my favorites: 

    • Nice interface, and offers suggestions on how to improve contrast 
    • ContrastChecker Includes a bit more detail on how far away you are from achieving contrast, shows what level of compliance you’d be achieving and a grayscale mode.
    • Webaim Classic no-frills option
    • Color Contrast CheckerSoftware option (Mac and Windows available), easy to use interface, quick calculations and takes all types of color codes (Hex, plain text, RGBA)

Be mindful of what level of accessibility you need and the tool you are testing with, as a test may pass if it’s only checking against AA contrast values. 

Screen Readers 

If you’ve never used a screen reader before, I’d highly recommend going to your favourite website, turning it on and closing your eyes. Now try to complete a task using only the audio prompts. How easy is it to use? Does the content make sense? How long did it take you to get to what you wanted? 

Screen readers are included in most operating systems, but they may not be intuitive to new users. I prefer to use the Chrome extension “Screen Reader” as it has a lot of commands and shortcuts to help you jump around the site. It’s a bit tricky to use at first, but that may be from trying to use both your eyes and ears to navigate!  

There is no one size fits all solution for making an application accessible, and it’s not always easy to consider everyone’s needs. What is simple for you to navigate, may be difficult for your friend or colleague! We need to collaborate, iterate and consider accessibility at every step of a project. It’s on us to make our applications as accessible to the greatest number of people that we can.

Sounds interesting to you? Find out more about working with Cogent here.

Liked this post? Share it on…

Share on facebook
Share on twitter
Share on linkedin

Related posts

Rachael Geaney

Our adaptation to distributed working

Multiple variables such as roles, work requirements, locations, business and client needs, impact how we work. There isn’t a one-size-fits-all solution and we needed to create a new, evolving framework that aligns with Cogent’s values. One that clearly defines the optimal balance of remote and distributed work, enabling the highest quality of work whilst protecting the health and well-being of Cogent, its people and our clients.

Read More
Anwesha Chatterjee

Remote Pairing – Do’s and Don’ts

Whilst pairing has been a fairly consistent part of my years as a software developer, Cogent was where I first started remote pairing. I’ve found the remote aspect of the experience amplifies certain challenges so in this post, I share some of the lessons I’ve learnt.

Read More
Sam Chalela

Deploying micro frontends with module federation and Next.js

Micro frontends are an architectural pattern that has become a hot topic in recent years for many good reasons. It has helped organisations break complex UI applications into smaller, more manageable pieces, as well as enabling teams to work end-to-end across a well-defined product or business domain whilst maintaining a consistent user experience across the entire app.

Read More