Search for a command to run...
At least one billion people with disabilities live in a world that was designed for somebody else. Good accessibility, HTML, and semantics can help.
No comments yet. Be the first to comment.
Today, May 19, 2022, is the 11th Global Accessibility Awareness Day. This article is a tiny contribution and an attempt at educating myself further on the matters of accessibility.
According to the 2011 World Report on Disability, at least one billion people out there live in a world that was designed for somebody else.
One billion people that suffer discrimination, have diminished employment opportunities, and simply struggle with things more in life. As it's frequently put, people with disabilities are the largest minority in the United States.
That is an absurd situation to consider at a personal level. However, it's hardly something difficult to put into perspective at scale.
Think of how your grandma might rely on you to make bank transactions or to get past a checkout page. Or how hard it was to get around places that one time you broke your foot. Or that one time you injured your wrist and had to rely on your keyboard to navigate the web.
These are all examples of assistive technology of some kind.
The truth is, that one billion number, although astounding, still doesn't paint the full picture! Accessibility is not only for people with disabilities but for everybody that for one reason or another has to rely on some external tool to get around.
And that is only the direct impact it has.
I find the engineering aspect of accessibility fascinating: in March 1989, Sir Tim Barnes-Lee first proposed the web as a gigantic collection of linked documents. And in 1994 he moved to MIT to found the World Wide Web Consortium (W3C), which has since been developing standards to enable data to be available to as many devices as possible, while also trying to keep up with the ever-growing technological boundaries.
Does that sound familiar? Well, it most certainly should! Accessibility, and what I've come to understand as availability are two sides of the same coin.
Web developers are always interested in making websites available to as many browsers and user agents as possible, but there is barely any reasoning to do so if these machines are not able to understand the content we have there.
That's where accessibility comes in: inaccessible software is essentially gibberish to humans and machines alike.
The very first step to accessible websites, is to understand the value and relationship of semantic syntax, which is used across all kinds of user agents to display content properly, including, but not limited to, your browser, a screen reader, and even your watch.
Here's a screenshot and excerpt of an Apple video introducing watchOS 5 showing how, for an input to fit on the screen and be usable, we want it to have a correct type and label.
First, choose the appropriate type attribute and element tag for your form controls.
WebKit supports a variety of form control types including passwords, numeric and telephone fields, date, time, and select menus. Choosing the most relevant type attribute allows WebKit to present the most appropriate interface to handle user input.
Secondly, it’s important to note that unlike iOS and macOS, input methods on watchOS require full-screen interaction. Label your form controls or specify aria label or placeholder attributes to provide additional context in the status bar when a full-screen input view is presented. — Designing Content for WatchOs
Consider how an input without a proper label, for example, would not have a relevant message on the status bar, or an input with the incorrect type could be cumbersome or entirely unusable on your watch. This is exactly the same issue people face using screen readers, and both are quite easily solved by good semantics.
The video contains more information on watchOS specifically, but the great thing about HTML is that the general definition applies, well, generally! Browsers and extensions reader modes do, microbrowsers do, and if your fridge has a screen, it will also work there!
But these are examples of stuff that takes the data from a webpage and completely restructures it for a specific need—say as a Screen Reader has to speak your content out loud, or Twitter has to create a preview of your link—, but this hardly is all the benefits we get from proper accessibility. Everybody dislikes text with poor contrast, and a tiny radio button without a label to click is always frustrating.
But accessibility is still much more than this.
I fussed about the title of this article for a while, but you might notice that it says it's an overview. It's not an introduction, tutorial, or guide, because that would not fit in a single article. Instead, I opted to provide you with the best resources I could find and my perspective on the topic.
And I understand that my perspective is very inclined towards the mechanical, and how very well aligned accessibility is with the core structure of the web. But accessibility is not about standards, it's about the people, and nothing I could put on paper would replace good user research and empathy.
That being said, when it comes down to it, following a checklist of simple well-defined standards is something 98% of the top one million websites won't do. Practically anything you do would put you ahead of the curve.
The starting point is giving a damn. Since you got to the end of this chapter, clearly, there is a significant chance you do. — Giving a Damn About Web Accessibility
The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability. — W3C - Accessibility
With the web development community putting so much effort into the JavaScript framework race, it seems that this kind of fundamental knowledge has lost its place in the spotlight. Which I'm not talking from experience here—I myself was exposed to this marvelous world at the height of the JavaScript fatigue era.
So it felt weird to me when I started researching this topic and noticed how much of a mathematical axiom accessibility and semantics truly seemed to be for development and design, and how much it impacted a lot of people's life.
Personally, I found that learning these concepts and applying them early on added next to no overhead to my development process. In fact, semantics is where I see myself going back to whenever I start wondering where a piece of code should go.
This is the main material I would recommend to anyone that is interested in starting on the topic. The order doesn't matter, but to be most straightforward I numbered them:
focus work.The next few links are much denser. They are not intended to be read top to bottom, but instead to be referenced throughout your career:
And lastly, some interesting content that you might be interested in:
This article was first published on my blog. You can also find me on Twitter and on GitHub.
Thanks for reading!