Accessibility
See original GitHub issueKeeping accessibility in mind
As we are creating a new application that brings together a variety of people without a paywall cough Wework cough, we need to keep accessibility in mind. Having the application being at least AA WCAG 2.1 compliant would ensure we can at least reach users with some level of visual or physical impairment. By adding minimal tweaks here and there, we can reach more by removing barriers to the platform, hence “accessibility”.
Accessibility is the law now - Quincy Larson
Since FCC is not owned or used federally, we can skip Section 508 but I added it below for reference if anyone is interested in seeing where it all started. If anyone has additional ideas on implementation or other helpful comments, please do share and feel free to make changes as needed.
A Practical Approach
Web Accessibility does not get enough coverage in CS or Web Dev courses, but it makes a huge difference for a lot of users online. - Roman Mikhailov
- Color Contrast: Run your color palette through Toolness Accessible Color Matrix or Web Aim Color Contrast Checker. You’ll learn that white text on a yellow background won’t cut it.
- Use Semantic markup: use HTML5 tags as they were intended (not using
<h1>
for it’s size or<div>
where<section>
,<article>
or<footer>
would be appropiate), use CSS for the rest - Screen readers: Use an actual screen reader like NVDA for Windows or VoiceOver for Mac alongside ChromeLens to mimic the experience of a person with visual impairments and see if you can still find what you need
- Aria Labels, tooltips, titles, and alt properties: making sure important content is not lost if images don’t load, ensure the form input fields have proper aria roles, and let users know that a dialog box or modal has been opened and how to close it
- Navigable Forms: For keyboard-heavy/only users, forms should follow a logical tab order and should display appropriate feedback if values are missing or entered incorrectly.
- Skip to Content button: avoids the user having to listen to every dropdown option in the navigation when using a screen reader
- Zoom: Some users need to enlarge content, make sure things don’t fall to pieces when they do
- CPU Throttling: One mistake devs often make is developing Frontend heavy sites on super fast computers, completely oblivious to the fact that their site is hanging on entry level laptops. Use chrome to throttle cpu and test performance. - @wellpaidgeek
- Font size: 16px is the web standard. Let’s save the light grey 10px font on a white background for things we intentionally don’t want users to see
Tools
a11y Quick Tests Axe Accessibility Chrome extension Function Accessibility Evaluator Toolness Accessible Color Matrix Web Aim Color Contrast Checker ChromeLens chrome extension - seeing through another’s eyes About Screen Readers: Narrator, AudioVox, NVDA, JAWS - prepare to be overwhelmed
References
Overview (with videos) Top Questions about Accessibility W3 Developing Tips Google Overview on Design and UX - specifically ARIA labels WCAG Quick Reference Quick tips using manual testing
Extra
Issue Analytics
- State:
- Created 4 years ago
- Reactions:24
- Comments:14 (8 by maintainers)
Top GitHub Comments
Moving the list of accessibility interested folks here from the #1 comment
We’ve started asking folks to update their Discord nickname to match their Github, but for earlier names you may need to search the messages to find and reach out to the Discord names. I’ll defer to this group to make those connections.
This is awesome! When we decide on a spec for this I (or someone) will add this to the docs.