What is A11Y and Who is it for?
Making your app or website accessible means making it usable for all people regardless of their limitations. Those limitations often are but aren't exclusively what we consider disabilities. Those can be grouped into roughly 4 categories:
- Visual Impairments (e.g. color-blindness, blindness)
- Motor Impairments (e.g. missing or paralyzed limbs)
- Neurological Disorders (e.g. autism, learning disabilities, epilepsy)
- Hearing Impairments (e.g. deafness, tinnitus)
According to the WHO World report on disability around 15% of the world's population deals with some sort of permanent disability. And this excludes people who have temporary or situational disabilities such as: a broken arm, lost their glasses, ...
These people actually have a legal (and moral) right to access your app/website.
Non-Default Users
There's another category of users though that fall under the accessibility umbrella that you should cater to. I call these 'Non-Default Users'. With very, very heavy sarcasm though. They are in contrast to the 'Default User' who has the following traits:
- white
- heterosexual
- cis-male
- aged between 20 and 45
- tech savvy
- are fluent in English
- have a Christian/Anglo-Saxon first and last name
- live in an English-language (or at least 'Western') country
- have the newest/fastest devices
- always have a great internet connection with unlimited data
- have 'Western' values (whatever that is...)
- right-handed
- of average height and limb size
- calm, rational and collected
This persona is generally what apps and websites coming out of silicon valley and all the other big tech hubs in the 'West' have as a target user. Technically, catering to people who aren't on the disability spectrum but don't fall into the 'default user group' isn't part of accessibility but instead 'inclusive design' but in my experience those two go hand in hand.
Why Should You Care?
Reason number one: Because it's the right thing to do.
You'd think that would be a good enough argument but unfortunately management is usually like: "If we spend all our time making our app accessible instead of launching it we will have 0 users". While I get the sentiment, getting to a base-level of accessibility is usually not a lot of effort. Accessbility doesn't mean that your app needs to function 100% the way it does for people without accessibility aids. Just that it's 'accessible' (i.e. usable).
Having your app/website not usable also leaves you at the risk of getting sued (just as Beyoncé did a while back). The fear of getting sued usually makes management listen very closely.
While there's no official guidelines on how accessible your website needs to be to not get sued there are WCAG Success Criteria that have been adopted as more or less the legal standard. The average app or website should comply with the AA level whereas certain government platforms need to comply with AAA.
Resources
Screen Readers
- Mac: VoiceOver
- Windows: Narrator, NVDA, JAWS
- iOS: VoiceOver
- Android: TalkBack
- Bonus: ChromeVox for Chrome
Documentation and Pattern Libraries
- MDN Accessibility Docs
- Google Web Fundamentals: Accessibility
- WAI ARIA Authoring Practices: Instructions on how to write accessible components
- A11Y Style Guide: Pattern library to help you build accessible components
- Inclusive Components: Another pattern library with accessible components
Browser Extensions for A11y Testing
- WAVE
- tota11y
- axe
- Accessibility Insights: Chrome and Edge only
- Pa11y: Not technically a browser extension but a command line tool
- Sa11y
Consulting Companies with Blogs
- WebAIM
- axess lab
- Simply Accessible
- Fable Tech Labs (they don't have a blog though)
- deque (the folks behind the axe browser extension)
- Intopia
- Hassell Inclusion
Other Links
- The A11Y Project: Community-driven resources about all things a11y
- A11yWeekly: Weekly newsletter about all things web accessibility
- A11y Rules: Podcast with conversations around web accessilibity
- HTMLHell: A blog about bad html code. Not necessarily built around accessibility but most of the issues have accessibility implications too
- Vox Media's Accessibility Checklist: A checklist for all stages in your product lifecycle
- Manuel Matuzovic's Blogpost on optimizing websites for Screen Readers instead of Default Users
- A11y Coffee: A small side with a short overview on web accessibility and a ton of links to other resources
- a11yresources: A huge list of web accessibility resources
- Accessibility Acceptance Criteria: Let's you build your own accessibliity checklist
- A Complete Guide To Accessible Front-End Components: As it says on the tin, a guide on how to make sure some of the most popular front-end patterns are accessible