Learn About Web Accessibility

What's Beyond the Screen

One of the speakers at DjangoCon giving a talk during the event.

Web accessibility is an essential pillar in developing and designing websites and applications that everyone can use. Tim Berners-Lee, the creator of the World Wide Web, has said,

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

This article stems from an internal talk I presented for the Octobot team last November. I’m a software developer, and last year I had the privilege of attending DjangoCon US 2023 as a speaker (and first-time conference attendee). Part of the inspiration for my talk to the Octobot team, and for this blog post, comes from a talk presented at last year’s DjangoCon, titled “Django’s Accessibility Track Record”. It explores the importance of web accessibility and the long journey still ahead to make the web truly accessible.

I was surprised to learn that despite the fact that around 15% of people live with some type of disability, over 96% of the top 1 million homepages have basic accessibility issues. This is something that needs to change. Web developers, designers, product owners, anybody and everybody that’s involved in the process of creating a web application: we need to do better.

In this article I’ll share some basic accessibility guidelines, as well as some tips and tools you can begin implementing.

Different People, Different Ways to Navigate Websites

The first step toward building accessible websites is to understand that there are multiple ways of navigating through one. You might be used to using your mouse, but this is not the only way people browse the Web.

  • Keyboard Navigation: Websites need to be navigable without using a mouse, since some users use only their keyboard to interact with a website. This means that all actionable items (buttons, forms, links, etc.) need to be reachable using the tab key to navigate.

  • Screen Readers: Screen readers are used by blind and visually impaired users; they read aloud what’s shown on the screen, and provide ways to directly access certain content (for example listing all links or headings). Screen readers are meant to be used only with the keyboard, so navigation without a mouse is particularly important.

  • Voice Recognition: Voice recognition interfaces allow navigating and interacting with a website through voice commands. This can be useful for different users, for example, those with mobility impairments.

Semantic HTML and ARIA Attributes: The Foundation of Accessibility

Using semantic HTML is essential for creating an accessible website. “Semantic HTML” means using HTML elements that describe content meaningfully; you can likely create any website using <div> elements almost exclusively, but you should strive to use the most appropriate element in each case, i.e <button> for buttons, <form> for forms, <h1> for  top-level headings, and so on. There are over 100 HTML elements choices!

One of the reasons  semantic HTML is particularly important is that assistive technologies, such as screen readers and voice recognition interfaces, infer meaning from different HTML elements. For example, when using a <button> element  the screen reader will read the element as a button and offer the user the option to click it; if the “button” was implemented with a clickable `<div>` element, the screen reader will not know it is a button, and will not be able to let the user know that it is clickable.

Comparison of the basic HTML layout of an example website: non-semantic HTML uses just div and span elements, while semantic HTML uses header, nav, aside, main, article, figure, p, section and footer
Source: Semrush blog post (https://www.semrush.com/blog/semantic-html5-guide/)

We can use Accessible Rich Internet Applications (ARIA) attributes and roles in order to enrich the semantic information conveyed by our HTML, so that assistive technologies can infer more meaning from our content, allowing for a better user experience.

Some examples include:

  • aria-label: Defines a label for the element, useful when visible content cannot be used; an example could be for labeling an SVG (since it’s not a <img> tag, it cannot have an alt attribute). 

  • aria-labelledby: Uses the ID of another DOM element as a label instead of setting it directly. This is useful when the items that label a particular element are already visible (represented by other DOM elements).
  • aria-description and aria-describedby: Provide additional descriptions or context for an element, offering information beyond what the label provides.

  • …and many more!


It’s not necessary to memorize all ARIA attributes; the key is to be aware of their existence and consult the reference list when needed. You can always look up things like “how to implement an accessible modal” (or whatever component you’re implementing) and see what’s the standard way to implement it. The W3 ARIA Authoring Practices Guide (APG) provides useful guidelines for implementing different patterns.

Before getting started with ARIA, I recommend reading the “Read Me First” section of the ARIA Authoring Practices Guide.

Accessible Design Systems: Facilitating Inclusive Development

The implementation of accessible design systems can be an effective strategy to ensure consistency and accessibility in web projects. An easy solution is using well-established design systems, such as Material Design, that already integrate accessibility principles into their components. This can streamline your development process and reduce the likelihood of overlooking basic accessibility issues. 

When designing and implementing a custom design system, it’s important that accessibility is taken into consideration from the get-go. Both the design team and the development team need to work together to ensure each component is accessible.


Automated and Manual Checks: Ensuring Accessibility

Integrating both automated and manual checks into development processes is essential for maintaining high accessibility standards. There’s a useful Chrome extension called Accessibility Insights for the Web, which can run some automatic checks and provide guidelines for manual testing.

The tool allows evaluating different accessibility criteria such as color contrast, keyboard navigation, and accessible names for the site content. It also provides an extensive list of  criteria that needs to be checked manually, as well as instructions on how to test each criterion. 

Another way to improve accessibility is to test your web applications using a screen reader and voice recognition interface. This will give you more insight into how assistive technology users will experience your site. To learn more about this, you can read this blog post explaining how to set up a screen reader on your computer.


Practical Tips for Developers:

  • Semantic HTML: Choose each HTML element carefully: the chosen element should convey the meaning, or semantics, of the element (don’t just use<div> for everything). Organize headings hierarchically and use appropriate tags in forms.

  • Alt Attribute for Images: Assign descriptive and human-readable alternative text (alt) to images, avoiding redundancies such as adding the word “image” to the alt text. Remember that alt text also benefits users when the image fails to load.
  • Styles & Contrast: It’s important that all text is readable! You should be aware of the contrast between your foreground text color and your background color, and make sure font sizes are appropriate. You can use a contrast checker to see if your styles are accessible according to the WCAG standards.
  • Include accessibility checks in your development & QA processes: You can use tools like Accessibility Insights for the Web to help find accessibility issues in your application. You should also test your application using assistive technologies such as screen readers to understand how users will experience your app.


A Collective Commitment to Accessibility

As developers, we can make a difference in the day-to-day lives of our users by making our web applications accessible. From using semantic HTML and ARIA, to designing with all users in mind, our decisions have a significant impact on the user experience of our applications. This is a shared responsibility that requires collaboration and awareness. By adopting these practices, we contribute to building an inclusive and user-friendly online environment for everyone.

We invite you to apply this knowledge in your projects and communities, fostering positive change toward a more accessible web. Web accessibility is not a change that happens overnight, but rather an ongoing commitment. We need to continue improving our applications to create online experiences that benefit a diverse audience and enrich digital connectivity for all.

To learn more about accessibility, I recommend The A11y Project, which contains multiple resources such as blog posts, videos, tools, and more. 

To read more about creating good platforms that go an extra mile, head to my colleague’s post about creating experiences users love.

See related posts