Accessibility 101

I spent about 10-15 hours on edx's online course 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 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 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
2. Structure
3. 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!
2. 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.
2. 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.
3. 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.
2. 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.
3. 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.
4. 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!