Development best practices

Summary: Review platform-specific accessibility guidance and choose an accessible framework for development.

Platform-specific resources

Different product platforms have different tools and resources.

Web

There are many web accessibility tools at Google, including automated testing tools that can help prevent accessibility issues at various points throughout the development lifecycle.

External specifications like ARIA and guidance like WCAG are the gold-standard for web development. Internal resources like the Web Accessibility Field Guide may help developers find resources, guidance, and answers to common problems.

Android

Consult these Android accessibility resources for guidance on engineering accessible Android experiences, including platform-specific best practices, codelabs, and testing tools. Review Android's public accessibility guide for additional guidance.

iOS

Consult these iOS accessibility resources for guidance on engineering accessible iOS experiences. Apple's Human Interface Guidelines are the official guidance on building usable apps in general and accessible apps in particular.

Front-end frameworks

There are different frameworks you can use when developing your application's front end. At go/a11y-frameworks-table, you can find the most common Google front-end frameworks.

The frameworks with "Full" or "Best Effort" support efforts will have the majority of the core components supporting accessibility. Learn more about accessibility and front-end frameworks at go/a11y-frameworks.

ARIA Prototypes

Various frameworks may provide helpful, centralized components that lessen the amount of work developers need to do to achieve high-quality apps. Sometimes, there may be an accessibility issue automatically detected or manually filed against your use of one of these centralized components.

For web apps, ARIA Prototypes can provide basic implementation for common components. These implementations are framework-agnostic and focus on external specifications like ARIA and guidance like WCAG. Developers can use these bare-bones implementations to compare the element structure, attributes used, and other features against the  implementation causing an accessibility issue.

Sometimes the issue may be as simple as a missing attribute that can be provided while using the framework's centralized components. Other times, developers may need to reach out to the centralized components' owners to have a bug fixed or a use-case supported. Being able to link an ARIA prototype in the bug may help the centralized component owners address the concern more quickly and effectively.

Code reviews

Engineers should ensure that their code is accessible before sending it for review, and code reviewers should consider accessibility when reviewing. Do not ignore accessibility issues that may be surfaced during review.

Accessibility fix-it

If your team is sifting through bugs, an accessibility fix-it is an event that will help speed up the process to make your project or app accessible:

1. Create a specific plan of attack for the initial audit bug list and put a timeline on it (e.g. prioritize GAR4 bugs for Q1)
2. Establish, document, and communicate a process for tracking accessibility bugs. Baking into your existing process is the best approach
3. Establish, document, and communicate an ongoing bug triage process

To catch basic accessibility issues, developers should use an accessibility automation testing framework: Web, Android, iOS

More resources