Make your app accessible

App Maker apps should be usable by everyone, including people with disabilities. Common disabilities that affect a person's use of an app include blindness or low vision, color blindness, deafness or impaired hearing, and restricted motor skills.

When you develop apps with accessibility in mind, you improve the user experience for all users, not only for people with disabilities.

Accessible design

Accessible design includes the layout, size, color, and navigation of your app, as well as its interaction with adaptive and assistive technologies.

To enable users of all abilities to use your app successfully, use the Material Design accessibility best practices. The following table describes the main principles of accessibility considerations and design.

Accessible design best practices
Clear, adaptable layout and design Make it easy for users to use your app by using a simple, clear, uncluttered layout. In particular:
  • Elements should be clearly visible, even at high magnification.
  • To adapt the layout to different screen sizes, use responsive design.
  • Text, buttons, and other element should be sufficiently large and have high enough contrast. Color should not be the only way to convey information or distinguish content.
  • If your app has elements that fade after a timeout, don't set a timeout on elements that are required to complete a task.
  • Complete and correct markup of headers, lists, and tables. Proper markup helps adaptive technologies read your content aloud, enlarge it, change the contrast, or otherwise adapt it.
Easy-to-follow navigation
  • Navigation should have clear, short task flows.
  • Navigation should be easy to find and consistent between pages. For example, use a header template in each page that provides the same menu navigation and search box.
  • Organize page elements in a logical order.
  • Group related items under descriptive headers.
Descriptive UI element labels Provide useful, unique, and descriptive labels that explain the purpose of each interactive element to users. These labels allow screen readers to properly explain the function of a particular control to users who rely on these services.
Alternative text or descriptions for media For images or videos that don't contain information, provide alternative text that briefly describes the content.

If the image contains information that the user needs to know, such as a chart or diagram, include a description of the data.

For informative videos, add captions or provide a full-text transcript.
Sound and video control Users should be able to pause or stop, adjust the volume, and, if available, turn captions on and off.
Keyboard control Organize your app so that users can navigate and use your app with only the keyboard (usually with Tab or arrow keys).

The keyboard focus should be visible and follow an intuitive, action-focused sequence through the page. Don't lose the focus when the user closes a dialog or submits a form.

For an example, open [App Maker](https://appmaker.google.com/){:.external target="_blank"} and use only the keyboard to move around your app.
Help with errors Provide descriptive text for error messages that includes how to resolve the problem, if possible.

Let users undo important actions, or require confirmation before they can continue. For example, ask a user to confirm that they want to delete data, then continue.
Automate data collection You can use client scripts to automatically get session information, such as the user's username, email, or the date that a record is created. For example, the following script gets the user's email and saves it to the "user" field. It also gets the date and saves it to the "date" field.
record.user = Session.getActiveUser().getEmail();
record.date = new Date();

App Maker accessibility tools

App Maker enables you to design accessible apps in several ways:

  • The built-in Material Design theme meets contrast and size recommendations.
  • App Maker elements have an ariaLabel property. Use it for WAI-ARIA (Accessible Rich Internet Applications) semantics if you need to override the default screen reader behavior or add ARIA labels for custom widgets.
  • If the result of a user action isn't automatically announced by screen readers, such as the successful deletion of a table row, you can use the app.accessibility.announce() Client API function to provide text to screen readers. For details, go to Accessibility.

Customize UI descriptions with ARIA labels

Each element in an App Maker page has an ARIA label property. The ariaLabel property sets the ARIA label HTML attribute, which is used by assistive technology to communicate the purpose of the widget to a visually impaired user.

Screen readers are designed to get context and labels directly from the HTML markup. Most of the time you don't need to explicitly enter an ARIA label.

Set an ARIA label when:

  • You want to override the default name of an element, such as when you want to provide a more descriptive name for a button for screen reader users
  • You create a custom widget with action that a screen reader can't detect. For example, you create a collapsible panel with a show/hide toggle. You should provide text that describes the state of the panel and specify how the keyboard focus should navigate through, into, and away from the panel.

To set the ariaLabel property for a widget:

  1. Select the widget and go to its property editor tab.
  2. Click Other.
  3. Either enter a value for the text or bind the value:

    • To enter text, click the ariaLabel box.
    • To bind the value, click the Down arrow and select the source.

Provide text to screen readers

Screen readers announce many app UI changes, such as when a dialog, popup, or menu opens. If your app interface changes as a result of some user action, such as a table row is created or a spinner widget is opened, visually impaired users might be unaware of the change.

To let users know, you can add a script that uses the function app.accessibility.announce to tell a screen reader to make an announcement as part of the action.

For example, you might create an app with a table. To delete a record in the table, the app user clicks a button to delete a row. To make a screen reader announce that the row is gone (or not if the action doesn't work), you set the onClick action of the button to the following:

widget.datasource.deleteItem({
  success: function (record) {
    app.accessibility.announce(‘Record was deleted and removed from the table.');
    console.info('Record with ID ' + record.id + ' was deleted from the database.);
  },
  failure: function (error) {
    app.accessibility.announce("The record wasn't deleted. Please try again");
    console.info('Record with ID ' + record.id + ' couldn't be deleted.');
  }
});

This sample uses asynchronous callback functions to alert the user to the success or failure of the action.