Accessibility 101
Tags: a11y, webdev, frontend, design
Published: 2023-03-07 07:25:00

---
title: Accessibility 101
published: true
description: Summary of Introduction to Web Accessibility as taught by W3Cx
tags: a11y,webdev,frontend,design
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dfwn0qdfu8ckpb3d3dm9.jpg
# Use a ratio of 100:42 for best results.
published_at: 2023-03-07 07:25 +0000
---
I spent about 10-15 hours on edx's [online course](https://learning.edx.org/course/course-v1:W3Cx+WAI0.1x+3T2019/home) on *Introduction to Web Accessibility*, authored by W3Cx, which seems to be a collection of trainings straight from the people in W3C (in W3C's [WAI](https://www.w3.org/WAI/) for this one, to be more precise).

I'm writing this so you don't have to spend the same amount of time on the course; although if you care about the Web and its fundamental principles, I strongly encourage you to do so. It's free and it's enlightening.

My prior knowledge to Accessibility, before attending this course:

 * there are contrast thresholds readable text should meet
 * use descriptive `alt` attribute for images
 * use appropriate css units for sizing font (`em`)
 * one should be able to browse a website or use a web app without a pointing device (keyboard only)
 * something with `aria`
 * there are some online evaluation tools that can score the accessibility of
   your website
 * a11y is the [numeronym](https://en.wikipedia.org/wiki/Numeronym) for accessibility

And that was it.

What I was looking for:

1. Theory, but in a practical approach. School was cool, but we need real life
   usable stuff shipped
1. Structure
1. Fundamentals on which to build upon - not just *tips and tricks*

## Theory

All great stories start with a history lesson, and accessibility makes no exception. 

> The power of the Web is in its universality. Access by everyone regardless
> of disability is an essential aspect said Tim Berners-Lee, W3C Director and inventor of the World Wide Web.

And because we're greedy and hungry for the greatest, the fastest, the bestest ways to grow a business, policies and laws were required to come in place and protect **people**. People are imperfect - we don't see, hear, move, or infer with the same acuity, and most often than not, not because of their own fault; not that it would matter. People are people, and in the society we want to live in, we ought to use technology in the *interest of all the human beings*. Not just the young, the sharp, the healthy, the genetically lucky ones, the ones privileged in the society. Let's remove the word *privileged* as much as we can.

The course is not intentionally sentimental; but it does showcase people with all sorts of disabilities. You will step into the shoes of the disadvantaged people. You will become emotional, realising how lucky you most probably are. Statistically, there's an 85% chance you have all your senses and your motor function in good shape to browse to and to read and understand the content on dev.to. Some people would have to use a keyboard with the aid of a stick in their mouth to get here.

WCAG - Web Content Accessibility Guidelines version 2.1 is what you're aiming to adhere to, when offering your services on the web. I like how the course is spot on from the start: *Don't jump to the standard*. Half of it explains how the other half should be read. It's a show stopper. Instead, the course introduces a less scary approach. And provides structure.

## Structure

There are two types of approaches people use to improve the way they interact with technology:

1. Through the means of *assistive technologies*, meaning software or hardware
   that help people more easily operate. I.e. a screen reader, a switch control,
   or even the ordinary glasses!
1. By employing *adaptive strategies* such as enlarging font size, changing
   contrast, resizing a window. Some people need to enlarge font and window
   width, others, surprisingly, read better when the text is smaller and the
   line length is much shorter.

Second module of the course focuses on these two, grouped by the types of disabilities: physical and visual, hearing and speech, cognition and learning.

Third module is all about business cases and benefits; probably the most dull, at least for me. Accessibility needs no business case, but in case you need some, they can be easily found.

Fourth module is the real deal, diving into *WCAG 2.1* fundamentals.

And the fifth is just as dull as the third. It's how to lure the important stakeholders in the organisation into accessibility. How to *get started*. I'm not sure one can make a real-life working guide on that, but I should however appreciate the *Shift-left* recommendation. I'm seriously starting to laugh every time I hear *shift-left*. So much shifting that one starts to wonder what's left on the *right-side* of the delivery, but that's for another story.

Key takeaway on the shifting is probably that particularly the persons involved  at the start of the product design process (product designers, UX architects, project managers)
**need** to have a working literacy on Accessibility, so issues are addressed earlier in the process. Don't leave Accessibility for the last week before first MVP go-live.

## Fundamentals

W3C WAI contributes with not one, but three guidelines:

1. WCAG - Web Content Accessibility Guidelines; the most popular ones, regarding Web Content.
1. ATAG - Authoring Tool Accessibility Guidelines; guidance in building
   accessible software used by content creators. Imagine the admin panel of a
   blogging platform. Or the "Create a Post" page of a social network.
1. UAAG - User Agent Accessibility Guidelines - for browsers, media players and
   other user agents.

WCAG defines four principles:

1. **Perceivable** - techniques for making information available in different ways.
1. **Operable** - In addition to perceiving info, users should be able to operate,
   to navigate, fill in and submit forms, have some sort of interactivity with
   the application; in order to do so, they might employ a mouse,
   or no mouse at all and stick to keyboard only, sip and puff, speech input; yes, some people
   are limited to simple switches because of their lack of mobility and their
   difficulty in speaking.
1. **Understandable** - both information, and functionality; use simple vocabulary,
   make intentions clear, be explicit on what is required and in which form.
   Don't make the user think or guess what is expected on his/her side.
1. **Robust** - Reliability when rendering the content or running the
   application on a variety of platforms. If it's a web content or app, it
   should run without issues in any present or future version of a major browser.
   If it's multimedia content, we should expect to behave the same on multiple players.

### Technical dive-in

On a scale of 1 to 5 on technical expertise, you need a 2, but it's not a hard requirement to follow through. The course only scratches the surface, for both web content and mobile apps - iOS and Android.

You will need some tiny knowledge on HTML and to be able to grasp basic native UI elements, like backward and forward navigation, gestures and haptic. That's it. The material *is not designed* for engineers. It's universal.

## Key takeaways

**Accessibility** is important for anyone who cares **about people**, before any policy or checkbox that we need to tick off, in our large business or for our small project. Following accessibility guidelines never stops, it's not a one time process. It needs to be embedded in the design and delivery process. The sooner, the better, the cheaper. Just like you strive to do with your other non functional requirements.

You only truly know your accessibility makes a difference when testing with **real people**. Evaluation tools can mislead. Ask for feedback people having trouble using technology, older people, your grandparents; reach out to organisations for people with disabilities. I bet they can't wait to help with feedback.

Thank you for reading, and keep caring!