I have been a web developer for over ten years now, and it’s not hard to see that accessibility is commonly misunderstood, neglected or point-blank ignored.

This is crazy, right? Considering one of the main objectives of all websites is to attract as many views or users as possible, by not taking accessibility into account, you’re literally turning away users and customers.

Not to mention that a large portion of people with disabilities rely on the internet to assist them in their everyday tasks. So, from a moral perspective, it’s pretty important.


The benefits of making your site accessible

Disabilities that make certain tasks difficult can indeed be mitigated with web accessibility.

For example, shopping for groceries can be made easier with online shopping. Other online activities, like catching up with news or socialising with friends, can also be liberating for someone with a disability.

By not taking accessibility into account you are refusing to provide service to the users who will benefit the most from it.

We must always remember that anything digital can be programmatically translated to a more suitable format for the end-user. A lot of disabled users rely on Assistive Technologies to interact with a computer. These may be responsible for translating textual data into audio or braille, or audio into text (subtitles on videos or text alternatives to sound).

A blind user may solely rely on the internet to access news because their local shop doesn’t provide braille-alternative newspapers. Similarly, food packaging doesn’t typically provide a braille alternative for their ingredients, so online shopping could be vital for blind users who have specific dietary requirements. There is a never-ending list of the benefits that the internet could provide for people with disabilities.

Ultimately by making your website, app or service of any kind accessible, you’re not only increasing your user base; you're also making the world a better place.

What is web accessibility?

Web technology is fast-paced and changes often. Developers all around the world are keeping up to date with these shifts, making sure their websites are responsive and look right on all screen sizes; making sure media is optimised so users on slow connections can still access content fast and efficiently enough, and so on.

These are quite common practices by today’s standards, and probably a few of the most conformed standards of accessibility being used today.

Cross-browser compatibility, responsive design, and speed optimization are all important aspects of website accessibility. However, they remain only a small part of what we all should be trying to achieve.

Web accessibility is about making your website or application usable for as many people as you possibly can, with the intention to keep that notion throughout its lifespan. I am a strong believer that web accessibility is not something that can be achieved in a development phase. You can implement your website to be compliant with accessibility standards, but this doesn’t mean your website is 100% accessible by any means.

Accessibility should be something that can be continuously improved upon, as you learn more and more about your user base.

Accessibility at Reading Room

The team and I here at Reading Room share the same moral perspective on website accessibility and treat it as a fundamental requirement for all our projects.

We specifically aim for double-A standards and ARIA (Accessible Rich Internet Application) as a guideline; however, we don’t stop there.

We attend to the specific functionality of our site components and evaluate with accessibility in mind by following a few points:

  • Making sure the component and its content is defined semantically. This gives a meaningful context to your component and helps Assistive Technologies interpret its meaning.
  • Making sure the navigational flow of the component is suitable for keyboard navigation and that the focus or active states of non-native elements are built so assistive technologies can still acknowledge these states.
  • Ensuring that all live content areas (where data and content is changed/updated without the reloading of a page) have the correct attributes set to them in order to communicate back to the assistive technology that content has been updated or changed.
    We achieve this by using ARIA live regions. A shopping basket is a good example of where we would use this, so when a blind user adds a new item into their basket it may update the number of items added to the basket. If the AT hasn’t been made aware of this, then the user will not be notified that their item has been successfully added.

Following these points, along with double-A and ARIA accessibility guidelines, gives us a good base for providing accessibility. Once we are done with the build of the component, we carry out full accessibility testing to make sure it works as expected before shipping it off to our internal testing team.

As mentioned earlier, this does not mean we have achieved a fully accessible component. It simply means we have developed with accessibility in mind.

We learn how to improve on the accessibility over time by asking for feedback in our accessibility statements and learning more about our client’s user base.

We will always continue to improve on our web accessibility knowledge, developing ways to support that in all our projects.


Do you need help from a web development company that understands accessibility?