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.
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
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:
- Giving a Damn About Accessibility. If you don't read anything else, read at least this one. Really. It's incredibly short and relevant to everybody, not only developers.
- Google's Accessibility Article doesn't give enough detail but it's a good initial high-level overview.
- An article on how to structure content for reader mode gives a good baseline for hierarchical HTML and even some points on structured data.
- I Used The Web For A Day With Only A Keyboard article from Smashing Magazine. It's a fun challenge and easy to replicate but has surprisingly useful advice on how
- Accessibility - MDN. There's a lot of stuff here. If you read all of the above I'm assuming you want to go beyond the basics; this is where it starts.
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:
- The A11Y Project has great articles, books, a great community, and a solid checklist right on the navbar.
- The WebAIM website has a lot of practical advice, guides, checklists, and tools to help with evaluation.
- The Web Accessibility Initiative W3C Website, and specifically their resources for developers and designers.
- The Web Content Accessibility Guidelines (WCAG).
And lastly, some interesting content that you might be interested in:
- The 2011 World Report on Disability, which I'm still going through. It has a lovely foreword from Stephen Hawking.
- HTML5 For Web Designers. It's a great introduction to the historical reasoning behind the HTML syntax and semantics.
- Bruce Lawson's articles on accessibility. His entire blog is golden.
- The author of Giving a Damn About Web Accessibility has a great book list on the topic.