Accessibility for Chromium Developers
Not everyone uses a computer the same way you do! If you're developing code for Chromium, it's important to pay attention to accessibility - making sure that all users get equal access to the product, even if they have a disability or use some alternative method to access their computer.
Accessibility includes, but is not limited to:
- Full keyboard accessibility.
- Support for large fonts and very high zoom levels.
- Support for screen readers for blind users.
- Support for magnifiers for low-vision users.
- Support for high-contrast modes for low-vision users.
- Support for voice-control software for users who cannot type.
More information on how to ensure changes to various parts of the codebase are accessible:
- Views (Windows & Chrome OS)
- HTML - also see the page on WebUI accessibility audits.
Test new features on Chrome OS with various accessibility support enabled - in particular, try it with spoken feedback enabled, which uses the ChromeVox screen reader.
- See ChromeVox on Desktop Linux for instructions on how to test ChromeVox on desktop Linux.
New features must go through accessibility review. When you create a meta bug (Type=Meta), you'll automatically get Dev-AccessibilityReview-No. Just add a comment to the bug when you believe it's ready for review or if you have any questions about what might be needed.
Google-internal: use the Chrome-Accessibility Group.
Public: the Chromium-Accessibility Group is a public list for discussion of end-user Chromium accessibility issues.
Bugs: tag it with Cr-UI-Accessibility.
For gory details of how Chromium handles web content accessibility in a multi-process browser, see Accessibility Technical Documentation.