Intro
We, the developers, are always trying to write clean code and keep in mind that other developers will have to read through our code, understand it and able to work in it.
We write documentation, we carefully choose our variable names to make it clear what that variable contains, we write clean functions and name the functions to best describe what its functionality is. How come we don't do the same for our end users, by writing accessible html so all of our users can use our site ?
And what if you knew that 1 billion people, or 15% of the worlds population, experience some form of disabilities? Shouldn't this then be baked into our code?
And what if I told you that accessible web is a basic human right?
Under the hood
I wanted to dig deeper and really understand how accessibility works and how our code, our browser and screen readers work together.
All browsers have an Accessibility API, which is built into the browser application. This Accessibility API exposes public properties and methods that can be queried by third party applications, such as screen readers, to retrieve information from the DOM. You can think about this like a hand shaking procedure between the screen reader and the browser.
Lets look at an example where you are the developer. You want to check on your work and see if your site is accessible. As you are tabbing through the page and hear or read the word "link" from your screen reader, you know that you are never using the word "link" in your code. The screen reader is conveying that the role of the anchor is a link.
The Accessibility API is exposed to the role of the element in one of it's public properties or methods, which the screen reader queries as it renders the page in the Virtual Buffer. The screen reader reads that in the browser's opinion, the element is a link, so the screen reader reflects this element type in the Virtual buffer.