Accessibility 101

These are the things you need to know to get started.

• The Web Accessibility Basics by Marco Zehe on Marco's Accessibility Blog
• Getting Started with Web Accessibility by Monika Piotrowicz at The Pastry Box.
• Dos and don'ts on designing for accessibility by Karwai Pun on Gov.UK. Includes posters for designing for people on the autism spectrum, people using screen readers or with low vision, people with physical or motor disabilities, [Deafness | people who are deaf or hard of hearing]], and people with dyslexia.
• Designing for Inclusivity: How and Why to Get Started by Allison Shaw at the Invision Design Blog
• Exclusive Design by Vasilis van Gemert is a thesis describing what design would be like if we designed not inclusively, but exclusively for people with disabilities. It's a long read, but covers a lot of ground about our current assumptions.

Mythbuster's Guide to Accessibility by the US Digital Service outlines myths about accessibility that affect all technologists:

• Myth: Government accessibility is harder than it is in the private sector. Reality: Accessibility is the same inside and outside the government.
• Myth: Accessibility requires very specific implementations. Reality: Content is accessible when it can be used by users with a disability, period. There are many ways to achieve this. Following a particular implementation pattern is not necessary to achieve accessibility.
• Myth: It's possible to build something that's 100% accessible. Reality: no product is perfect by any metric.
• Myth: It's easy to treat accessibility as an afterthought. Reality: Designing for accessibility from the beginning is way easier.
• Myth: Implementing accessibility can only be done by 10x Rockstar Ninja Guru A-Player Front-End Engineers. Reality: Accessibility is straightforward for mid-level developers.
• Myth: Testing can be done without consulting assistive technologies or users with disabilities. Reality: The only way to ensure that users with a disability get a comparable experience is to test with them and the tools they use.

Myth: Text-only versions of your content are accessible. Reality: "Separate but equal" accommodations are a lose-lose.

Design considerations

14 easy ways to make your website more accessible by Carl Cahill and Joss Cook cover:

1. Remember alt text
2. Consider animations carefully
3. Think about other languages (especially around line heights)
4. Keep the writing straightforward
5. Use simple colors and shapes
6. Empower the user
7. Offer multiple options
8. Offer customizations
9. Think about tab order
10. Don't forget about bots
11. Get the right line length and amount of text
12. Avoid anxiety-inducing prompts
13. Add in verifications and checks
14. Confirm the end of a user journey

It is not coincidental that these are all usability concerns as well.

Developer considerations

Common Accessibility Mistakes and How To Avoid Them by Ben Robertson outlines four of his own principles for developing accessible websites.

1. Web Design is more than graphic design
2. Be ASAP: As Semantic As Possible
3. Websites should look good naked
4. Talk to your computer (Use ARIA attributes)

It also outlines common accessibility mistakes:

• Missing page titles
• Poor heading structure
• Link text should tell where or what a user is clicking on
• Inputs missing a <label>
• CSS Grid / Flexbox: visual reordering sets a mismatch between logical ordering and visual ordering
• Missing or poor alt attributes for images
• Removing focus outlines
• Missing keyboard functionality
• Hiding things the wrong way

Paint the Picture, Not the Frame: How Browsers Provide Everything Users Need by Eric Bailey on A List Apart outlines some major browser functionality that is sometimes recreated by developers, such as a scroll-to-top pattern, scrollbar designs, scrolling, highlighting, text resizing, high-contrast themes, moving the focus, the clipboard, and browser history, that really probably shouldn't be messed with unless you're going to be incredibly thorough and consider a wide array of inclusive use cases.